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

Átírás

1 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 típusai lehetnek: l Munkafolyam 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.) BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 41 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 42 Modellezési koncepció Mit nevezünk modellnek? la rendszer megértést segítő absztrakció lelhanyagolja a lényegtelen részleteket la modell kizárólag az eredeti rendszer lényegi elemeit tartalmazza LÉNYEGI ELEM? -- lényeges a vizsgálat szempontjából Modellek például: Építészeti modellek, Modellvasút, Claudia Schiffer, Naomi Campbell, A modellek különböző célokat szolgálhatnak: l a 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 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 43 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 44

2 2.1 A vízesv zesés s (waterfall( waterfall) ) modell A szoftverfolyamatok osztályozása: l Vízesés modell l Evolúciós fejlesztés l Formális rendszerfejlesztés l Újrafelhasználás alapú fejlesztés Hagyományos szemléletű, erősen szeparált fázisokat tartalmazó modell. Az eredeti vízesés modellt 1970-ben W. W. Royce publikálta. BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 45 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 46 Követelmények meghatározása Rendszer és szoftvertervezés Implementáció és egységteszt A Royce féle vízesés s modell Integráció és rendszerteszt 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 Működtetés és karbantartás I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 47 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 48

3 Problémák: l a 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 Előnyök: 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 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 49 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 50 Recommended Approach to Software Development NASA/GSFC-SEL BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 51 The spread of activities Throughout the development life cycle NASA/GSFC-SEL BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 52

4 2.2 Az evolúci ciós s modell A prototípus pus készk szítés folyamata Kommunikáció Gyors tervezés 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 Modellezés, gyors megvalósítási terv Prototípus készítés BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 53 R. S. Pressman: Software Engineering BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 54 Prototípus típusok: t Az evolúciós fejlesztés modellje Specifikáció Kezdeti verzió l Termék prototípus l Rész-prototípus l Interfész prototípus Vázlat leírása Fejlesztés Közbenső verziók Validálás Végleges verzió I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 55 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 56

5 Az evolúci ciós s fejlesztések sek típusai, t problematikája Típusok l Feltáró fejlesztés l Eldobható prototípus készítése 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 2.3 Formális rendszerfejlesztés 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 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 57 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 58 A leglényegesebb különbsk nbségek a vízesv zesés modell és s formális modell között: k 1. A követelményspecifikáció részletes matematikai jelölésekkel leírt formális specifikálás. 2. 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). A formális rendszerfejlesztés s fázisaif Követelmények meghatározása Formális specifikáció Formális transzformáció Integráció és rendszerteszt BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 59 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 60

6 Formális specifikáció A formális transzformáci ció menete R1 R2 R3 P1 P2 P3 P4 Futtatható program 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 Tick: Szoftver Tervezés és Technológia 61 A formális modell előnyei l A 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 Tick: Szoftver Tervezés és Technológia 62 A Cleanroom szoftverfejlesztés 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 A Cleanroom fejlesztés s főf jellemzői 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) BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 63 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 64

7 A Cleanroom fejlesztési si folyamat Linger- Rendszer formális meghatározása Működési profil fejlesztése Szoftver inkrementumok Definiálása Strukturált Program készítése Statisztikai tesztek tervezése I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 féle modellje (1994) Kód formális átvizsgálása Integrált rendszer tesztelése Inkrementum integrálása BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 65 A cleanroom fejlesztés s 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 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 66 A cleanroom fejlesztés s a számok tükrt krében l 15 projektet (5 MSLOC) elemezve a hibák száma: 3.3 / KSLOC (a hagyományos /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 Tick: Szoftver Tervezés és Technológia Újrafelhasználás- orientá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 Tick: Szoftver Tervezés és Technológia 68

8 Az újrafelhaszn jrafelhasználás s gyakorisága ga Az újrafelhasználás s mértm rtéke Az újrafelhaszn jrafelhasználás s m mért rtéke Az újrafelhasználás-orientált fejlesztés folyamata Követelmények specifikációja Komponenselemzés Követelmények módosítása Fejlesztés és integráció Rendszertervezés újrafelhasználással Rendszer validáció Az újrafelhasznált lt elem mérete, m komplexitása BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 69 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia Folyamatiteráci ció 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). Inkrementális fejlesztés l Mills ajánlotta 1980-ban l Cél 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 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 71 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 72

9 Az inkrementális fejlesztés s modellje Kommunikáció A projekt előrehalad rehaladása Vázlatos követelmények meghatározása Rendszerinkremens fejlesztése Követelmények Inkremensekhez rendelése Inkremens validálása Rendszer Architektúrájának megtervezése Inkremens integrálása Rendszer validálása Szoftver funkcionalitása Analízis, tervezés Kódolás, tesztelés Validálás Szállítás, visszajelzés 2. inkremens 3. inkremens n. inkremens Végleges rendszer BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia inkremens Projekt idő R. S. Pressman: Software Engineering BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 74 Az inkrementális fejlesztés s előnyei l A 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) A RAD Modell (Rapid Application Development) 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. BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 75 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 76

10 l Különböző 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 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 77 A RAD vázlatos v modellje Communication Planing Team #n Modelling Business Modelling Data Modelling Process Modelling Construction Component reuse authomatic code generation, testing Team #1 Modelling Business Modelling Data Modelling Process Modelling Construction Component reuse authomatic code generation, testing days R. S. Pressman: Software Engineering BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 78 Deployment Integration, Delivery Feedback A RAD modell problémái A Boehm-féle spirál l modell l Nagy 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 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 Tick: Szoftver Tervezés és Technológia 79 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 80

11 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 Tick: Szoftver Tervezés és Technológia 81 A BoehmBoehm-féle spirá spirál modell ciklusai és lé lépései A BoehmBoehm-féle spirá spirálmodell I. Sommerville: Szoftverrendszerek fejlesztése, Panem, 2002 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 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 Tick: Szoftver Tervezés és Technológia 83 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 84 11

12 A legfontosabb elvek 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 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 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 85 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 86 Ezen elveket követk vető módszerek: l Extreme Programming (XP) l Adaptive Software Development (ASD) l Dynamic Software Development Method (DSDM) l Scrum l Crystal l Feature Driven Development (FDD) l Agile Modeling (AM) Extrém m programozás s (XP) l Beck publikálta először 1999-ben l Inkrementális megközelítés OO alapon l Ajánlott szabályok és praktikumok l 4 alapvető aktivitás: Planing Design Coding Testing Kent Beck BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 87 BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 88

13 Az extrém m programozás s vázlatos v modellje User stories Iteration plan Acceptance test Release Software increment Simple design CRC cards Spike solutions planing testing design coding Pair programming Continous integration No overtime Unit test R. S. Pressman: Software Engineering Acceptance test BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 89 Az extrém m programozás s 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 Tick: Szoftver Tervezés és Technológia 90 Az extrém m programozás s szabályai (2) 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 Usecollectivecodeownership. 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. BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 91 A változtatv ltoztatás s költsk ltségeinek alakulása BMF-NIK-SZTI Tick: Szoftver Tervezés és Technológia 92