RUP, XP és SPEM. Budapest Április 21. Ráth István (Szőke Ákos fóliái alapján)
|
|
|
- Adrián Dobos
- 5 évvel ezelőtt
- Látták:
Átírás
1 RUP, XP és SPEM Budapest Április 21. Ráth István (Szőke Ákos fóliái alapján)
2 Tartalomjegyzék Best pracpces A RaPonal Unified Process (RUP) RUP elveinek bemutatása RUP elemeinek bemutatása RUP fázisok bemutatása RUP, mint termék bemutatása extreme programming Agilis metodikák összehasonlítása Folyamatmintáktól a SPEM- ig 2
3 Best PracPces 3
4 Trend a szowvertechnológiában Egyre komplexebb rendszerek A meglévő fejlesztési folyamatok nem megfelelőek: 4
5 Trend a szowvertechnológiában Egyre komplexebb rendszerek A meglévő fejlesztési folyamatok nem megfelelőek: Az OK: a megfelelő módszertan hiánya! 4
6 A hinta 5
7 A probléma megoldás lépései: 6
8 A probléma megoldás lépései: Szimptómák (tünetek) meghatározása 6
9 A probléma megoldás lépései: Szimptómák (tünetek) meghatározása 6
10 A probléma megoldás lépései: Szimptómák (tünetek) meghatározása Okok felderítése 6
11 A probléma megoldás lépései: Szimptómák (tünetek) meghatározása Okok felderítése 6
12 A probléma megoldás lépései: Szimptómák (tünetek) meghatározása Okok felderítése Okok megszüntetése 6
13 Szimptómák meghatározása Elvárások nem teljesülnek Követelmények zavarosak Modulok nem illeszkednek egymáshoz Nehéz a karbantartás Hibák késő detektálása Gyenge minőség Gyenge performancia Fejlesztők közö_ eltérések 7
14 Okok felderítése Elégtelen követelmény- meghatározás Félreérthető kommunikáció Nem eléggé robosztus az architektúra Túlságosan nagy komplexitású a rendszer Nem detektált inkonzisztencia Alacsony fokú kiteszteltség Szubjekbv értékelés Vízesés modellen alapuló fejlesztés Nem kontrollált változtatás Elégtelen automapzáció 8
15 Okok megszüntetése Legjobb gyakorlatok Elvárások nem teljesülnek Követelmények zavarosak Modulok nem illeszkednek egymáshoz Nehéz a karbantartás Hibák késő detektálása Gyenge minőség Gyenge performancia Fejlesztők közö_ eltérések Elégtelen követelménymeghatározás Félreérthető kommunikáció Nem eléggé robosztus az architektúra Túlságosan nagy komplexitású a rendszer Nem detektált inkonzisztencia Alacsony fokú kiteszteltség Szubjektív értékelés Vízesés modellen alapuló fejlesztés Nem kontrollált változtatás Elégtelen automatizáció Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Control Changes (UCM) 9
16 Okok megszüntetése Legjobb gyakorlatok Elvárások nem teljesülnek Követelmények zavarosak Modulok nem illeszkednek egymáshoz Nehéz a karbantartás Hibák késő detektálása Gyenge minőség Gyenge performancia Fejlesztők közö_ eltérések Elégtelen követelménymeghatározás Félreérthető kommunikáció Nem eléggé robosztus az architektúra Túlságosan nagy komplexitású a rendszer Nem detektált inkonzisztencia Alacsony fokú kiteszteltség Szubjektív értékelés Vízesés modellen alapuló fejlesztés Nem kontrollált változtatás Elégtelen automatizáció Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Control Changes (UCM) 9
17 Mit jelentenek a legjobb gyakorlatok? Elvek, módszerek és folyamatok egy szerveze6 és dokumentált halmaza, amely növeli a szo=verfejlesztési minőségét és produkavitását. 10
18 PracPce 1 Fejlessz iterabvan! Develop Iteratively Manage Requirements Best Practices Use Component Architectures Model Visually Continuously Verify Quality Control Change 11
19 Szekvenciális fejlesztés Szekvenciális tevékenységek: Requirements Design Code Integra=on Test 100% Fejlesztés előrehaladása (% kódolt) Integráció kezdete Late Design Breakage Eredeti átadási dátum 12
20 A szekvenciális és az iterabv fejlesztési folyamat Folyamatok időbeli lefutása: összehasonlítása
21 A termékek evolúciója a fejlesztési Az iterabv megközelítés miaj az idő előrehaladtával a termékek egyre érejebbek lesznek. 14
22 Bizonytalansági kúp 15
23 PracPce 2 Kezeld a követelményeket! Develop Iteratively Manage Requirements Best Practices Use Component Architectures Model Visually Continuously Verify Quality Control Change 16
24 PracPce 3 Használj komponens architektúrákat Develop Iteratively Manage Requirements Best Practices Model Visually Continuously Verify Quality Use Component Architectures Control Change 17
25 Komponens alapú architektúra előnye Komplexitás jobban kezelhető Integritás jobban biztosítható Újrafelhasználást támogatja: Komponens újrafelhasználás Architektúra újrafelhasználás Projekt menedzsmentet támogatja: SzoWver tervezés Emberi erőforrás tervezés 18
26 Példa: komponens alapú architektúra Lead Tracking Functions User Interface Mechanisms Customer Product Purchased Existing New 19
27 Példa: komponens alapú architektúra Lead Tracking Functions User Interface Mechanisms Customer Product License Purchased Existing New 19
28 Példa: komponens alapú architektúra Lead Tracking Functions User Interface Mechanisms Customer Product License Purchased Existing New 19
29 Példa: komponens alapú architektúra Lead Tracking Functions Licensing Functions User Interface Mechanisms Customer Product License Purchased Existing New 19
30 PracPce 4 Modellezz vizuálisan! Develop Iteratively Manage Requirements Best Practices Use Component Architectures Continuously Verify Quality Model Visually (UML) Control Change 20
31 Reprezentáció: az UML Az UML, a szowver- intenzív rendszerek termékeinek vizuális megjelenítésre, specifikálásra, tervezésre, és dokumentálásra kidolgozoj jelölésrendszer. 21
32 Vizuális modellezés az UML- lel Sequence Diagrams Use-Case Diagrams Class Diagrams Object Diagrams Collaboration Diagrams Models Component Diagrams Dynamic Diagrams Statechart Diagrams Activity Diagrams Deployment Diagrams Static Diagrams 22
33 PracPce 5 Folyamatosan ellenőrizd a szowver minőségét! Develop Iteratively Manage Requirements Best Practices Use Component Architectures Model Visually Control Change Continuously Verify Quality 23
34 Minőség méréséhez: szowver metrikák alkalmazása Termék metrikák pl. méret, funkcionalitás, komplexitás, struktúra Folyamat (fejlesztés és támogatás) metrikák pl. hibaszám, követelményeknek való megfelelőség Projekt metrikák pl. produkpvitás, ütemezés, költség, munkaerő- minta 24
35 PracPce 6 Kezeld a szowver változásait! Develop Iteratively Manage Requirements Best Practices Use Component Architectures Model Visually Continuously Verify Quality Control Change (UCM) 25
36 Mire való a változáskezelés? Iterabv fejlesztésből adódó változások vezérléséhez, nyomon követéséhez és monitorozásához. Minden fejlesztőnek biztonságos workspace- t biztosítson. AutomaPkus integrációhoz és build menedzsmenthez. Workspace Management Parallel Development Process Integration REPORT ALERT Build Management 26
37 A Best PracPce- ek egymást erősípk Develop Iteratively Best Practices Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Control Changes (UCM) A felhasználók bevonása a követelmények meghatározásába. Architektúra korai validációja. A tervezés és implementáció komplexitása fokozatosan nő. A minőség korai és gyakori mérése. Változások folyamatos nyomonkövetése. 27
38 A RUP ezen Best PracPce- okon alapul 28
39 A RUP ezen Best PracPce- okon alapul Develop Iteratively Manage Requirements Use Component Architectures Model Visually Continuously Verify Quality Control Change 28
40 A RUP ezen Best PracPce- okon alapul Develop Iteratively Manage Requirements Use Component Architectures Model Visually Continuously Verify Quality Control Change 28
41 A RUP ezen Best PracPce- okon alapul Develop Iteratively Manage Requirements Use Component Architectures Model Visually Continuously Verify Quality Control Change 28
42 A RaPonal Unified Process (RUP) RUP elveinek bemutatása RUP elemeinek bemutatása RUP fázisok bemutatása RUP, mint termék bemutatása
43 A RaPonal Unified Process (RUP) RUP elveinek bemutatása RUP elemeinek bemutatása RUP fázisok bemutatása RUP, mint termék bemutatása
44 Mi a RUP? 31
45 Mi a RUP? Szoftverfejlesztési elv, mely: - Use-case vezérelt - Architektúra központú - Iteratív 31
46 Mi a RUP? Szoftverfejlesztési elv, mely: - Use-case vezérelt - Architektúra központú - Iteratív Szoftverfejlesztési folyamat, mely: - Jól definiált (ki, mit, mikor, hogyan) - Jól strukturált (életciklus, mérföldkövek, döntések) 31
47 Mi a RUP? Szoftverfejlesztési elv, mely: - Use-case vezérelt - Architektúra központú - Iteratív Szoftverfejlesztési folyamat, mely: - Jól definiált (ki, mit, mikor, hogyan) - Jól strukturált (életciklus, mérföldkövek, döntések) Termék a szoftverfejlesztéshez, mely - Testre szabható (projekt méret, ceremónia) - A projekt összes tagjának szolgáltatásokat nyújt 31
48 A RUP, mint szowverfejlesztési elv mopvációja A megrendelői igények kielégítése a cél, ezért ennek kell a központban lenni a folyamat során Minden jól működő rendszernek egy egyszerű, jól működő architektúrája van A szowverfejlesztés bizonytalanságának a csökkentése a fokozatos előrehaladással 32
49 A RUP, mint szowverfejlesztési elv mopvációja A megrendelői igények kielégítése a cél, ezért ennek kell a központban lenni a folyamat során Minden jól működő rendszernek egy egyszerű, jól működő architektúrája van A szowverfejlesztés bizonytalanságának a csökkentése a fokozatos előrehaladással Use case vezérelt 32
50 A RUP, mint szowverfejlesztési elv mopvációja A megrendelői igények kielégítése a cél, ezért ennek kell a központban lenni a folyamat során Use case vezérelt Minden jól működő rendszernek egy egyszerű, jól működő architektúrája van Architektúra centrikus A szowverfejlesztés bizonytalanságának a csökkentése a fokozatos előrehaladással 32
51 A RUP, mint szowverfejlesztési elv mopvációja A megrendelői igények kielégítése a cél, ezért ennek kell a központban lenni a folyamat során Use case vezérelt Minden jól működő rendszernek egy egyszerű, jól működő architektúrája van A szowverfejlesztés bizonytalanságának a csökkentése a fokozatos előrehaladással Architektúra centrikus Inkrementális és iteratív 32
52 Use Case vezérelt 33
53 Architektúra centrikusság: MDA Legend: Mostly text Diagram + text Model Code 34
54 Architektúra centrikusság: MDA Requirements Analysis Design Coding Testing Deployment Legend: Mostly text Diagram + text Model Code 34
55 Architektúra centrikusság: MDA Requirements Analysis Design Coding Testing Deployment Vision/scope SRS SDD Code Code Legend: Mostly text Diagram + text Model Code 34
56 Architektúra centrikusság: MDA Iterative process Requirements Analysis Design Coding Testing Deployment Vision/scope SRS SDD Code Code Legend: Mostly text Diagram + text Model Code 34
57 Architektúra centrikusság: MDA Iterative process Requirements Analysis Design Coding Testing Deployment Vision/scope SRS SDD Code Code Programmer s shortcut Legend: Mostly text Diagram + text Model Code 34
58 Architektúra centrikusság: MDA Iterative process (Non)Functional features Requirements Analysis Design Coding Testing Deployment Vision/scope SRS SDD Code Code Programmer s shortcut Legend: Mostly text Diagram + text Model Code 34
59 Architektúra centrikusság: MDA Iterative process (Non)Functional features Requirements Analysis Design Coding Testing Deployment Vision/scope SRS SDD Code Code Requirements Analysis Design Coding Testing Deployment Programmer s shortcut Legend: Mostly text Diagram + text Model Code 34
60 Architektúra centrikusság: MDA Iterative process (Non)Functional features Requirements Analysis Design Coding Vision/scope SRS SDD Requirements Analysis Design Coding PIM PIM PSM Testing Code Testing Code Deployment Code Deployment Code Programmer s shortcut Legend: Mostly text Diagram + text Model Code 34
61 Architektúra centrikusság: MDA Iterative process (Non)Functional features MDA process (Non)Functional features Requirements Analysis Design Coding Vision/scope SRS SDD Requirements Analysis Design Coding PIM PIM PSM Testing Code Testing Code Deployment Code Deployment Code Programmer s shortcut Legend: Mostly text Diagram + text Model Code 34
62 Az MDA előnyei A befektetej tudás megőrzése Különböző implementációs plauorm Tudás explicijé tétele Fejlesztés felgyorsítása Implementáció jelentős része generált Implementáció minősége Szakértők transzformációs template- eket biztosítanak Karbantartás és dokumentáció Analízis és design modell továbbírása történik meg 100% nyomon követés specifikációtól a teszpg 35
63 Iterabv és inkrementális folyamat Minden iterációban: RADIT lépések Minden iteráció az előzőre épül Konvergál a végleges termékhez 36
64 A RaPonal Unified Process (RUP) RUP elveinek bemutatása RUP elemeinek bemutatása RUP fázisok bemutatása RUP, mint termék bemutatása
65 A fejlesztési folyamat két dimenziója 38
66 A folyamat dinamikus struktúrája Mind a 4 fázis végén mérföldkő és jól definiált termékek: 39
67 A folyamat dinamikus struktúrája Mind a 4 fázis végén mérföldkő és jól definiált termékek: 39
68 A folyamat fázisai KezdeP fázis (IncepPon Phase) Kidolgozási fázis (ElaboraPon Phase) Megvalósítási fázis (ConstrucPon Phase) Átadási fázis (TransiPon Phase) 40
69 A folyamat fontosabb mérföldkövei Inception Elaboration Construction Transition time Lifecycle Objective Milestone Lifecycle Architecture Milestone Initial Operational Capability Milestone Product Release 41
70 Iterációk és fázisok kapcsolata Inception Elaboration Construction Transition Preliminary Iteration Architect. Iteration Architect. Iteration Devel. Iteration Devel. Iteration Devel. Iteration Transition Iteration Transition Iteration Kisebb mérföldkövek: release-k Az iteráció egy jól körülhatárolt tevékenység sor, mely egy megalapozoj terven és kiértékelhető kritériumon alapul, mely egy fujatható release- t (belső/külső) hoz létre. 42
71 A RaPonal Unified Process (RUP) RUP elveinek bemutatása RUP elemeinek bemutatása RUP fázisok bemutatása RUP, mint termék bemutatása
72 Az egyes fázisok ráfordítási szükséglete Inception Elaboration Construction Transition Munka ~5% 20 % 65 % 10% Idő 10 % 30 % 50 % 10% 44
73 KezdeP fázis helye a 45
74 KezdeP fázis főbb tevékenységei Projekt scope Projekt vízió elkészítése: Probléma megfogalmazása Kulcs felhasználók, stakeholder- ek analízise Magasszintű funkcionális, nem funkcionális követelmények megfogalmazása mile- wide, inch- deep felmérése: Aktorok azonosítása Magasszintű use- case- ek elkészítése Fejlesztési folyamat és eszközök meghatározása ÜzleP eset (business case) elkészítése: költség, ütemezés és kockázat becslés 46
75 Kidolgozási fázis helye a 47
76 Kidolgozási fázis főbb tevékenységei Köv. és kock. analízis Követelmények részletes felmérése, kidolgozása (lényegiek) Architektúra megtervezése, implementálása és validációja: Hw és Sw architektúra Építőkockák (building blocks) és IF- ek Technológiai döntések Kockázatok csökkentése: ütemezés, költség és terjedelem finomítása Fejlesztési folyamat finomítása 48
77 Megvalósítási fázis helye a 49
78 Megvalósítási fázis főbb tevékenységei Költség-hatékony fejlesztés Jól megalapozoj architektúra - >fejlesztési tevékenység párhuzamosítása Kimaradt követelmények részletes felmérése, kidolgozása Implementáció és unit- teszt Folyamatos integráció és regressziós tesztelés Megrendelő intenzív bevonása: alfa és béta tesztelés 50
79 Átadási fázis helye a 51
80 Átadási fázis főbb tevékenységei Rendszer finomhangolása Teljesség ellenőrzése Felhasználók oktatása, oktatási anyagok Telepítés a megrendelő telephelyére, konfigurálás Termék elfogadási teszt (kritériumok definiálása a teszt előj!) Tanulságok levonása 52
81 Mi történik átadás után? Fejlesztési ciklus Evolúciós ciklusok emberi tevékenység - termék (gyakori az átlapolódás) Patch- ek készítése 53
82 A fázisok gyakori Nem tévesztendő össze a vízesésmodell hagyományos fázisaival! Figyelembe kell venni mindkét dimenziót ( tevékenység púpok )! Nincs rögzítej munkafolyamat! Nincsenek rögzítej termékek! 54
83 A RaPonal Unified Process (RUP) RUP elveinek bemutatása RUP elemeinek bemutatása RUP fázisok bemutatása RUP, mint termék bemutatása
84 A RaPonal Unified Process (RUP) RUP elveinek bemutatása RUP elemeinek bemutatása RUP fázisok bemutatása RUP, mint termék bemutatása Live show!
85 extreme programming (XP)
86 Közvélemény kutatás Ki szeret napokat eltölteni azzal, hogy követelmény specifikáció és rendszer terv megbeszéléseken részt venni? Ki szeret hosszú és részletes specifikációkat és terv dokumentumokat írni? Ki szeret hosszú és részletesen megtervezett projekt státusz megbeszéléseken ülni? Ki szeret az első követelmény meghallását követően rögtön kódolni? Ki szereti a Java-t, vagy a C++-t? (megengedő vagy! ) Ki szeretne heti 40 órát programozni a munkahelyén, a többi 128-at pedig hobby programozással tölteni? 57
87 Közvélemény kutatás Ki szeret napokat eltölteni azzal, hogy követelmény specifikáció és rendszer terv megbeszéléseken részt venni? Ki szeret hosszú és részletes specifikációkat és terv dokumentumokat írni? Ki szeret hosszú és részletesen megtervezett projekt státusz megbeszéléseken ülni? Ki szeret az első követelmény meghallását követően rögtön kódolni? Ki szereti a Java-t, vagy a C++-t? (megengedő vagy! ) Ki szeretne heti 40 órát programozni a munkahelyén, a többi 128-at pedig hobby programozással tölteni? 57
88 Közvélemény kutatás Ki szeret napokat eltölteni azzal, hogy követelmény specifikáció és rendszer terv megbeszéléseken részt venni? Ki szeret hosszú és részletes specifikációkat és terv dokumentumokat írni? Ki szeret hosszú és részletesen megtervezett projekt státusz megbeszéléseken ülni? Ki szeret az első követelmény meghallását követően rögtön kódolni? Ki szereti a Java-t, vagy a C++-t? (megengedő vagy! ) Ki szeretne heti 40 órát programozni a munkahelyén, a többi 128-at pedig hobby programozással tölteni? 57
89 Közvélemény kutatás Ki szeret napokat eltölteni azzal, hogy követelmény specifikáció és rendszer terv megbeszéléseken részt venni? Ki szeret hosszú és részletes specifikációkat és terv dokumentumokat írni? Ki szeret hosszú és részletesen megtervezett projekt státusz megbeszéléseken ülni? Ki szeret az első követelmény meghallását követően rögtön kódolni? Ki szereti a Java-t, vagy a C++-t? (megengedő vagy! ) Ki szeretne heti 40 órát programozni a munkahelyén, a többi 128-at pedig hobby programozással tölteni? 57
90 Közvélemény kutatás Ki szeret napokat eltölteni azzal, hogy követelmény specifikáció és rendszer terv megbeszéléseken részt venni? Ki szeret hosszú és részletes specifikációkat és terv dokumentumokat írni? Ki szeret hosszú és részletesen megtervezett projekt státusz megbeszéléseken ülni? Ki szeret az első követelmény meghallását követően rögtön kódolni? Ki szereti a Java-t, vagy a C++-t? (megengedő vagy! ) Ki szeretne heti 40 órát programozni a munkahelyén, a többi 128-at pedig hobby programozással tölteni? 57
91 Közvélemény kutatás Ki szeret napokat eltölteni azzal, hogy követelmény specifikáció és rendszer terv megbeszéléseken részt venni? Ki szeret hosszú és részletes specifikációkat és terv dokumentumokat írni? Ki szeret hosszú és részletesen megtervezett projekt státusz megbeszéléseken ülni? Ki szeret az első követelmény meghallását követően rögtön kódolni? Ki szereti a Java-t, vagy a C++-t? (megengedő vagy! ) Ki szeretne heti 40 órát programozni a munkahelyén, a többi 128-at pedig hobby programozással tölteni? 57
92 Közvélemény kutatás Ki szeret napokat eltölteni azzal, hogy követelmény specifikáció és rendszer terv megbeszéléseken részt venni? Ki szeret hosszú és részletes specifikációkat és terv dokumentumokat írni? Ki szeret hosszú és részletesen megtervezett projekt státusz megbeszéléseken ülni? Ki szeret az első követelmény meghallását követően rögtön kódolni? Ki szereti a Java-t, vagy a C++-t? (megengedő vagy! ) Ki szeretne heti 40 órát programozni a munkahelyén, a többi 128-at pedig hobby programozással tölteni? 57
93 Közvélemény kutatás Ki szeret napokat eltölteni azzal, hogy követelmény specifikáció és rendszer terv megbeszéléseken részt venni? Ki szeret hosszú és részletes specifikációkat és terv dokumentumokat írni? Szép lenne az élet mi? Ki szeret hosszú és részletesen megtervezett projekt státusz megbeszéléseken ülni? Ki szeret az első követelmény meghallását követően rögtön kódolni? Ki szereti a Java-t, vagy a C++-t? (megengedő vagy! ) Ki szeretne heti 40 órát programozni a munkahelyén, a többi 128-at pedig hobby programozással tölteni? 57
94 Közvélemény kutatás Ki szeret napokat eltölteni azzal, hogy követelmény specifikáció és rendszer terv megbeszéléseken részt venni? Ki szeret hosszú és részletes specifikációkat és terv dokumentumokat írni? Ki szeret hosszú és részletesen megtervezett projekt státusz megbeszéléseken ülni? Ki szeret az első követelmény meghallását követően rögtön kódolni? Ki szereti a Java-t, vagy a C++-t? (megengedő vagy! ) Ki szeretne heti 40 órát programozni a munkahelyén, a többi 128-at pedig hobby programozással tölteni? 57
95 Közvélemény kutatás Ki szeret napokat eltölteni azzal, hogy követelmény specifikáció és rendszer terv megbeszéléseken részt venni? Ki szeret hosszú és részletes specifikációkat és terv dokumentumokat írni? extreme programming! Ki szeret hosszú és részletesen megtervezett projekt státusz megbeszéléseken ülni? Ki szeret az első követelmény meghallását követően rögtön kódolni? Ki szereti a Java-t, vagy a C++-t? (megengedő vagy! ) Ki szeretne heti 40 órát programozni a munkahelyén, a többi 128-at pedig hobby programozással tölteni? 57
96 Tipikus XP projekt Rövid iterációk (2-3 hét) sorozata Minden iterációban üzlep értékek kerülnek átadásra Működő kód centrikus (állandó tesztelés) Szoros megrendelői együjműködés ( közös fejlesztés a megrendelővel) Naponta stand up megbeszélések (státusz nyomon követés) Kis létszámú programozókból álló Pger team Kis méretű szowver 58
97 Az XP projekt folyamata Forrás: Linda Farrenkopf - Software Methodologies and Impacts to Quality,
98 Tervezési és visszajelzési hurkok az XP- ben Forrás: Per Runeson and Peter Greberg - Extreme Programming and Rational Unified Process,
99 XP 12 szabálya Tervezési folyamat (planning game): Követelményeket storycard- okra írd! (cards on a wall) Teszt eseteket már a követelményeknél definiáld! Felhasználó válasszon az általad írandó funkciók közül a költség becslés alapján! Kis release - ek, rövid ciklusok Mielőbbi fujasd a programot! Mielőbbi szerezz visszajelzést a felhasználótól! Metafora használata Közösen használt nevek és leírásokat használj! Egyszerű tervezés UML- t használhatod, de egyáltalán nem szükséges! (elegendő a code model) 61
100 XP 12 szabálya (folyt.) Tesztelés Tesztelj állandóan! (verifikáció) Ellenőrizesd a felhasználóval! (User acceptance test) Refactoring Írd újra egyszerűbben! Pair programming Minden program funkciót kejen írjatok egy számítógép előj ülve! (állandó code review) Kollekbv tulajdonú kód Minden kódot közös felelősséggel kezeld és vele közös tulajdonként bánj! 62
101 XP 12 szabálya (folyt.) Állandó integráció Minden nap legalább egy kód integrációt hajtsatok végre, amely működik is! 40 óra egy hét Ne dolgozz többet egy héten 40 óránál, különben a minőség rovására megy! On- site customer A felhasználóval szorosan dolgozz együj! Kódolási standardok Tiszta, érthető, közös standardot használjatok a kód megírása során! 63
102 XP szabályok összefüggései Forrás: Per Runeson and Peter Greberg - Extreme Programming and Rational Unified Process,
103 XP összegzése + Nagyon produkbv Projekt kockázatokat hatékonyan kezeli Helyesen futó kódra helyezi a hangsúlyt Vevői megelégedést kiemelten kezeli - 12 fő alaj alkalmas Maximum fél éves kifutású projektek KörnyezeP megkötés (közös légtér) Kultúrális megkötés (kooperáló közösség) Nem specifikál közbenső termékeket 65
104 Agilis metodikák összehasonlítása
105 A RUP, mint agilis szowverfejlesztési elv Az agilitás... annak a képessége, hogy gyorsabban cselekszünk, mint azok a dolgok, melyek negabvan befolyásolhatják a projektet. annak a képessége, hogy a releváns változásokkal: megrendelői igényekkel üzlep célokkal technológiai szükségeletekkel képes lépést tartani. 67
106 Agilis metodikák (RaPonal) Unified Process a 3 amigo : Bootch, Rumbaugh, Jacobson extreme programming (XP) Kent Beck SCRUM - Ken Schwaber, Mike Beedle Dynamic Systems Development Method (DSDM) Feature Driven Development (FDD) - Peter Coad Lean SoWware Development AdapPve SoWware Development - Jim Highsmith Crystal Methodologies - Alistair Cockburn 68
107 A vízeséses, a RUP és az XP metodika összehasonlítása Vízeséses RUP XP Prj mgt Szekvenciális Iteratív Iteratív Team formáció Nagy, erősen struktúrált Közepes méretű, tech. specialisták Programozók párban és prjmgr Követelmény mgt Szigorúan definiált és kezelt Szigorúan definiált és kezelt Programozás közben (stry crd) Elemzés és tervezés Széleskörűen és szigorú exit crit. Adott fázis részletes OO terve Követelmény elemzéssel együtt Tesztelés Modul tesztre koncentrál Tesztelési tervek szerint (U,I,UAT) Automatizált unit tesztre épít és napi integrációra 69
108 SoWware Process Engineering Metamodel Folyamat mintáktól a SPEM- ig RUP és XP modellek
109 SoWware Process Engineering Metamodel Folyamat mintáktól a SPEM- ig RUP és XP modellek
110 Út a folyamat mintákig Számos különböző szowverfejlesztési folyamat jöj létre. Mindegyik best pracpce - eket foglal magába néhány új ötlejel kiegészítve. A Design pajern- ök bebizonyítoják az előnyüket a szowver tervezése során, ezért ez az ötlet lej alkalmazva a szowverfejlesztési folyamatok szintjén is. 72
111 Út a folyamat mintákig Számos különböző szowverfejlesztési folyamat jöj létre. Mindegyik best pracpce - eket foglal magába néhány új ötlejel kiegészítve. A Design pajern- ök bebizonyítoják az előnyüket a szowver tervezése során, ezért ez az ötlet lej alkalmazva a szowverfejlesztési folyamatok szintjén is. 72
112 Út a folyamat mintákig Számos különböző szowverfejlesztési folyamat jöj létre. Mindegyik best pracpce - eket foglal magába néhány új ötlejel kiegészítve. A Design pajern- ök bebizonyítoják az előnyüket a szowver tervezése során, ezért ez az ötlet lej alkalmazva a szowverfejlesztési folyamatok szintjén is. Folyamat minták: A folyamat minták kipróbált és sikeresnek talált folyamatlépések sorozatát foglalja magába. 72
113 Észrevételek a folyamat mintákra A szöveges folyamat minta leírások alkalmazása nehézkes A minták testreszabása nagy munka Nincs formális leírásuk 73
114 Észrevételek a folyamat mintákra A szöveges folyamat minta leírások alkalmazása nehézkes A minták testreszabása nagy munka Nincs formális leírásuk 73
115 Észrevételek a folyamat mintákra A szöveges folyamat minta leírások alkalmazása nehézkes A minták testreszabása nagy munka Nincs formális leírásuk SPEM Software Process Engineering Meta-model 73
116 Észrevételek a folyamat mintákra A szöveges folyamat minta leírások alkalmazása nehézkes A minták testreszabása nagy munka Nincs formális leírásuk SPEM lehetővé teszi a formális definíciót! SPEM Software Process Engineering Meta-model 73
117 Észrevételek a folyamat mintákra A szöveges folyamat minta leírások alkalmazása nehézkes A minták testreszabása nagy munka Nincs formális leírásuk SPEM Software Process Engineering Meta-model Folyamat minták Gamma-szerű leírása lehetségesé válik! SPEM lehetővé teszi a formális definíciót! 73
118 Észrevételek a folyamat mintákra A szöveges folyamat minta leírások alkalmazása nehézkes A minták testreszabása nagy munka Nincs formális leírásuk SPEM Software Process Engineering Meta-model Folyamat minták Gamma-szerű leírása lehetségesé válik! SPEM lehetővé teszi a formális definíciót! 73
119 Észrevételek a folyamat mintákra A szöveges folyamat minta leírások alkalmazása nehézkes A minták testreszabása nagy munka Nincs formális leírásuk SPEM Software Process Engineering Meta-model Folyamat minták Gamma-szerű leírása lehetségesé válik! SPEM lehetővé teszi a formális definíciót! Eszköztámogatás is megoldható! 73
120 SoWware Process Engineering Metamodel SPEM: egy UML profile, amely szowver process modellezésre lej kifejlesztve egy OMG specifikáció Folyamat struktúra: WorkProduct, WorkDefiniPon, AcPvity, Step Folyamat komponens: Process, Discipline Folyamat életciklus: Phase, IteraPon 74
121 SPEM helye a modellek közöj 75
122 SPEM helye a modellek közöj SPEM helye 75
123 RUP konfigurációk 76
124 SoWware Process Engineering Metamodel Folyamat mintáktól a SPEM- ig RUP és XP modellek
125 SoWware Process Engineering Metamodel Folyamat mintáktól a SPEM- ig RUP és XP modellek Live show!
126 RUP referenciák I. Jacobson, G. Booch, J. Rumbaugh, The Unified So=ware Development Process, Addison Wesley 1999 P. Kroll, P. Kruchten, RaAonal Unified Process Made Easy, Addison Wesley 2003 P. Robillard, P. Kruchten, So=ware Engineering Process with the UPEDU, Addison Wesley 2003 M. Paulk, B. CurPs, M. Chrissis, C. Weber, Capability Maturity Model for So=ware, Tech. Report 1993 CMU SEI Website: 78
127 XP referenciák Kent Beck. Extreme Programming Explained: Embrace Change. Jeffries, Ron, Ann Anderson, and Chet Hendrickson. Extreme Programming Installed. Beck, Kent and MarPn Fowler. Planning Extreme Programming. Craig Larman: Agile and IteraAve Development: Manager's Guide Websites:
Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve
Hatékony iteratív fejlesztési módszertan a gyakorlatban a RUP fejlesztési módszertanra építve Kérdő Attila, ügyvezető, INSERO Kft. EOQ MNB, Informatikai Szakosztály, HTE, ISACA 2012. május 17. Módszertanok
Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Munkafolyamat (Workflow): azoknak a lépéseknek a sorozata,
The Unified Software Development Process. Történet. Feltételek. Rational Unified Process. Krizsán Zoltán Ficsor Lajos
The Unified Software Development Process Rational Unified Process Krizsán Zoltán Ficsor Lajos Miskolci Egyetem Általános Informatikai Tanszék Utolsó módosítás: 2007. 12. 04. Történet The Rational Rational
01. gyakorlat - Projektalapítás
2 Követelmények 01. gyakorlat - Projektalapítás Szoftvertechnológia gyakorlat OE-NIK A félév során egy nagyobb szoftverrendszer prototípusának elkészítése lesz a feladat Fejlesztési módszertan: RUP CASE-eszköz:
V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus
V. Félév Információs rendszerek tervezése Komplex információs rendszerek tervezése dr. Illyés László - adjunktus 1 Az előadás tartalma A GI helye az informatikában Az előadás tartalmának magyarázata A
Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Ez vajon egy állapotgép-e? Munkafolyamat (Workflow):
UML (Unified Modelling Language)
UML (Unified Modelling Language) UML (+ Object Constraint Language) Az objektum- modellezés egy szabványa (OMG) UML A 80-as, 90-es években egyre inkább terjedő objektum-orientált analízis és tervezés (OOA&D)
TESZTELÉS A SZOFTVER ÉLETCIKLUSÁN ÁT SZOFTVERFEJLESZTÉSI MODELLEK
TESZTELÉS A SZOFTVER ÉLETCIKLUSÁN ÁT SZOFTVERFEJLESZTÉSI MODELLEK MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR, GÉPÉSZET, INFORMATIKA,
Fejlesztési projektek menedzselése IBM Rational CLM termékekkel. Ker-Soft Kft. Kaszás Orsolya - üzleti tanácsadó
Fejlesztési projektek menedzselése IBM Rational CLM termékekkel Ker-Soft Kft. Kaszás Orsolya - üzleti tanácsadó Tartalom I. CLM termékek rövid ismertetése II. Projekt menedzsment módszertanokról III. Demo
A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom
A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-folyamat Szoftver
Verifikáció és validáció Általános bevezető
Verifikáció és validáció Általános bevezető Általános Verifikáció és validáció verification and validation - V&V: ellenőrző és elemző folyamatok amelyek biztosítják, hogy a szoftver megfelel a specifikációjának
Életciklus modellek a rendszer és szoftverrendszer-fejlesztésben. SDLC System Development Life Cycle Software Development Life Cycle
Életciklus modellek a rendszer és szoftverrendszer-fejlesztésben SDLC System Development Life Cycle Software Development Life Cycle Mi az életciklus? A termék piacon való megjelenésétől a kivonásáig terjedő
Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata
Angolul: Extreme Programming, röviden: XP Agilis módszertan. Más módszertanok bevált technikáinak extrém módú (nagyon jó) használata jelentése: gyors, fürge 1990-es évek vége Változás igénye Módszertan-család
A szoftver-folyamat. Szoftver életciklus modellek. Szoftver-technológia I. Irodalom
A szoftver-folyamat Szoftver életciklus modellek Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 4. Roger S. Pressman: Software Engineering, 5th e. chapter 2. 2 A szoftver-technológia aspektusai
Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár
Software Engineering Dr. Barabás László Ismétlés/Kitekintő Ismétlés Software Engineering = softwaretechnológia Projekt, fogalma és jellemzői, személyek és szerepkörök Modell, módszertan Kitekintés Elemzés/
(Teszt)automatizálás. Bevezető
(Teszt)automatizálás Bevezető Órák ( az előadások sorrendje változhat) 1. Bevezető bemutatkozás, követelmények, kérdések és válaszok 2. Előadás Unit test in general, 3. Előadás Unit test, Tools and practices,
Információs rendszerek Információsrendszer-fejlesztés
Információs rendszerek Információsrendszer-fejlesztés A rendszerfejlesztés életciklusa problémadefiniálás helyzetfeltárás megvalósítási tanulmány döntés a fejlesztésrıl ELEMZÉS IMPLEMENTÁCIÓ programtervezés
MIÉRT KELL TESZTELNI?
Unrestricted MIÉRT KELL TESZTELNI? MIÉRT KELL TESZTELNI? A termékminőség fejlesztése...hogy megtaláljuk a hibákat, mert azok ott vannak... MIÉRT KELL TESZTELNI? Hogy felderítsük, mit tud a szoftver MIÉRT
A CMMI alapú szoftverfejlesztési folyamat
A CMMI alapú szoftverfejlesztési folyamat Készítette: Szmetankó Gábor G-5S8 Mi a CMMI? Capability Maturity Modell Integration Folyamat fejlesztési referencia modell Bevált gyakorlatok, praktikák halmaza,
Minőségmenedzsment és Informatika Test-Driven Development
Minőségmenedzsment és Informatika Test-Driven Development Varga Balázs G5S8 2008.10.27 Szoftverfejlesztés jellemzői Megrendelői igények Tervezés Implementálás Tesztelés Dokumentálás
Szoftvertechnológia 12. előadás. Szoftverfejlesztési módszerek és modellek. Giachetta Roberto. Eötvös Loránd Tudományegyetem Informatikai Kar
Eötvös Loránd Tudományegyetem Informatikai Kar Szoftvertechnológia 12. előadás Szoftverfejlesztési módszerek és modellek Giachetta Roberto groberto@inf.elte.hu http://people.inf.elte.hu/groberto A szoftver
extreme Programming programozástechnika
extreme Programming programozástechnika Készítette: Török T k Balázs G5-S8 Kezdetek Martin Fowler : The New Methodology Legtöbb projekt követelményei állandóan változnak Megoldást adaptív módszerek Kezdetek
Név: Neptun kód: Pontszám:
Név: Neptun kód: Pontszám: 1. Melyek a szoftver minőségi mutatói? Fejlesztési idő, architektúra, programozási paradigma. Fejlesztőcsapat összetétele, projekt mérföldkövek, fejlesztési modell. Karbantarthatóság,
Tartalom. Szoftverfejlesztési. Szoftver = Termék. módszertan. la Rational XDE CASE eszköz. Az előállításához technológiára van szükség
Tartalom 6. Unified Process & Rational Unified Process lmi a szoftverfejlesztési módszertan? lunified Process lrational Unified Process (RUP) la Rational XDE CASE eszköz lpélda BMF-NIK-SZTI Tick: Szoftver
Bevezetés a programozásba
Bevezetés a programozásba A szoftverfejlesztés folyamata PPKE-ITK Tartalom A rendszer és a szoftver fogalma A szoftver, mint termék és készítésének jellegzetességei A szoftverkészítés fázisai: Az igények
Intelligens eszközök fejlesztése az ipari automatizálásban Evosoft Hungary kft., Evosoft Hungary Kft.
Intelligens eszközök fejlesztése az ipari automatizálásban Evosoft Hungary kft., Evosoft Hungary Kft. Intelligens eszközök fejlesztése az ipari automatizálásban Evosoft Hungary kft., Evosoft Hungary Kft.
Agilis projektmenedzsment
Agilis projektmenedzsment 2013. április 10. 1 Adaptive Consulting Kft. Csutorás Zoltán Agile coach, tréner zoltan.csutoras@adaptiveconsulting.hu 2 www.scrummate.hu 3 Agilis ernyő Scrum Lean/Kanban Crystal
4. A szoftvergyártás folyamata
4. A szoftvergyártás folyamata Kérdések Mi a szoftvergyártás modellje? Mi a három alapvető modell és mikor használjuk ezeket? Mik a követelménytervezés, a szoftverfejlesztés, a tesztelés és az szoftver-evolúció
Folyamatmodellezés és eszközei. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Folyamatmodellezés és eszközei Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Folyamat, munkafolyamat Munkafolyamat (Workflow): azoknak a lépéseknek a sorozata,
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2017-18/2 (2) Szoftverminőségbiztosítás A szoftverminőségbiztosítási rendszer A szoftver-minőségbiztosítási rendszer összetevői Minőségbiztosítási rendszer Minőség menedzsment Minőségbiztosítás
Objektum orientált software fejlesztés (Bevezetés)
Objektum orientált software fejlesztés (Bevezetés) Lajos Miskolci Egyetem Általános Informatikai Tanszék Út az objektum orientált szemléletig 1. Klasszikus módszerek: program = adatszerkezetek + algoritmusok
A szoftverfejlesztés eszközei
A szoftverfejlesztés eszközei Fejleszt! eszközök Segédeszközök (szoftverek) programok és fejlesztési dokumentáció írásához elemzéséhez teszteléséhez karbantartásához 2 Történet (hw) Lyukkártya válogató
Verziókövető rendszerek használata a szoftverfejlesztésben
Verziókövető rendszerek használata a szoftverfejlesztésben Dezső Balázs Szakszeminárium vezető: Molnár Bálint Budapesti Corvinus Egyetem Budapest, 2009. június 24. 1 Bevezetés 2 Verziókövetőrendszerek
Modellinformációk szabványos cseréje. Papp Ágnes, Debreceni Egyetem EFK
Modellinformációk szabványos cseréje Papp Ágnes, agi@delfin.unideb.hu Debreceni Egyetem EFK Tartalom MOF, UML, XMI Az UML és az XML séma MDA - Model Driven Architecture Networkshop 2004 2 Az OMG metamodell
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (2) Szoftverminőségbiztosítás A szoftverminőségbiztosítási rendszer A szoftver-minőségbiztosítási rendszer összetevői Szoftver minőségi alapkérdések Hogyan hasznosítsuk a know-how-t
SW-project management
SW-project management 1 PM tárgya tervezés megfigyelés ellenőrzés emberek folyamat események 4P People (emberek) Product (termék) Process (folyamat) Project PM szintjei 3 SW előállítási folyamat bizonytalansága
IT Factory. Kiss László
IT Factory Kiss László Mit jelent az IT Factory Együttműködő építőelemekből áll, amelyek jól definiált céllal, feladattal rendelkeznek. A tervezés és megvalósítás világosan elkülönül. A folyamatok és teljesítmény
Modell alapú tesztelés mobil környezetben
Modell alapú tesztelés mobil környezetben Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék A terület behatárolása Testing is an activity performed
Teszt terv Új funkció implementációja meglévı alkalmazásba
Teszt terv Új funkció implementációja meglévı alkalmazásba Passed Informatikai Kft. www.passed.hu Farkas Gábor 2007-P-123-45-T-1-1 IIR - Test Manager course 2 Szerepkör Név Aláírás Aláírás dátuma IT Projekt
A TANTÁRGY ADATLAPJA
A TANTÁRGY ADATLAPJA 1. A képzési program adatai 1.1. Felsőoktatási intézmény Babeş Bolyai Tudományegyetem 1.2. Kar Matematika és Informatika 1.3. Intézet Magyar Matematika és Informatika 1.4. Szakterület
Szoftvertechnológia ellenőrző kérdések 2005
Szoftvertechnológia ellenőrző kérdések 2005 Mi a szoftver, milyen részekből áll és milyen típusait különböztetjük meg? Mik a szoftverfejlesztés általános lépései? Mik a szoftvergyártás általános modelljei?
A szoftver tesztelés alapjai
Szoftverellenőrzési technikák A szoftver tesztelés alapjai Micskei Zoltán, Majzik István http://www.inf.mit.bme.hu/ 1 Hol tartunk a félévi anyagban? Követelményspecifikáció ellenőrzése Ellenőrzések a tervezési
Miskolci Egyetem Általános Informatikai Tanszék
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
A tesztelés feladata. Verifikáció
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
TESZTMENEDZSMENT TESZTELŐ SZERVEZET TESZTTERVEZÉS ÉS BECSLÉS
TESZTMENEDZSMENT TESZTELŐ SZERVEZET TESZTTERVEZÉS ÉS BECSLÉS MUNKAERŐ-PIACI IGÉNYEKNEK MEGFELELŐ, GYAKORLATORIENTÁLT KÉPZÉSEK, SZOLGÁLTATÁSOK A DEBRECENI EGYETEMEN ÉLELMISZERIPAR, GÉPÉSZET, INFORMATIKA,
Szoftvertechnológia szakirány
Szoftvertechnológia szakirány A szakirány keretében a hallgatók a jó minõségû szoftvertermékek elõállításához szükséges módszertani, technológiai és szervezési ismereteket szerezhetik meg. A súlypontot
Szoftver újrafelhasználás
Szoftver újrafelhasználás Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással
Nagy bonyolultságú rendszerek fejlesztőeszközei
Nagy bonyolultságú rendszerek fejlesztőeszközei Balogh András balogh@optxware.com A cég A BME spin-off-ja A Hibatűrő Rendszerek Kutatócsoport tagjai alapították Tisztán magánkézben Szakmai háttér Hibatűrő
Hogyan lehet megakadályozni az üzleti modellezés és az IT implementáció szétválását? Oracle BPM Suite
Hogyan lehet megakadályozni az üzleti modellezés és az IT implementáció szétválását? Oracle BPM Suite Petrohán Zsolt Vezető tanácsadó zsolt.petrohan@oracle.com Napirend Oracle Fusion Middleware BPM kihívásai
2. A szoftver mint termék llításának folyamata, a szoftver életciklus modelljei
2. A szoftver mint termék előáll llításának folyamata, a szoftver életciklus modelljei A szoftverfolyamat modellje a szoftverfolyamat absztrakt reprezentációja egy adott speciális aspektusból. Szokásos
S01-7 Komponens alapú szoftverfejlesztés 1
S01-7 Komponens alapú szoftverfejlesztés 1 1. A szoftverfejlesztési modell fogalma. 2. A komponens és komponens modell fogalma. 3. UML kompozíciós diagram fogalma. 4. A szoftverarchitektúrák fogalma, összetevői.
A szoftverellenőrzés szerepe
A szoftverellenőrzés szerepe Majzik István majzik@mit.bme.hu http://www.inf.mit.bme.hu/ 1 Motiváció Tartalomjegyzék Milyen minőségi igények vannak a szoftverrel szemben, és mit tud ma a szoftveripar? Miért
Software Engineering Babeş-Bolyai Tudományegyetem Kolozsvár
Software Engineering Dr. Barabás László Ismétlés/Kitekintő Software Engineering = softwaretechnológia Projekt, fogalma és jellemzői, Személyek és szerepkörök Kitekintő: Modell, módszertan 2 Dr. Barabás
Közösség, projektek, IDE
Eclipse Közösség, projektek, IDE Eclipse egy nyílt forráskódú (open source) projekteken dolgozó közösség, céljuk egy kiterjeszthető fejlesztői platform és keretrendszer fejlesztése, amely megoldásokkal
Software engineering (Software techológia) Bevezetés, alapfogalmak. Történelem 1. Történelem as évek Megoldandó problémák: Fejlesztő: Eszköz:
Software engineering (Software techológia) Bevezetés, alapfogalmak Utolsó módosítás: 2006. 02. 16. SWENGBEV / 1 Történelem 1. 60-as évek Megoldandó problémák: egyedi problémákra kis programok Fejlesztő:
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (3) Szoftverminőségbiztosítás A szoftverminőségbiztosítási rendszer (folyt.) Eljárások, munkautasítások Eljárás: egy adott módja valami elvégzésének részletezett tevékenységek,
Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E
Alkalmazások fejlesztése A D O K U M E N T Á C I Ó F E L É P Í T É S E Követelmény A beadandó dokumentációját a Keszthelyi Zsolt honlapján található pdf alapján kell elkészíteni http://people.inf.elte.hu/keszthelyi/alkalmazasok_fejlesztese
TOGAF elemei a gyakorlatban
TOGAF elemei a gyakorlatban Vinczellér Gábor 2009.06.0406 04 8 éves szakmai tapasztalat Bemutatkozás IT Support, Programozó, jelenleg Projektvezető, Termékfejlesztési Üzletág Vezető Tanácsadási és Szoftverfejlesztési
Sapientia - Erdélyi Magyar TudományEgyetem (EMTE) Csíkszereda IRT 6. kurzus
Sapientia - Erdélyi Magyar TudományEgyetem (EMTE) Csíkszereda IRT 6. kurzus 5-ös Kurzus (UML) Visszatekintés: történelmi szempontok Az UML létrejötte UML-1 (Unified Modeling Language) és UML-2 Magyarul
Szoftver-technológia I.
Szoftver technológia I. Oktatók Sziray József B602 Heckenast Tamás B603 2 Tananyag Elektronikus segédletek www.sze.hu/~sziray/ www.sze.hu/~heckenas/okt/ (www.sze.hu/~orbang/) Nyomtatott könyv Ian Sommerville:
Szoftver-technológia II. Szoftver újrafelhasználás. (Software reuse) Irodalom
Szoftver újrafelhasználás (Software reuse) Irodalom Ian Sommerville: Software Engineering, 7th e. chapter 18. Roger S. Pressman: Software Engineering, 5th e. chapter 27. 2 Szoftver újrafelhasználás Szoftver
Projectvezetők képességei
Projectvezetők képességei MOI modell Motivation ösztönzés Organisation szervezés Ideas or Innovation ötletek vagy újítás Más felosztás Probléma megoldás Vezetői öntudat Teljesítmény Befolyás, team képzés
Komponens alapú fejlesztés
Komponens alapú fejlesztés Szoftver újrafelhasználás Szoftver fejlesztésekor korábbi fejlesztésekkor létrehozott kód felhasználása architektúra felhasználása tudás felhasználása Nem azonos a portolással
Modellezési Kockázat. Kereskedelmi Banki Kockázatmodellezés. Molnár Márton Modellezési Vezető (Kockázatkezelés)
Modellezési Kockázat Kereskedelmi Banki Kockázatmodellezés Molnár Márton Modellezési Vezető (Kockázatkezelés) Modellek Kockázata Adathibák Szabályozói elvárások figyelmen kívül hagyása Becslési Bizonytalanság
Előzmények 2011.10.23.
Előzmények Dr. Mileff Péter A 80-as évek közepétől a szoftverek komplexitása egyre növekszik. Megjelentek az OO nyelvek. Az OO fejlesztési módszerek a rendszer különböző nézőpontú modelljeit készítik el.
Programfejlesztési Modellek
Programfejlesztési Modellek Programfejlesztési fázisok: Követelmények leírása (megvalósíthatósági tanulmány, funkcionális specifikáció) Specifikáció elkészítése Tervezés (vázlatos és finom) Implementáció
Kis-és nagyvállalatok együttműködésének előnyei és nehézségei a projektmenedzser szemével. Gyutai Balázs Loxon Tessényi András - Supercharge
Kis-és nagyvállalatok együttműködésének előnyei és nehézségei a projektmenedzser szemével Gyutai Balázs Loxon Tessényi András - Supercharge Kik Vagyunk Szoftverfejlesztő cégünk nagy üzleti tudással és
S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN. Structured Systems Analysis and Design Method
S S A D M ELEMZÉSI ÉS TERVEZÉSI MÓDSZERTAN Structured Systems Analysis and Design Method Mi az SSADM? Kifejezetten a rendszerelemzést és a szoftverfejlesztést támogatja. Eljárási, műszaki és dokumentációs
A CMMI alapú szoftverfejlesztési si folyamat
A CMMI alapú szoftverfejlesztési si folyamat Készítette: Szmetankó Gábor G-5S8 Mi a CMMI? Capability Maturity Modell Integration Folyamat Folyamat fejlesztési si referencia modell Bevált gyakorlatok, praktikák
Ami a vízesésen túl van
Ami a vízesésen túl van Adattárház fejlesztés módszertani tapasztalatok a T-Systems adattárházában, a HIFI-ben Ponori.Ajtony@iqpp.hu 2012. június 12. Miről is lesz szó? HIFI háttér HIFI projekt szkóp Két
A fejlesztési szabványok szerepe a szoftverellenőrzésben
A fejlesztési szabványok szerepe a szoftverellenőrzésben Majzik István majzik@mit.bme.hu http://www.inf.mit.bme.hu/ 1 Tartalomjegyzék Biztonságkritikus rendszerek A biztonságintegritási szint Az ellenőrzés
DW 9. előadás DW tervezése, DW-projekt
DW 9. előadás DW tervezése, DW-projekt Követelmény felmérés DW séma tervezése Betöltési modul tervezése Fizikai DW tervezése OLAP felület tervezése Hardver kiépítése Implementáció Tesztelés, bevezetés
Szabálykezelés a gyakorlatban
Szabálykezelés a gyakorlatban ILOG-eszközökkel Ivicsics László vezető tanácsadó BCA Hungary 2008. június 25. Üzleti folyamatok és szabályok Üzleti folyamatok Munkautasítások Szabályzatok Példa: Hitelképesség
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (13) Szoftverminőségbiztosítás Szoftverminőség és formális módszerek Formális módszerek Formális módszer formalizált módszer(tan) Formális eljárások alkalmazása a fejlesztésben
Software Engineering
Software Engineering Software Engineering Software Engineering értelmezése Az a folyamat, mely eredményekénk létrehozunk egy adott feladatot megvalósító szoftver rendszert. Tevékenységek, technológia,
Orvostechnikai eszköz tesztelése DSS Unit test. Taliga Miklós BME-IIT
Orvostechnikai eszköz tesztelése DSS Unit test Taliga Miklós BME-IIT Szabványok és direktívák Orvostechnikai eszközök feladatai Objektív eredmények képzése Embernek érzékelhetetlen paraméterek mérése Sokféle
Pénzügy, számvitel. Váradi Mónika 2013.01.29.
Pénzügy, számvitel Váradi Mónika 2013.01.29. Pénzügy, számvitel A rendszer megoldást nyújt a teljeskörű pénzügyi, számviteli műveletek elvégzésére a törvényi megfelelőségek biztosítása mellett. Pénzügy,
Adattárház kialakítása a Szövetkezet Integrációban, UML eszközökkel. Németh Rajmund Vezető BI Szakértő március 28.
Adattárház kialakítása a Szövetkezet Integrációban, UML eszközökkel Németh Rajmund Vezető BI Szakértő 2017. március 28. Szövetkezeti Integráció Központi Bank Takarékbank Zrt. Kereskedelmi Bank FHB Nyrt.
Scrum vagy nem scrum - ahol nem hibázhatunk Röviden a budapesti fejlesztési központról
Röviden a budapesti fejlesztési központról MIT? Érzékelés, mérés Ultrahang (Beparkolás) Video (számtalan szolgáltatás) Radar (Ködben, sötétben ) Műszerfal Szabályzás Váltó és motor Menetstabilizálás (ESP)
IRÁNYTŰ A SZABÁLYTENGERBEN
IRÁNYTŰ A SZABÁLYTENGERBEN amikor Bábel tornya felépül BRM konferencia 2008 október 29 BCA Hungary A Csapat Cégalapítás: 2006 Tanácsadói létszám: 20 fő Tapasztalat: Átlagosan 5+ év tanácsadói tapasztalat
Miért is transzformáljunk modelleket? Varró Dániel
Miért is transzformáljunk modelleket? Varró Dániel Mit látunk a képen? Tipikus kérdések (Hardvertervezés) Jól működik-e? 1+1 = 2? Hogyan készítsünk 8 bites összeadót 4 bites összeadóval? Hogyan készítsünk
Bevezetés a programozásba előadás: Alapvető programtervezési elvek
Bevezetés a programozásba 2 12. előadás: Alapvető programtervezési elvek Miről lesz szó A félév célja a nagyobb programrendszerek felépítésében való részvétel képességét megszerezni Mindenki a saját widgetkészletének
Azonnali fizetési rendszer megvalósítása
Azonnali fizetési rendszer megvalósítása 2017. 05. 24. Keretek, alapvetések, megoldandók (minden projekt résztvevőnek) 24/7/365-ös működés (folyamatos működés a karbantartások, upgrade-ek alatt is). Tranzakciók
Böngészők, böngészőmotorok
Böngészők, böngészőmotorok WebKit, Blink, Servo Elismert fejlesztők: 20+ contributor, committer, reviewer 6. legaktívabb csapat (akadémiában első) K+F: Optimalizálás: JIT, párhuzamosítás, GPU Tesztelés:
Fejlesztési modellek és módszertanok
2016/11/11 08:50 1/15 Fejlesztési modellek és módszertanok < Szoftverfejlesztés Fejlesztési modellek és módszertanok Szerző: Sallai András Copyright Sallai András, 2014 Licenc: GNU Free Documentation License
Gyakorlat és házi feladat tájékoztató
Szoftverellenőrzési technikák (VIMIM148) Gyakorlat és házi feladat tájékoztató Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Szoftverellenőrzési
Szoftverminőségbiztosítás
NGB_IN003_1 SZE 2014-15/2 (7) Szoftverminőségbiztosítás Szoftvertesztelési folyamat Szoftverek és környezet Nem egyforma a szoftverek használatához kapcsolódó kockázat Különböző kockázati szintek -> eltérő
A TANTÁRGY ADATLAPJA
A TANTÁRGY ADATLAPJA 1. A képzési program adatai 1.1 Felsőoktatási intézmény Babeș Bolyai Tudományegyetem 1.2 Kar Matematika és Informatika Kar 1.3 Intézet Magyar Matematika és Informatika Intézet 1.4
Összetett szoftverrendszerek fejlesztése Innovatív szoftver prototípusok a Codespring Mentorprogram keretein belül
Összetett szoftverrendszerek fejlesztése Innovatív szoftver prototípusok a Codespring Mentorprogram keretein belül Simon Károly simon.karoly@codespring.ro Miért nem? Új, természetből inspirált számítástechnikai
Az alkalmazás minőségbiztosítás folyamata Fókuszban a teszt-automatizálás
Az alkalmazás minőségbiztosítás folyamata Fókuszban a teszt-automatizálás Alvicom HP szeminárium 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without
KOGGM614 JÁRMŰIPARI KUTATÁS ÉS FEJLESZTÉS FOLYAMATA
KOGGM614 JÁRMŰIPARI KUTATÁS ÉS FEJLESZTÉS FOLYAMATA System Design Wahl István 2019.03.26. BME FACULTY OF TRANSPORTATION ENGINEERING AND VEHICLE ENGINEERING Tartalomjegyzék Rövidítések A rendszer definiálása
Előadók: Angyal Gergely (Raiffeisen), tesztelési csoportvezető Kováts Márton (KFKI), szenior rendszermérnök 2010.03.25.
Fejlesztéskövetés fejvesztés nélkül, avagy Kiadáskezelés megvalósítása banki környezetben Előadók: Angyal Gergely (Raiffeisen), tesztelési csoportvezető Kováts Márton (KFKI), szenior rendszermérnök 2010.03.25.
Programozási technológia 2.
Programozási technológia 2. Dr. Szendrei Rudolf ELTE Informatikai Kar 2018. Információk Képzés Programtervező Informatikus BSc, nappali tagozat, C szakirány Tárgykód: IP-17cPROGT2EG Előfeltétel (erős):
Modell alapú tesztelés: célok és lehetőségek
Szoftvertesztelés 2016 Konferencia Modell alapú tesztelés: célok és lehetőségek Dr. Micskei Zoltán Budapesti Műszaki és Gazdaságtudományi Egyetem Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika
Szoftverspecifikáció fázis: Követelmény specifikáció. 2. fázis: Követelmények feltárása és elemzése
Folyamattevékenységek Dr. Mileff Péter Alapvetıen négy különbözı folyamattevékenység: Specifikáció (követelménytervezés) Tervezés és implementáció Validáció Evolúció Ezeket a különféle fejlesztési folyamatmodellek
Járműinformatika A járműinformatikai fejlesztés
Járműinformatika A járműinformatikai fejlesztés 2016/2017. tanév, II. félév Dr. Kovács Szilveszter E-mail: szkovacs@iit.uni-miskolc.hu Informatika Intézet 107/a. Tel: (46) 565-111 / 21-07 A járműfejlesztés
A DevOps-kultúra eszközei
ELTE Informatikai Kar, Programozási Nyelvek és Fordítóprogramok Tanszék patakino@elte.hu Neumann Konferencia Mi az a DevOps? Development & Operations Alapok Szoftverfejlesztés: csapatmunka Csapatmunka
Kód átvizsgálás. Irodalom. (Code review) code review,smart Bear Inc., ! Jason Cohen: Best kept secrets of peer
Kód átvizsgálás (Code review) 2 Irodalom! Jason Cohen: Best kept secrets of peer code review,smart Bear Inc., 2006 3 Célok, el!nyök! Jobb min!ség" kód! jobban karbantartható! Kevesebb hiba a kódban! rövidebb
Autóipari beágyazott rendszerek Dr. Balogh, András
Autóipari beágyazott rendszerek Dr. Balogh, András Autóipari beágyazott rendszerek Dr. Balogh, András Publication date 2013 Szerzői jog 2013 Dr. Balogh András Szerzői jog 2013 Dunaújvárosi Főiskola Kivonat
SOA projektmenedzsment. Kondorosi Károly BME IIT, 2011.
SOA projektmenedzsment Kondorosi Károly BME IIT, 2011. Tartalom Projektmenedzsment - általában SOA projektek tulajdonságai SOA projektek menete (roadmap) Zachman Framework TOGAF Gartner EA Process Model