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

Ficsor Lajos

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ő: Speciális tudású személy (kutató)

Eszköz: assembler, memória térkép

Módszer: nincs Ficsor Lajos

Software engineering (Bevezetés)

SWENGBEV / 2

Történelem 2. a software krízis (1960. évek vége) zuhanó hardware árak növekvő hardware teljesítmény növekvő igény a software-ekre software költségeinek ugrásszerű növekedése a software minősége nem megfelelő.

Ficsor Lajos


SWENGBEV / 3

1

Történelem 3. 70-es évek Megoldandó problémák: Visszatérő problémák Nagy, monolitikus programok Nincs (vagy korlátozott) interaktivitás

Fejlesztő: speciális szaktudású szakember esetleg informális csoportok

Ficsor Lajos


SWENGBEV / 4

Történelem 4. 70-es évek (folyt) Eszköz: editor – compiler – linker, kezdetleges debugger első generációs. majd strukturált programnyelvek célnyelvek (pl. report generator) egyedi adatkezelés

Módszer: algoritmusok, adatszerkezetek kutatása strukturált, majd moduláris programozás Ficsor Lajos


SWENGBEV / 5

Történelem 5. 80-es évek Megoldandó problémák: nagyméretű, folyamatosan működő, nagy megbízhatóságot követelő programok Egyre bonyolultabbá váló felhasználói felületek Nagy mennyiségű adatok, tranzakció szemléletű feldolgozás Adatok tárolási és feldolgozási struktúrája elválik Hálózat megjelenése

Ficsor Lajos


SWENGBEV / 6

2

Történelem 6. Fejlesztő: csoportmunka igénye szakmán belüli specializálódás Management problémák megjelenése

Eszköz: fejlesztői környezetek korai CASE (Computer Aided Software Engineering) rendszerek adatbázis kezelő rendszerek

Módszer: kezdeti módszertanok - dekompozíció Ficsor Lajos


SWENGBEV / 7

Történelem 7. 90-es évektől Megoldandó problémák: hálózat és internet széles körűvé válása elosztott rendszerek igénye információk változatos megjelenési formája fejlesztési ciklus idejének rövidülése (üzleti nyomás a folyamatos továbbfejlesztésre) nyílt, hordozható sőt platform független megoldások igénye minőségbiztosítás igénye Fejlesztő: csoportmunka, sokszor térben elosztva Ficsor Lajos


SWENGBEV / 8

Történelem 8. Eszköz: integrált, csoportmunkát támogató fejlesztő környezetek szélessávú CASE rendszerek keretrendszerek software management támogatása

Módszer: Objektum orientált technológia Szabványok (X, Corba, DCOM, Java RMI) Komponens alapú programozás kutatások további technológiai fejlesztésekre

Ficsor Lajos


SWENGBEV / 9

3

Mi a software? TERMÉK, azaz Hasznosnak kell lennie (szolgáltatások) Elvárt minőségűnek kell lennie Előállításának költsége és határideje van Általában fizetnek érte a használói (ára van) Marketing szempontok is befolyásolják a technikai szempontok mellett Sokszor divatkövetőnek kell lennie

DE Speciális tulajdonságai vannak Általában hosszú élettartamú Ficsor Lajos


SWENGBEV / 10

A software speciális tulajdonságai nem anyagi jellegű másolat = eredeti használat miatt nem igényel karbantartást nincs sorozatgyártás tükröznie kell a valóságot

Ficsor Lajos


SWENGBEV / 11

A software speciális tulajdonságai (folytatás) komplexitása nagyobb a legtöbb műszaki terméknél viselkedése nem folytonos hibák előzetes jelek nélkül alkalmazkodás a külső környezethez

Ficsor Lajos


SWENGBEV / 12

4

A software engineering definíciói 1. Ha termék, előállítási ("gyártási") folyamat kell Egy előállítási folyamat szabályait technológiának nevezzük. A software technológia egy egyszerű definíciója: Eszközök és módszerek a szoftver termékszerű előállítására Ficsor Lajos


SWENGBEV / 13

A software engineering definíciói 2. A klasszikus definíció (Boehm, 1976): The practical application of scientific knowledge in the design and construction of computer programs and the associated documentation required to develop, operate and maintain them.

Ficsor Lajos


SWENGBEV / 14

A software engineering definíciói 2. Magyarul: Tudományos ismeretek gyakorlati alkalmazása számítógépes programok és a fejlesztésükhöz, használatukhoz és karbantartásukhoz szükséges dokumentációk tervezésében és előállításában.

Ficsor Lajos


SWENGBEV / 15

5

A software engineering definíciói 3. A hivatalos definíció (IEEE, 1983): The technological and managerial discipline concerned with systematic production and maintenance of software products that are develop and modified on time and within cost estimated.

Ficsor Lajos


SWENGBEV / 16

A software engineering definíciói 4. Magyarul: Technológiai és vezetési alapelvek, amelyek lehetővé teszik programok termékszerű gyártását és karbantartását a költség- és határidő korlátok betartásával.

Ficsor Lajos


SWENGBEV / 17

A szoftver fejlesztés fázisai 1. 1.Követelmény analízis Mit is kellene csinálni? Mikorra, és mennyiért? Kikkel? 2.Specifikáció Mit kell csinálni?

Ficsor Lajos


SWENGBEV / 18

6

A szoftver fejlesztés fázisai 2. 3.Tervezés Hogyan kell megcsinálni? 4.Implementáció Na, akkor csináljuk!! 5.Installáció és tesztelés Mit műveltünk? Ficsor Lajos


SWENGBEV / 19

A szoftver fejlesztés fázisai 3. 6. Karbantartás

Ha elszúrtad, javítsd is ki! Aki elszúrta, azóta már főnök - TE javítsd ki! Ha pedig a rendszer hibátlan(nak látszik) - Az Úr (a felhasználó) szava : igazából nem is ez kellene, hanem .... azt pedig nem úgy értettem, hanem... ha már ezt tudja, tudhatná azt is, hogy... újabban ezt már nem is így kell csinálni, hanem...

Azaz: esmétlés onnan, hogy ... Ficsor Lajos


SWENGBEV / 20

Kiegészítő munkafolyamatok Projekt menedzsment Verzió kezelés / verzió követés Erőforrás management Minőségbiztosítás Terméktámogatás Projekt értékelés, fejlesztési folyamat továbbfejlesztése

Ficsor Lajos


SWENGBEV / 21

7

Software életciklus modellek Az egyes fejlesztési fázisok viszonya egymáshoz

Ficsor Lajos


SWENGBEV / 22

Klasszikus ("waterfall") 1. Boehm, 1976 Analízis Specifikáció Tervezés Implem. Tesztelés Használat

Ficsor Lajos


SWENGBEV / 23

Klasszikus ("waterfall") 2. Jellemzői: technikai problémának tekinti a fejlesztést nem foglalkozik a kommunikációs problémákkal visszacsatolás túl későn (a teljes rendszer elkészülte utáni tesztelés után) lehetséges hol a helye a karbantartásnak?

Ficsor Lajos


SWENGBEV / 24

8

Gyors prototípus (rapid prototyping) 1. Analízis Specifikáció

^

Tervezés Implem.

V

Tesztelés

Prototípus

Ficsor Lajos

>

Használat


SWENGBEV / 25

Gyors prototípus (rapid prototyping) 2. Jellemzői: segíti a fejlesztő és a felhasználó kommunikációját főleg kisebb csoportoknál vált be

Ficsor Lajos


SWENGBEV / 26

Inkrementális (vagy evolúciós) 1. Analízis Specifikáció

Specifikáció

Tervezés

Implem.

Tervezés

Tesztelés

Specifikáció

Implem. Tervezés Tesztelés Implem.

Tesztelés Használat

Ficsor Lajos


SWENGBEV / 27

9

Inkrementális 2. Jellemzői: az eredeti célhoz egyre közelebb álló rendszerek sorozata minden rendszer átmegy legalább a tervezés implementálás - tesztelés fázisokon csökkenthető a fejlesztés kockázata az objektum orientált fejlesztési módszertanok általában ezt ajánlják szokás iterációs modellnek is nevezni Ficsor Lajos


SWENGBEV / 28

Újrafelhasználás 1. Analízis Specifikáció Tervezés Implem.

Kész elemek Kész elemek Kész elemek


Ficsor Lajos


SWENGBEV / 29

Újrafelhasználás 2. Jellemzői: ez alulról felfelé építkező modell (bottom - up) gyors módszer, ha van elég "építőanyag" a hatékonyság a szükséges helyeken utólag javítható

Ficsor Lajos


SWENGBEV / 30

10

Újrafelhasználás 3. Újrafelhasználható elemek Implementáció algoritmusok függvény könyvtárak osztály és objektum könyvtárak software komponensek korábban fejlesztett, hasonló rendszerek

Ficsor Lajos


SWENGBEV / 31

Újrafelhasználás 4. Tervezés tervezési minták (design patterns) bevált architekturális megoldások

Analízis, specifikáció leginkább az előző fejlesztések tapasztalatai

Ficsor Lajos


SWENGBEV / 32

Very High Level Languages 1. Analízis Specifikáció

Fejlesztõeszköz Tervezés és implementáció


Ficsor Lajos


SWENGBEV / 33

11

Very High Level Languages 2. (nem-procedurális nyelvek, alkalmazásgenerátorok) Jellemzői: a fejlesztőeszköz számára le kell írni, hogy MIT csináljon - a többi az eszköz dolga általában jól körülhatárolt területekre (pl. FOCUS, Oracle, Magic - AB alk.) esetleg hatékonysági problémák Ficsor Lajos


SWENGBEV / 34

Spirál-modell (Boehm, 1988) 1. Célok Célokkitűzése, kitűzése, megoldási megoldási Célok, alternatívák alternatívák kidolgozása kidolgozása alternatívák

A következő iteráció Új ciklus megtervezése és elindítása, vagy a befejezés eldöntése

Ficsor Lajos

Alternatívák keértékelése, Alternatívák kiértékelése, kockázat elemzés, prototípus kockázat elemzés készítés

A prototípus elemzése, (Prototípus) gyártás, tesztelése tesztelés


SWENGBEV / 35

Spirál-modell (Boehm, 1988) 2. Jellemzői: A fejlesztés iterációs lépések sorozata Az egyes iterációkban kitűzött célok folyamatosan fejlődnek Valamennyi fázis ciklikusan ismétlődik Minden (rész)megoldást ki kell értékelni Elemezni kell az adott megoldás kockázatát Ha a kockázat kisebb, mint a várható haszon, újabb ciklus kezdődhet Újdonság: kockázat kezelés Ficsor Lajos


SWENGBEV / 36

12

Eszközkészlet Módszer (Methodology) Technika (Technique) Eszköz (Tool)

Ficsor Lajos


SWENGBEV / 37

Módszer Technika Technika Technika

Ficsor Lajos

Eszköz

Eszközkészlet

Módszer Technika Technika Technika


SWENGBEV / 38

Módszerek és a software engineering Módszer (methodology): tudás (tapasztalat) + ajánlott technikák A jó módszer jellemzői: hatékony racionális: tudományos alapok, amelyeket a gyakorlat igazol konzisztens az egyes fázisokban Ficsor Lajos


SWENGBEV / 39

13

A jó módszer jellemzői: (folytatás) teljes: minden fázisra ajánl megoldást ismételhető: személytől független, jól definiált, megtanulható automatizálható (és automatizált)

Ficsor Lajos


SWENGBEV / 40

Technikák Az egyes részfolyamatok segítésére. Célja: információk rögzítése (egyértelműség!) kapcsolatok rögzítése ellentmondások kiszűrése. Leggyakrabban grafikus.

Ficsor Lajos


SWENGBEV / 41

Eszközök Programok, amelyek támogatnak módszer(eke)t technikákat dokumentáció készítést.

Jellemzője az integráltság szintje és a támogatott fázisok száma.

Ficsor Lajos


SWENGBEV / 42

14

A dekompozíció Alapprobléma: a software komplexitása Megoldás reménye: részek összege < az egész

Dekompozíció: a teljes software módszeres részekre bontása. Egy módszer meghatározza a dekompozíció elveit.

Ficsor Lajos


SWENGBEV / 43

Dekompozíció funkcionális szemléletben Program = adatszerkezetek + algoritmusok Dekompozíció alapja: adat vagy process Dekompozíció módja: felülről lefelé (top - down) alulról felfelé (bottom - up) Modulok között kommunikáció szükséges => belső interface Ficsor Lajos


SWENGBEV / 44

Dekompozíció funkcionális szemléletben (folytatás) Dualitás elve: Modul Processz alapú (Algoritmus) Adat alapú (adatszerkezet)

Interface Adatszerkezet Algoritmus

Több lépés szükséges => absztrakciós szintek! Ficsor Lajos


SWENGBEV / 45

15

Dekompozíció objektum orientált szemléletben Program = együttműködő objektumok halmaza Struktúra: osztályok/objektumok közötti kapcsolatok Működés: üzenetváltás A modulok egysége az osztály.

Ficsor Lajos


SWENGBEV / 46

Vizsgált módszertanok 1. A tárgy során két módszertanra fogunk hivatkozni Mindkettő objektum orientált szemléletű. OMT (Object Modelling Technique) Viszonylag korai, ezért jól áttekinthető Jól definiált eljárásokat javasol Komplex rendszerek fejlesztésére nem elég hatékony Ficsor Lajos


SWENGBEV / 47

Vizsgált módszertanok 2. RUP (Rational Unified Process) Keretrendszer, a mai modern fejlesztése feladatokra tulajdonságainak figyelembe vételével Testre szabással tehető alkalmassá a fejlesztés jellege és a projekt nagysága szerint egy adott feladatra Jól definiált munkafolyamatok Számos dokumentációs sablon Ficsor Lajos


SWENGBEV / 48

16

Software engineering (Software techológia) Bevezetés, alapfogalmak. Történelem 1. Történelem as évek Megoldandó problémák: Fejlesztő: Eszköz:

Recommend Documents