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

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

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

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

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 20., pótlási lehetőség: december 4. 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

Követelményrendszer nappali tagozaton2
Egyéb Ha egy csoport minden tagja minden konzultáción jelen van, akkor a csoport minden tagja 5 pontot kap. 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

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

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

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

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

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

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

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

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

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

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 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

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

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

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

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

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

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 é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

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

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.

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

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

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

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

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

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

Tevékenységháló Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése 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. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

Tevékenység (Gantt) diagram
Forrás: Ian Sommerville: Szoftverrendszerek fejlesztése 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. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Gantt diagram – MS Project 2013

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

Munkacsoport szintű felelősségi mátrix
A felelősségi mátrixot megadhatjuk csoportok szintjén (ha vannak munkacsoportok) vagy egyének szintjén. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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ások 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

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

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

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

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

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

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

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

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

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

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

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.

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

2. A kockázat elemzése Valószínűség: nagyon kicsi (<10%), kicsi (10-25%), mérsékelt (25-50%), magas (50-75%) vagy nagyon magas (>75%); A kockázat hatása: nem jelentős, elviselhető, súlyos vagy 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

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

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

2. előadás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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 A kockázatelemzéshez kapcsolódik a mai előadás első témaköre a SWOT elemzés. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

SWOT elemzés (vállalati példa)

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

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

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

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

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

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

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

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

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

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

Diagram Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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 végre, a vállalati kultúrára. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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 20000) 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

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 vagy állapotgép diagrammal vagy állapotátmenet mátrixxal lehet leírni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

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

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

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

Szoftverfolyamat modellek
Vízesés Boehm féle spirál Inkrementális (evolúciós) Újrafelhasználás orientált (komponens alapú) V ISO/IEC (1995, 2008) Objektum orientált módszerek Agilis módszerek 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

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:

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

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

Spirál Modell Prototípus 3 Elemzés Igények és Célok Prototípus 2
Megvalósítás Tervezés

Spirál modell megvalósíthatóság a rendszer követelményeinek meghatározása rendszertervezés, stb. Ábra forrása: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

Inkrementális (evolúciós)
Dr. Johanyák Zs. Csaba - Szoftvertechnológia Ábra forrása: Ficsor Lajos:

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

Ú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

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

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:

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

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

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

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

Objektum orientált szoftverfejlesztési módszertanok

Objektum orientált szoftverfejlesztési módszertanok
OMT Booch RUP Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Object Modeling Technique (OMT)
Rumbaugh, Blaha, Premerlani, Eddy és Lorensen 1991 Egyszerű objektum orientált szoftverfejlesztési módszertan Jelölésrendszerének számos elemét átvették az UML-ben Alapgondolat: az OO gondolkodás közelebb áll az emberi problémamegoldáshoz, mint a korábbi próbálkozások A követelmény elemzés és tervezési fázis támogatására dolgozták ki Szekvenciális. Először a követelmény elemzés, majd a tervezés Mindegyik fázisban a kis lépések ciklikusan ismétlődnek Nem hangsúlyozza ki a tényleges implementációt, a tesztelést és a többi alaptevékenységet (fázist) Forrás: 5.2.7 Object Modeling Technique (OMT) OMT (Rumbaugh et al., 1991) was developed as an approach to software development. A fundamental assumption of OMT is that object-oriented thinking represents a more natural and intuitive way for people to reason about reality (ibid.:21), although this claim has been severely questioned, e.g. by Høydalsvik and Sindre, 1993; and Hanseth and Monteiro, OMT is included here because Rumbaugh (1993:18) discusses enterprise modeling explicitly using OMT. OMT is also a widely popular and comprehensive approach that exemplifies the vast number of object-oriented approaches to modeling. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A modellezés célja (Rumbaugh )
A fizikai egységek tesztelése még beépítés előtt (szimuláció), Kommunikáció a megrendelővel Megjelenítés (vizualizáció) Bonyolultság csökkentése testing physical entities before building them (simulation), The purposes of modeling according to Rumbaugh et al. (1991:15) are communication with customers, visualization (alternative presentation of information), and reduction of complexity. Hence, understanding and simulation is at the core. As a general modeling approach, OMT may be used to model all types of work. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

OMT Három modell kidolgozását javasolja Objektum modell: a rendszer építőelemei  OM diagramok: objektumok és osztályok közötti statikus kapcsolatok Dinamikus modell: építőelemek közötti kölcsönhatás (események, állapotok átmenetek)  állapot diagram és esemény folyam diagram Funkcionális modell: a rendszer eljárásai adatfolyam/áramlás szempontból  adatfolyam diagramok OMT proposes three main types of models: Object model The object model represents the static and most stable phenomena in the modeled domain (Rumbaugh et al.,1991:21). Main concepts are classes and associations, with attributes and operations. Aggregation and generalization (with multiple inheritance) are predefined relationships. Dynamic model The dynamic model represents a state/transition view on the model. Main concepts are states, transitions between states, and events to trigger transitions. Actions can be modeled as occurring within states. Generalization and aggregation (concurrency) are predefined relationships. Functional model The functional model handles the process perspective of the model, corresponding roughly to data flow diagrams. Main concepts are process, data store, data flow, and actors. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Objektum diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

OMT fázisai Elemzés - feladatmeghatározás (célok és alapkoncepciók felsorolása is) Rendszertervezés fázis A rendszer felépítése (architektúra) Alrendszerek meghatározása Alrendszerek folyamatokhoz rendelése figyelembe véve a párhuzamos végrehajtást és együttműködést Perzistens adattárolás (adatbázis) Megosztott – globális információ kezelése, Határesetek vizsgálata, prioritások meghatározása Objektum tervezés fázis Implementációs terv elkészítése Osztályok és algoritmusok definiálása Adattárolás optimalizálás Öröklődés, asszociáció, aggregáció, alapértelmezett értékek vizsgálata Szoftver implementálás Perzisztens=tartós The entire OMT software development process has four phases: Analysis, system design, object design, and implementation of the software. Most of the modeling is performed in the analysis phase. The recommended method incorporates the following activities (Rumbaugh et al., 1991:261ff): Develop a Problem Statement. Build an Object Model: Identify object classes. Develop a data dictionary for classes, attributes, and associations. Add associations between classes. Add attributes for objects and links. Organize and simplify object classes using inheritance. Test access paths using scenarios and iterate the above steps as necessary. Group classes into modules, based on close coupling and related function. Build a Dynamic Model: Prepare scenarios of typical interaction sequences. Identify events between objects and prepare an event trace for each scenario. Prepare an event flow diagram for the system. Develop a state diagram for each class that has important dynamic behavior. Check for consistency and completeness of events shared among the state diagrams. Build a Functional Model: Identify input and output values. Use data flow diagrams as needed to show functional dependencies. Describe what each function does. Identify constraints. Specify optimization criteria. Verify, iterate, and refine the three models: Add most important operations to the object model. Verify that classes, associations, attributes and operations are consistent and complete, check with problem statement. Iterate steps to complete the analysis. A remark concerning the method is that it exclusively refers to activities using concepts from the modeling language, i.e., classes, attributes, etc. Hence, the focus is on the representation of enterprise models. Worldview is not discussed explicitly, but OMT seems to have an objectivistic foundation. This was also concluded by Krogstie (1995:126). One indication can be found when looking at the method above: There is no support for the sense-making part of modeling, the focus is on representation. Another indication is the lack of discussion of modeling as a social and creative activity: The references to social actors typically concern the modeler obtaining a problem statement from the requestor or a domain expert (Rumbaugh et al., 1991:150) or checking his model with the requestor or the domain expert (ibid.:186). There are no indications of seeing reality as socially constructed. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Booch módszertan Grady Booch A grafikus jelölésrendszer egy része bekerült az UML-be Az követelmény elemzési és a tervezési fázist fedi le Négy modellt dolgoz ki a feladatról Logikai modell (az osztályok és objektumok) Fizikai modell Statikus modell Dinamikus modell A modellek dokumentálására használt diagramok Osztály, objektum, modul, Állapot, kölcsönhatás, folyamat További információ: Grady Booch: Object-Oriented Analysis and Design. With Applications, 2nd edition, Addison-Wesley Longman, ISBN , 1994 A két fő fázist szekvenciálisan hajtja végre. Nem foglalkozik elég részletesen az implementációval és a teszteléssel. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Booch osztálydiagram A jobb oldalon az osztálydiagram számára használható kétfajta jelölésmódot láthatjuk. A felső az eredeti, az alsó a Rumbaugh féle jelölés átvétele. A fejlesztés előrehaladásával az osztálydiagram különböző részletezettségi (kidolgozottsági) szinteken jelenik meg. Forrás: Grady Booch: Object-Oriented Analysis and Design. With Applications, 2nd edition, Addison-Wesley Longman, ISBN , 1994 Forrás: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Osztálydiagram példa Forrás: Grady Booch: Object-Oriented Analysis and Design. With Applications, 2nd edition, Addison-Wesley Longman, ISBN , 1994 Hidrokultúrás kertészeti rendszer Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Booch objektum diagram
A vízszintes vonal, és az attribútumok megjelenítése opcionális. Az objektumok mellett megjelennek az üzenetek (metódushívások is). Forrás: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Booch modul diagram Dr. Johanyák Zs. Csaba - Szoftvertechn. - 2009
Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás:

Booch állapot átmenet diagram
Dr. Johanyák Zs. Csaba - Szoftvertechnológia Object-Oriented Systems Development Bahrami © Irwin/ McGraw-Hill 116

Booch - Fázisok Követetelmény-elemzés (analízis) – ciklikusan ismétli a három részfeladatot Követelmények a megrendelő szempontjából (a rendszer feladatainak és struktúrájának magasszintű leírása) Domain elemzés (osztályok attribútumok, öröklődés, metódusok + állapot diagramok az objektumokhoz) Validálás Tervezés (design) – ciklikusan ismétli a részfeladatokat Logikai tervezés Fizikai tervezés (Végrehajtási szálak, folyamatok, teljesítmény, adattípusok, adattstruktúrák) Prototípus létrehozása és tesztelése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. előadás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

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

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

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

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

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:

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

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

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

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

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

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

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

Másodfokú egyenlet megoldása

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

Tevékenység diagram aktorok szerinti partícióval

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

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

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

Á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

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

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

Diszjunkt alállapotok

Á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

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

Á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

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

Á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

Diszjunkt alállapotok

Emlékező vagy történeti állapot

Állapotátmenetek

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

Á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

Állapotgép - párátlanító

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

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

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

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

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

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

Ö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

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

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

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

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

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

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

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

Osztálydiagram példa

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

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

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

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

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

Objektum diagram Objektumdiagram A rendszerben egy adott időpillanatban szereplő objektumok pillanatképét jeleníti meg. Itt az osztályokat példányosítjuk, ezek a példányok lesznek az objektumok. Az első példa objektum a hallgató osztály Péter nevű „példánya”. A másik példa egy név nélküli, árucikk típusú objektumot mutat be, amit az attribútumai értékeivel jellemzünk. (Kód, név és ár attribútumai vannak.) Az osztály és az objektumdiagram kapcsolata Az első rajz az osztálydiagram, ahol egy-sok típusú asszociációs kapcsolatban van a classA és a classB osztály. Ebből a második rajzon látható objektumdiagram készülhet, ahol az „a” nevű classA típusú objektum van összekapcsolva egy név nélküli, classB típusú multiobjektummal. Ami az osztálydiagramon reláció (itt a példában az asszociáció), azt az objektumdiagramon összekapcsolásnak nevezzük. Az objektumdiagram az osztálydiagram relációjának számosságát is mutatja, hiszen az „a” objektum „sok” (1..*) classB típusú objektummal van összekapcsolva. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Sokszög Az osztálydiagram sokszög és pont osztályát egy tartalmazás reláció köti össze. A reláció számossága 3..* vagyis egy sokszöghöz legalább 3 pont kell. Az {ordered} egy megszorítás, azt jelenti, hogy a pontok sorrendje fontos, nem cserélhetők fel. Az osztálydiagram mellett látható egy S nevű négyszög. A négyszög által meghatározott objektumdiagramot jelenik meg az aló ábrában. Az {ordered} megszorítást az objektumdiagramban a tartalmazás relációk pont felőli végére írt szerepkör (első, második, harmadik, negyedik) helyettesíti. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Kölcsönhatási diagramok
Sorrend diagram – kevés résztvevő sok üzenettel Kommunikációs diagram – sok résztvevő kevés üzenettel Időzítés diagram – kevés résztvevő, komplex időbeli egymásra hatás A sorrend diagram üzenetváltásokat ábrázol, amelyek több, kölcsönhatásban lévő partner között zajlanak le. A partnerek lehetnek osztályok, aktorok, komponensek, csatlakozók és csomópontok. Akkor érdemes használni, ha kevés résztvevő (partner) van, de azok sok üzenetet küldenek. A kommunikációs diagram szintén erre szolgál, de őt akkor érdemes választani, ha sok résztvevő van és azok viszonylag kevés üzenetet küldenek egymásnak. Az időzítés diagram akkor megfelelő, ha a résztvevők állapotainak komplex időbeli egymásra hatását akarjuk szemléltetni. Ez is csak kevés résztvevő esetén praktikus. A kölcsönhatás áttekintő diagram kicsit kilóg a sorból, mivel ő a fenti három fajta módon megrajzolt (de ugyanarra a rendszerre vonatkozó) diagramok között fennálló összefüggéseket a tevékenységdiagramok vizuális eszközeivel fejezi ki. Ő valóban egy áttekintést nyújt. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Sorrend diagram Üzenetváltásokat ábrázol, amelyek több, kölcsönhatásban lévő partner között zajlanak le A partnerek lehetnek osztályok, aktorok, komponensek, csatlakozók és csomópontok. Akkor érdemes használni, ha kevés résztvevő (partner) van, de azok sok üzenetet küldenek. Az életvonalon látható üres téglalapot aktivációs résznek nevezzük, ilyenkor csinálhat valamit az adott szereplő. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Sorrend diagram A függőleges szaggatott vonalat életvonalnak nevezzük. Minden objektum vagy aktor, aki vagy ami részt vesz az üzenetküldésben rendelkezik egy ilyen életvonallal. Az életvonalon látható üres téglalapot aktivációs résznek nevezzük, ilyenkor csinálhat valamit az adott szereplő. Egyik objektum létrehozhatja vagy megszüntetheti a másikat: (A megszűnő B objektum életvonala végén egy keresztet látunk, ez a megszűnés rajzjele.) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Sorrend diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Sorrend diagram

Kommunikációs diagram
ha sok résztvevő van és azok viszonylag kevés üzenetet küldenek egymásnak. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Kommunikációs diagram

Időzítés diagram kevés résztvevő, komplex időbeli egymásra hatás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Kölcsönhatás áttekintő diagram
A kölcsönhatás áttekintő diagram kicsit kilóg a sorból, mivel ő az előző három fajta módon megrajzolt (de ugyanarra a rendszerre vonatkozó) diagramok között fennálló összefüggéseket a tevékenységdiagramok vizuális eszközeivel fejezi ki. Ő valóban egy áttekintést nyújt. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Olyan, mintha egy tevékenységdiagramot rajzolnánk (kezdőpont, végpontok, elágazás, stb.), de a tevékenységek helyett ref-ek állnak (referenciák). A referenciák általában egy sorrenddiagramra vonatkoznak, amit már részletesen megrajzoltunk. A példában mindkét ref mögött létezik egy-egy ugyanilyen nevű sorrenddiagram, ami megmutatja a bejelentkezés és a felhasználó megrendeléseinek a részleteit. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Üzenettípusok Az első háromfajta kölcsönhatási diagramban egyaránt a következő háromfajta üzenettípust használjuk. Kérés: Szinkron üzenet. Kérés alkalmával a küldő szünetelteti aktivitását (vár) és a fogadó aktiválása következik be. (pl. telefonálás) Válasz: Szinkron üzenet. A kérést küldő a válaszüzenet hatására újra aktiválódik. Szignál: Aszinkron üzenet, vagyis a küldő nem szünetelteti az aktivitását az üzenet elküldése után, hanem tovább dolgozik. (pl. levélküldés) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Kérés, válasz és szignál

Komplex interakció Az első háromfajta kölcsönhatási diagramban szerepelhetnek. Folyamatok egész halmazát reprezentálhatják, amelyeket az interakciós operátorok kötnek össze. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Interakciós operátorok
strict operátor – szigorú sorrend ref operátor – névvel hivatkozik más interakciókra opt operátor – opcionális alt operátor – alternatívák (választási lehetőség) brk operátor - megszakítás seq operátor – sorrend, de nem szigorú sorrend, mint a strict-nél loop operátor – ciklus, ismétlés par operátor – párhuzamosság … (vannak még továbbiak) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Interakciós operátorok

Implementálás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Implementálás A technológiai részletek kidolgozása, a tényleges kód előállítása Komponens tervezés, adatszerkezet tervezés Felhasználói interakció megtervezése, felülettervek Integrálás (modulok összekapcsolása). Dokumentáció: objektum d., csomag d., komponens d. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Csomag diagram Az UML-elemek csoportosítására, közös névtérben való elhelyezésére alkalmas Tartalmazhat további csomagot Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Csomag láthatóság és útvonal megadás
Public (default) – más névtérből is látható, private Teljes minősített név egymásba ágyazásnál: gyökércsomag_neve::csomag_neve::elemnév Relatív útvonal <<import>>-al Az ábra Utasnyilvántartó csomagja importálja a személy osztályt (publikus/public – ezért van előtte a plusz jel) az Adatbázis csomagból, és egyúttal utasnak nevezi át a saját névterében. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Csomag beolvasztás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Csomagok közötti kapcsolatok
<<import>> a csomag összes elemét vagy egy elemet láthatóvá tesz a másik csomag számára <<access>> privát import, ez az elem nem importálható tovább újabb csomagokba <<merge>> összeolvasztás, a csomagimportálás egy fajtája, a beolvasztott része lesz a beolvasztónak Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Összetevő (komponens) diagram

Komponens Komponens: a rendszer fizikailag létező és kicserélhető része, feltéve, hogy az új komponens csatlakozási felülete (interfésze) megegyezik a régivel. Az osztály és a komponens fogalma nagyon hasonló az UML-ben Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Interfész Van nyújtott (szolgáltatott) interfész (kör a jele) Van elvárt (required) interfész (félkör a jele) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Összetevő diagram Komponens: a rendszer fizikailag létező és kicserélhető része, feltéve, hogy az új komponens csatlakozási felülete (interfésze) megegyezik a régivel. A komponens nagysága változó lehet, az egy-két osztályt tartalmazó kis méretű komponenstől az egész alrendszert tartalmazó nagy méretűig. (A komponens lehet egy EJB vagy Corba komponens is.) A komponens egy egységbezárt, önálló, teljes és ezáltal cserélhető egység, amely függetlenül működtethető, telepíthető és összekapcsolható más komponensekkel. Az osztály és a komponens fogalma nagyon hasonló az UML-ben, már csak azért is, mert a komponens az UML-metamodellben (metamodell – ami leírja a modell és a benne található diagramok kapcsolatát és jelentését) osztályok egy alosztálya, tehát rendelkezik az osztályok összes jellemzőjével. Egy példa komponensdiagramra: A komponenseket vagy az ábrán a téglalapok jobb felső sarkában látható rajzjellel vagy a <<component>> sztereotípiával lehet megjelölni. A komponens rendelkezhet elvárt interfésszel (itt az Order (Rendelés) komponens rendelkezik három elvárt interfésszel), illetve nyújtott interfésszel (a gömb; az Account (Számla), a Customer (Vásárló) és a Product (Termék) komponensek rendelkeznek vele). Az interfészeket csatlakozóba (Port) foghatjuk össze (a rajzjele egy kis téglalap). Egy csatlakozó a komponens összes interakcióját összefogja, a nyújtott és az elvárt interfészeket, sőt ezek használati protokollját is. Egy bonyolult csatlakozót akár állapotautomataként (State Machine) is fel tudunk majd rajzolni (amikor megismerkedünk az állapotautomatákkal). A következő két ábra ugyanazt jelenti. A kilens és a szerver nevű komponensek egy-egy összeillő nyújtott és elvárt interfésszel rendelkeznek. A második ábra ezt egyszerűbben mutatja be, az interfészeket és a kapcsolatukat egy összekötő (Connector) helyettesíti. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Interfészek összefogása csatlakozóba (portba)

Kialakítási diagram A kész fizikai rendszer (szoftver- és hardverkomponensek) felépítését mutatja be ez a diagramfajta. Kétféle megközelítés létezik, az első szerint a rendszerstruktúrát hangsúlyozzunk: itt csomópontok (Node) vannak (a téglatest a rajzjele), amik között asszociációs kapcsolatok lehetnek. A <<device>> sztereotípiával ellátott csomópont egy fizikai eszközt jelent. A csomópontok neveit konkrétabban is megadhatjuk, pl.: bsza5 : beszállóautomata. Ebben az esetben az aláhúzás a csomópont példányosítását jelenti, ahogy az osztályokból konkrét objektumokat hoztunk létre, itt is hasonló dologról van szó. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Kihelyezési/telepítési diagram
A második megközelítés szerint a szoftverösszetevők rendszerre való kihelyezését hangsúlyozzunk, ilyenkor a telepítés részletei a lényegesek. Ehhez a fajta kialakítási diagramhoz szükség van a műtermék (Artifact) fogalmára. Műtermék (Artifact): az információ egy fizikai darabja, pl.: állományok, a futási idejű adatszerkezetek a memóriában, az adatbázistáblák, ek, dokumentumok, stb. Ezek a műtermékek helyezhetők ki a csomópontokra. Az ábrán az alkalmazásszerver csomópontra két műterméket helyeztünk ki, egy weboldal típusút és egy dokumentum típusút. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Adatbázisok modellezése
Ismétlés és kiegészítés a tervezés témakörhöz Szoftvertechnológia Adatbázisok modellezése Ebben a szakaszban az a cél, hogy a projektfeladathoz szükséges adatbázis tervezési kérdéseket nagy vonalakban átismételjük. Az alábbiak lesznek a főbb témakörök Szemantikai modell Relációs modell Normalizálás Entity Framework modell Dr. Johanyák Zs. Csaba - Szoftvertechnológia

ER modell Forrás: Az egyed-kapcsolat modell egy magas szintű, szemantikai (logikai) adatmodell, amely egyedtípusokból, a köztük lévő kapcsolatokból, és az egyes egyedtípusokhoz tartozó attribútumokból épül fel. Itt már meghatározhatunk ún. kulcs attribútumokat (aláhúzott név). Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Relációs modell Ábra: Forrás: A relációs modell elkészítésének lépései: Kiinduló relációk elkészítése az ER modellből a leképezési szabályok segítségével Normalizálási folyamat 1NF->2NF->3NF Konszolidáció Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Leképezési szabályok Egyedtípus → reláció Összetett attribútumok → komponensekre bontás → reláció Kulcsattr. → elsődleges kulcs N:M kapcsolat → kapcsolat reláció A relációs modellt az ER modellből az ún. leképezési szabályokkal képezzük. A dia csak néhány fontosabb szabályt emel ki! A relációs (koncepcionális) modellben végső formáját normalizálás útján nyerjük. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Kiinduló relációk Forrás: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Normálformák A táblázat minden cellájában csak egy attribútum érték szerepel (1NF) Minden nem kulcs (másodlagos) attribútum funkcionálisan teljesen függ minden kulcstól (2NF) Nincs olyan másodlagos attribútum, ami tranzitívan függne valamilyen kulcstól Normalizálás 1NF-re: sorok ismétlésével vagy reláció felbontásával 2NF-re: reláció felbontása (ha egy attr. csak egy részkulcstól függ, akkor a részkulcssal együtt külön táblázatba tesszük) 3NF-re: a tranzitív függőségeket külön táblázatba tesszük Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Entity Framework Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Entity Framework modell kialakítása
Id Egyedtípus → entitás Összetett attribútumok → komponensekre bontás → entitás Kulcsattr. → elsődleges kulcs (Entity key) N:M kapcsolat → kapcsolat Automatikusan keletkező navigációs tulajdonságok A leképzési szabályok hasonlóak a relációshoz. Az Id numerikus azonosító automatikusan keletkezik. A kapcsolatot majd a keretrendszer alakítja automatikusan kapcsoló táblává. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Implementálás - folytatás
Szoftvertechnológia Implementálás - folytatás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Prototípus A szoftverrendszer kezdeti verziója, amelyet arra használnak, hogy bemutassák a koncepciókat kipróbálják a tervezési opciókat jobban megismerjék a problémát és annak lehetséges megoldásait Támogatott tevékenységek a követelménytervezési folyamatban követelmények feltárása követelmények validálása Felhasználható Felhasználók képzésére Rendszer tesztelésére Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A prototípus készítés előnyei
A funkciók bemutatásakor azonosítani lehet a szoftverfejlesztők és a felhasználók közötti félreértéseket A szoftverfejlesztésen dolgozók hiányos és/vagy ellentmondásos követelményekre akadhatnak Hamar a rendelkezésünkre áll egy működő rendszer, így demonstrálhatjuk a vezetőségnek az alkalmazás megvalósíthatóságát és hasznosságát A prototípus felhasználható a valódi rendszer specifikációjának megírásakor A rendszer jobban használható lesz A rendszer jobban illeszkedik a felhasználói igényekhez Jobb a tervezés minősége Jobb a rendszer karbantarthatósága Kevesebb erőfeszítés szükséges a fejlesztéshez Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Prototípus típusai Evolúciós prototípus - készítésének célja egy működő rendszer átadása a végfelhasználóknak Eldobható prototípus - készítésének célja a rendszerkövetelmények validálása vagy származtatása. Forrás: Szabolcsi Judit Szoftvertechnológia Az evolúciós prototípus készítésének célja egy működő rendszer átadása a végfelhasználóknak. Ezért a legjobban megértett és leginkább előtérbe helyezett követelményekkel javallott kezdeni. A kevésbé fontos és körvonalazatlanabb követelmények akkor kerülnek megvalósításra, amikor a felhasználók kérik. Ez a módszer a weblapfejlesztés és az e-kereskedelmi alkalmazások szokásos technikája. Az eldobható prototípus készítésének célja a rendszerkövetelmények validálása vagy származtatása. A nem jól megértett követelményekkel érdemes kezdeni, mivel azokról szeretnénk többet megtudni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Gyors prototípus készítési technikák
Magas szintű nyelvek (3GL, 4GL) Komponensek és alkalmazások összeépítése Alkalmazási szinten Komponens szinten Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Programozási nyelvek 1. generációs: gépi szintű nyelv/utasítások, kapcsolókkal vitték be Kép forrása Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Programozási nyelvek 2. generációs (2GL): assembly nyelvek – van logikai struktúra, lassú fejlesztés 3. generációs (3GL): magasszintű nyelvek, strukturált programozás támogatása, kényelmi funkciók, nem kell a programozó kidolgozzon minden egyes részletet pl. C, C++, C#, Java, BASIC and Delphi gyorsabb fejlesztés, de sok hibalehetőség Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Programozási nyelvek 4. generációs(4GL): kereskedelmi/üzleti célú szoftverek fejlesztéséhez, magasabb absztrakciós szint még gyorsabb fejlesztés kevesebb hibával, cél a fejlesztési költségek csökkentése PowerBuilder, jelentés generáló rendszerek, form generáló rendszerek, adatfeldolgozó rendszerek: SAS, SPSS Pl: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Programozási nyelvek 5 GL: mesterséges intelligencia nyelvek, feladatmegoldás a korlátok/kényszerek megadásával, logikai nyelvek - ? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Az objektum-orientált tervezés néhány kérdése
Mik az objektumok? Alapelvek: egységbezárás, öröklődés, többrétűség, adatrejtés Vezérlés – szolgáltatáskérés Szinkron kommunikáció Aszinkron kommunikáció Ütemezés – szabályozott megosztott hozzáférés erőforráshoz Nem preemptív – pl. szemaforok Preemptív Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Az objektum-orientált tervezés néhány kérdése
Objektum belső állapota Objektumok élettartama Perzisztens objektumok: élettartamuk hosszabb mint a program futási ideje Tranziens objektumok Nagyszámú perzisztens objektum  adatbáziskezelő rendszer alkalmazása RDB ha sok objektum, de kevés osztály OODB A megvalósítandó objektum belső állapotát az attribútumainak pillanatnyi értéke határozza meg. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

Hasonló előadás

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

Hasonló előadás

Projectumról

Visszajelzés

Bejelentkezés

A társadalmi hálózaton keresztül belépni:

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

Hasonló előadás

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

Hasonló előadás

Projectumról

Visszajelzés