A szoftverfejleszt

1
A szoftverfejlesztési módszertan

• A fejlesztési modellek a fejlesztési folyamat
  átfogó, koncepcionális modelljét írják le
• Útmutatást ad a csoportmunka irányítására
• Meghatározza, hogy milyen termékeket kell
  kifejleszteni és mikor
• Meghatározza az egyes fejlesztoknek, valamint a
  csoportnak a feladatát
• Kritériumokat ad a termékek és tevékenységek
  mérésére és minosítésére
• Ritkán jelennek meg tiszta, ideális formában
• A fejlesztési folyamat egyfajta logikai
  absztrakciója.

2
Szoftverfejlesztési modellek (életciklus modellek)

• Do Until Done modell
• Vízesés modell
• V-Modell
• Evolúciós modell
• Iteratív fejlesztések
• Spirál modell
• Inkrementális fejlesztés (UP, RUP)

Az ido és az információ áramlása szerint
tárgyalják, csoportosítják a fejlesztési
tevékenységeket
A modellválasztás függ a feladat jellegétol.
Például kis project számára a vízesés modell
lehet a legjobb, egy nagy projectnek viszont
megfelelobb lehet egy iteratív eljárás.
3
A vízesés modell

• A modell eredeti fázisai (Royce, 1970)

4

• A fejlesztés fázisai szekvenciálisan követik
  egymást
• Ironikus módon Royce mint vitatott modellt említi
  a tanulmányában, hiszen nincs visszacsatolás,
  iteráció.
• This process is represented by the "Waterfall"
  Model, which serves as the conceptual guideline
  for almost all Air Force and NASA software
  development. (www1.jsc.nasa.gov)
• Módosítás visszacsatolás az elozo fázisokra

5
A fázisokról röviden

• Requirements (követelmények) A felhasználó
  igényeinek analizálása, a szoftverrel szemben
  támasztott követel-mények összegyujtése
  (Requirements Specification Document)
• Design (tervezés)
• System Design hardver, szoftver környezet,
  architektúra (blokkok, interfészek) (System
  Architecture Document)
• Software Design a rendszerarchitektúra fo
  szoftver blokkjainak továbbbontása modulokra
  (Software Design Document)
• Implementation (implementáció, kódolás) A
  rendszer egységeinek kódolása
• Software Integration Verification modulok
  egyesítése, tesztelése
• Maintenance (karbantartás) átadás a
  felhasználónak, esetleges módosítások

6
A vízesés-modell elonyei

• Nemcsak a szoftverfejlesztésnél használható,
  hanem egyéb végfelhasználói projekteknél is.
• A jól értheto és kevésbé komplex projektek esetén
  szabályozottan rögzíti a komplexitást, és jól
  megbirkózik azzal.
• Könnyu megérteni.
• Egyfázisú fejlesztéseknél egyszeru a használata.
• Strukturáltságot biztosít még a kevésbé képzett
  fejlesztok számára is.
• Biztosítja a követelmények rögzítését, és azok
  nem is változnak a fejlesztés során.
• Meghatározott sablont biztosít arra vonatkozóan,
  hogy mely módszereket használjuk az analízis,
  tervezés, kódolás, tesztelés és üzemeltetés
  során.
• Feszes ellenorzést biztosít.
• Ha jól alkalmazzuk, a hibák már valamely korai
  fázisban kiderülnek, amikor javításuk még
  lehetséges, és kevésbé költségigényes.
• A projekt menedzser számára könnyu a tervezés és
  a szereplok kiválasztása.
• Ha valaki készen van az adott fázisban rá
  kiosztott munkával, másik projekten dolgozhat,
  míg a többiek is elérik a fázis lezárásához
  szükséges állapotot.
• A mérföldkövei könnyen érthetoek.
• Könnyu ellenorizni a projekt aktuális állapotát.

7
A vízesés-modell hátrányai

• Lineáris, így nehéz a visszalépés a felmerül
  problémák megoldására, és ez jelentosen megnöveli
  a javítás mind költség-, mind idoigényét.
• Nem kezeli a szoftverfejlesztésben elterjedt
  iterációkat.
• Nincs összhangban a szoftverfejlesztés
  problémamegoldó természetével.
• Az integráció a teljes folyamat végén, egyben,
  robbanásszeren történik. A korábban fel nem
  fedezett hibák ilyenkor hirtelen, együttesen
  jelennek meg, így felderítésük és javításuk
  egyaránt nehezebb feladat.
• A megrendelo csak a folyamat végén láthatja a
  rendszert, menet közben nincs lehetosége
  véleményezni azt.
• A minoség szintén csak a folyamat utolsó
  fázisában mérheto.
• Minden egyes fázis az elozo fázis teljes
  befejezésére épít, ezzel jelentosen megno a
  kockázat.
• A fejlesztés során a követelmények nem
  módosíthatók, hiszen már az életciklus elején
  befagyasztjuk oket.
• Már a fejlesztés kezdetén ismernünk kell
  valamennyi követelményt, azok késobbi
  módosítására vagy bovítésére nincs lehetoség.
• Elképzelheto, hogy bár a végtermék megfelel
  valamennyi specifikációnak, mégsem muködik (pl.
  mert az elvárásokban vannak ellentmondások).
• Dokumentum-vezérelt, és túlzott dokumentálási
  követelményeket állít fel.
• Az egész szoftvertermék egy idoben készül, nincs
  lehetoség kisebb részekre osztására.

8
V-modell

• Ezt a változatát a vízesésmodellnek a német
  védelmi minisztérium fejlesztette ki, és tette a
  német hadsereg szoftver-fejlesztési modell
  szabványává 1992-ben.
• Minden tervezési fázisok van egy párja a
  tesztelési fázisok között
• A tesztelés hangsúlyozása

9
(No Transcript)
10
(No Transcript)
11
Evolúciós szoftverfejlesztés

• Feltáró fejlesztés
• Eldobható prototípus készítése

12
Spirál modell iteratív fejlesztés
13
(No Transcript)
14

• A spirál modell iterációkból áll, melyek
  folyamatosan ismétlodnek a projekt során.
• Valamennyi iteráció ugyanazon lépésekbol áll
• Lehetové teszi a kockázatok korai felismerését
• A megrendelot minden fázisba aktívan bevonja
• A modell elég komplex, megértése nem egyszeru
• Jelentos kockázatkezelési szakértelem szükséges.
• A nagyszámú köztes iteráció miatt sok, végül
  felesleges dokumentáció születhet.

15
Iteratív-inkrementális fejlesztési modell
16

• The basic idea behind iterative enhancement is to
  develop a software system incrementally, allowing
  the developer to take advantage of what was being
  learned during the development of earlier,
  incremental, deliverable versions of the system.
• Learning comes from both the development and use
  of the system, where possible.
• Key steps in the process were
• to start with a simple implementation of a subset
  of the software requirements
• and iteratively enhance the evolving sequence of
  versions until the full system is implemented.
• At each iteration, design modifications are made
  and new functional capabilities are added.

17
(No Transcript)
18

• A kész szoftvert az egymást követo iterációk
  során állítja elo
• Az egyes iterációk végén a követelmények egyre
  nagyobb részhalmazát kielégíto rendszer áll elo.
• Az iterációk során a rendszer szélességében bovül
  és nem bonyolódik.
• Kiválasztjuk a kritikus funkciókat és azt
  valósítjuk meg legelobb, majd szélességében
  bovítjük a rendszert.
• Minden egyes iteráció egy-egy kis vízesés (vagy
  evolúciós) fejlesztés.
• A jól definiált követelményeket kielégíto
  inkremensek fejleszthetoek a vízesés modell
  alapján
• Ahol a specifikáció nem kelloen egyértelmu, ott
  alkalmazható az evolúciós megközelítés.

19

• A fejlesztés indításakor a megrendelo vázlatosan
  közli a követelményeit, illetve meghatározzák
  mely követelmények a fontosabbak, s melyek
  kevésbé fontosak.
• Amikor egy inkremens elkészül, azt integrálni
  kell a már elkészült rendszerbe, s utána azt a
  felhasználó használatba is veheti. Az
  üzemeltetéssel kapcsolatos tapasztalatok
  visszacsatolhatóak a további inkremensek
  tervezésébe.
• Az inkrementális fejlesztés elonye, hogy
• A megrendelonek nem kell megvárnia a teljes
  rendszer elkészültét, hanem már az elso inkremens
  átadása után használhatja a rendszer legfontosabb
  szolgáltatásait.
• A korábban kifejlesztett inkremensek tekinthetok
  prototípusnak, a használatuk során szerzett
  tapasztalatok beépíthetoek a fejlesztés
  folyamatába.
• Csökkenti a kockázatot. Az egyes inkremensekben
  ugyan lehetnek hibák, azonban nem valószínu, hogy
  ezek az egész projekt kudarcát okozzák.
• A magas prioritású inkremenseket szállítjuk le
  eloször, így azok lesznek a legjobban
  kitesztelve.
• Az egyes inkremenseknek viszonylag kicsinyeknek
  kell lenniük (Sommerville szerint 20 ezer sornál
  kisebbek), minden egyes inkremensnek szolgáltatni
  kell valamilyen rendszerfunkciót. Idonként
  nehézségeket okozhat a rendszer ilyen méretu
  elemekre való particionálása.

20

• Tolerálja a követelmények megváltozását
• Csökkenti a kockázatot
• Biztonságosabb, hibaturobb alkalmazást eredményez
  
• Lehetové teszi a résztvevok folyamatos tanulását,
  a módszertan finomítását
• Lerövidíti a fejlesztés idotartamát
• Az iteratív fejlesztés terv szeru

21
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 elozo módszertanból merít, és mindazt
  egyesíti
• Keret módszertan -gt testre kell szabni

22
Fobb jellemzoi

• Használatieset-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övekvo)
• Az egyes iterációk során a rendszer újabb
  verzióit fejlesztjük, készítjük el. Végighaladunk
  a fejlesztés fázisain.
• Az egyes iterációk munkafolyamatokból állnak

23
Fázisok Elokészítés Kidolgozás
Megvalósítás Átadás
Munka- folyamatok Követelmények Tervezés
Implementáció Teszt

• Az ábra vízszintes dimenziója az idobeliséget, a
  függoleges dimenziója a különbözo 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, eroforrás igényét szimbolizálja.
• Egy-egy fázis elkészítése során több
  munkafolyamatot illetve diszciplínát érint,
  ugyanakkor az egyes diszciplínák a különbözo
  fázisokban különbözo intenzitásúak, eroforrás
  igényuek.

24

• 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
  muködo és végrehajtható alkalmazásnak kell
  elállnia, az iteráció végén a rendszer újabb,
  boví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 ellenorzöttek. Az iterációk számát és
  idotartamát, az egyes iterációk feladatát és az
  általuk eloállított termékeket, az iterációs
  munkafolyamatok résztvevoit elore tervezi az
  Egységesített Eljárás.

25
The Rational Unified Process
26

• Az elkészítés fázisában a legnagyobb hangsúly a
  követelmények rögzítésére helyezodik, a többi
  tevékenység pedig jóval kisebb mértékben kap
  szerepet, tesztelés pedig gyakorlatilag nincs is.
  
• A késobbi iterációkban, illetve fázisokban ez a
  hangsúly fokozatosan áthelyezodik a technikaibb
  jellegu tevékenységekre.
• Az átadás fázisában már elsosorban tesztelés
  zajlik, így elemzés, tervezés és implementáció a
  tesztekre vonatkozóan és azok eredményeitol
  függoen válik szükségessé, míg a követelmények
  összegyujtése már nem kap szerepet.

27
A fejlesztés fázisai

• Elokészítés
• a rendszer eredeti ötletét olyan részletes
  elképzeléssé dolgozzuk át, mely alapján a
  fejlesztés tervezheto lesz, a költségei pedig
  megbecsülhetok
• 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 alapveto szolgáltatásait.
• milyen alapveto belso szerkezetet, architektúrát
  alakítunk ki.
• Kidolgozás
• a használati eseteket részleteiben is
  kidolgozzuk
• alaparchitektúrát kialakítása (Executable
  Architecture Baseline)
• az alaparchitektúra segítségével a teljes
  fejlesztés folyamata ütemezheto, é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

28
(No Transcript)
29
A fázisok eroforrás- és idoigénye
65
10
20
5
10 30
50 10
30
Egy iteráció munkafolyamataia tevékenységbeli
dimenzió

• A módszertan statikus, tevékenység típusok
  szerinti tagozódása (ábra függoleges tengelye)
• Ez a munkafolyamatok (újabb megfogalmazás szerint
  diszciplínák), termékek, munkatársak szerinti
  tagozódás.
• Üzleti modellezés (Business Modeling)
• Követelmények (Requirements)
• Elemzés és Tervezés (Analysis Design)
• Implementáció (Implementation)
• Teszt (Test)
• Telepítés (Deployment)

31
Egy iteráció munkafolyamatai (RUP)

• Üzleti modellezés (Business Modeling) a
  készítendo rendszer üzleti (szakterületi)
  környezetének vizsgálata
• Követelmények (Requirements) a rendszer
  muködésével kapcsolatos kezdeti elképzelések
  összegyujtése (a felhasználó szemszögébol)
• Elemzés (Analysis) követelményeket a fejlesztok
  szempontjának megfeleloen rendezzük át, így azok
  együttessen a rendszer egy belso képét határozzák
  meg, mely a további fejlesztés kiindulópontja
  lesz. Rendszerezzük és részletezzük az
  összegyujtö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, melybol 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. eloállítása. Az állományok elállítása
  egyben azok függetlenül végrehajtható, önálló
  tesztjeit is jelentik.
• 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.

32
Egységesített Eljárás architektúrája
33
Az Egységesített Eljárás termékei

• A fejlesztés eredménye mindig több, mint a kód
  tervek, dokumentációk, modellek.
• Egymásra épülnek a termékek
• Két különbözo kategorizálás
• Nézetek Lényegében ugyanannyira részletes
  leírások, de a rendszer különbözo oldalait
  mutatják. Egyenrangúak, az alkalmazás jellege
  dönti el, hogy melyik nézet mennyire határozza
  meg az architektúrát.
• Modellek A rendszer logikailag különbözo
  absztrakciós szintjeit mutatják be. Az egyes
  munkafázisok, diszciplínák különbözo modelleket,
  más néven termék csoportokat hoznak létre,
  illetve bovítenek.
• (ld. UML)

34
Az egyes termékcsoportok eltéro növekedése
35
Az Egységesített Eljárás jellegzetességei

• Fo jellegzetességek
• Használati eset vezérelt
• Architektúra központú
• Iteratív és inkrementális

• További jellegzetességek
• Objektum-orientált
• Komponens alapú
• Vizuális modellezésre (UML) épül
• Ellenorzött
• Konfigurálható

36
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 rendszertol
• Használati eset a használatnak egy értelmes,
  kerek egysége, kívülrol í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 belso szerkezete
  (architektúra)

37

• Követelmény nézet (Requirements View) vagy
  Használatieset-nézet (Use Case View)
• Dinamikus nézet (Dynamic View) vagy Folyamat
  nézet (Process View)
• Logikai nézet (Logical View) vagy Tervezési nézet
  (Design View)
• Komponens nézet (Component View) vagy
  Implementációs nézet (Implementation View)

38

• A használati eset nézet meghatározza a tervezési
  nézetet, mert a használati eseteket megvalósító
  osztályok, együttmuködések alkotják a kívánt
  rendszert.
• A használati eset nézet meghatározza az
  implementációs nézetet, mert a használati
  eseteket megvalósító szoftver komponenseket kell
  kifejleszteni vagy megvásárolni.
• A használati eset nézet meghatározza a folyamat
  nézetet, mert a használati esetek befolyásolják,
  hogy hol és milyen mértéku párhuzamosságra,
  illetve hol és milyen aktív osztályokra van
  szükség.
• A használati eset nézet meghatározza a telepítési
  nézetet, mert a használati eseteknek megfelelo
  topológiát célszeru kialakítani.
• A használati esetek a rendszer funkcionális
  tagolását, függoleges, felosztását, a
  funkcionális alrendszerekre való felosztás
  határozzák meg.

39
Architektúra központú fejlesztés

• Architektúra strukturálisan fontos elemek és
  ezek kapcsolata.
• A rendszer nagy léptéku 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, futés

40
Az architektúra célja

• Lehetové teszi a bonyolultság kezelését
• Átláthatóvá tesz a fejlesztést
• Könnyebben felismerhetoek az újrafelhasználható
  elemek
• Átlátható project menedzsment
• Kockázatok csökkentése
• Lehetové válik a párhuzamos fejlesztés

41
Rétegzett architektúra

• Fizikai, telepítési rétegzettség (layer) az
  egyes rétegek különbözo futtatható állományokban
  vannak, ezek a futtatható állományok különbözo
  gépeken helyezkednek el, az egyes futtatható
  elemek hálózati protokollon keresztül
  beszélgetnek divatos, de drága.
• Logikai rétegzettség (tier) a forráskód belso
  tagozódása. Ez áttekinthetové teszi az
  alkalmazást, nem hat a teljesítményre
• Egyirányú a logikai függés a fizikai
  rétegzettség feltételezi a logikait, de fordítva
  nem!

42
Logikai rétegek

• Kezeloi felület
• Csak a megjelenés
• Nem gondolkodik, de csinos
• Alkalmazás logika
• Az alkalmazásra jellemzo elemek
• Adatbázis logika
• Egész szervezetre, egész adatbázisra jellemzo,
  nem alkalmazás függo

43
Three-tier

• The 3-Tier architecture has the following
  3-tiers.
• Presentation Tier
• Application Tier/Logic Tier/Business Logic Tier
• Data Tier

44
(No Transcript)
45
(No Transcript)
46
Model-view-controller

• Model Domain logic adds meaning to raw data
  (e.g., calculating if today is the user's
  birthday, or the totals, taxes and shipping
  charges for shopping cart items).
• Many applications use a persistent storage
  mechanism (such as a database) to store data. MVC
  does not specifically mention the data access
  layer because it is understood to be underneath
  or encapsulated by the Model.
• View Renders the model into a form suitable for
  interaction, typically a user interface element.
  MVC is often seen in web applications, where the
  view is the HTML page and the code which gathers
  dynamic data for the page.
• Controller Processes and responds to events,
  typically user actions, and may invoke changes on
  the model and view.

47
Events typically cause a controller to change a
model, or view, or both. Whenever a controller
changes a models data or properties, all
dependent views are automatically updated.
Similarly, whenever a controller changes a view,
for example, by revealing areas that were
previously hidden, the view gets data from the
underlying model to refresh itself.
48
(No Transcript)
49
Java Platform, Enterprise Edition (J2EE)

• View
• The view in a J2EE application may be represented
  by a Java Server Page. Alternately, the code to
  generate the view may be part of a servlet.
• Controller
• The controller in a J2EE application may be
  represented by a servlet.
• Model
• The model is represented by entity beans.

50
Komponens alapú fejlesztés

• Buy the best, build the rest
• Az alkalmazás diszkrét, jellegzetesen önállóan
  fejlesztheto és futtatható elembol épül fel
• Kis lépésekben, kis változással fejlesztheto
  tovább az alkalmazás
• A komponensek megoszthatóak az alkalmazások között