2. A szoftver mint termék llításának folyamata, a szoftver életciklus modelljei

2. A szoftver mint termék előá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 típusai lehetnek: BMF-NIK-SZTI

Tick: Szoftver Tervezés és Technológia

41

Mit nevezünk modellnek?

BMF-NIK-SZTI


42

A modellek különböző célokat szolgálhatnak:

la

rendszer megértést segítő absztrakció l elhanyagolja a lényegtelen részleteket l a modell kizárólag az eredeti rendszer lényegi elemeit tartalmazza

la

komplexitás csökkentése l kommunikáció az ügyféllel l a rendszer vizsgálata megépítése előtt l vizualizálás

LÉNYEGI ELEM ? -- lényeges a vizsgálat szempontjából Tick: Szoftver Tervezés és Technológia

modell (tevékenységek sorrendje, bemenetei, kimenetei, függőségei) l Az adatfolyam vagy tevékenység modell (mindegyik tevékenység valamilyen adattranszfomációt hajt végre. Azt reprezentálja, hogyan alakul át a folyamat bemenete kimenetté az emberek, vagy számítógépek által végrehajtott tevékenységek során). l A szerepkör / cselekvés modell(a szoftverfolyamatban résztvevő emberek szerepköreit és felelősségüket ábrázolja.)

Modellek például: Építészeti modellek, Modellvasút, Claudia Schiffer, Naomi Campbell, …

Modellezé Modellezési koncepció koncepció

BMF-NIK-SZTI

l Munkafolyam

43

BMF-NIK-SZTI


44

1

2.1 A vízesés (waterfall) modell A szoftverfolyamatok osztályozása: Hagyományos szemléletű, erősen szeparált fázisokat tartalmazó modell.

l Vízesés

modell l Evolúciós fejlesztés l Formális rendszerfejlesztés l Újrafelhasználás alapú fejlesztés

BMF-NIK-SZTI

Az eredeti vízesés modellt 1970-ben W. W. Royce publikálta.


Követelmények meghatározása

45

A Royce féle vízesé zesés modell

Rendszer és szoftvertervezés

BMF-NIK-SZTI


46

Jellemzők: l szisztematikus,

szekvenciális, top-down modell l a hagyományos mérnöki szemléletet követi l leginkább elterjedt (legrégibb) modell

Implementáció és egységteszt

Integráció és rendszerteszt

Működtetés és karbantartás I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI


47

BMF-NIK-SZTI


48

2

Problémák: Előnyök:

la

valós projektek ritkán követnek szekvenciális modellt l nehezen valósítható meg az iteráció l az egész modell a specifikáció minőségétől függ l a projekt elején meglévő kezdeti bizonytalanságot nem tudja kezelni l nagyon későn lát a megrendelő működő programot

BMF-NIK-SZTI


l modellt

ad a különböző fázisokhoz tartozó módszerek elhelyezésére l logikus, könnyen érthető, kézenfekvő modell l sok tapasztalat halmozódott fel

49

Recommended Approach to Software Development NASA/GSFC-SEL http://sel.gsfc.nasa.gov BMF-NIK-SZTI

BMF-NIK-SZTI


50

The spread of activities Throughout the development life cycle NASA/GSFC-SEL http://sel.gsfc.nasa.gov


51

BMF-NIK-SZTI


52

3

A prototí prototípus ké készí szítés folyamata

2.2 Az evolúciós modell

Gyors tervezés Kommunikáció Modellezés, gyors megvalósítási terv

Egy kezdeti implementációt (prototípust) a felhasználókkal véleményeztetünk és soksok verzión keresztül addig finomítjuk, amíg a megfelelő rendszert el nem érjük. Prototípus véleményezés

Prototípus készítés

R. S. Pressman: Software Engineering BMF-NIK-SZTI


53

BMF-NIK-SZTI


54

Az evolúciós fejlesztés modellje

Prototí Prototípus tí típusok: Specifikáció

prototípus l Rész-prototípus l Interfész prototípus

Kezdeti verzió

l Termék

Vázlat leírása

Fejlesztés

Validálás

Közbenső verziók Végleges verzió

I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI


55

BMF-NIK-SZTI


56

4

Az evolú evolúció ciós fejleszté fejlesztések tí típusai, problematiká problematikája

2.3 Formális rendszerfejlesztés

Típusok l Feltáró fejlesztés l Eldobható prototípus készítése

A formális rendszerfejlesztés jellegében a vízesés modellhez hasonlít. Lényege a specifikáció futtatható formába transzformálása formális matematikai eszközökkel

Problémák l A folyamat nehezen menedzselhető l A rendszerek struktúrája nem megfelelő l Minőségbiztosítási problémák l Speciális eszközök és technikák igénye BMF-NIK-SZTI


57

A leglé leglényegesebb kü különbsé nbségek a ví vízesé zesés modell és formá formális modell kö között: 1.

2.

BMF-NIK-SZTI


58

A formá formális rendszerfejleszté rendszerfejlesztés fá fázisai Követelmények meghatározása

A követelményspecifikáció részletes matematikai jelölésekkel leírt formális specifikálás. A tervezés, implementáció, egységteszt egy transzformációs folyamat (a formális specifikáció transzformációk során programmá válik).

Formális specifikáció

Formális transzformáció

Integráció és rendszerteszt

BMF-NIK-SZTI


59

BMF-NIK-SZTI


60

5

A formá formális modell elő előnyei

A formá formális transzformá transzformáció ció menete lA Formális specifikáció

R1

P1

R2

P2

Futtatható program

R3

P3

P4

A transzformációs folyamat során a kezdeti formális specifikáció transzformálódik egyre jobban kifejtett, de matematikailag korrekt rendszerreprezentációvá. Minden egyes lépés további finomítás mindaddig, amíg a formális Specifikáció vele ekvivalens programmá nem válik. I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI


61

transzformációk korrektek, így könnyű a verifikációjuk, a sok kis lépés után a program lényegében a specifikáció szisztematikus transzformációja. l Annak bizonyítása, hogy a program megfelel a specifikációnak, más paradigmákkal szemben itt egyszerű, hiszen sok kis ellenőrzéssé csökken a transzformációk során. l Használata nagyon előnyös olyan rendszerek, vagy részrendszerek esetében, ahol elsődleges a rendszer biztonsága, megbízhatósága és annak autentikus bizonyítása. BMF-NIK-SZTI


62

A Cleanroom fejleszté fejlesztés fő fő jellemző jellemzői

A Cleanroom szoftverfejlesztés

l Formális

specifikáció (a kifejlesztendő rendszer formális modelljének megadása állapot-átmenet modellel) l Inkrementális fejlesztés (a szoftver fejlesztés folyamatát jól definiálható inkrementumokra osztjuk) l Strukturált programozás (kis számú konstrukció alkalmazása, lépésenkénti finomítás) l Statikus verifikáció (nem a hagyományos értelemben vett modul- és integrációs teszt) l A rendszer statisztikai tesztelése (a rendszer specifikációjával párhuzamosan kifejlesztett működési profilon alapuló teszt)

l Mills,

Cobb, Linger, Prowell munkái nyomán l Formális, inkrementális fejlesztési modell l Alapgondolata, hogy a szoftverhibák elkerülhetők egy szigorú átvizsgálási folyamat segítségével. A rendszerkomponensek modultesztelését helyettesítő átvizsgálások a komponensek specifikációjukkal való konzisztenciájuk ellenőrzése

BMF-NIK-SZTI


63

BMF-NIK-SZTI


64

6

A Cleanroom fejleszté fejlesztési folyamat LingerLingerféle modellje (1994) Rendszer formális meghatározása

Szoftver inkrementumok Definiálása

Működési profil fejlesztése

Strukturált Program készítése

Kód formális átvizsgálása

Statisztikai tesztek tervezése

Inkrementum integrálása

Integrált rendszer tesztelése

A cleanroom fejleszté fejlesztés elő előnyei l Először

a kritikus funkciókat valósítják meg és az inkrementumokkal haladnak a kevésbé kritikusok felé. (Így a kritikus van legtöbbet tesztelve). l A specifikáció és a terv folyamatos átdolgozás alatt áll, diszkrét inkrementumok formájában (élő kapcsolat a felhasználóval, kitűnő változáskövetés) l Állapot alapú rendszermodell, kiegészítő modellek, Æ jól definiált transzformációk sorozata Æ korrekt szoftver



65

A cleanroom fejleszté fejlesztés a szá számok tü tükré krében… ben… l 15

projektet (5 MSLOC) elemezve a hibák száma: 3.3 / KSLOC (a hagyományos 30-50 /KSLOC-kal szemben) l A hibák a cleanroom esetében tipikusan kódolási hibák és nem tervezési, specifikációs hibák, mint az a hagyományos esetben szokásos l US Army’s Life Cycle Software Engineering Center jelentése szerint: a termelékenység 121 SLOC / emberhónapról 559 SLOC / emberhónapra nőtt a teljes ciklusra vonatkoztatva (hibák száma: 1.14/KSLOC) l NASA-nál a hibák száma 7/KSLOC-ról 4.3-6/KSLOCra csökkent a cleanroom bevezetésével BMF-NIK-SZTI


67

BMF-NIK-SZTI


66

2.4 Újrafelhasználásorientált fejlesztés Tisztázandó kérdések: l Mi

az újrafelhasználás l Mi az előnye az újrafelhasználás-orientált fejlesztésnek l Mi az, ami újrafelhasználható l Az újrafelhasználás formái (tervezett, nem tervezett) l Az újrafelhasználás költség-komponensei BMF-NIK-SZTI


68

7

jrafelhasznáálás m méért rtééke Az újrafelhaszn

jrafelhasznáálás gyakoris gyakorisáága Az újrafelhaszn

Az újrafelhaszná jrafelhasználás mé mérté rtéke

Az újrafelhaszná jrafelhasználás-orientá orientált fejleszté fejlesztés folyamata Követelmények specifikációja

Komponenselemzés

Követelmények módosítása

Rendszertervezés újrafelhasználással

Fejlesztés és integráció

Rendszer validáció

Az újrafelhaszná jrafelhasznált elem mé mérete, komplexitá komplexitása BMF-NIK-SZTI


69

BMF-NIK-SZTI


70

Inkrementá Inkrementális fejleszté fejlesztés

2.5 Folyamatiteráció

l Mills

ajánlotta 1980-ban az átdolgozások számának csökkentése a fejlesztési folyamatban. l Lehetőséget ad a megrendelőnek bizonyos a követelményekkel kapcsolatos döntések későbbre halasztására. l A fejlesztés jól meghatározott inkremensekben történik. l Ha egy inkremens elkészül, átadásra kerül, azt a megrendelő akár használatba is veheti l Cél

l Inkrementális

fejlesztés (a specifikáció, a tervezés, az implementálás kis inkrementális lépésekben valósul meg).

l Spirális

fejlesztés (belülről kifelé tartó spirálvonalat követ a fejlesztés).

BMF-NIK-SZTI


71

BMF-NIK-SZTI


72

8

A projekt elő előrehaladá rehaladása

Az inkrementá inkrementális fejleszté fejlesztés modellje Vázlatos követelmények meghatározása

Rendszerinkremens fejlesztése

Követelmények Inkremensekhez rendelése

Inkremens validálása

Szoftver funkcionalitása

Kommunikáció

Rendszer Architektúrájának megtervezése

Inkremens integrálása

Analízis, tervezés

n. inkremens

Kódolás, tesztelés Validálás Szállítás, visszajelzés

3. inkremens

Rendszer validálása

2. inkremens 1. inkremens

Végleges rendszer R. S. Pressman: Software Engineering BMF-NIK-SZTI


73

BMF-NIK-SZTI

Az inkrementá inkrementális fejleszté fejlesztés elő előnyei

A RAD Modell

szoftver már menetközben használhatóvá válik a megrendelő számára (kritikus követelmények teljesülnek először) l A megrendelők használhatják a korábbi inkremenseket, mint prototípusokat a későbbi inkremensekhez l Kisebb a kockázata a projekt kudarcának, biztonságos fejlesztés l A legkritikusabb funkciókat teszteljük legtöbbet (azok készülnek el először) Tick: Szoftver Tervezés és Technológia

74

(Rapid Application Development) Development)

lA

BMF-NIK-SZTI

Projekt idő


l J.

Martin publikálta 1991-ben l Inkrementális modell l Kifejezetten rövid fejlesztési ciklus (60-90 nap) l „High-speed” adaptációja a vízesés modellnek l A nagy sebesség a „component based construction” , „software reuse”, „automatic code generation” technikák alkalmazásával érhető el. 75

BMF-NIK-SZTI


76

9

A RAD vá vázlatos modellje

Communication

Planing Team #1 Modelling Business Modelling Data Modelling Process Modelling


77

A RAD modell problé problémái projektek esetén nagy a humán erőforrás igény az elegendő számú RAD-team felállításához l Ha a rendszer nehezen modularizálható, a komponensek elkészítése problematikus l Magas műszaki kockázat esetén a RAD nem működik biztonságosan


BMF-NIK-SZTI

60 – 90 days


78

A Boehm-féle spirál modell

l Nagy

BMF-NIK-SZTI

Construction Component reuse authomatic code generation, testing

Construction Component reuse authomatic code generation, testing R. S. Pressman: Software Engineering

BMF-NIK-SZTI

Deployment Integration, Delivery Feedback

teamek dolgoznak párhuzamosan a tervezés fázisától a különböző funkciókon l A team tagjainak sokoldalúnak kell lennie l A megrendelő szakemberei is részt vesznek a teamek munkájában l Modern fejlesztői környezetet használ l RAD-et támogató tool-ként hirdetik magukat: – Microsoft Visual Studio .NET – Sun Java Studio Creator – BEA Web Logic Workshop – Borland C# Builder – IBM WebSphere Studio Application Developer

Team #n Modelling Business Modelling Data Modelling Process Modelling

l Különböző

79

l l

Boehm publikálta 1988-ban A valós fejlesztést jól követő modell

Prof. Dr. Barry Boehm University of Souther California

BMF-NIK-SZTI


80

10

A spirál minden ciklusa négy szektorra bontható: 1. Célok kijelölése (célok, alternatívák, megszorítások, kockázatok meghatározása 2. Kockázat becslése, csökkentése (kockázat elemzés, kockázati tényezők csökkentésére intézkedés kidolgozása 3. Fejlesztés és validálás (a következő szintű termék fejlesztése, a kockázat analízis eredményének függvényében fejlesztési modell választása 4. Tervezés (a következő fázis, ciklus megtervezése BMF-NIK-SZTI


81

A BoehmBoehm-féle spirá spirál modell ciklusai és lé lépései

A BoehmBoehm-féle spirá spirálmodell



82

2.6 „Agile Software Pocesses” 2001-ben 17 neves szoftver fejlesztő alapította meg az „Agile Allience”-t és fogalmazta meg a „Manifesto for Agile Software Development”et

BMF-NIK-SZTI


83

BMF-NIK-SZTI


84

11

A legfontosabb elvek

– A haladás legjobb mértéke a működő szoftver – „Agile process” fenntartható fejlődést ösztönöz – A fejlesztőknek és a megrendelőnek egy állandó ütemet kell fenntartani a fejlesztési folyamatban – A kiváló műszaki színvonalra és a jó tervre folyamatosan ügyelni kell – Egyszerűség – csak az igazán fontos feladat elvégzése – Az önszerveződő, aktív teamektől származnak a legjobb megoldások (szerkezetekre, követelményekre, tervekre) – Rendszeres időközönként a teamnek önvizsgálatot kell tartani és viselkedését esetleg módosítani

– Első rendű szempont a megrendelő maradéktalan kielégítése – Flexibilitás a követelmények változásával szemben – Működő szoftver gyors átadása (inkrementálisok) – Az üzleti szakembereknek és a fejlesztőknek napi kapcsolatban kell lenniük – Motivált szakembereket gyűjts a projekt köré, teremtsd meg a feltételeket a munkájukhoz – Szorgalmazd a szemtől-szembeni párbeszédet a teamen belül az információ cserére

BMF-NIK-SZTI


85

BMF-NIK-SZTI


86

Extré Extrém programozá programozás (XP)

Ezen elveket kö követő vető módszerek: l Beck l l l l l l l

publikálta először 1999-ben megközelítés OO alapon l Ajánlott szabályok és praktikumok l 4 alapvető aktivitás:

Extreme Programming (XP) Adaptive Software Development (ASD) Dynamic Software Development Method (DSDM) Scrum Crystal Feature Driven Development (FDD) Agile Modeling (AM)

l Inkrementális

– – – –

Planing Design Coding Testing

www.agilealliance.org www.extremeprogramming.org BMF-NIK-SZTI


87

BMF-NIK-SZTI


Kent Beck

88

12

Az extré extrém programozá programozás vá vázlatos modellje Simple design CRC cards Spike solutions User stories Iteration plan Acceptance test

design

planing coding

Release Software increment

testing

R. S. Pressman: Software Engineering BMF-NIK-SZTI

Pair programming Continous integration No overtime Unit test Acceptance test


89

Az extré extrém programozá programozás szabá szabályai (2)

Az extré extrém programozá programozás szabá szabályai (1) Planning User stories are written. Release planning creates the schedule. Make frequent small releases. The project velocity is measured. The project is divided into iteration. Iteration planing starts each iteration. Move people around. A stand-up meeting starts each day. Fix XP when it breaks. Designing Simplicity. Choose a system metaphor. Use CRC cards for design sessions. Create spike solutions to reduce risk. No functionality is added early. Refactor whenever and wherever possible. BMF-NIK-SZTI


90

A vá változtatá ltoztatás kö költsé ltségeinek alakulá alakulása

Coding The customer is always available. Code must be written to agreed standards. Code the unit test first. All production code is pair programmed. Only one pair integrates code at a time. Integrate often Use collective code ownership. Leave optimization till last. No overtime. Testing All code must have unit tests. All code must pass all unit tests before it can be released. When a bug is found tests are created. Acceptance tests are run often and the score is published.

www.khatovaretech.com

BMF-NIK-SZTI

BMF-NIK-SZTI


91


92

13

2. A szoftver mint termék llításának folyamata, a szoftver életciklus modelljei

Recommend Documents