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

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

Dr. Johanyák Zs. Csaba - Szoftvertechnológia - 2015
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 26., pótlási lehetőség: december 10. Megszerezhető pontszám: 40 Kötelező minimum: 21 Projektfeladat Első konzultáció: megszerezhető pontszám: 5, kötelező minimum nincs Második konzultáció: megszerezhető pontszám: 5, kötelező minimum nincs Végső bemutatás: megszerezhető pontszám: 50, kötelező minimum: 25 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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 Idő Erőforrás Minőség A projekt végrehajtása során fontos követelmény az idő- és erőforrásigény (költségigény) csökkentése a legjobb minőség biztosítása mellett. Ezt a három jellemzőt a projekt három dimenziójának is nevezik. Gyakran kompromisszumot kell kötni, mert mindhárom elvárás egyszerre igen ritkán biztosítható. Tipikus problémák Nem készül el határidőre Tervezettnél nagyobb költségek Nem felel meg a követelményeknek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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 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. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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 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 (7) Alkalmazott szempontjából 20 perc K (8) Alkalmazott hitelesítés 1 perc (9) Hitelesítés létrejövetele 0 perc 8 (10) Kiválasztott könyv rögzítése 5 perc 4, 8 (11) Vevő adatainak bevitele (ha számlát kér) (12) Könyv kifizetése 2 perc Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

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

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

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

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

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

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

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 Költség Most BCWS ACWP CV SV BCWP Idő
Forrás: Langer Tamás: Projektmenedzsment a szoftverfejlesztésben

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

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 Elemzés Prototípus 3 Igények és Célok Prototípus 2 Prototípus 1 Megvalósítás Tervezés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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)
Analízis Specifiká-ció Tervezés Specifiká-ció Implemen-táció Tervezés Specifiká-ció Tesztelés Implemen-táció Tervezés Tesztelés Implemen-táció Tesztelés Implemen-táció Ábra forrása: Ficsor Lajos:

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

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

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ó

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

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 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

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

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

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

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 239

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

Egységesített eljárás – Rational Unified Process
A három legelterjedtebb szoftverfejlesztési módszer egységesítésével jött létre 1997-ben (OMT + Booch + OOSE) Rational Unified Process (RUP) IBM Világszerte elterjedt fejlesztési módszertan Nagyon sok előző módszertanból merít Keret módszertan -> testre kell szabni Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Főbb jellemzői Használati eset vezérelt (use case driven) A rendszer fejlesztésének elején meghatározott használati esetek végigkísérik a teljes fejlesztést Architektúra központú (architecture centric) A teljes fejlesztést meghatározza a rendszer architektúrája Iteratív és inkrementális (növekvő) Az egyes iterációk során a rendszer újabb verzióit fejlesztjük, készítjük el. Az egyes iterációk munkafolyamatokból állnak Használatieset-vezérelt fejlesztés Azt akarjuk elkészíteni, amire a felhasználónak szüksége van. Aktor: a rendszeren kívül álló személy, vagy másik gépi rendszer, aki üzeneteket küld, illetve kap a rendszertől Használati eset: a használatnak egy értelmes, kerek egysége, kívülről írja le a rendszer viselkedését, szolgáltatásait Architektúrálisan fontos használati eset: a rendszer meghatározása, azonosítása szempontjából kulcsfontosságúak, ami a rendszer célját valósítja meg A használati esetek határozzák meg, hogy mit fejlesztünk? (rendszerhatárok, funkcionalitás) milyen sorrendbe fejlesszük? (prioritás) milyen legyen a termékünk belső szerkezete (architektúra) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Architektúra központú fejlesztés
Architektúra: strukturálisan fontos elemek és ezek kapcsolata A rendszer nagy léptékű tagolását írja elő Nehezen megváltoztatható, a rendszer egész élettartama alatt változatlan A helyes architektúra meghatározása kulcsfontosságú: ha itt hibázunk, akkor ennek a kijavítása nagyon sokba kerül A klasszikus példa: ház Alaprajz Homlokzati rajz Elektromos kábelezés és berendezések Épületgépészet, vízvezetékek, fűtés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Az architektúra célja Lehetővé teszi a bonyolultság kezelését Átláthatóvá tesz a fejlesztést Könnyebben felismerhetőek az újrafelhasználható elemek Átlátható projekt menedzsment Kockázatok csökkentése Lehetővé válik a párhuzamos fejlesztés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

RUP 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 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 Ábra:

RUP – mérföldkövek - iterációk
Minden fázis vége a fejlesztés egy-egy jól meghatározott mérföldkövét (milestone) jelenti, azaz olyan pontot, ahol egy célt kell elérnünk, illetve ahol kritikus döntéseket kell meghozni. A fázisok további kisebb egységekre, iterációkra (iteration) bonthatók. Minden iteráció egy teljes, illetve részben önálló fejlesztési ciklust jelent, mivel az iteráció végén egy működő és végrehajtható alkalmazásnak kell felállnia, az iteráció végén a rendszer újabb, bővített funkcionalitású verziója készül el. Minden egyes iteráció egy-egy mini fejlesztés. Az Egységesített Eljárás iterációi tervezettek és szigorúan ellenőrzöttek. Az iterációk számát és időtartamát, az egyes iterációk feladatát és az általuk előállított termékeket, az iterációs munkafolyamatok résztvevőit előre tervezik. Az iterációk számát nem rögzíti a szabvány, fázisonként illetve fejlesztésenként eltérő számú iterációra lehet szükségünk. A hasonló iterációk összességét fázisoknak nevezzük. Hasonlóan az iterációkhoz, a fázisok is a projekt időbeli lefolyását tagolják, számuk és nevük azonban kötött. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

RUP – átlós jelleg RUP - dimenziók Dr. Johanyák Zs. Csaba - Szoftvertechnológia Ábra:

Átlós jelleg Az előkészítés fázisában a legnagyobb hangsúly a követelmények rögzítésére helyeződik, a többi tevékenység pedig jóval kisebb mértékben kap szerepet, tesztelés pedig gyakorlatilag nincs is. A későbbi iterációkban, illetve fázisokban ez a hangsúly fokozatosan áthelyeződik a technikaibb jellegű tevékenységekre. Az átadás fázisában már elsősorban tesztelés zajlik, így elemzés, tervezés és implementáció a tesztekre vonatkozóan és azok eredményeitől függően válik szükségessé, míg a követelmények összegyűjtése már nem kap szerepet. Az üzleti modellezés ugyan jellemző a ciklus elejére, de bármikor előfordulhat. Ugyanígy, elemzés, tervezés a ciklus első harmadára a jellemző, de nem kizárólagos, előfordulhat már a fejlesztés első pillanatától az utolsóig akármikor. – Ez az, ami az iteratív fejlesztés alapvetően megkülönbözteti a vízesés jellegű fejlesztéstől. Nem igaz, hogy az előkészítés egyenlő lenne az üzleti modellezéssel és a követelmények összegyűjtésével. Ezek a leghangsúlyosabb tevékenységek, mellette van elemzés, tervezés, implementálás, tesztelés is. A kidolgozás nem egyenlő az elemzéssel és a tervezéssel. Ugyan a kidolgozásra ezek a munkafolyamatok a legjellemzőbbek, de nem csak ezekből áll. Van mellette üzleti modellezés, követelmény összegyűjtés, implementáció, tesztelés is. Az építésre nagyon jellemző a részletes tervezés és az implementálás, tesztelés, de lehet benne üzleti modellezés, követelményelemzés is. És ugyanez igaz az átadásra is. Az átadás nem csak telepítés, bár az a legfontosabb tevékenysége. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A fejlesztés fázisai Előkészítés a rendszer eredeti ötletét olyan részletes elképzeléssé dolgozzuk át, mely alapján a fejlesztés tervezhető lesz, a költségei pedig megbecsülhetők; megfogalmazzuk, hogy a felhasználók milyen módon fogják használni a rendszert, itt azonosítjuk a kulcsfontosságú használati eseteket, azaz a rendszer alapvető szolgáltatásait. milyen alapvető belső szerkezetet, architektúrát alakítunk ki. Kidolgozás a „használati eseteket” részleteiben is kidolgozzuk; alaparchitektúra kialakítása (Executable Architecture Baseline); az alaparchitektúra segítségével a teljes fejlesztés folyamata ütemezhető, és a költségei is tisztázhatók. Megvalósítás a rendszer iteratív és inkrementális növelése. a teljes rendszert kifejlesztjük (tervezés, kódolás). Átadás bétaváltozatok, tesztelés, módosítás dokumentációk, egyéb kapcsolódó termékek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A fázisok erőforrás- és időigénye egy átlagos fejlesztés esetében
65% 10% 20% 5% 10% % % % Fázisok: Előkészítés Kidolgozás Megvalósítás Átadás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Idő- és erőforrásigény
A különböző jellegű fejlesztéseknél az egyes fázisok idő illetve erőforrás igénye lényegesen különbözhet. Például egy létező termék újabb verziójánál az előkészítő fázis majdnem nullára zsugorodhat, s a kidolgozási fázis is rövid lehet. Ugyanakkor egy ismeretlen szakterülten, ismeretlen eszközökkel végzett fejlesztés esetében az előkészítés igen hosszú ideig tarthat. Általános jellegzetesség, hogy az építési fázis a leghosszabb és a legnagyobb erőforrás igényű. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Idő- és erőforrásigény
Viszonylag általános jellegzetesség, hogy az előkészítő fázisnak jellemzően nagyobb az idő, mint az erőforrás igénye. Az elkészítő fázisban viszonylag kevés ember s viszonylag csekély intenzitással foglalkozik a projekttel. A megvalósítási fázisnak jellemzően nagyobb az erőforrás és arányosan kisebb az időigénye, mivel ez a fázis viszonylag jól párhuzamosítható, a már jól definiált feladatokon párhuzamosan sok fejlesztő dolgozhat Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Egy iteráció munkafolyamatai (RUP)
Üzleti modellezés (Business Modeling): a készítendő rendszer üzleti (szakterületi) környezetének vizsgálata Követelmények (Requirements): a rendszer működésével kapcsolatos kezdeti elképzelések összegyűjtése (a felhasználó szemszögéből) Elemzés (Analysis): követelményeket a fejlesztők szempontjának megfelelően rendezzük át, így azok együttessen a rendszer egy belső képét határozzák meg, mely a további fejlesztés kiindulópontja lesz. Rendszerezzük és részletezzük az összegyűjtött használati eseteket, valamint azok alapján meghatározzuk a rendszer alapstruktúráját. Tervezés (Design): az elemzés során kialakított szerkezeti váz teljessé tétele. A tervezésnek a rendszert olyan szinten kell vázolnia, melyből az közvetlenül, egyetlen kérdés és probléma felvetése nélkül implementálható. Implementáció (Implementation): forráskódok, bináris és futtatható állományok, szövegek, képek, stb. előállítása. Az állományok előállítása egyben azok függetlenül végrehajtható, önálló tesztjeit is jelenti. Teszt (Test): Megtervezzük és implementáljuk a teszteket, azok eredményeit szisztematikusan feldolgozzuk, majd hibák vagy hiányosságok esetén újabb tervezési vagy implementációs tevékenységeket hajtunk végre. Minden iteráció különböző, minden iterációt külön meg kell tervezni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Egységesített Eljárás architektúrája
Megvalósítás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Az egyes termékcsoportok eltérő növekedése
Megvalósítás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

RUP irodalom Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Agilis módszerek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Gyors szoftverfejlesztés – agilis módszerek
Lassú fejlesztési folyamatok Gyorsan változó környezet A gyors szoftverfejlesztési folyamatokat arra tervezték, hogy segítségükkel gyorsan készíthessük használható szoftvereket A szoftverrendszereknél ma a legkritikusabb követelmény a gyors fejlesztés és üzembe helyezés. A hagyományos szoftverfejlesztési folyamatok viszont túl lassúak a gyorsan változó üzleti környezethez. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Kiáltvány az agilis szoftverfejlesztéséért (2001. február)

Az agilis fejlesztés 12 alapelve1
Legfontosabbnak azt tartjuk, hogy a vevőnk elégedett legyen, mert értékes szoftvert szállítunk neki hamar és folyamatosan. Elfogadjuk, hogy a követelmények változhatnak akár a fejlesztés vége felé is. Az agilis módszertanok befogadják a változást a megrendelő versenyképességének érdekében. Gyakran szállítsunk működő szoftvert, pár hetes és hónapos időközönként, lehetőleg a rövidebb periódust választva. A megrendelők, üzleti szakemberek és a szoftverfejlesztők dolgozzanak együtt minden nap a teljes projekt során. Építsük motivált egyénekre a projekteket. Teremtsük meg nekik a számukra szükséges környezetet és támogatást, és bízzunk bennük, hogy elvégzik a munkát. A személyes beszélgetés az információ átadásának leghatásosabb és hatékonyabb módja a fejlesztő csapaton belül. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Az agilis fejlesztés 12 alapelve
Az előrehaladás elsődleges mércéje a működő szoftver. Az agilis módszertanok elősegítik a fenntartható fejlesztést. A szponzoroknak, fejlesztőknek, felhasználóknak korlátlan ideig képesnek kell lenniük az egyenletes sebesség megőrzésére. A folyamatos figyelem a technikai kiválóságra és a jó tervezésre fokozza az agilitást. Az egyszerűség – az el nem végzett munkamennyiség maximalizálásának művészete – alapvető érték. A legjobb architektúrák, követelmények és rendszertervek az önszerveződő csapatmunkából alakulnak ki. A fejlesztői csapat rendszeres időközönként megfontolja, hogyan válhatna hatékonyabbá, és ennek megfelelően változtatja viselkedését. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Általános jellemzők - alapelvek
A specifikáció, a tervezés és az implementálás párhuzamosan zajlik. Nincs részletes rendszerspecifikáció. Inkrementális fejlesztés. A végfelhasználók is részt vesznek minden lépés specifikációjában és az eredmény kiértékelésében. Indítványozhatnak változtatásokat és új követelményeket (gyakran). Felhasználói felület vizuális tervezéssel Kezelési egyszerűség: az egyszerűségre kell koncentrálni, mind a fejlesztendő szoftver, mind a fejlesztési folyamat tekintetében. Amikor csak lehet, aktívan kell dolgozni a rendszer komplexitásának (összetettségének) csökkentésén. Az ügyfél bevonása: az ügyfeleket minél jobban be kell vonni a fejlesztési folyamatba, hogy a rendszerkövetelményekről gondoskodjanak, azokat prioritizálják és kiértékeljék a rendszer minden egyes iterációját. Inkrementális átadás: a szoftver lépésenként fejlődik, az ügyfél adja meg a követelményeket, amelyeket majd az egyes lépésekben implementálni kell. Az emberek nem folyamatok: a fejlesztőcsapat képességeit ismerni kell és ki is kell használni. Hagyjuk, hogy a csapattagok a feladatokat a saját módszerükkel végezzék el, nem pedig előírt folyamatok szerint. A változtatás törvényszerű: számítani kell a rendszerkövetelmények változására, és úgy kell megtervezni a rendszert, hogy könnyű legyen a változtatások megvalósítása Kezelési egyszerűség: az egyszerűségre kell koncentrálni, mind a fejlesztendő szoftver, mind a fejlesztési folyamat tekintetében. Amikor csak lehet, aktívan dolgozni kell a rendszer komplexitásának csökkentésén. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Előnyök A szolgáltatások hamar használhatók Mivel a felhasználót bevonják a fejlesztésbe, a rendszer sokkal jobban meg fog felelni az igényeiknek és ráadásul jobban elkötelezik magukat a szoftver mellett Az inkrementális szoftverfejlesztés közel áll az emberek probléma-megoldási módjához: mivel ritkán dolgozunk ki teljes megoldásokat, hanem a megoldásainkat lépésenként továbbfejlesztjük, és visszalépünk, ha hibáztunk Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Nehézségek Nem biztos, hogy az ügyfél tud és akar is időt tölteni a fejlesztőcsapattal Személyi adottságok hiánya Gyakori áttervezés Az egyszerűség fenntartása külön munkát igényel Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Hátrányok Kezelési problémák - kevés a rendszerdokumentáció Szerződésbeli problémák - nincs rendszer-specifikáció A független validáció nehezen oldható meg A folyamatos változtatás elronthatja a rendszer struktúráját Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Alkalmazás Mikor alkalmazzák? Kis rendszerek/ kis projekt Kevés fejlesztő Alacsony kritikussági fok Gyakran változó követelmények Csak gyakorlott, szenior fejlesztők esetén Mikor nem? Nagy és elosztott rendszerek Kritikus rendszerek Hosszú élettartamú rendszerek Mikor ne alkalmazzuk az agilis megközelítést? Nagyon nagy rendszerek, ahol a fejlesztésen több, különböző helyen lévő csapat dolgozik Beágyazott rendszerek, ahol a szoftver erősen függ a hardvertől Néhány kritikus rendszer, ahol a minden követelményt elemezni kell, hogy átvizsgáljuk a rendszert olyan kölcsönhatások után kutatva, amelyek veszélyeztetik a rendszer biztonságát. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Agilis technikák eXtrém Programozás Scrum KristályTiszta és más Kristály módszertanok Dynamic Systems Development Method Feature Driven Development (Funkcionalitáson Alapuló Fejlesztés) Test Driven Development (Tesztelésen Alapuló Fejlesztés) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

eXtrém Programozás Minden követelmény forgatókönyv (felhasználói történet) Ez feladatokra bontható és egy-egy feladat önállóan implementálható A programozók változó párokban dolgoznak, és minden feladatra teszteket készítenek mielőtt még a kódot megírnák Minden tesztnek sikeresen le kell futnia, mielőtt az új kódot elhelyeznék a rendszerben A rendszer kiadásai között csak kis idő telik el (pl. 1 hét) Folyamatos tökéletesítés (a kódot át kell írni, átszervezni, hatékonyabbá tenni, amikor csak lehet) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

XP lépések A kiadáshoz történő felhasználói történet kiválasztása A történet feladatokra bontása A kiadás tervezése A szoftver fejlesztése/integrálása/tesztelése A szoftver kiadása A rendszer értékelése Vissza  1. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Felhasználói történet
„Egy cikk letöltése és kinyomtatása Először válasszuk ki egy megjelenített listából a kívánt cikket. Aztán adjuk meg a rendszernek a fizetési módot – ez lehet előfizetéses vagy vállalati számláról történő vagy hitelkártyával. Ezután kapunk egy kitöltendő szerzői jogi űrlapot. Ha ezt elküldtük, a cikk letöltődik a számítógépünkre. Ezután választunk egy nyomtatót és kinyomtatjuk a cikk egy másolatát. Közöljük a rendszerrel a sikeres nyomtatás tényét. Ha a cikk csak nyomtatható, akkor nem őrizhetjük meg a PDF-verziót, így az automatikusan törlődik a számítógépünkről.” Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Feladatokra bontás „3. feladat: A fizetési lehetőségek implementálása A fizetés három különböző úton történhet. A felhasználó kiválasztja, hogy milyen módon szeretne fizetni. Ha a felhasználónak van könyvtári olvasójegye, akkor beírhatja ide annak azonosítóját, amit a rendszernek ellenőriznie kell. Másik lehetőség, hogy megad egy szervezeti számlaszámot. Ha az érvényes, akkor a cikknek megfelelő költséggel megterhelik a számlát. Végül beírható a 16 számjegyből álló hitelkártyaszám és lejárati dátum. Ellenőrizni kell ennek az érvényességét, és amennyiben érvényes, akkor terhelést kell küldeni a hitelkártyaszámlára.” Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Teszteset-leírás 4. teszt: Hitelkártya érvényességének ellenőrzése Bemenet: A hitelkártyaszám egy karaktersorozat, míg a kártya lejárati hónapját és évét két egész szám reprezentálja. Tesztek: Ellenőrizni kell, hogy a karaktersorozat minden bájtja számjegy-e. Ellenőrizni kell, hogy a hónap egy és 12 között van-e és az év nagyobb vagy egyenlő-e az aktuális évvel. A hitelkártya számának első négy számjegye alapján ellenőrizni kell, a kibocsátó érvényességét a kártyakibocsátók táblázata alapján. A hitelkártya érvényességét ellenőrizzük úgy, hogy elküldjük a kártyaszámot és a lejárati dátuminformációt a kártya kibocsátójához. Kimenet: OK vagy hibaüzenet, ami a kártya érvénytelenségét jelzi. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

SCRUM Források: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Scrum Hirotako Takeuchi & Ikoyiro Nonaka (1986) új, gyors termékfejlesztési módszer A Scrum elnevezés a rugby-ből ered Iteratív és inkrementális agilis szoftverfejlesztési keretrendszer Rugalmas Demokratikus, rugalmas, felelősség- és eredményközpontú, emberközpontú módszer A határidő szent és sérthetetlen Elsősorban kis csapatok 5-9 fő esetén működik jól A csapat végig együtt dolgozik Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Scrum jellemzők Szóbeli kommunikáció Gyakran önszerveződő csapat Nem fedi le a teljes termékfejlesztési életciklust, ezért gyakran együtt alkalmazzák más módszerekkel Pl. kezdeti követelményelemzés, prioritások meghatározása, kezdeti magas szintű tervezés, ütemezés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Scrum alapelvek A vevő igényei menet közben változhatnak Elfogadjuk, hogy lehet, hogy a feladatot nem tudjuk teljesen megérteni vagy definiálni Arra összpontosít a csapat, hogy a lehető leggyorsabban szállítson reagáljon az új követelményekre Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Szerepkörök1 Termékgazda (Product Owner): Termék teendőlista (Product Backlog) Biztosítja az értékteremtést Felhasználói történeteket ír és karbantartja azokat A fejlesztő csapat tagja lehet, lehet ő a projektmenedzser Fejlesztő csapat Feladata a sprint cél teljesítése A sprint végére átadható terméket kell előállítson 7±2 fő A termékgazda feladata a product backlog karbantartása. A felhasználói történetek megírása történhet a csapattal közösen. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Szerepkörök2 SrumMaster: Segíti a csapatot Elhárítja a sprintcélt veszélyeztető akadályokat Gondoskodik arról, hogy helyesen alkalmazzák a Scrum-ot Nem csapatvezető, nem lehet azonos a projekt menedzserrel Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A Scrum folyamat Termék teendőlista (Product Backlog) Sprint teendőlista (Sprint Backlog) 2-4 weeks 24h Futam (Sprint) Egy működő szoftveregység (Working increment of the software) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Termék teendőlista (Product Backlog)
Magas szintű követelmény leírások Fejlesztési célok (funkciók leírásai, kívánságok, ötletek, stb.) Prioritások Üzleti érték becslés ← Terméktulajdonos Ráfordításigény becslés ← Fejlesztők Termék teendőlista A „termék teendőlistája” ez egész termékre vonatkozóan tartalmaz magas szintű követelmény leírásokat. A lista elemei lehetnek funkciók leírásai, kívánságok, ötletek, stb., amelyek prioritás szerint vannak rendezve. Tulajdonképpen azt tartalmazza, hogy mi a fejlesztés célja. A lista szabadon szerkeszthető bárki által, és becsléseket tartalmaz a bejegyzések üzleti értékére és ráfordításigényére vonatkozóan. A becslések abban segítik a terméktulajdonost, hogy meghatározza a bejegyzések sorrendjét és bizonyos mértékig a prioritásukat. Ha például a „helyesírás-ellenőrzés” és „repülőgép-szimulátor” funkcióknak azonos az üzleti értékük, akkor a kevesebb fejlesztési ráfordítást igénylő funkció fog magasabb prioritást kapni, hiszen annak jobb a megtérülése. A termék teendőlistája a terméktulajdonos kezelése alatt áll. Az üzleti értéket a terméktulajdonos, míg a fejlesztési ráfordításigényt a fejlesztők határozzák meg. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Sprint - Futam Egy előre meghatározott időtartamú részfolyamat 1 hét … 1 hónap (ált. 2 hét) Futamtervező megbeszélés → feladatok beazonosítása → Futam teendőlistája Sprintcélok megvalósítása (fejlesztés) és napi megbeszélés A végén értékelés (sprint forduló) Futamáttekintés Visszatekintés Ez lényegében egy iterációs ciklus. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Futamtervező megbeszélés (Sprint planning)
Elvégzendő feladatok kijelölése a termék teendőlistájáról (product backlog) a terméktulajdonos közreműködésével Futam teendőlistájának előkészítése, amely a teljes csapat figyelembevételével részletezi az egyes részfeladatok időszükségleteit Annak meghatározása és kommunikálása, hogy mennyi feladat elvégzése várható el az aktuális futam során 4 hetes futam esetén maximum 8 óra hosszúságú, rövidebb futam esetén ez az esemény is rövidebb Minden futam elején futamtervező megbeszélést tartanak Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Futam teendőlistája (Sprint Backlog)
A fejlesztő csapat "vállalja be a termék teendőlistáról" A csapat kezeli Felhasználói történetek/Funkciók részfeladatokra bontva A csapattagok önkéntesen vállalnak egy-egy részfeladatot a napi megbeszélések során – prioritások és készségek alapján Követés: Scrum Task Board A futam teendőlistája olyan dokumentum, amely azt tartalmazza, hogy a csapat hogyan fogja elkészíteni a futam során megvalósítandó funkciókat. Ez egyes funkciókat részfeladatokra bontják. A felbontást célszerű úgy elvégezni, hogy egy részfeladat 4-16 óráig tartson. Ilyen szintű részletezettség mellett a csapat összes tagja pontosan érti, hogy mit kell elvégezni, és mindenki kiválaszthatja a neki legmegfelelőbb részfeladatot. A futam teendőlistájában levő részfeladatokat nem rendelik személyhez, inkább a csapattagok választják ki azokat a meghatározott prioritások, szükségletek és a csapattag képességeinek megfelelően. A futam teendőlistája a csapat kezelése alatt áll. A becsléseket a csapattagok adják meg. Gyakran előfordul, hogy feladattáblát (Task Board) használnak, amely követhető a teendők állapots („elvégzendő”, „folyamatban”, „elvégzett”, stb.) a futam során. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Scrum Task Board Forrás: A követés történhet egy szoftver segítségével is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Napi megbeszélés (Daily Scrum)
Minden nap ugyanott, ugyanakkor, max. 15 perc Minden csapattagnak válaszolni kell: Mit csináltál az előző „Daily Scrum” óta? Mit tervezel mára? Akadályozza-e valami a munkádat? Ábra: A napi megbeszélés célja, hogy a csapat tagjai összehangolják tevékenységüket. A résztvevők általában állnak a megbeszélés során (ez elősegíti, hogy a megbeszélés ne húzódjon el). A Scrum Master feljegyzi és megpróbálja elhárítani az akadályokat. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Burn down chart Naponta frissített diagram a futam állapotáról A hátralevő munka mennyisége The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burndown, for example the release burndown chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the alternative release burndown chart,[18] which basically does the same, but clearly shows scope changes to Release Content, by resetting the baseline. It should not be confused with an earned value chart. Ábra: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Futamáttekintés (Demo vagy Sprint Review)
Mely munkák készültek el és melyek nem? Az elkészült munka bemutatása a terméktulajdonos és a fejlesztésben érdekeltek részére (demo) Be nem fejezett munkát nem lehet bemutatni 4 hetes futam esetén maximum 4 óra hosszúságú, rövidebb futam esetén ez az esemény is rövidebb Sprint bemutató, elemzés (sprint review) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Visszatekintés (Sprint Retrospective)
A csapattagok véleményt alkotnak az elmúlt futamról Javaslatokat tesznek a folyamatok továbbfejlesztésére Két kérdés merül fel a megbeszélésen: Mi az, ami jól ment a futam alatt? Mi az, amit a következő futam során jobban lehetne csinálni? 4 hetes futam esetén maximum 3 óra hosszúságú, rövidebb futam esetén ez az esemény is rövidebb A vélemény lehet egy puszta benyomás is, nem kell kidolgozott, szilárd álláspontnak lennie. A javaslatok nem kell kiérleltnek lenniük, a kidolgozás nem a visszatekintés része. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Növekmény (Increment) A korábbi és a jelenlegi futam által megvalósított teendők összessége The increment is the sum of all the Product Backlog Items completed during a sprint and all previous sprints. At the end of a sprint, the Increment must be done according to the Scrum Team's definition of done. The increment must be in usable condition regardless of whether the Product Owner decides to actually release it. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Szoftverek ellenőrzése és elemzése
Szoftvertechnológia Szoftverek ellenőrzése és elemzése Szoftverellenőrzéssel kapcsolatos további irodalom: Ficsor Lajos, Dr. Kovács László, Krizsán Zoltán, Dr. Kusper Gábor: Szoftvertesztelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Verifikáció és validáció
Verifikáció: a specifikációnak való megfelelés ellenőrzése Validáció: a vevői elvárások teljesülésének ellenőrzése (pl. ide tartozhat a hatékonyság e., hibatűrés e., erőforrásigény e. is) V&V-re a teljes fejlesztési folyamat során szükség van Bonyolult rendszereknél a V&V a teljes költségek 50%-át is kiteheti. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

V modell A V&V szükségességét a teljes fejlesztési folyamat során tükrözi a V (szoftver életciklus) modell. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Ellenőrzési technikák
Statikus elemzés Szoftver átvizsgálás Automatikus elemzés Dinamikus tesztelés Hiányosság tesztelés Stressz tesztelés Komponens tesztelés Rendszer (integrációs) tesztelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Szoftver átvizsgálás Legalább 4 fős csapat: szerző, olvasó, tesztelő, moderátor Átvizsgálás ↔ Szerző módosít Tipikus hibák: adath., vezérlési h., I/O h., interfész h., tárkezelési h., kivételkezelési h. A program hibáinak több mint 60%-a felderíthető ily módon Egy menetben több független hiba is felderíthető. A ~ alapja a résztvevők szakmai tapasztalata. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Automatikus elemzés Szoftver, ami a forrásszöveget vizsgálja (nem futtat) Nem használt kódrészlet, inicializálatlan változók Tipikus hibák: adath., vezérlési h., I/O h., interfész h., tárkezelési h. Pl. LINT/Splint C; VS beépített figyelmeztetések, ReSharper Nem ismeri fel a helytelen inicializálást Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Technikák Statikus elemzés Szoftver átvizsgálás Automatikus elemzés Dinamikus tesztelés Hiányosság tesztelés Stressz tesztelés Komponens tesztelés Rendszer tesztelés Hogyan? Milyen céllal? Az ellenőrzés kezdetben kisebb egységekre összpontosít, majd a fejlesztés előrehaladtával a nagyobb egységek és végül a teljes rendszer következik. A legvégén a vevő végrehajthat egy elfogadási tesztsorozatot. Mit? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A hiányosságtesztelés folyamata
Teszteset: Input+elvárt output+ rövid leírás Minden követelményhez és rendszertulajdonsághoz legalább egy teszteset. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Hiányosság tesztelés Célok A specifikáció és a megvalósított program közötti eltérések felderítése A rendszer helytelen működésének előidézése Irányelvek Válasszunk olyan bemeneteket, amelyekkel az összes lehetséges hibaüzenetet előidézhetjük Próbáljuk meg elérni a bemeneti pufferek túlcsordulását Ugyanaz a bemenet ugyanazt a kimenetet adja mindig? Kényszerítsük ki az érvénytelen kimenetet Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Hiányosság-tesztelési módszerek
Fekete doboz tesztelés A rendszer/komponens belseje nem ismert A bemenetre adott válaszok tanulmányozása Fehér doboz tesztelés Ismert a szerkezet Kis egységekre alkalmazzák Minden független végrehajtási utat kipróbálnak (útvonal teszt) Olyan bemenet kell találni, ami rendellenes viselkedést eredményez. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Fehér doboz tesztelés Útvonalak felderítése Egyszerű esetekben folyamatgráf felrajzolása kézzel Bonyolult esetekben dinamikus programelemzővel (DPE) DPE: a fordítóval együttműködő szoftver, számolja, hogy az egyes utasítások hányszor kerültek végrehajtásra – mi maradt ki → futási profil Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Útvonalak - folyamatgráf

Stressz (teljesítmény) tesztelés
Cél A teljesítmény és a megbízhatóság tesztelése A tervezett terhelés mellett képes legyen dolgozni a rendszer Olyan hiányosságok is kiderüljenek, amelyek nem jelennek meg normál körülmények között Eljárás Addig növeljük a terhelést, amíg a rendszer teljesítménye elfogadhatatlanná nem válik Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Technikák Statikus elemzés Szoftver átvizsgálás Automatikus elemzés Dinamikus tesztelés Hiányosság tesztelés Stressz tesztelés Komponens tesztelés Rendszer tesztelés Hogyan? Milyen céllal? Mit? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Komponenstesztelés (egységteszt)
Cél a komponensekben levő hibák felderítése Általában hiányosságtesztelés Mit tesztelünk? Metódusok Osztályok Teljes komponens (több osztály) funkcionalitása Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Rendszertesztelés A komponensek integrálásával kapott egész tesztelése Szakaszok Integrációs tesztelés – fehér doboz tesztelés Cél a hiányosságok felderítése Kiadás tesztelés – fekete doboz tesztelés Jól működik-e a rendszer? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Integrációs tesztelés
Cél az együttműködésből adódó problémák felderítése Képesek-e együttműködni? Megfelelőek-e a metódushívások? Mely komponens csoportok biztosítják az egyes funkcionalitás elemeket? Leggyakoribb az inkrementális integrációs tesztelés Integráció: a rendszer felépítése komponensekből. Az integrációs tesztelés magában foglalhat regressziós tesztelést is. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Regressziós tesztelés
Minden változtatás után lefuttatjuk az összes régi unit-tesztet + az új szoftverkomponenshez tartozó teszteket. Ez biztosítja, hogy az új komponens beépítése nem okozott hibát. Forrás: Mileff Péter: Szoftverfejlesztés segédlet [Link] Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Programtervezési minták
Szoftvertechnológia Programtervezési minták Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Programtervezési minták
Design Patterns Újrahasznosítható osztályok: igazodnia kell a megoldandó problémához  eléggé általánosnak kell lennie ahhoz, hogy később könnyen módosítható legyen Típusfeladatokra bevált megoldások Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (GoF - Gang of Four) 23 minta Minta: „Egymással együttműködő objektumok és osztályok leírása, amely testreszabott formában valamilyen általános tervezési problémát old meg egy bizonyos összefüggésben.” Azonosítja a résztvevő osztályokat és objektumokat, szerepüket és kapcsolataikat Az újrahasznosítható osztályok tervezése nehéz feladat, mert két néha ellentmondó követelménynek kell megfelelni egyszerre. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Tervezési minták Singleton (Egyke) Simple Factory Adapter (Illesztő) Bridge (Híd) Composite (Összetétel) Observer (Megfigyelő) Strategy Dependency injection Template Method (Sablonfüggvény) MVC,MVP Repository Data Mapper Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Egyke - singleton A minta neve és besorolása: Egyke, objektum-létrehozási minta Cél: Egy osztályból csak egy példányt engedélyezni, és ehhez globális hozzáférési pontot megadni Egyéb nevek: Singleton Feladat: Egyes osztályok esetén fontos, hogy pontosan egy példány legyen belőlük. Egy rendszerben több nyomtató is lehet, de nyomtatási sorból csak egyet lehet használni. Vagy csak egy fájlrendszer és csak egy ablakkezelő futhat. Hogyan biztosíthatjuk, hogy egy osztályból csak egyetlen példány legyen, de azt könnyen el lehessen érni? Ha globális változót hozunk létre, akkor az objektum könnyen elérhető lesz, de akkor akárhány példányt létrehozhatunk belőle. Maga az osztály a felelős a példányok nyilvántartásáért. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Egyke Alkalmazhatóság: Pontosan egy példányra van szükség egy osztályból és annak elérhetőnek kell lennie az ügyfelek számára. Az osztály bővíthető kell legyen (leszármazott osztályok), és az ügyfelek legyenek képesek a saját kódjuk módosítása nélkül használni a bővített osztály példányát. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Egyke Szerkezet: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Egyke Résztvevők: Egyke: Meghatároz egy olyan Példány műveletet, amely lehetővé teszi, hogy az ügyfelek hozzáférjenek az osztály egyedi példányához. A Példány statikus metódus. Felelős saját egyedi példányának (objektumának) létrehozásáért. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Egyke Együttműködés: Az ügyfelek az Egyke példányt kizárólag az Egyke Példány műveletén keresztül érik el. Következmények: Az Egyke minta előnyei: Szabályozott hozzáférés az egyetlen példányhoz. Nincs globális változó. A leszármazással bővíthető az Egyke osztály funkcionalitása. Nem csak pontosan egy, hanem akárhány példány ellenőrzött létrehozására is alkalmas. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

C# megvalósítás class Egyke { private static Egyke EgyediPéldány; public static Egyke Példány() if (EgyediPéldány == null) EgyediPéldány = new Egyke(); return EgyediPéldány; } protected Egyke(){ … } … A felhasználó csak a Példány() metóduson keresztül tudja példányosítani az osztályt. A metódus létrehozza az objektumot vagy visszaadja a már létező objektum referenciáját. Csak a Példány metódus nyilvános és statikus egyszerre, minden mást az objektum referencián Keresztül lehet elérni. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Használat Egyke e=new Egyke(); Miért nem jó a fenti utasítás? A jó megoldás: Egyke e=Egyke.Példány(); Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Simple Factory Dr. Johanyák Zs. Csaba - Szoftvertechnológia

ClassicStyle public class ClassicStyle:Name { public ClassicStyle(string FullName) { string[] sa = FullName.Split(' '); LastName = sa[sa.Count() - 1]; FirstName = ""; for (int i = 0; i < sa.Count()-1; i++) { FirstName += sa[i]+" "; } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

CommaStyle public class CommaStyle:Name { public CommaStyle(string FullName) { string[] sa = FullName.Split(','); FirstName = sa[1].Trim(); LastName = sa[0].Trim(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

NameFactory public class NameFactory { public NameFactory(string FullName) { if (FullName.IndexOf(",") > -1) Name = new CommaStyle(FullName); else Name = new ClassicStyle(FullName); } public Name Name{get; set;} Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Adapter - Illesztő A cél egy olyan új osztály/objektum létrehozása, ami a korábbi osztály felhasználásával megvalósít egy elvárt új interfészt Például: a korábbi osztály rendelkezik Vezetéknév és Utónév tulajdonságokkal, de Teljesnév tulajdonsággal nem, és nekünk erre a tulajdonságra van szükségünk Megvalósítási módok Öröklődés Beágyazás Kiegészítés Bővítő metódus Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Megoldás öröklődéssel
public class Alap { public Alap(string V, string U) { Vezetéknév = V; Utónév = U; } public string Vezetéknév{ get; set; } public string Utónév { get; set; } Előfeltétel, hogy az alap osztály ne legyen sealed Dr. Johanyák Zs. Csaba - Szoftvertechnológia

public class Leszármazott:Alap { public Leszármazott(string V, string U):base(V,U){} public string Teljesnév { get { return Vezetéknév + " " + Utónév; } } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

static void Main(string[] args) { Leszármazott l = new Leszármazott("Duli", "Fuli"); Console.WriteLine(l.Teljesnév); Console.ReadLine(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Megoldás beágyazással
public class Beágyazott { Alap Alap; public string Teljesnév { get { return Alap.Vezetéknév + " " + Alap.Utónév; } } public string Vezetéknév get { return Alap.Vezetéknév; } set { Alap.Vezetéknév = value; } public string Utónév get { return Alap.Utónév; } set { Alap.Utónév = value; } public Beágyazott(string V,string U) Alap = new Alap(V,U); Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Megoldás beágyazással
static void Main(string[] args) { Beágyazott b = new Beágyazott("Zsákos", "Bilbó"); Console.WriteLine(b.Teljesnév); Console.ReadLine(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Megoldás kiegészítéssel
public partial class Alap { public Alap(string V, string U) { Vezetéknév = V; Utónév = U; } public string Vezetéknév { get; set; } public string Utónév { get; set; } Előfeltétel, hogy az alap osztály el legyen látva partial jelzővel Dr. Johanyák Zs. Csaba - Szoftvertechnológia

public partial class Alap { public string Teljesnév get return Vezetéknév + " " + Utónév; } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

static void Main(string[] args) { Alap a = new Alap("Zsákos", "Frodó"); Console.WriteLine(a.Teljesnév); Console.ReadLine(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Megoldás bővítő metódussal

public sealed class Alap { public Alap(string V, string U) { Vezetéknév = V; Utónév = U; } public string Vezetéknév { get; set; } public string Utónév { get; set; } Jól alkalmazható olyankor is, ha a származtatás tiltott. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

public static class Bővítő { public static string Teljesnév(this Alap a) return a.Vezetéknév + " " + a.Utónév; } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Bridge - Híd Egy képzeletbeli okos TV, amivel nézhetünk Kábel TV-t Műholdas adást IPTV-t A felhasználó lekérheti a műsort (Guide) és indíthatja a kiválasztott műsorforrás megtekintését Absztrakció: műsor lekérés, indítás Minden műsorforrás esetén más a megvalósítás Forrás: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Interfész interface IVideoSource { string GetTvGuide(); string PlayVideo(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Megvalósítás class LocalCabelTv : IVideoSource { const string SOURCE_NAME = "Local Cabel TV"; string IVideoSource.GetTvGuide() return string.Format("Getting TV guide from - {0}", SOURCE_NAME); } string IVideoSource.PlayVideo() return string.Format("Playing - {0}", SOURCE_NAME); Dr. Johanyák Zs. Csaba - Szoftvertechnológia

LocalDishTv class LocalDishTv : IVideoSource { const string SOURCE_NAME = "Local DISH TV"; string IVideoSource.GetTvGuide() return string.Format("Getting TV guide from - {0}", SOURCE_NAME); } string IVideoSource.PlayVideo() return string.Format("Playing - {0}", SOURCE_NAME); Dr. Johanyák Zs. Csaba - Szoftvertechnológia

IPTvService class IPTvService: IVideoSource { const string SOURCE_NAME = "IP TV"; string IVideoSource.GetTvGuide() return string.Format("Getting TV guide from - {0}", SOURCE_NAME); } string IVideoSource.PlayVideo() return string.Format("Playing - {0}", SOURCE_NAME); Dr. Johanyák Zs. Csaba - Szoftvertechnológia

RefinedAbstraction class MySuperSmartTV { IVideoSource currentVideoSource = null; public IVideoSource VideoSource { get { return currentVideoSource; } set { currentVideoSource = value;} } public void ShowTvGuide() { if (currentVideoSource != null) { Console.WriteLine(currentVideoSource.GetTvGuide()); else { Console.WriteLine("Please select a Video Source to get TV"+ " guide from"); Dr. Johanyák Zs. Csaba - Szoftvertechnológia

RefinedAbstraction public void PlayTV() { if (currentVideoSource != null) Console.WriteLine(currentVideoSource.PlayVideo()); } else Console.WriteLine( "Please select a Video Source to play"); } } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

class SuperSmartTvController { static void Main(string[] args) { MySuperSmartTV myTv = new MySuperSmartTV(); Console.WriteLine("Select A source to get TV Guide and Play"); Console.WriteLine("1. Local Cable TV\n2. Local Dish TV\n3. IP TV"); ConsoleKeyInfo input = Console.ReadKey(); switch (input.KeyChar) { case '1': myTv.VideoSource = new LocalCabelTv(); break; case '2': myTv.VideoSource = new LocalDishTv(); break; case '3': myTv.VideoSource = new IPTvService(); break; } myTv.ShowTvGuide(); myTv.PlayTV(); } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

Composite - Összetétel
A Composite tervezési mintát olyan feladatokhoz találták ki, ahol egy objektum szerepelhet önálló egységként és szerepelhet objektumok gyűjteményeként. Pl. egy kép objektum lehet egy önálló rajzegység (pl. egy vonal ), de összefoghat további vonal, téglalap, rajz objektumokat is, mint az ábra esetében. Az objektumok ilyetén szerkezetére tekintsünk úgy, mint egy faszerkezetre. Forrás: Mathias Bartoll, Nori Ahari, Oliver C. Moldez: Design Patterns in C# Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Az összetétel minta szerkezete
A feladat megoldására az Összetétel tervezési minta a következőket javasolja. Készítsünk egy absztrakt osztályt (Component), ami tartalmazza a megjelenítéshez (Operation()), új gyermek hozzáadásához (Add()), gyermek eltávolításához (Remove()), gyermekek lekérdezéséhez (GetChild()), stb. szükséges metódusok deklarációit. A Component osztálynak két leszármazottja van: Egy olyan, amiből levél objektum lesz a fában (Leaf), azaz olyan, ami már nem tartalmaz gyermek objektumokat (pl. vonal, téglalap). Ha ehhez egy gyermeket próbálunk hozzáadni, kivétel keletkezik. Egy olyan, ami gyermekeket tartalmazhat (Composite). Amikor egy ilyen objektumon meghívjuk az Operation metódust, akkor ő meghívja minden gyermek objektumára az Operation metódust. A gyermek objektumok esetén csak azt adjuk meg, hogy típusuk Component absztrakt osztály leszármazottja kell legyen. Az „ügyfél” osztály, aki igénybe veszi ezt a fajta megoldást egy Component típusú (azaz annak egy leszármazott típusával rendelkező) osztállyal kerül kapcsolatba. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Implemen-táció Nézzünk meg egy egyszerűsített implementációt az Összetétel tervezési mintához. Az absztrakt osztállyal kezdünk, neve legyen graphic. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

line osztály levél A levél objektum típusát megvalósító line osztály. A másik levél osztály a text. Implementációja hasonló a text-hez. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Picture osztály csomópont Picture osztály A csomópont osztály implementációja Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Observer - Megfigyelő A megfigyelő minta lehetővé teszi, hogy a rendszer egy része értesüljön arról, hogy a rendszer egy más részében bekövetkezik egy esemény. Ez 1:n függőségi kapcsolat az objektumok között. Ha a kiemelt objektum állapota változik, akkor a függő objektumok automatikusan értesülnek (és frissülnek). Alkalmazási terület: ha egy objektumban bekövetkező változás esetén több más objektum változtatása szükséges. Szerepkörök: A Subject a megfigyelés tárgya. Ebből egy van. Kell rendelkezzen egy olyan interfésszel, ami lehetővé teszi, hogy a megfigyelők futási időben rákapcsolódhassanak illetve lekapcsolódhassanak. Ezt biztosítják az Attach és a Detach metódusok. Az Observer a megfigyelő. Ebből lehet több. Kell rendelkezzen egy olyan interfésszel, ami lehetővé teszi, hogy értesítést fogadjon a Subject-től. Ezt biztosítja az Update() metódus. A gyakorlatban ez nem jelent mást, mint eseményvezérelt alkalmazás fejlesztését. A Subject eseményt tesz közzé, amire az Observer eseménykezelő metódusa feliratkozik. Az Observer mintát valósítja meg a klasszikus közzétevő-feliratkozó modell, amivel Vizuális programozás tárgy keretében találkoztunk. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Közzétevő osztály A Stock a közzétevő osztály. Definiál egy eseményt (AskPriceChanged) és egy metódusreferenciát (AskPriceDelegate), ami meghatározza, hogy milyen szignatúrájú metódus lehet eseménykezelő, azaz iratkozhat fel az eseményre. Ha az AskPrice tulajdonság értéke változik, akkor előállítja az eseményt. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Megfigyelő (feliratkozó)

Fel/leiratkozás Mindkét osztályból létrehozunk egy-egy példányt, majd az AskPriceChanged metódust beregisztráljuk az eseményhez (feliratkozás). Egy ideig várakozik, majd ha lefutott a ciklus leiratkozik az eseményről. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Strategy - stratégia Egy algoritmus családot definiál, befoglalja és cserélhetővé teszi az érintett algoritmusokat. Olyan esetekben ajánlott az alkalmazása, amikor egy alkalmazás egy bizonyos szolgáltatást igényel, és ez a szolgáltatás többféleképpen oldható meg. Az algoritmus kiválasztás történhet a felhasználó által vagy számítási hatékonyság, stb. alapján. Péda: különböző tömörítési eljárások alkalmazása, mentés különböző formátumokba. Általában mindegyik viselkedési módot/megoldást külön osztállyal (ConcreteStrategyA..C) valósítják meg. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Megoldások/stratégiák
Mindegyik megoldás (stratégia) a Strategy interfészt kell megvalósítsa, ami azt jelenti, hogy implementálnia kell az AlgorithmInterface metódust. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Illesztő modul Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Használat Az ügyfélmodul az illesztő modulnak (Context) megadja, hogy melyik stratégiát kell alkalmazni, majd igénybe veszi a szolgáltatást a ContextInterface metódus meghívásával. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Dependency Injection Interfész konkrét osztálynév helyett A Client csak az IService interfészről kell tudjon, az azt megvalósító Service osztály nevét nem kell ismerje Megoldások Constructor Injection Property (Setter) Injection Method Injection Forrás: Osztályok és komponensek közötti laza csatolást tesz lehetővé. Az erős kapcsolatok elkerülése könnyebbé teszi a későbbi változtatásokat és a kód karbantartást. „Építő” (builder) objektumokat használ az objektumok inicializálásához és lehetővé teszi, hogy az objektumok közötti függőségeket „befecskendezzük” (inject) az osztályon kívülről. Reduces class coupling Increases code reusing Improves code maintainability Improves application testing Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Constructor Injection A szolgáltatást nyújtó osztály
public interface IService { void Serve(); } public class Service : IService public void Serve() Console.WriteLine("Service Called"); //To Do: Some Stuff This is the most common DI. Dependency Injection is done by supplying the DEPENDENCY through the class’s constructor when instantiating that class. Injected component can be used anywhere within the class. Should be used when the injected dependency is required for the class to function. It addresses the most common scenario where a class requires one or more dependencies. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Az ügyfél osztály public class Client { private IService _service; public Client(IService service) { this._service = service; } public void Start() Console.WriteLine("Service Started"); this._service.Serve(); //To Do: Some Stuff A konstruktor paraméterként megkapja a szolgáltatást végző objektum referenciáját. A szolgáltatás a Start metódus meghívásával indítható. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Használat class Program { static void Main(string[] args) { client = new Client(new Service()); client.Start(); Console.ReadKey(); } Itt a Program osztály látja el az építő szerepet. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Property (Setter) Injection A szolgáltatást nyújtó osztály
public interface IService { void Serve(); } public class Service : IService public void Serve() Console.WriteLine("Service Called"); //To Do: Some Stuff Also called Setter injection. Used when a class has optional dependencies, or where the implementations may need to be swapped. Different logger implementations could be used this way. May require checking for a provided implementation throughout the class(need to check for null before using it). Does not require adding or modifying constructors. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Az ügyfél osztály public class Client { private IService _service; public IService Service { set { this._service = value; } public void Start() { Console.WriteLine("Service Started"); this._service.Serve(); //To Do: Some Stuff Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Használat class Program { static void Main(string[] args) Client client = new Client(); client.Service = new Service(); client.Start(); Console.ReadKey(); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Method Injection A szolgáltatást nyújtó osztály
public interface IService { void Serve(); } public class Service : IService public void Serve() Console.WriteLine("Service Called"); //To Do: Some Stuff Inject the dependency into a single method, for use by that method. Could be useful where the whole class does not need the dependency, just the one method. Generally uncommon, usually used for edge cases. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Az ügyfél osztály public class Client { private IService _service; public void Start(IService Service) { this._service=Service Console.WriteLine("Service Started"); this._service.Serve(); //To Do: Some Stuff } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Használat class Program { static void Main(string[] args) Client client = new Client(); client.Start(new Service()); Console.ReadKey(); } További olvasmány: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Template Method - Sablonfüggvény

Az absztrakt ős osztály
abstract class AbstractClass { public abstract void PrimitiveOperation1(); public abstract void PrimitiveOperation2(); // The "Template method" public void TemplateMethod() { PrimitiveOperation1(); PrimitiveOperation2(); Console.WriteLine(""); } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Leszármazott - A class ConcreteClassA : AbstractClass { public override void PrimitiveOperation1() { Console.WriteLine("ConcreteClassA.PrimitiveOperation1()"); } public override void PrimitiveOperation2() Console.WriteLine("ConcreteClassA.PrimitiveOperation2()"); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Leszármazott - B class ConcreteClassB : AbstractClass { public override void PrimitiveOperation1() { Console.WriteLine("ConcreteClassB.PrimitiveOperation1()"); } public override void PrimitiveOperation2() Console.WriteLine("ConcreteClassB.PrimitiveOperation2()"); } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Használat class MainApp { /// <summary> /// Entry point into console application. /// </summary> static void Main() { AbstractClass aA = new ConcreteClassA(); aA.TemplateMethod(); AbstractClass aB = new ConcreteClassB(); aB.TemplateMethod(); // Wait for user Console.ReadKey(); } } Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Model-View-Controller (MVC)
Modell – az üzleti logikát megvalósító komponens View – a felhasználói felületet megvalósító réteg, egy modellhez több nézet is tartozhat Controller – módosításokat hajt végre a modellen (meghívja a modell metódusait), lehetővé teszi az aktuális nézet kiválasztását, fogadja a nézettől érkező felhasználói utasításokat – ez a komponens felelős az alkalmazás kezeléséért Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás:

MVC alapelvek „Loose coupling” „Program to the interface” Eredmények Jobb karbantarthatóság Könnyebb újrahasznosíthatóság Dr. Johanyák Zs. Csaba - Szoftvertechnológia

MVC - általánosan Dr. Johanyák Zs. Csaba - Szoftvertechnológia

ACME 2000 sport car Dr. Johanyák Zs. Csaba - Szoftvertechnológia

MVC – ACME 2000 sport car Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Preliminaries public enum AbsoluteDirection { North = 0, East, South, West } public enum RelativeDirection Right, Left, Back Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Program to the Interface + loose coupling
Step 1 – Interfaces v1.0 Step 2 – Interfaces v2.0 Step 3 – Abstract Class Automobile Automobile.cs Step 4 – Concrete Automobile Implementations Truck.cs and RaceCar.cs Step 5 – Concrete Control Step 6 – Concrete View Olyan architektúrát/keretrendszert akarunk kialakítani, ami több autótípus esetén is alkalmazható lesz. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Control Interface v1.0 public interface IVehicleControl { void RequestAccelerate(int paramAmount); void RequestDecelerate(int paramAmount); void RequestTurn(RelativeDirection paramDirection); } The Control has to pass requests to the Model. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Model Interface v1.0 public interface IVehicleModel { string Name { get; set; } int Speed { get; set; } int MaxSpeed { get; } int MaxTurnSpeed { get; } int MaxReverseSpeed { get; } AbsoluteDirection Direction { get; set; } void Turn(RelativeDirection paramDirection); void Accelerate(int paramAmount); void Decelerate(int paramAmount); } We need to know the Vehicle's name, speed, maximum speed, maximum reverse speed, maximum turn speed and direction. We also need the methods to accelerate, decelerate, and turn. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

View interface v1.0 public interface IVehicleView { void DisableAcceleration(); void EnableAcceleration(); void DisableDeceleration(); void EnableDeceleration(); void DisableTurning(); void EnableTurning(); } The view should expose some functionality to the Control, such as enabling and disabling acceleration, deceleration, and turn requests. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Control Interface v2.0 public interface IVehicleControl { void RequestAccelerate(int paramAmount); void RequestDecelerate(int paramAmount); void RequestTurn(RelativeDirection paramDirection); void SetModel(IVehicleModel paramAuto); void SetView(IVehicleView paramView); } Any Control should be aware of it's View and Model. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Model Interface v2.0 public interface IVehicleModel { string Name { get; set; } int Speed { get; set; } int MaxSpeed { get; } int MaxTurnSpeed { get; } int MaxReverseSpeed { get; } AbsoluteDirection Direction { get; set; } void Turn(RelativeDirection paramDirection); void Accelerate(int paramAmount); void Decelerate(int paramAmount); void AddObserver(IVehicleView paramView); void RemoveObserver(IVehicleView paramView); void NotifyObservers(); } We want the View to be aware of changes in the Model. To do this we'll use a GOF design pattern "Observer". Observer Pattern Dr. Johanyák Zs. Csaba - Szoftvertechnológia

View interface v2.0 public interface IVehicleView { void DisableAcceleration(); void EnableAcceleration(); void DisableDeceleration(); void EnableDeceleration(); void DisableTurning(); void EnableTurning(); void Update(IVehicleModel paramModel); } The view will be "observing" the Model. Practically the Model will have a reference to the View. When the Model changes, it will call the NotifyObservers() method and pass a reference to itself and notify the View of a change by calling the Update() method of the View. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

MVC minta megvalósítása
Megolvalósítás Visual Studio 2013 segítségével Demo Dr. Johanyák Zs. Csaba - Szoftvertechnológia

MVVM tervezési minta Ismétlés: MVC tervezési minta Az MVVM tervezési minta alapelveinek és megvalósításának áttekintése (a táblán) A minta megismerése egy gyakorlati példán keresztül Feladat: egy WPF-es hagyományos módon megírt alkalmazás átalakítása az MVVM tervezési mintának megfelelő struktúrába Dr. Johanyák Zs. Csaba - Szoftvertechnológia

MVVM Unit Tests View Integration Tests ViewModel Model Service Proxies
XAML, Code Behind Bindings Behavior Actions ViewModel Properties, Commands, View Logic Data Events Model Service Proxies Web Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás:

Model-View-Presenter (MVP)
Az MVC továbbfejlesztése. Fő változás: a modell a megjelenítőt értesíti a változásról. A fejlesztés célja, hogy a nézetben a lehető legkevesebb logika legyen Dr. Johanyák Zs. Csaba - Szoftvertechnológia Forrás:

MVC<->MVP Dr. Johanyák Zs. Csaba - Szoftvertechnológia

MVP Alkalmazási terület: adattárolással, megjelenítéssel, adatbevitellel kapcsolatos alkalmazások Célok: A kód minél nagyobb része automatikusan tesztelhető legyen (egységtesztek) Jól áttekinthető, könnyen megírható és könnyen karbantartható forráskód előállítása Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Alapgondolat A felhasználói felület, az üzleti logika és az alkalmazáson belüli adatmodell szétválasztása – külön osztályok Szerepkörök Model (adatmodell) View (megjelenítő réteg) Presenter (eseménykezelést, üzleti logikát megvalósító osztály) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

MVP Ajánlás: laza csatolás Változatok: Supervising Presenter (controller) Passive View Laza csatolás: definiáljunk egy IView interfészt, amit a View megvalósít és a Presenter erre hivatkozzon, ne a tényleges View osztályra, így az egységteszteknél könnyen helyettesíthetjük a View-t. Az alapvető különbség ott jelentkezik, hogy a SP megengedi a Model és a View közötti közvetlen kapcsolatot, míg a PV nem. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Supervising Presenter
Mikor alkalmazható? Állapottárolásra képes alkalmazásoknál (a klasszikus web alkalmazásoknál nem – ott állapotmentes) Asztali és okos kliens alkalmazások A Presenter és a View a kliensen Model megosztottan a kliensen és a szerveren Dr. Johanyák Zs. Csaba - Szoftvertechnológia

MVP Felhasználói esemény View Presenter Adatmódosítás Lekérdezés Adatlekérés Esemény, állapot változás Parancs Model Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Példa Asztali alkalmazás Felület Sorrend diagram Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Passive View Ez a vékony View modell A View nem tartalmaz semmilyen alkalmazáslogikát  a teljes alkalmazáslogika könnyen tesztelhető A P felelős a teljes munkafolyamatért – gyakran alkalmazzák ASP.NET alkalmazásokban Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Hogyan működik? A V az Observer mintát követve azonnal szinkronizálódik a modellel (adatkötés) A V és M között a kapcsolatot deklaratív módon adjuk meg Felhasználói interakció esetén az eseménykezelést a P egy metódusa valósítja meg. Ez magába foglalhat ellenőrzött adatbevitelt vagy komplex lekérdezést. A művelet ereményének a visszajelzéséről a P gondoskodik – változást idéz elő a V-ben Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

Példa Vékony webes kliens Szekvencia diagram Az előző alkalmazás webes vékony kliens megfelelőjénél (állapotmentes alkalmazás) a felhasználó kattint a hozzáad gombon, a szerveren egy új P objektum keletkezik + egy új M objektum. A P eseménykezelő metódusa végrehajtódik, megkapja V-től az adatokat (aktuális paraméterek), végrehajtja a szükséges műveleteket, és értesíti P-t a frissítés szükségességéről. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Repository minta Alkalmazási terület Olyan programok, amelyek adatbázisban, SharePoint listákon, webszolgáltatásokon elérhető adatokon dolgoznak Célok A kód minél nagyobb része automatikusan tesztelhető legyen Központosítottan felügyelt adathozzáférés, következetes hozzáférés szabályozás Központosított adat-gyorstárazás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Repository Célok (folytatás) Jól áttekinthető, könnyen megérthető és könnyen karbantartható forráskód előállítása Üzleti logika elválasztása az adat és szolgáltatás hozzáférési logikától Erősen típusos megoldások alkalmazása (ellenőrzés már fordítási időben) „Viselkedés” rendelése adatcsoportokhoz (pl. számított mezők, komplex kapcsolatok) Üzleti logika egyszerűsítése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Megvalósítás Egy „raktár” segítségével elválasztjuk az adatokat az őket lekérdező logikától Az üzleti logika független kell legyen az adatforrás rétegben alkalmazott adattárolási eszköztől (DB, SP, WS) Az R végzi az adatforrás lekérdezést, leképezi azt üzleti entitássá és visszafelé gondoskodik az üzleti entitáson végrehajtott módosítások tartós tárolásáról Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Ábra Az ügyfél új vagy módosított üzleti entitásokat küld az R-hez tartós tárolás céljából lekérdezést küld az R-hez Az R gondoskodik a tárolásról visszaadja a lekérdezés eredményét üzleti entitások formájában Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Az R általában gyengén típusos alakban kapja meg a lekérdezés eredményét az adatforrástól és erősen típusos (objektum) formába alakítva továbbítja azt az üzleti logikai réteg felé Átalakítás: Data Mapper minta Az R elfedi a tényleges adatlekérés módját (pl. SQL), azaz az ügyfél nem kell tudjon arról, hogy pontosan milyen paranccsal lett lekérdezve az adatforrás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Gyorstárazás és WS Az R gyakran gyorstárazást is megvalósít, amire akkor van különösen szükség, ha az adatelérés lassú (pl. WS) Ha az adatforrás egy WS, akkor az R némileg módosul, megjelenik egy proxy osztály: Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Az alkalmazás hatásai Csökkenti a kódredundanciát Növeli az osztályok számát Részekre bont, ami megkönnyíti az egységtesztek készítését, az egyes részek mock objektumokkal való helyettesítését Többszálú környezetben a cache hozzáférést szinkronizálni kell Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Data Mapper Martin Fowler 2003 Egy leképezési réteg, ami biztosítja az adatbázis és a memória objektumok közötti adatáramlást úgy, hogy az adatok az ábrázolási technikától és leképezésektől függetlenek maradjanak. Miért van rá szükség? – az objektumok és a relációs adatbázisok eltérően strukturálják az adatokat (pl. gyűjtemények, öröklődés, stb.) The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper the in-memory objects needn't know even that there's a database present; they need no SQL interface code, and certainly no knowledge of the database schema. (The database schema is always ignorant of the objects that use it.) Since it's a form of Mapper (473), Data Mapper itself is even unknown to the domain layer. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A DM használata mellett a memória objektumok nem kell tudjanak a relációs tárolásról, nem kell tartalmazzanak SQL kódot Így a DM réteget vagy az adatbázis réteget könnyen lecserélhetjük a teszteléshez Egyszerű DM: adattábla mező—adattag Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Insert és Update esetén a DM-nek tudnia kell, hogy mely objektumok módosultak, keletkeztek, szűntek meg  tranzakció kezelési keretrendszer szükséges ld. Unit of Work minta Egy alkalamzáshoz több DM is tartozhat Hol találkozhattunk eddig DM-el? Table/DataAdapter EntityFramework Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Tervezési minták osztályozása
Létrehozási Szerkezeti Viselkedési Singleton (Egyke) Adapter Observer Simple Factory Bridge Strategy Dependency Injection Composite Template Method MVC MVP MVVM Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Fontosabb szoftverminőség modellek
Termék alapú megközelítés modellek McCall ISO 9126  ISO 25010 SCOPE NF Logiciel Folyamat alapú megközelítés CMM/CMMI Bootstrap SPICE Dr. Johanyák Zs. Csaba - Szoftvertechnológia

McCall 1978, James McCall a General Electrics egyik projektvezetője a végtermékre koncentrál a modellben meghatározzák a felhasználói alapszempontokat meghatározzák a termék minőségfaktorait (quality factors) a minőségfaktorokat minőségi jellemzőkre bontják (quality criteria) a minőségi jellemzőkhöz mérőszámokat rendelnek (metrics) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

McCall modell Három fő kategória Termék működése Termék átdolgozása Termék átvitel Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A termék működéséhez kapcsolódó faktorok
Correctness Reliability Efficiency Integrity Usability How well does it run and ease of use. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

McCall’s Quality Factors Category: Product Operation Factors
1. Correctness - Helyesség. ‘correctness’ issues are arising from the requirements documentation and the specification of the outputs… Examples include: Specifying accuracies for correct outputs at, say, <1% errors, that could be affected by inaccurate data or faulty calculations; Specifying the completeness of the outputs provided, which can be impacted by incomplete data Specifying the timeliness of the output (time between event and its consideration by the software system) Specifying the standards for coding and documenting the software system Dr. Johanyák Zs. Csaba - Szoftvertechnológia

2. Reliability - Megbízhatóság. (remember, this quality factor is specified in the specs!) Reliability requirements deal with the failure to provide service. Address failure rates either overall or to required functions. Example specs: A heart monitoring system must have a failure rate of less than one per million cases. Downtime for a system will not be more than ten minutes per month 3. Efficiency - Hatékonyság Deals with the hardware resources needed to perform the functions of the software. Here we consider MIPS, MHz (cycles per second); data storage capabilities measured in MB or TB; communication lines (usually measured in KBPS, MBPS, or GBPS). Example spec: simply very slow communications… Dr. Johanyák Zs. Csaba - Szoftvertechnológia

4. Integrity – Biztonság – deals with system security that prevent unauthorized persons access. 5. Usability – Használhatóság – deals with the scope of staff resources needed to train new employees and to operate the software system. Deals with learnability, utility, and more. Example spec: A staff member should be able to process n transactions / unit time. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Termék átdolgozásához kapcsolódó faktorok
Maintainability Flexibility Testability Can I fix it easily, retest, version it, and deploy it easily? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

McCall’s Quality Factors Category: Product Revision Software Factors
These deal with requirements that affect the complete range of software maintenance activities: corrective maintenance, adaptive maintenance, and perfective maintenance 1. Maintainability Requirements The degree of effort needed to identify reasons (find the problem) for software failure and to correct failures and to verify the success of the corrections. Deals with the modular structure of the software, internal program documentation, programmer manuals Example specs: size of module <= 30 statements. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

McCall’s Quality Factors Category: Product Revision Software Factors
2. Flexibility Requirements – deals with resources to change (adopt) software to different types of customers that use the app perhaps a little differently May also involve a little perfective maintenance to perhaps do a little better due to the customer’s perhaps slightly more robust environment. 3. Testability Requirements – Are intermediate results of computations predefined to assist testing? Are log files created? Does the software diagnose itself prior to and perhaps during operations? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Termék átvitel faktorai
Portability Reusability Interoperability Can I move the app to different hardware? Interface easily with different hardware / software systems; can I reuse major portions of the code with little modification to develop new apps? Dr. Johanyák Zs. Csaba - Szoftvertechnológia

McCall’s Quality Factors Category: Product Transition Software Quality Factors 1. Portability Requirements: If the software must be ported to different environments (different hardware, operating systems, …) and still maintain an existing environment, then portability is a must. 2. Reusability Requirements: Are we able to reuse parts of the app for new applications? Can save immense development costs due to errors found / tested. Certainly higher quality software and development more quickly results. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

McCall’s Quality Factors Category: Product Transition Software Quality Factors 3. Interoperability Requirements: Does the application need to interface with other existing systems Frequently these will be known ahead of time and plans can be made to provide for this requirement during design time. Sometimes these systems can be quite different; different platforms, different databases, and more Also, industry or standard application structures in areas can be specified as requirements. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

ISO/IEC 9126 (1991) ISO 9126:2001: „Software engineering — Product quality”. ISO helyett : ISO/IEC 25010:2011: Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models Felhasználta: a McCall és Boehm modelleket a modellek használatában szerzett tapasztalatokat a korabeli piaci igényeket Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Elvek az ISO által meghatározott szoftverminőség –a definícióból adódó összes aspektust lefedje a szoftvertermék minőségét a lehető legkevesebb átfedéssel határozza meg az alkalmazott technológiához a lehető legközelebb legyen az egyszerűség kedvéért max. 6-8 minőségi jellemzőt azonosítson azonosítsa a továbbiakban javítandó területeket Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Minőségi jellemzők Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

Használhatóság Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Megbízhatóság Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Hatékonyság és karbantarthatóság

Hordozhatóság Dr. Johanyák Zs. Csaba - Szoftvertechnológia

SCOPE Software assessment and CertificatiOn Programme in Europe 1989 – 1993 16 szervezet 8 országból (EU és EFTA) módszertan és technológia szoftver termékek értékelésére és tanúsítására Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Célok hagyományos mérési technikák alkalmazási lehetőségeinek kutatása és ezen technikák kombinálása szoftver termékek értékelése céljából termék értékelése aszerint, hogy milyen mértékben felel meg az elvárásoknak, pl. az ISO 9126-ban megfogalmazott minőségi jellemzőknek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Módszertan az értékelés ötlépéses folyamat az ISO két része (a hatból) innen lett átvéve négy értékelési szint: A (legszigorúbb) – D minden szinthez különböző értékelési módszerek szint minden minőségi jellemzőre egyedileg megválasztható magas kockázatú jellemzőknél szigorú értékelési szintet kell választani Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Értékelési szintek megválasztása
D: tulajdon kismértékű megkárosítása, emberek számára nem okoz kockázatot C: tulajdon veszélyeztetése, néhány személy kismértékű veszélyeztetése B: életveszély A: többen meghalhatnak Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Értékelési modulok az értékelő által használható metrikákat és technikákat rögzítő dokumentum alkalmazási módszertan, alkalmazási módok előny: ismételhetőség és újra előállítható eredmények Dr. Johanyák Zs. Csaba - Szoftvertechnológia

D szint C szint B szint A szint Funkcionalitás funkcionális tesztelés (black box) átvizsgálás (check lists) komponens teszt (glass box) formális ellenőrzés Megbízhatóság programnyelvi adottságok hibatűrési elemzés Megbízhatóság növelési modell Használhatóság Felhasználói interfész felülvizsgálata Interfész szabványoknak való megfelelés labor teszt Felhasználói modell Hatékonyság Végrehajtási idő mérése benchmark algoritmikus komplexitás Teljesítmény elemzés Karbantartahatóság Dokumentumok felülvizsgálata statikus elemzés A fejlesztési folyamat elemzése Visszavezethetőségi elemzés Hordozhatóság Telepítés elemzése Programozási szabályoknak való megfelelés Környezeti korlátozások értékelése Programterv értékelés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

NF Logiciel AFNOR (Association Francaise de NORmalisation) 1996 Logiciel =szoftver minden szoftverre alkalmazható alkalmazási területtől, funkcionalitástól és eredettől függetlenül megszerzéséhez nem előfeltétel a tanúsítás megléte az elvárások a minőségrendszerek tanúsításánál megfogalmazott elvárásokon alapulnak az NF Logiciel célja a szállított termék minőségének garantálása az NF Logicielnek nem célja a minőségrendszer értékelése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

NF Logiciel alapelvek1 ISO/IEC ből levezetett elvárások teszt dokumentációval szembeni elvárások egyes szoftverkategóriákhoz speciális elvárások Dr. Johanyák Zs. Csaba - Szoftvertechnológia

NF Logiciel alapelvek 2 ISO/IEC ből levezetett elvárások minden szoftvercsomaghoz készüljön termékleírás fő célja, hogy segítse a felhasználót vagy potenciális vásárlót annak értékelésében, hogy megfelelő-e a termék számára és megalapozza a tesztelést tartalmi követelmények minden szoftvercsomaghoz készüljön felhasználói dokumentáció legyen teljes, korrekt, következetes, érthető és könnyen áttekinthető programokhoz és adatokhoz kapcsolódó elvárások: telepíthetőség, elvárt funkciók, megbízhatóság, használhatóság... előírások arra, hogy hogyan kell tesztelni a minőségi elvárásoknak való megfelelést Dr. Johanyák Zs. Csaba - Szoftvertechnológia

NF Logiciel alapelvek3 A teszt dokumentációval kapcsolatos elvárások: tartalmaznia kell: teszt tervet validálási stratégiát teszt specifikációt teszt eredményeket követhetőséghez szükséges azonosító elemeket Dr. Johanyák Zs. Csaba - Szoftvertechnológia

NF Logiciel alapelvek4 egyes szoftverkategóriákhoz speciális elvárások, mint pl. mechanikai szerkezetek számításai, fordítók, adatátvitel minőségbiztosítási szempontokból az ISO 9001 követelményeinek egy részét átvették Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Tanúsítási eljárás az ANFOR (francia tanúsítási testület) által akkreditált tesztlabor egy tesztjelentést készít ANFOR minőségügyi audit bizottsági döntés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Fontosabb szoftverminőség modellek
Ismétlés Fontosabb szoftverminőség modellek Termék alapú megközelítés modellek McCall ISO 9126  ISO 25010 SCOPE NF Logiciel Folyamat alapú megközelítés CMM/CMMI Bootstrap SPICE Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A szoftverminőség folyamat alapú megközelítése
Szoftvertechnológia A szoftverminőség folyamat alapú megközelítése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Szoftverfolyamat érettsége
A szoftver folyamat érettsége: Annak mértéke, hogy egy folyamat mennyire pontosan meghatározott, vezérelt, mért, ellenőrzött és hatékony. Az érett szoftver folyamat: Meghatározott (definiált), vezérelt, mért, ellenőrzött, hatékony és javulásra képes. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Érettségi modellek Lépcsős modellek (staged models) Teljes szervezet CMM, Bootsrap Folytonos modellek (continuous models) Kiválasztott folyamat(ok) SPICE/ISO 15504 Kombinált, integrált modellek: ötvözik a kétféle modellt, a bizonyítottan hasznos elemeket kiválasztva Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Lépcsős modellek A szervezet egészét vizsgálják Úgy tekintik, hogy a szervezetben „egyetlen” folyamat van, a „szervezeti szintű folyamat”, ez maga a szoftverfejlesztési folyamat, amely magába foglalja: a szoftverfejlesztésben részt vevő embereket a szoftverfejlesztésben alkalmazott technológiát a szoftverfejlesztésben alkalmazott módszereket a szoftverfejlesztésben alkalmazott eszközöket ... Dr. Johanyák Zs. Csaba - Szoftvertechnológia

CMM 1 2 5 4 3 Kezdő Ismételhető Definiált Menedzselt Optimalizált Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Capability Maturity Model
Értékelési kérdőív (módszer) kidolgozása szoftverfejlesztő vállalatok számára (Eredetileg az Amerikai Védelmi Minisztérium megrendelésére készült, amelyet a SW-beszállítóinak értékelésére akart használni) (1987) Ezt a módszert az USA-ban a Carnegie Mellon Egyetem Software Engineering Institute (SEI) intézete dolgozta ki (1991) Referenciamodell a később ez alapján levezetett modellek számára: Bootstrap-Assessment (európai értékelési módszer) (1992) és a Siemens-OPAL-Assessment (ZT SE) (1992) Először csak szoftver folyamat értékelése (SW-CMM), majd kibővül általános folyamatmodell értékeléssel (SW-A-CMM, SE-CMM, People-CMM) (1995) Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A CMM szerepe CMM egy referenciamodell, amely a helyes gyakorlatot mutatja a szoftverfejlesztésben CMM szintek alapján meghatározható a szervezet érettségi szintje egy adott referenciamodellhez viszonyítva CMM szintek alapján értékelhetők a SW-beszállítok (pl. DoD, Boeing, NASA) CMM Assessment (értékelés) irányadó a szoftverfejlesztési tevékenység folyamatfejlesztésében a célok prioritások koncepciók meghatározásában Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A CMM felépítése Folyamatváltozás-menedzselés Technológiai innováció Hibamegelőzés Minőségmenedzselés Folyamatmérés és -elemzés Képzési program Review-k, szemlék Folyamatközpontúság Szervezeti folyamatok meghatározása Integrált folyamat menedzselés Szoftvertechnológia Csoportközi együttműködés Konfiguráció-menedzselés Minőségbiztosítás Alvállalkozó-menedzselés Projektkövetés Projekttervezés Követelménymenedzselés Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Első - Kezdő szint Jellemzői: Tervezés hiánya Dokumentálás hiánya, ill. ésszerűtlensége „Tűzoltóakciók” Nem működő kommunikáció Tisztázatlan kompetenciák és felelősségek Végeredmény: Hibás szoftver (funkcionális, technikai) Kötbér Elégedetlen vevő Elégedetlen munkatársak, vezetők, tulajdonosok Ezen a szinten a folyamatok gyakran ad-hoc jellegűek. A siker jelentős mértékben a dolgozók rendkívüli erőfeszítésein és szakmai tapasztalatán múlik. Gyakori a kudarc, a határidők és célok nem teljesülése, a tervezettnél nagyobb mértékű erőforrás felhasználás. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Második - Ismételhető szint
Jellemzők: Dokumentált folyamatok Projekt tervezés és követés (költség, idő, minőség) Kialakult projekt menedzsment irányvonal Tapasztalati bázis (becslések, előrejelzések) Állandó módszerek, technikák, eljárások Végeredmény: Ismételhető folyamat Reális ígéretek tétele Hosszú távú működőképesség A szervezet képes a sikerek ismétlésére a megfelelő dokumentálásnak köszönhetően. Hatékonyabb az erőforrás felhasználás, jobban követik a tervezett költségeket, de még mindig előfordul a költségvetés túllépése. Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Harmadik - Definiált szint
Hangsúly a szervezeten A menedzsment folyamatosan kap adatokat a szervezet és az egyes folyamatok működéséről A folyamatokat a szervezet speciális igényeihez igazítva alakítják ki A folyamatok rendszerezettek és ellenőrzöttek „Helyes gyakorlat” (minták) definiálása Hangsúly a dolgozók oktatásásn Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Negyedik - Menedzselt szint
Jellemzők: Statisztikai kontroll Mutatószámrendszer (termelékenység, minőség) Eltérésvizsgálat („kell” és „van” érték) Hatékony korrekciós intézkedések Végeredmény: Szabályozott menedzselt folyamat Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Ötödik - Optimalizált szint
Jellemzők: Hibamegelőzés Állandó folyamatjavítás Innovatív szellemiség Motivált munkatársak Végeredmény: Önadaptív folyamat Lehetőségeinek határát ostromló vállalat Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Az értékelés (Assessment) kérdéslistája
Folyamatkritériumok Vezetési Projekttervezés és projektkövetés Alvállalkozó-menedzselés Minőségbiztosítás Konfiguráció-menedzselés Mérnöki Követelmény-menedzselés Rendszer -engineering és -érvényesítés SW-előállítás SW-integráció és teszt HW-előállítás HW- integráció és teszt Újrafelhasználás Szervezési Folyamatdefiníció és -fejlesztés Képzés Folyamat és termék mérése Folyamat- és technológiai javítások Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A CMM felépítése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A Bootstrap módszer A CMM kiterjesztése / változata Az EU ESPRIT projektje keretében dolgozták ki, 1991.szept. és 1993 febr. között a szoftverfejlesztési folyamat minőségének felmérésére és javítására szolgál, és többek között CMM-re valamint az ISO, ESA, DoD, IEEE, NATO szoftverminőségi szabványokra épül Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Bootstrap a felmérés a CMM-en kívül az ISO 9001 és ISO szabványokat is felhasználja, így kimutatható az is, hogy az ISO 9001 tanúsítvány megszerzéséhez mely követelmények teljesülnek, és melyek nem a szoftver fejlesztési folyamat szervezettségét tekinti elsődlegesnek, de foglalkozik a fejlesztés módszertanával és a fejlesztés technológiájával is Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Bootstrap jellemzők a szoftverfejlesztési egység (SPU: Software Production Unit) és a projektek számára szükséges területeket, folyamatokat és tevékenységeket határoz meg három vonatkozásban auditálja az SPU-t és a projekteket: szervezet módszerek technológia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Alkalmazásának előnyei
felkészít az ISO 9000 szerinti minősítésre olcsóbb az ISO 9000 felmérésnél útmutatást ad a magasabb szint elérésére nemcsak egész értékekben kifejezhet érettségi szinteket mutat (pl. lehet 2.75) a különböző attribútumok érettségi szintjeit külön is megmutatja Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Folytonos modellek Az egyes folyamatokra (és nem a teljes szervezetre) állapítanak meg érettségi szinteket bizonyos jellemzők alapján A modell alkalmazója maga döntheti el, hogy milyen folyamat érettségét szeretné vizsgálni SPICE/ISO 15504 Dr. Johanyák Zs. Csaba - Szoftvertechnológia

SPICE/ISO 15504 Software Process Improvement and Capability dEtermination A projekt 1993-ban indult, hivatalos szabvány 2002 folyamatos modell az egyes folyamatokra (és nem a teljes szervezetre) állapít meg érettségi szinteket bizonyos jellemzők alapján a modell alkalmazója maga döntheti el, hogy milyen folyamat érettségét szeretné vizsgálni Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Jellemzők átfogó, referenciamodell a folyamatokra és a folyamatok érettségére vonatkozóan, kis-, közepes- és nagyvállalatok nemzetközi tapasztalatait összegezve keretrendszer folyamatok erősségeinek és gyengeségeinek feltérképezésére szoftverfolyamatok javítására és ilyen javítások mérésre amely segíti a szoftvert felhasználókat felmérni, hogy a szoftver gyártói mennyire „érettek” a célnak megfelelő, árban, időben és minőségben szoftvert szállítani folyamat felmérési modellek harmonizációjára szolgáló lehetőség Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Jellemzők általános keretet és nyelvezetet ad a szoftver folyamat értékeléséhez egy referencia modellhez (folyamatok és folyamat képességek) folyamatképesség értékeléséhez elvárásokat fogalmaz meg, amelyeket ki kell elégíteni a sikeres felülvizsgálathoz a referenciamodellel való kompatibilitáshoz Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Process Capability Dimension
Defined on a six point nominal scale (0 to 5) Low end - level 0 (Not Performed): general failure to attain the purpose of the process; little or no easily identifiable work products or outputs of the process High end - level 5 (Optimizing): performance of the process is optimized to meet current and future business needs, and the process achieves repeatability in meeting its defined business goals. Based upon the ratings assigned to a set of nine process attributes Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Képességi szintek Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Szintek Végrehajtott Menedzselt teljesítmény menedzsment: erőforrás igények meghatározása a folyamat teljesítményének tervezése a definiált tevékenységek implementálása a tevékenységek elvégzésének menedzselése a munka eredményének menedzselése az integritásra és minőségre vonatkozó követelmények meghatározása a szükséges tevékenységek meghatározása a munka eredményének konfigurációkezelése a munka eredményének minőségmenedzsmentje Dr. Johanyák Zs. Csaba - Szoftvertechnológia

3. Meghatározott Meghatároz: a szabvány folyamat meghatározása, a szabvány folyamat testre szabása, a meghatározott folyamat bevezetése, visszajelzés a szabvány folyamatnak a folyamathoz rendelt erőforrások az emberi erőforrás kompetenciájának meghatározása a folyamat infrastrukturális követelményeinek meghatározása megfelelő képesség emberi erőforrások biztosítása megfelelő infrastruktúra biztosítása Dr. Johanyák Zs. Csaba - Szoftvertechnológia

4. Jósolható folyamat mérése folyamatok céljainak és a kapcsolódó mérőszámoknak a meghatározása megfelelő erőforrások és infrastruktúra biztosítása a meghatározott mérési adatok gyűjtése annak figyelése, hogy a folyamat céljai teljesültek-e folyamat ellenőrzése elemzési és ellenőrzési technikák meghatározása meglévő mérési eredmények elemzése az eltérések azonosítása és szükséges beavatkozás Dr. Johanyák Zs. Csaba - Szoftvertechnológia

5. Optimalizált folyamat változása a szabvány folyamatban szükséges változások azonosítása és jóváhagyása a bevezetéshez szükséges erőforrások rendelkezésre bocsátása a jóváhagyott változás bevezetése a változtatás hatékonyságának vizsgálata folyamatos javítás javítási lehetőségek beazonosítása bevezetési stratégia meghatározása a testre szabott folyamat meghatározott területén végrehajtott módosítás bevezetése Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Az érettségi szint kiszámolása
kérdőív Teljes – 1, Széleskörű – 0.666, Részleges – 0.333, Nem létező – 0 -ez 1-es szinten érvényes, más szinteken más számok vannak!!! átlagszámítás kérdéscsoportokra Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Kérdőív Dr. Johanyák Zs. Csaba - Szoftvertechnológia

A folyamatok érettsége
megállapítására un. „generic practices”- általános gyakorlat – leírásokat használnak hogy egy folyamat bizonyos érettségi szinten legyen, ahhoz meg kell lenniük a szinthez tartozó általános gyakorlat-elemeknek azt is értékelik, hogy ha egy folyamat bizonyos szinten van, akkor bizonyos (szintén általánosan leírt) célokat ki kell elégítenie, és bizonyos munka eredményeket (termékeket) kell létrehoznia Dr. Johanyák Zs. Csaba - Szoftvertechnológia

SPICE és CMM azonosságok az állandó folyamatjavításra koncentrálnak a referencia modellt és az érettségi szint skálát az értékelés keretrendszreként alkalmazzák felismerik a képzett felülvizsgáló fontosságát felismerik az ismételhetőség, konzisztencia és összehasonlíthatóság fontosságát eltérések keretrendszer  módszer/modell referencia modell felépítése referencia modell célja Dr. Johanyák Zs. Csaba - Szoftvertechnológia

Referencia modell felépítéseSPICE

Referencia modell felépítéseCMM

Referencia modell célja
CMM a szoftver előállításával és karbantartásával kapcsolatos irányítási és technológiai gyakorlatra koncentrál – ez a céljainak egy alrendszerét fedi a legtöbb szerinti folyamat valamilyen szinten megtalálható a szoftver CMM-ben Dr. Johanyák Zs. Csaba - Szoftvertechnológia

SPICE for SPACE kiinduló pontja az ISO 15504 European Cooperation for Space Standardisation ECSS E 40: Space Engineering – Software ECSS Q 80: Space Product Assurance – Software Product Assurance ISO 12207 European Space Agency értékelési modell az európai űripar szoftverei számára a hez képest: 4 új folyamat, 50 új "általános gyakorlat", Dr. Johanyák Zs. Csaba - Szoftvertechnológia

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

Hasonló előadás

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

Hasonló előadás

Projectumról

Visszajelzés

Bejelentkezés

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

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

Hasonló előadás

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

Hasonló előadás

Projectumról

Visszajelzés