Az első részben a szoftverfejlesztési módszertanok összehasonlítását választottuk, olyan mutatókat, mint a módszertan és az iteratív fejlesztés aránya, valamint a formalitás mértéke a munkaanyagok tervezésében és általában a fejlesztésben. Ebben a részben ezekkel a mérőszámokkal hasonlítjuk össze a legismertebb szoftverfejlesztési gyakorlatokat.

Meglátjuk, hogy alakul…

Sajnos ez a legnehezebben leírható kategória – elvégre ez magában foglalja mind az első projektjét bármi áron befejezni próbáló kezdő görcsös dobálásának termékét, mind a meglehetősen kiforrott és jól bevált módszereket, amelyek sok évet magukba szívtak. konkrét fejlesztőcsapatok sokrétű tapasztalata, sőt belső szabályzatban is le vannak írva. Mivel azok, akik képesek saját módszertanukat kidolgozni, általában maguk is tudják értékelni azt iteráció és formalizálás szempontjából, ezért a kezdőkre fogunk összpontosítani. Sajnos ez leggyakrabban azt jelenti, hogy a fejlesztés lebonyolítására vonatkozó szabályok vagy egyáltalán nem léteznek, vagy kidolgozták és elfogadták, de nem hajtják végre. Természetes ilyen körülmények között rendkívül alacsony szintű fejlődési formalizmus. Szóval ez minden világos.

Fejlesztés "Hogyan működik"

Mit szólnál egy iteratív megközelítéshez? Sajnos általában nem használják ilyen projektekben. Mindenekelőtt azért, mert ez már az első iterációknál lehetővé tenné, hogy a projektet rendkívül kétesnek ítéljék meg, és a rend helyreállításához a felsőbb vezetés sürgős beavatkozását igénylőnek minősítsék. Hiszen egy iteratív projektben a programozó hagyományos válasza, hogy minden 90%-ban készen van, csak az első iteráció befejezéséig tart…

Strukturális módszertanok

Strukturális módszertanok

A strukturális módszerek olyan módszertanok csoportja, amelyeket rendszerint még az objektum-orientált nyelvek elterjedése előtt fejlesztettek ki. Mindegyik vízesés fejlesztésével jár. Bár, mint kiderült, abban a cikkben, amelyet gyakran emlegetnek a vízesés megközelítés első bemutatásaként, elhangzott, hogy kívánatos a projektet egy prototípus kifejlesztésével kezdeni, vagyis legalább két iteráció.

Mindazonáltal ezeknek a módszereknek az alapja a munkából a munkába való szekvenciális átmenet és a következő szakasz eredményeinek (dokumentumainak) átadása a következő szakasz résztvevőinek.

Mindezek a módszertanok is erősen formalizált megközelítést feltételeznek, bár ésszerű mennyiségű dokumentációra vonatkozó kijelentések találhatók bennük. Az egyik nem kézenfekvő példa arra, hogy a szoftverfejlesztési módszertanok nemcsak nyugaton alakultak ki, egy, a nyolcvanas évek elején hazánkban megjelent könyvből vett idézet, amely szerint egy programozási feladat formalizáltsági fokát az alapján kell meghatározni. hogy milyen jól az elemző és a programozó. És mindez annak ellenére, hogy a könyv témája meglehetősen kritikus – mai nevén – rendszerek kifejlesztése volt, amelyek hibái komoly veszteségekhez vagy akár katasztrófákhoz vezetnek.

Agilis módszertanok

Az agilis módszertanok tíz alapelven alapulnak, amelyek közül csak azokat nevezzük meg, amelyek ezeknek a módszertanoknak a kiválasztott paraméterek szerinti értékelését határozzák meg:

• a legfontosabb az, hogy az ügyfél elégedett legyen, és a lehető leghamarabb biztosítsa számára a terméket;
• a termék új kiadásainak néhány hetente, szélsőséges esetekben hónaponként kell megjelenniük;
• a legtöbb hatékony módszer tudás átadása a fejlesztésben résztvevőknek és közöttük - személyes kommunikáció;
• egy futó program a legjobb mutatója a fejlesztés előrehaladásának.

Így ezek a módszerek egyértelműen az iteratív szoftverfejlesztésre és a folyamat minimális formalizálására összpontosítanak. A második ponttal kapcsolatban azonban fenntartással kell élni: ezek a módszerek az adott projekt számára elfogadható minimális formalizáltsági szintre összpontosítanak. A rugalmas csoportba tartozó módszertanok közül legalább egy - a Crystal - olyan módosításokat tartalmaz, amelyek különböző résztvevőszámú és a kifejlesztett szoftver eltérő kritikusságú folyamatainak végrehajtására szolgálnak (a szoftverkritikusságot a hibák lehetséges következményei határozzák meg, amelyek kisebbek lehetnek. pénzügyi veszteségek egy katasztrofális hiba kijavításából). Annak érdekében, hogy a rugalmas módszerekkel való további összehasonlítás ne legyen értelmetlen, ezek közül néhányat röviden ismertetünk.

extrém programozás vagy XP (extrém programozás)

A Kent Beck, Ward Cunningham és Ron Jeffries által kifejlesztett XP módszertan a legismertebb az agilis módszertanok közül manapság. Néha az „agilis módszertanok” fogalmát kifejezetten vagy implicit módon azonosítják az XP-vel, amely a társaságiságot, az egyszerűséget hirdeti, Visszacsatolásés bátorság. Gyakorlatok összességeként írják le: a tervezés játéka, rövid kiadások, metaforák, egyszerű tervezés, kódrefaktorálás (refaktoring), előretesztelő fejlesztés, páros programozás, kollektív kódtulajdonlás, 40 órás munkahét, állandó ügyféljelenlét, ill. kódszabványok. Az XP iránti érdeklődés alulról felfelé nőtt – a fejlesztők és tesztelők részéről, akiket fájdalmas folyamat, dokumentáció, mérőszám és egyéb formalizmus gyötört. Nem utasították el a fegyelmet, de nem voltak hajlandók értelmetlenül követni a formai követelményeket, és új, gyors és rugalmas megközelítéseket kerestek a színvonalas programok kidolgozásához.

XP használatakor a gondos előzetes szoftvertervezést felváltja egyrészt a megrendelő állandó jelenléte a csapatban, készen válaszolni minden kérdésre és kiértékelni bármilyen prototípust, másrészt a rendszeres kódrevíziók (ún. refaktorálás). Az alaposan kommentált kód a tervdokumentáció alapja. A módszertanban nagy figyelmet fordítanak a tesztelésre. Általános szabály, hogy minden új metódushoz először egy tesztet írnak, majd a tényleges metóduskódot fejlesztik, amíg a teszt sikeresen el nem indul. Ezek a tesztek olyan csomagokban vannak tárolva, amelyek minden kódmódosítás után automatikusan végrehajtásra kerülnek.

Bár a páros programozás és a 40 órás munkahét az XP talán legismertebb funkciója, továbbra is támogató jellegűek, és hozzájárulnak a magas fejlesztői termelékenységhez és a fejlesztési hibák csökkentéséhez.

Kristálytiszta

A Crystal olyan módszertancsalád, amely a résztvevők számától és a feladatok kritikusságától függően meghatározza a fejlesztési folyamat formalizáltságának szükséges mértékét.

A Crystal Clear módszertana teljesítményben gyengébb az XP-nél, de a lehető legkönnyebben használható. Megvalósítása minimális erőfeszítést igényel, mert az emberi szokásokra összpontosít. Úgy gondolják, hogy ez a módszertan a szoftverfejlesztés természetes rendjét írja le, amely kellően képzett csapatokban jön létre, ha nem vesznek részt más módszertan célirányos megvalósításában.

A Crystal Clear legfontosabb tulajdonságai:

• iteratív inkrementális fejlesztés;
• automatikus regressziós tesztelés;
• a felhasználók részt vesznek a projektben való aktív részvételben;
• a dokumentáció összetételét a projekt résztvevői határozzák meg;
• rendszerint kódverzió-vezérlő eszközöket használnak.

A Crystal Clear mellett számos más módszer is található a Crystal családban, amelyeket nagyobb vagy kritikusabb projektekre terveztek. A dokumentáció mennyiségére és a támogató eljárásokra, például a változtatásokra és a verziókezelésre vonatkozó, kissé szigorúbb követelményekben különböznek egymástól.

Funkcióvezérelt fejlesztés

A Feature Driven Development (FDD) olyan rendszerfunkció vagy szolgáltatás szempontjából működik, amely meglehetősen közel áll a RUP használati eset koncepciójához. A legjelentősebb különbség talán egy további korlátozás: "minden egyes funkciónak legfeljebb két hét alatt kell megvalósítania." Vagyis ha elég kicsi a használati eset, akkor függvénynek tekinthető, ha pedig nagy, akkor több, viszonylag független függvényre kell bontani.

Az FDD öt folyamatot tartalmaz, amelyek közül az utolsó kettő minden funkciónál megismétlődik:

• közös modell kidolgozása;
• a szükséges rendszerfunkciók listájának összeállítása;
• az egyes funkciókra vonatkozó munka tervezése;
• funkciótervezés;
• funkció konstrukció.

A projekten végzett munka gyakori felépítésekkel jár, és iterációkra oszlik, amelyek mindegyikét egy adott szolgáltatáskészlet segítségével valósítják meg.

Az FDD fejlesztőit "osztálymesterekre" és "főprogramozókra" osztják. A fő programozók bevonják az érintett osztályok tulajdonosait, hogy a következő ingatlanon dolgozzanak. Összehasonlításképpen: XP-ben nincs személyes felelősség az osztályokért vagy metódusokért.

Közös jellemzők

A rugalmas módszertanok listája jelenleg meglehetősen széles. Mindazonáltal az általunk leírt módszertanok nagyon teljes képet adnak az egész családról.

Szinte minden agilis módszertan iteratív megközelítést alkalmaz, amelyben csak a következő kiadás kiadásához kapcsolódó korlátozott mennyiségű munkát terveznek meg részletesen.

Szinte minden agilis módszertan a fejlesztés leginformálisabb megközelítésére összpontosít. Ha a probléma egy normális beszélgetés során megoldható, akkor jobb, ha ezt tesszük. És rajzolni döntés papír formában, ill elektronikus dokumentum csak akkor szükséges, ha nélküle lehetetlen.

Agilis módszertanok

GOST-ok

A GOST-ok, akárcsak a következő részben ismertetett CMM-követelmények, nem módszertanok. Általában nem magukat a szoftverfejlesztési folyamatokat írják le, hanem csak megfogalmazzák bizonyos követelményeket olyan folyamatokhoz, amelyeknek különböző módszertanok felelnek meg ilyen vagy olyan mértékben. A követelmények összehasonlítása ugyanazon kritériumok szerint, amelyek alapján a módszereket összehasonlítjuk, azonnal eldöntheti, hogy melyik módszertant használja, ha a GOST-nak megfelelően kell fejlesztenie.

Jelenleg Oroszországban a 19. és 34. sorozat régi GOST-jai vannak érvényben új GOST R ISO IEC 122207. A 19. és 34. sorozat GOST-jai szigorúan a szoftverfejlesztés lépcsőzetes megközelítésére összpontosítanak. Ezekkel a GOST-okkal összhangban a fejlesztés szakaszokban történik, amelyek mindegyike szigorúan meghatározott munka elvégzését foglalja magában, és a kellő mennyiségű kiadás kiadásával ér véget. egy nagy szám rendkívül formalizált és kiterjedt dokumentumok. Így ezeknek a szabványoknak az azonnali szigorú betartása nemcsak a vízesés megközelítéséhez vezet, hanem egy nagyon magas fok a fejlesztés formalizálása.

GOST követelmények

A GOST 12207 a 19. és 34. sorozat szabványaival ellentétben a szoftverfejlesztést fő- és segédfolyamatok összességeként írja le, amelyek a projekt elejétől a végéig működhetnek. Modell életciklus a projekt sajátosságai alapján választható ki. Így ez a GOST nem tiltja kifejezetten az iteratív megközelítés alkalmazását, de kifejezetten nem is ajánlja annak használatát. A GOST 12207 rugalmasabb a fejlesztési folyamat formalitására vonatkozó követelmények tekintetében is. Csak utalásokat tartalmaz az összes folyamat főbb eredményeinek dokumentálásának szükségességére, de nem tartalmazza a szükséges dokumentumok listáját és a tartalmukra vonatkozó utasításokat.

Így a GOST 12207 lehetővé teszi az iteratív és kevésbé formalizált szoftverfejlesztést.

Fejlesztési folyamat érettségi modellek (CMM, CMMI)

A nemzeti és nemzetközi szabványok mellett számos megközelítés létezik a fejlesztési folyamat tanúsítására. Oroszországban a leghíresebbek a CMM és a CMMI.

A CMM (Capability Maturity Model) a szoftverfejlesztési folyamatok érettségi modellje, amely egy adott vállalat fejlesztési folyamatának érettségi szintjének felmérésére szolgál. E modell szerint a fejlesztési folyamat érettségének öt szintje van. Az első szint a „hogyan megy” fejlesztésnek felel meg, amikor a fejlesztők minden projekthez bravúrként mennek hozzá. A második a többé-kevésbé jól bevált folyamatoknak felel meg, amikor kellő magabiztossággal lehet számítani a projekt pozitív kimenetelére. A harmadik a fejlesztés során használt kidolgozott és jól leírt folyamatok meglétének, a negyedik pedig a mérőszámok aktív felhasználásának az irányítási folyamatban a célok kitűzésére és azok elérésének nyomon követésére. Végül az ötödik szint a vállalat azon képességére vonatkozik, hogy szükség szerint optimalizálja a folyamatot.

CMM és CMMI követelmények

A CMM megjelenése után speciális érettségi modelleket kezdtek fejleszteni a létrehozáshoz információs rendszerek, a beszállítók kiválasztásának folyamatához és néhány máshoz. Ezek alapján egy integrált CMMI modellt (Capability Maturity Model Integration) fejlesztettek ki. Emellett a CMMI-ben kísérlet történt a CMM addigra megnyilvánuló hiányosságainak áthidalására - a folyamatok formális leírásának szerepének eltúlzására, amikor bizonyos dokumentációk meglétét sokkal magasabbra értékelték, mint egy jól bevált, de nem leírt folyamat. A CMMI azonban egy erősen formalizált folyamat használatára is összpontosít.

Így a CMM és CMMI modellek alapja a fejlesztési folyamat formalizálása. A szabályzatban és utasításban részletesen leírt folyamat megvalósítását célozzák meg a fejlesztők, amihez viszont nagy mennyiségű projektdokumentáció kidolgozása szükséges a megfelelő ellenőrzéshez és jelentéstételhez.

A CMM és a CMMI kapcsolata az iteratív fejlesztéssel közvetettebb. Formálisan egyikük sem támaszt konkrét követelményeket a vízeséshez vagy az iteratív megközelítéshez való ragaszkodáshoz. Egyes szakértők szerint azonban a CMM jobban kompatibilis a vízesés megközelítéssel, míg a CMMI lehetővé teszi az iteratív megközelítést is.

RUP

Természetesen a RUP egy iteratív módszertan. Bár formálisan az összes fázis kötelező végrehajtása vagy bizonyos minimális számú iteráció nincs feltüntetve a RUP-ban, az egész megközelítés arra irányul, hogy ezekből elég sok van. Korlátozott mennyiség Az iterációk nem teszik lehetővé a RUP teljes előnyeinek kihasználását. Ugyanakkor a RUP szinte lépcsőzetes projektekben is használható, amelyek valóban csak néhány iterációt tartalmaznak: az egyik a Build fázisban, a másik pedig az átviteli fázisban. Mellesleg, ez az iterációk száma, amelyet ténylegesen használnak a vízesés projektekben. Hiszen a rendszer tesztelése, próbaüzeme magában foglalja a korrekciók elvégzését is, amelyek bizonyos elemzéssel, tervezéssel, fejlesztéssel kapcsolatos tevékenységeket is magukban foglalhatnak, vagyis tulajdonképpen egy újabb áthaladást jelentenek a fejlesztés minden fázisán.

RUP módszertan

Ami a módszertan formalitását illeti, a RUP nagyon széles lehetőségeket kínál a felhasználónak. Ha az összes munkát és feladatot elvégzi, minden műtárgyat készítsen és kellően formálisan (hivatalos lektorral, teljes körű bírálat elkészítésével elektronikus ill. papír dokumentum stb.) az összes felülvizsgálat elvégzéséhez a RUP egy nagyon formális, körülményes módszertan lehet. Ugyanakkor a RUP lehetővé teszi, hogy csak azokat a műtermékeket fejlessze, és csak azokat a munkákat és feladatokat hajtsa végre, amelyek egy adott projektben szükségesek. A kiválasztott műtermékek pedig tetszőleges fokú formalitás mellett végrehajthatók és áttekinthetők. Előírható minden egyes dokumentum részletes tanulmányozása, gondos kivitelezése, ugyanolyan gondosan elkészített és formalizált felülvizsgálat biztosítása, sőt a régi gyakorlat szerint minden ilyen felülvizsgálat jóváhagyása a vállalkozás tudományos és műszaki tanácsánál. Vagy korlátozhatja magát egy e-mailre vagy egy papíron készült vázlatra. Ezen kívül mindig van még egy lehetőség: fejben formálni egy dokumentumot, vagyis átgondolni a releváns kérdést, és konstruktív döntést hozni. És ha ez a döntés csak Önt érinti, korlátozza magát például egy megjegyzésre a programkódban.

Így a RUP egy iteratív módszertan, nagyon széles skálával lehetséges megoldások a fejlesztési folyamat formalizálása szempontjából.

Foglaljuk össze a cikk második részét. A RUP, ellentétben a legtöbb más módszertannal, lehetővé teszi a fejlesztési folyamat formalizálásának és iterációjának széles körben történő kiválasztását, a projektek és a fejlesztő szervezet jellemzőitől függően.

És hogy ez miért olyan fontos - a következő részben tárgyaljuk.

1. Cascade (angol vízesés) - szabványos fejlesztési modell

Kaszkád fejlesztési modell - olyan modell, amelyben a fejlesztés minden szakaszát egymás után hajtják végre - a következő szakasz az előző befejezése után kezdődik.

Ez a modell a szoftverfejlesztési folyamat következő lépéseit tartalmazza:

Mindenekelőtt el van határozva Műszaki adatok jövőbeli program, ennek eredményeként jóváhagyásra kerül a szoftverkövetelmények listája. Ezután következik a tervezésre való áttérés, melynek során dokumentáció készül, amely leírja a programozók számára a tervet és a követelmények megvalósításának módját.

A tervezés befejezése után a programozók megvalósítják (konstruálják) a projektet. A megvalósítás szakaszában a projekt összes összetevője integrálva van. Csak ezeknek a szakaszoknak a teljes befejezése után kerül sor a késztermék tesztelésére és hibakeresésére. Továbbá a szoftvertermék implementálható, és a megvalósítás után támogatást nyújthat - új funkcionalitást vezet be, és kiküszöbölheti a hibákat.

A vízesés fejlesztésének fő előnyei:

2. Agilis szoftverfejlesztési módszertan

Fejlesztési módszertanok sora szoftver, amely a megrendelő és a fejlesztők képviselőinek közös munkáját biztosítja. Az agilis fejlesztési módszer az iteratív megközelítésen, a követelmények dinamikus kialakításán és azok rövid szakaszokban történő megvalósításán alapul.

Minden ilyen szakasz eredménye, beleértve az iterációs ciklust is, egy miniatűr szoftverprojekt,

Számos agilis fejlesztési módszer létezik, a leghíresebbek a Scrum, Extreme Programming, DSDM.

Az agilis fejlesztés fő előnyei:

		kockázat minimalizálása; a szoftvertermék funkcionalitásának fokozatos növelése; kis mennyiségű írásos dokumentáció; a program alapverziójának mielőbbi elindítása.
Vannak hátrányai is:
		képtelenség pontosan meghatározni a projekt költségvetését; a projekt készenlétének pontos időzítésének lehetetlensége; nem alkalmas állami és költségvetési szervezetek számára; motivációt igényel az ügyfél felelős képviselőitől.

Agilis szoftverfejlesztési kiáltvány Folyamatosan jobb módszereket fedezünk fel a szoftverfejlesztés közvetlen fejlesztésével és mások segítésével. Az elvégzett munkának köszönhetően rájöttünk, hogy: Emberek és interakció fontosabb, mint a folyamatok és az eszközök Működő termék fontosabb, mint az átfogó dokumentáció Együttműködés az ügyféllel fontosabb, mint a szerződés feltételeinek tárgyalása A változásra való felkészültség sokkal fontosabb az eredeti tervet követve Vagyis anélkül, hogy tagadnánk a jobb oldali jelentőségét, mégis jobban értékeljük azt, ami a bal oldalon van.

Az agilis fejlesztés alapelvei:

Ügyfél-elégedettség a szükséges szoftverek gyors és zavartalan szállítása miatt; a követelmények változásának üdvözlése már a fejlesztés végén is (ez növelheti a keletkező termék versenyképességét); működő szoftverek gyakori szállítása (havonta vagy hetente vagy még gyakrabban); szoros, napi kommunikáció a megrendelő és a fejlesztők között a projekt során; a projektet motivált személyek hajtják végre, akik számára biztosítottak a szükséges munkakörülmények, támogatás és bizalom; az információátadás javasolt módja a személyes beszélgetés (szemtől szemben); a működő szoftver a fejlődés legjobb mércéje; a szponzoroknak, a fejlesztőknek és a felhasználóknak a végtelenségig állandó tempót kell tartaniuk; állandó összpontosítás a műszaki kiválóság és a felhasználóbarát tervezés javítására; egyszerűség - a művészet, hogy ne végezzünk felesleges munkát; a legjobb műszaki követelmények, a tervezés és az építészet egy önszerveződő csapattól származik; állandó alkalmazkodás a változó körülményekhez.

Szoftverfejlesztési modellek Vízesés Cascade modell Spirál Extrém programozás UI prototípusok növekményes W-modell tesztelése az egységes szoftverfejlesztési folyamat (USDP) MSF módszertana

Vízesés modell Követelményelemzés Termékspecifikáció összeállítása Tervezés Termékarchitektúra összeállítása Megvalósítás Forráskód fejlesztése Forráskód külön részeinek integrálása Tesztelés és hibaelhárítás

Extrém programozási kezdeti követelmények elemzése tervezés integráció megvalósítás tesztelése új követelmények felülvizsgálata/jóváhagyása/módosítása fejlesztési terv kiadása

UI Prototyping Termék kiadás Szoftverfejlesztés a változásokat szem előtt tartva Követelmények és specifikációk tisztázása Prototípus módosítása és néhány funkció finomítása Alapvető funkcionalitás Interfész prototípus Előzetes specifikáció

Növekményes fejlesztés 1. iteráció 2. iteráció …. Követelmények Elemzés Tervezés Megvalósítás Komponens tesztelés Integráció A teljes egész iteráció tesztelése N

Egységes szoftverfejlesztési folyamat (USDP) Ø Használati esetmodell, leírja azokat az eseteket, amikor az alkalmazást használni fogják. Ø Az analitikai modell leírja az alkalmazás alaposztályait. Ø A tervezési modell az osztályok és a kiválasztott objektumok közötti kapcsolatokat és kapcsolatokat írja le. Ø A telepítési modell a szoftverek számítógépek közötti elosztását írja le. Ø A megvalósítási modell leírja belső szervezet programkód. Ø A tesztmodell tesztkomponensekből, vizsgálati eljárásokból és különböző tesztesetekből áll

Egységes szoftverfejlesztési folyamat (USDP) követelményeinek összegyűjtése Iter 1…. Iter N Az Iter 1 tervezése…. Iter N Az Iter 1 megvalósítása…. Iter N Az Iter 1 tervezése…. Iter N tesztelése Iter 1…. Iter N

Tipikus szoftvertermék-architektúra komponensek és tipikus szoftverkövetelmények Ø Ø Ø Ø Programszervezés Fő rendszerosztályok Adatszervezés Üzleti szabályok Felhasználói felület Erőforrás-kezelés Biztonság Teljesítmény Skálázhatóság Interakció más rendszerekkel (integráció) Nemzetköziesítés, honosítás Bemeneti-kimeneti adatok Hibakezelés

Tipikus szoftvertermék-architektúra-összetevők és tipikus szoftverkövetelmények A hibatűrés olyan rendszertulajdonságok halmaza, amelyek javítják a rendszer megbízhatóságát azáltal, hogy észlelik a hibákat, helyreállítják és elkülönítik a rendszerre gyakorolt ​​rossz következményeket. Bármilyen valós rendszer tervezése során a hibatűrés biztosítása érdekében előre kell látni minden olyan lehetséges helyzetet, amely rendszerhibához vezethet, és ki kell dolgozni a meghibásodások kezelésére szolgáló mechanizmusokat. A megbízhatóság a rendszer azon képessége, hogy ellenálljon a különféle hibáknak és hibáknak. A meghibásodás a rendszer átmenete egy hiba következtében teljesen működésképtelen állapotba. A hiba a rendszer működésében fellépő hiba, amely nem vezet a rendszer meghibásodásához. Minél kevesebb meghibásodás és meghibásodás egy bizonyos ideig, annál megbízhatóbbnak tekinthető a rendszer.

A szoftvertermék architektúrájának tipikus összetevői és tipikus szoftverkövetelményei Megbízhatósági görbe N t 1 t Minél távolabbról, annál nehezebb lesz hibát találni. Minél összetettebb a rendszer, annál nagyobb a meghibásodások és meghibásodások valószínűsége.

A szoftvertermék architektúrájának jellemző komponensei és jellemző szoftverigényei Ø A kifejlesztett architektúra megvalósításának lehetőségei. Ø Túl sok funkcionalitás. Ø Döntés meghozatala kész szoftverkomponensek vásárlásáról. Ø Stratégia módosítása.

A kérdések ellenőrző listája, amely lehetővé teszi, hogy következtetéseket vonjon le az architektúra minőségéről: Ø Világosan le van írva a program általános felépítése; Ø Ø Ø A specifikáció tartalmazza-e az architektúra áttekintését és annak indokait. Megfelelően meghatározzák-e a program fő összetevőit, felelősségi területeiket és interakcióikat a többi komponenssel. A követelményspecifikációban meghatározott összes funkciót ésszerű számú rendszerkomponens megvalósítja-e. Leírják és indokolják a legfontosabb osztályokat. Adva van-e az adatbázis felépítésének leírása. Minden üzleti szabály meghatározott? Leírják a rendszerre gyakorolt ​​hatásukat?

A kérdések ellenőrző listája, amely lehetővé teszi, hogy következtetést vonjon le az architektúra minőségéről: Ø Le van írva a felhasználói felület tervezési stratégiája. Ø Megtörtént felhasználói felület moduláris, így annak változásai ne érintsék a rendszer többi részét. ØAdva van-e az adatbeviteli/kimeneti stratégia leírása. Ø Elvégezték-e az ezzel az architektúrával megvalósítandó rendszer teljesítményelemzését. Ø Elvégezték-e a tervezett rendszer megbízhatósági elemzését. Ø Megtörtént-e a rendszer skálázhatósági és bővíthetőségi kérdéseinek elemzése.

Szoftver-refaktorálás A refaktorálás magában foglalja a szoftverek újhoz igazítását hardver valamint az új operációs rendszerekre, új fejlesztőeszközökre, új követelményekre, valamint a szoftver architektúrára és funkcionalitására. Ez a szoftver belső szerkezetének megváltoztatása anélkül, hogy azt megváltoztatná. külső viselkedés szoftver módosítására tervezték. A refaktorálás ésszerű okai: A kód ismétlődő; a módszer megvalósítása túl nagy; túl sok hurkok egymásba ágyazása, vagy maga a hurok nagyon nagy; az osztálynak gyenge a kapcsolata (az osztály tulajdonságai és metódusai csak 1 objektumot írjanak le); egy osztályinterfész nem alkot konzisztens absztrakciót; a módszer túl sok paramétert igényel. Meg kell próbálnia a paraméterek számát ésszerű minimumon tartani; az osztály egyes részei az osztály többi részétől függetlenül változnak;

A szoftver átalakítása a program megváltoztatásakor több osztály párhuzamos megváltoztatását igényli. Ha ilyen helyzet adódik, az osztályok átszervezése szükséges, hogy a jövőben minimálisra csökkenjenek az esetleges változások helyei; párhuzamosan több öröklési hierarchiát kell megváltoztatnia; több esetblokkot kell módosítania. A programot úgy kell módosítani, hogy az ügy blokkba kerüljön, és a programban annyiszor hívja meg; Az együtt használt kapcsolódó adattagok nincsenek osztályokba rendezve. Ha ismételten ugyanazt az adatelem-készletet használja, akkor érdemes megfontolni ezen adatok kombinálását és a velük végzett műveletek külön osztályba helyezését;

Egy szoftverrefaktorálási módszer több elemet használ egy másik osztályból, mint a sajátja. Ez azt jelenti, hogy a metódust át kell helyezni egy másik osztályba, és a régiből kell meghívni; az elemi adattípus túlterhelt. A való világ lényegének leírásához jobb bármelyik osztályt használni, mint bármelyiket túlterhelni meglévő típus adat; az osztály túlságosan korlátozott funkciókkal rendelkezik. Jobb, ha megszabadulunk ettől az osztálytól, ha funkcionalitását egy másik osztályba helyezzük át; "kóbor" adatokat továbbítanak a módszerek láncolatán. Azokat az adatokat, amelyeket egy metódusnak csak azért adnak át, hogy átadják egy másik metódusnak, kóbor adatoknak nevezzük. Ha ilyen helyzetek merülnek fel, próbálja meg megváltoztatni az osztályok és módszerek architektúráját, hogy megszabaduljon tőlük.

A médiaobjektum újrafaktorálása nem tesz semmit. Ha egy osztály feladata a metódushívások átirányítása más osztályokhoz, akkor a legjobb, ha megszünteti ezt a proxyt, és közvetlenül más osztályokat hív meg; az egyik osztály túl sokat tud a másik osztályról. Ebben a helyzetben szigorúbbá kell tenni a tokozást, hogy az örökös minimális ismeretekkel rendelkezzen a szülőjéről; a módszernek szerencsétlen neve van; az adatok tagjai nyilvánosak. Ez elmossa a határvonalat az interfész és a megvalósítás között, elkerülhetetlenül megszakítja a tokozást, és korlátozza a program rugalmasságát; hozzászólásokat írj be forráskód;

Egy szoftverrefaktoráló alosztály csak egy kis töredékét használja az ősei módszereinek. Ez a helyzet akkor fordul elő, ha egy új osztály csak néhány metódus öröklésére szolgál az alaposztályból, és nem ír le új entitást. Ennek elkerülése érdekében az alaposztályt úgy kell átalakítani, hogy az csak a számára szükséges metódusoknak adjon hozzáférést az új osztályhoz; a kód globális változókat tartalmaz. Csak a teljes program által ténylegesen használt változók legyenek globálisak. Az összes többi változónak vagy lokálisnak kell lennie, vagy valamilyen objektum tulajdonságává kell válnia; a program olyan kódot tartalmaz, amelyre egyszer szükség lehet. A rendszer fejlesztésénél célszerű olyan helyeket biztosítani, ahol a jövőben forráskódot lehet hozzáadni.

Tehát az EIS szoftverek fejlesztésének strukturális megközelítésének lényege az automatizált funkciókra való lebontásában (particionálásában) rejlik: a rendszer funkcionális alrendszerekre oszlik, amelyek viszont alfunkciókra, ezek feladatokra, stb. meghatározott eljárásokig. Ugyanakkor a rendszer megőrzi a holisztikus nézetet, amelyben az összes alkotóelem összekapcsolódik. Az "alulról felfelé" építkező rendszer kialakítása során az egyes feladatoktól a teljes rendszerig elvész az integritás, problémák merülnek fel az egyes komponensek információs interakciójának leírásánál.

A strukturális megközelítés összes leggyakoribb módszere számos Általános elvek:

1. Az „oszd meg és uralkodj” elve;

2. A hierarchikus rendezés elve - a rendszer alkotórészeinek hierarchikus fastruktúrákba szervezésének elve, minden szinten új részletek hozzáadásával.

Válogatás kettőből alapelvek nem jelenti azt, hogy a többi elv másodlagos, mert ezek bármelyikének figyelmen kívül hagyása beláthatatlan következményekkel járhat (beleértve a teljes projekt kudarcát is). Ezen elvek főbbek a következők:

1. Az absztrakció elve - a rendszer lényeges aspektusainak kiemelése és a figyelemelvonás a nem lényegestől.

2. A rendszer elemeinek konzisztenciájának, érvényességének és konzisztenciájának elve.

3. Strukturálási elv adat – adat strukturáltnak és hierarchikusan szervezettnek kell lennie.

A strukturális megközelítésben alapvetően két eszközcsoport van, amelyek a rendszer funkcionális felépítését és az adatok közötti kapcsolatokat írják le. Minden eszközcsoport bizonyos típusú modelleknek (diagramoknak) felel meg, ezek közül a leggyakoribbak:

· DFD (Data Flow Diagrams) - adatfolyamok diagramjai;

SADT (Structured Analysis and Design Technique - szerkezeti elemzés és tervezés módszertana) - modellek és megfelelő funkcionális diagramok: IDEF0 (rendszerek funkcionális modellezése), IDEF1x (adatbázisok fogalmi modellezése), IDEF3x (egy objektum minőségének felmérésére szolgáló építési rendszerek) jelölések az áramlási folyamatok grafikus leírása, a folyamatok és a folyamatok által megváltoztatott objektumok interakciója);

· ERD (Entity - Relationship Diagrams) - "entitás-kapcsolat" diagramok.

A strukturális megközelítés (strukturális elemzés) szinte minden módszerében a modellező eszközök két csoportját használják a szoftverkövetelmények kialakításának szakaszában:

1. A rendszernek végrehajtandó funkciókat és a funkciók közötti kapcsolatokat bemutató diagramok - DFD vagy SADT (IDEF0).

2. Adatokat és kapcsolataikat modellező diagramok (ERD).

A felsorolt ​​diagramok konkrét formája és felépítésük értelmezése a szoftver életciklusának szakaszától függ.

A szoftverkövetelmények kialakításának szakaszában a SADT modelleket és a DFD-t használják az „AS-IS” és a „TO-BE” modell felépítésére, így tükrözve a szervezet üzleti folyamatainak meglévő és javasolt struktúráját, valamint a köztük lévő kölcsönhatást. (A SADT modellek használata általában csak erre a szakaszra korlátozódik, mivel eredetileg nem szoftvertervezésre készültek). Az ERD segítségével a szervezetben használt adatok fogalmi szintű leírása valósul meg, függetlenül az adatbázis (DBMS) megvalósításának eszközeitől.

Megjegyzés: A szoftverfejlesztés rugalmas megközelítését, a rugalmas fejlesztés alapelveit veszik figyelembe. Olyan technikák listája szerepel, amelyek bizonyos mértékig megfelelnek a rugalmas szoftverfejlesztés alapelveinek. Elemezzük az agilis fejlesztés kulcsfontosságú értékeit és alapelveit.

Az előadás prezentációja letölthető.

Az előadás célja:

Ismerje meg az agilis szoftverfejlesztés célját és alapelveit.

Bevezetés

Agilis szoftverfejlesztési módszertan iteratív megközelítés alkalmazására összpontosított, amelyben szoftver fokozatosan, kis lépésekben jön létre, beleértve egy bizonyos követelményrendszer megvalósítását. Feltételezhető, hogy a követelmények változhatnak. Az agilis módszertanokat alkalmazó csapatok sokoldalú fejlesztőkből alakulnak, akik különféle feladatokat látnak el a szoftvertermékek létrehozásának folyamatában.

Agilis módszerek alkalmazásakor a kockázatminimalizálást úgy hajtják végre, hogy a fejlesztést rövid ciklusok sorozatára, ún iterációk, 2-3 hétig tart. Az iteráció a végrehajtásra ütemezett feladatok halmaza bizonyos időszak idő. Minden iterációban létrejön a szoftverrendszer működőképes verziója, amelyben a legnagyobb prioritás (ennél az iterációnál) vevői követelmények. Minden iteráció elvégzi a működő szoftver létrehozásához szükséges összes feladatot: tervezés, követelményelemzés, tervezés, kódolás, tesztelés és dokumentáció. Bár egyetlen iteráció általában nem elég a kiadáshoz új verzió termék, érthető, hogy a jelenlegi szoftver kiadásra kész minden iteráció végén. Minden iteráció végén a csapat újra priorizálja a szoftvertermék követelményeit, esetleg módosítja a rendszerfejlesztést.

Az agilis fejlesztés alapelvei és jelentése

Az agilis fejlesztési módszertanhoz kulcsfontosságú posztulátumok vannak deklarálva, amelyek lehetővé teszik a csapatok számára, hogy magas teljesítményt érjenek el:

• emberek és interakcióik;
• működő szoftverek szállítása;
• együttműködés az ügyféllel;
• válasz a változásra.

Emberek és interakció. Az emberek a legfontosabbak összetevő siker. Az egyéni csapattagok és a jó kommunikáció elengedhetetlen a jól teljesítő csapatokhoz. A kommunikáció megkönnyítése érdekében az agilis gyakorlatok magukban foglalják a munkaeredmények és a döntések megváltoztatásának gyakori megbeszélését. A megbeszéléseket naponta néhány percig, az iteráció végén pedig a munka eredményeinek elemzésével és visszatekintéssel lehet tartani. Az értekezletek során a hatékony kommunikáció érdekében a csapattagoknak be kell tartaniuk a következőket kulcsfontosságú szabályokat viselkedések:

• minden csapattag véleményének tiszteletben tartása;
• legyen őszinte minden kommunikációban;
• minden adat, intézkedés és döntés átláthatósága;
• bizalom abban, hogy minden résztvevő támogatni fogja a csapatot;
• elkötelezettség a csapat és céljai iránt.

A hatékony csapat és a jó kommunikáció mellett tökéletes szoftvereszközökre van szükség ahhoz, hogy agilis módszertannal nagy teljesítményű csapatokat hozzanak létre.

A működő szoftver fontosabb, mint az átfogó dokumentáció. Minden agilis módszertan rámutat arra, hogy előre meghatározott időközönként kisméretű működő szoftvereket kell eljuttatni az ügyfélhez. Szoftver, mint szabály, meg kell felelnie az egységtesztelés szintjén, a rendszerszintű tesztelésnek. A dokumentáció mennyiségét minimálisra kell csökkenteni. A tervezési folyamat során a csapatnak naprakészen kell tartania egy rövid dokumentumot, amely tartalmazza a döntés indoklását és a szerkezet leírását.

Az ügyféllel való együttműködés fontosabb, mint a szerződés szerinti formális megállapodások. A projekt sikeres befejezéséhez rendszeres és gyakori kommunikáció szükséges a megrendelővel. Az ügyfélnek rendszeresen részt kell vennie a szoftverrel kapcsolatos döntések megvitatásában, ki kell fejeznie kívánságait, észrevételeit. A minőségi termék létrehozásához szükséges az ügyfél bevonása a szoftverfejlesztési folyamatba.

A változásokra való gyors reagálás fontosabb, mint a terv követése. A változásokra való reagálás képessége nagymértékben meghatározza egy szoftverprojekt sikerét. A szoftvertermékek létrehozása során gyakran változnak vevői követelmények. Az ügyfelek gyakran nem tudják pontosan, mit akarnak, amíg nem látják, hogy működik. szoftver. Az agilis módszertanok a szoftvertermékek létrehozása során visszajelzéseket keresnek az ügyfelektől. A változásokra való reagálás elengedhetetlen egy olyan termék létrehozásához, amely vevői elégedettséget és üzleti értéket biztosít.

Az agilis fejlesztés alapelveit 12 alapelv támogatja. Az agilis specifikus módszertanok olyan folyamatokat és szabályokat határoznak meg, amelyek többé-kevésbé megfelelnek ezeknek az elveknek. A szoftvertermékek létrehozásának rugalmas módszerei a következő elveken alapulnak:

1. A legfontosabb az, hogy a vevő kívánságait kielégítsük hasznos szoftverek rövid időn belüli szállításával, folyamatos frissítés. Az agilis gyakorlatok közé tartozik a gyors kezdeti kiadás és a gyakori frissítések. A csapat célja, hogy a projekt elindítását követő néhány héten belül működő verziót szállítsanak. További szoftverrendszerek fokozatosan bővülő funkcionalitással néhány hetente kell szállítani. Az ügyfél elkezdheti kereskedelmi működés rendszert, ha kellően működőképesnek tartja. Ezenkívül az ügyfél egyszerűen tud olvasni jelenlegi verzió szoftver, adja meg visszajelzését megjegyzésekkel.
2. Ne hagyja figyelmen kívül a változó követelményeket, még a fejlesztés késői szakaszában sem. Az agilis folyamatok lehetővé teszik a változtatások befogadását, hogy biztosítsák versenyelőny vevő. Az agilis módszertanokat alkalmazó csapatok arra törekszenek, hogy a programszerkezet minőségi legyen, a változtatások minimális hatással a rendszer egészére.
3. A szoftver új működő verzióinak átadása gyakran, egy héttől két hónapig terjedő időközönként, a rövidebb határidők preferálásával. Ugyanakkor cél a felhasználó igényeinek megfelelő program szállítása, minimális kísérő dokumentációval.
4. Az ügyfeleknek és a fejlesztőknek együtt kell működniük a projekt során. Úgy gondolják, hogy egy sikeres projekthez az ügyfeleknek, a fejlesztőknek és az összes érdekelt félnek gyakran és sokféleképpen kell kommunikálnia a szoftvertermék célirányos fejlesztése érdekében.
5. A projekteket motivált embereknek kell megvalósítaniuk. Biztosítson egészséges munkakörnyezetet a projektcsapatnak, biztosítsa a szükséges támogatást, és bízzon abban, hogy a csapattagok elvégzik a munkát.
6. A leghatékonyabb és legtermékenyebb módszer a fejlesztőcsapat felé történő információtovábbításra és azon belüli véleménycserére a személyes beszélgetés. Az agilis projektekben a kommunikáció fő módja az egyszerű emberi interakció. Az írásos dokumentumok a szoftver fejlesztésével párhuzamosan jönnek létre és frissülnek, és csak szükség esetén.
7. A munkaprogram a projekt előrehaladásának fő mutatója. Egy agilis projekt befejezésének megközelítését a rendelkezésre álló mennyiség alapján ítélik meg Ebben a pillanatban a program megfelel a megrendelő igényeinek.
8. Az agilis folyamatok elősegítik a hosszú távú fejlődést. Az ügyfeleknek, fejlesztőknek és felhasználóknak a végtelenségig állandó ütemben kell tartaniuk.
9. A mérnöki kiválóságra és a minőségi tervezésre való szakadatlan összpontosítás növeli az agilis technológiák megtérülését. Az agilis csapattagok arra törekszenek, hogy minőségi kódot hozzanak létre rendszeres átalakításokkal.
10. Az egyszerűség annak művészete, hogy kevesebbet csinálva többet érjünk el. A csapat tagjai az aktuális feladatokat a lehető legegyszerűbben és leghatékonyabban oldják meg. Ha a jövőben probléma adódna, akkor lehetőség van a minőségi kód módosítására nagy költség nélkül.
11. A legjobb architektúrák, követelmények és tervek önszerveződő csapatoktól származnak. A rugalmas csapatokban a feladatokat nem egyes tagokhoz, hanem a csapat egészéhez osztják ki. A csapat maga dönti el, hogyan valósítja meg a legjobban az ügyfél igényeit. A csapat tagjai a projekt minden területén együttműködve dolgoznak. Minden résztvevő hozzájárulhat a közös ügyhöz. A csapat egyetlen tagja sem felelős kizárólag az architektúráért, a követelményekért vagy a tesztekért.
12. A csapatnak rendszeresen át kell gondolnia, hogyan válhat még hatékonyabbá, majd ennek megfelelően igazítsa és finomítsa viselkedését. Egy agilis csapat folyamatosan módosítja szervezetét, szabályait, megállapodásait és kapcsolatait.

A fenti elvek bizonyos mértékig megfelelnek számos szoftverfejlesztési módszertannak:

Agilis modellezés	koncepciók, elvek és technikák (gyakorlatok) összessége, amely lehetővé teszi a szoftverfejlesztési projektekben a modellezés és a dokumentáció gyors és egyszerű végrehajtását;
Agilis egységes folyamat (AUP)	az IBM RationalUnifiedProcess(RUP) egyszerűsített változata, amely egy egyszerű és érthető közelítést (modellt) ír le az üzleti alkalmazások szoftvereinek elkészítéséhez;
Nyit	ez a szoftverfejlesztés iteratív-növekményes módszere. Könnyű és rugalmas RUP opcióként van elhelyezve;
AgileDataMethod	iteratív szoftverfejlesztési módszerek csoportja, amelyben a követelmények és a megoldások különböző, többfunkciós csapatok együttműködésével valósulnak meg;
DSDM	a gyors alkalmazásfejlesztés (RapidApplicationDevelopment, RAD) koncepcióján alapuló dinamikus rendszerek fejlesztésének módszertana. Iteratív és inkrementális megközelítést képvisel, amely hangsúlyozza a felhasználó/fogyasztó folyamatos részvételét a folyamatban;
Extrém programozás (XP)	extrém programozás;
Adaptív szoftverfejlesztés (ADD)	adaptív szoftverfejlesztés;
Funkcióvezérelt fejlesztés (FDD)	a funkcionalitás fokozatos kiegészítésére összpontosító fejlesztés;
Igazivá válni	iteratív megközelítés a webes alkalmazásokhoz használt funkcionális specifikációk nélkül;
MSFfogAgileSoftwareDevelopment	Agilis szoftverfejlesztési módszertan a Microsofttól;
Dulakodás	szabályokat állapít meg a fejlesztési folyamat irányítására, és lehetővé teszi a meglévő kódolási gyakorlatok használatát a követelmények módosításával vagy taktikai változtatásokkal [