3.2. Kaszkád stratégia

A kaszkád stratégia (egyszeri áthaladás, vízesés vagy klasszikus modell) magában foglalja az információs rendszer létrehozásának szakaszainak lineáris végrehajtási sorrendjét (3.1. ábra). Más szóval, az egyik szakaszból a másikba való átmenet csak az aktuális munka teljes befejezése után következik be.

3.1. ábra. Kaszkád stratégia

Ezt a modellt használják az információs rendszerek fejlesztésében, amelyekre vonatkozóan már a fejlesztés kezdetén minden követelmény elég pontosan és maradéktalanul megfogalmazható.

A modell előnyei:

Minden szakaszban egy komplett dokumentáció, szoftver és hardver készlet készül, amely megfelel a teljesség és a következetesség kritériumainak;

Az egyértelmű sorrendben végrehajtott szakaszok lehetővé teszik a munka ütemezésének és a megfelelő erőforrások (pénzügyi, anyagi és emberi) magabiztos megtervezését.

A modell hátrányai:

Az információs rendszer fejlesztésének tényleges folyamata ritkán illeszkedik teljesen egy ilyen merev sémába. Ez különösen vonatkozik az atipikus és innovatív rendszerek fejlesztésére;

Az információs rendszerrel szemben támasztott kezdeti követelmények pontos megfogalmazása alapján. A valóságban a projekt kezdetén az ügyfél igényei csak részben vannak meghatározva;

A fő hátrány, hogy a fejlesztési eredmények csak a projekt végén állnak a megrendelő rendelkezésére. Ha a követelményeket pontatlanul fogalmazzák meg, vagy az IP kialakításának hosszú ideje alatt változnak, akkor az ügyfél olyan rendszert kap, amely nem felel meg az igényeinek.

3.3. Inkrementális stratégia

Az inkrementális stratégia (angolul: increment) egy olyan információs rendszer kifejlesztését jelenti, amely szakaszok lineáris sorozatával, de több lépésben (verzióban) történik, azaz a termék tervezett fejlesztésével.

3.2. ábra. Inkrementális stratégia

A projekten végzett munka elején meghatározzák a rendszerre vonatkozó összes alapvető követelményt, majd ezt követően változatok sorozata formájában fejlesztik. Sőt, mindegyik verzió egy komplett és funkcionális termék. Az első verzió a tervezett képességek egy részét valósítja meg, a következő verzió további lehetőségeket valósít meg, és így tovább, egészen a teljes rendszer eléréséig.

Ez az életciklus-modell a komplex és integrált rendszerek fejlesztésére jellemző, amelynél világos elképzelés van (mind a megrendelő, mind a fejlesztő részéről), hogy mi legyen a végeredmény (információs rendszer). A verziófejlesztés különböző okokból történik:

Az ügyfélnek nincs lehetősége a teljes költséges projektet egyszerre finanszírozni;

A fejlesztő nem rendelkezik a szükséges erőforrásokkal egy komplex projekt rövid időn belüli megvalósításához;

A termék végfelhasználók általi szakaszos bevezetésére és elfogadására vonatkozó követelmények. A teljes rendszer egyidejű bevezetése elutasítást okozhat a felhasználók körében, és csak „lelassítja” az új technológiákra való átállás folyamatát. Képletesen szólva, előfordulhat, hogy egyszerűen „nem emésztenek meg egy nagy darabot, ezért fel kell vágni és részekre kell adni”.

Előnyök És hibákat Ez a stratégia ugyanaz, mint a klasszikus. De a klasszikus stratégiával ellentétben az ügyfél korábban láthatja az eredményeket. Az első változat fejlesztésének és megvalósításának eredményei alapján a fejlesztés követelményeit kismértékben módosíthatja, lemondhat arról, vagy új szerződés megkötésével egy fejlettebb termék fejlesztését ajánlhatja fel.

3.4. Spirális stratégia

A spirálstratégia (evolúciós vagy iteratív modell, Barry Boehm, 1988) magában foglalja a változatok sorozatában történő fejlesztést, de nem minden követelmény van meghatározva a projekt elején. A követelmények a verziók fejlesztésével finomodnak.

Rizs. 3.3. Spirális stratégia

Ez az életciklus-modell az innovatív (nem szabványos) rendszerek fejlesztésére jellemző. A projekten végzett munka kezdetén a megrendelőnek és a fejlesztőnek nincs világos elképzelése a végtermékről (a követelmények nem határozhatók meg egyértelműen), vagy száz százalékos bizalommal a projekt sikeres megvalósításában (a kockázatok nagyon magasak). Ezzel kapcsolatban döntés születik a rendszer részleges fejlesztéséről, a követelmények megváltoztatásának lehetőségével vagy a további fejlesztés megtagadásával. Amint a 3.3. ábrán látható, a projektfejlesztés nem csak a megvalósítás, hanem a kockázatelemzési szakasz után is befejezhető.

A modell előnyei:

Lehetővé teszi, hogy gyorsan megmutassa a rendszer felhasználóinak működőképes terméket, ezáltal aktiválja a követelmények tisztázásának és kiegészítésének folyamatát;

Lehetővé teszi a követelmények megváltoztatását az információs rendszer fejlesztése során, ami a legtöbb fejlesztésre jellemző, beleértve a szabványosakat is;

Nagyobb rugalmasságot biztosít a projektmenedzsmentben;

Lehetővé teszi, hogy megbízhatóbb és stabilabb rendszert kapjon. Ahogy a rendszer fejlődik, a hibákat és gyengeségeket minden iterációnál felfedezik és kijavítják;

Lehetővé teszi a fejlesztési folyamat javítását - az egyes iterációk során elvégzett elemzés lehetővé teszi, hogy felmérje, mit kell változtatni a fejlesztési szervezetben, és javítani kell a következő iterációnál;

A vásárlói kockázatok csökkennek. A megrendelő minimális anyagi veszteséggel fejezheti be egy kilátástalan projekt kidolgozását.

A modell hátrányai:

Növekszik a fejlesztő bizonytalansága a projekt fejlesztési kilátásaival kapcsolatban. Ez a hátrány a modell korábbi előnyéből következik;

Az egész projekt idő- és erőforrás-tervezésének műveletei bonyolultak. A probléma megoldásához az életciklus minden szakaszára időbeli korlátozásokat kell bevezetni. Az átállás a tervek szerint halad, még akkor is, ha nem fejeződik be minden tervezett munka. A terv a korábbi projektek során szerzett statisztikai adatok és a fejlesztők személyes tapasztalatai alapján készül.

3.5. Modellek összehasonlító elemzése

A különböző életciklus-modellek ismerete és gyakorlati alkalmazásának képessége minden projektvezető számára szükséges. A modell helyes megválasztása lehetővé teszi a munka elvégzéséhez szükséges finanszírozás, időzítés és erőforrások hozzáértő megtervezését, csökkentve a fejlesztő és a megrendelő kockázatait. Ez segít növelni a fejlesztők tekintélyét (imázsát) az ügyfél szemében, és befolyásolja a vele és más ügyfelekkel való további együttműködés kilátásait. Tévedés azt gondolni, hogy a spirálmodell jobb, mint a többi. Hiszen minden projektre külön szerződést kötnek bizonyos költséggel. Az ügyfél soha nem köt nagy összegű, bizonytalan végeredménnyel járó szerződést (hacsak nem altruista). Ebben az esetben felajánlja, hogy kezdetben egy kis összeget fektet be a projektbe, és az első verzió (iteráció) eredményei alapján dönt a rendszer fejlesztésére vonatkozó további szerződés megkötéséről.

Mindegyik modellnek megvannak a maga előnyei és hátrányai, valamint alkalmazási területei, a fejlesztendő rendszer sajátosságaitól, a megrendelő és a fejlesztő képességeitől stb. függően. Táblázat. A 3.1 összehasonlító leírást ad a fent tárgyalt modellekről, ami segíthet egy adott projekt stratégiájának kiválasztásában.

3.1. táblázat. Életciklus modellek összehasonlítása

Jellegzetes projektet	Modell (stratégia)
A fejlesztés újszerűsége és az erőforrások elérhetősége	Tipikus. Jól kidolgozott technológia és módszerek a probléma megoldására		Atipikus (innovatív). Nem szokványos egy fejlesztő számára
	A megrendelő és a fejlesztő erőforrásai elegendőek a projekt rövid időn belüli megvalósításához	A megrendelő vagy a fejlesztő erőforrásai nem elegendőek a projekt rövid időn belüli megvalósításához
Projekt hatóköre	Kis és közepes projektek	Közepes és nagy projektek	Bármilyen projekt
A projekt határideje	Akár egy évig	Akár több évig is. Egy-egy verzió fejlesztése több héttől egy évig is eltarthat
Külön szerződések megkötése az egyes változatokra	Egy szerződés jön létre. A verzió a projekt végeredménye	Külön szerződést általában egyetlen vagy több egymást követő változatra kötnek
Alapvető követelmények meghatározása a projekt elején	Igen	Igen	Nem
A követelmények a projekt fejlődésével változnak	Nem	Kisebb	Igen
Fejlesztés iterációk szerint (verziók)	Nem	Igen	Igen
Köztesszoftver-terjesztés	Nem	Lehet	Igen

táblázatban 3.1, az „Igen” és „Nem” értékek nem tekinthetők szigorú követelménynek. Például a vízesés-modell alkalmazása során a projekt fejlődése során a követelmények kisebb változásai (például néhány előre nem látható szolgáltatási funkció hozzáadása) nem olyan ritkák, és ha megvalósul, hozzájárulnak a felek közötti kapcsolat javításához. Hasonlóképpen, a köztes szoftverek spirálmodellben történő elosztása szükségtelen, sőt néha még káros is a rendszer bevezetésének és próbaüzemének folyamatára nézve.

A rendszer fejlesztése során a végterméket és a köztes szoftvert a következőképpen kell érteni:

- könyvvizsgálat (javító vagy kísérleti) - a szoftverek és információs szoftverek, valamint az adatbázis minden olyan működési változása, amely jelenleg nem szükséges a megvalósítási helyekre való átvitelhez, és hibaelhárítással, javítással jár;

- módosítás – a szoftverek és információs szoftverek, valamint az adatbázis minden olyan működési változása, amely a megvalósítási helyszínekre történő átadáskor kötelező, és a működési jellemzők változását okozza a funkciók megváltoztatása nélkül (előírt), valamint a hibaelhárítással, javítással kapcsolatos változtatások;

- változat – a szoftverek és információs szoftverek, valamint az adatbázis bármely olyan változtatása, amely kötelező az implementációs objektumokhoz történő átvitelhez, lehetővé téve a deklarált vagy kiegészítő funkciók ellátását, valamint az új operációs rendszerre és információs környezetre való átállást;

- fejlesztés (sor) – az információs rendszer tervezett változtatásai új funkciók bevezetésével és a működési jellemzők javításával, új információs környezetre való átállással, új technikai eszközkészletek, új információs technológiák bevezetésével, stb.

A fenti besorolásnak megfelelően bármely életciklus-modell végterméke a rendszer kötelező verziója vagy sora. A sorban állás a növekményes stratégiára jellemző. A felülvizsgálatokat és módosításokat köztes szoftvernek kell tekinteni. Mint fentebb megjegyeztük, nem kívánatos a felülvizsgálatok és módosítások gyakori terjesztése a végfelhasználók (különösen az egyéb termelési tevékenységekkel elfoglalt) felé. A vasúti közlekedés információs rendszereinek verzióváltása szerint évente legfeljebb egy-két alkalommal, átalakítást havonta legfeljebb egyszer kell végrehajtani.

3.6. A spirálmodellt támogató módszertanok

Jelenleg több szoftverfejlesztési módszertan 1 is ajánlható a spirális életciklus modell alkalmazásakor. Közülük a leghíresebb a gyors alkalmazásfejlesztés (RAD) és az extrém programozás (eXtreme Programming, XP – szerző Kent Beck, 1999) módszertana.

3. Adjon rövid leírást a módszertanokról és.

2. előadás.

Az életciklus és az életciklus-modell fogalma. Az életciklus kaszkádmodellje. Lépésenkénti modell köztes vezérléssel. Spirál modellJ C. FolyamatokJ CÁLTAL. Rapid Application Development (RAD). Extrém programozás (XP). Rational Unified Process (RUP). Microsoft Solution Framework (MSF). Egyéni fejlesztési módszer (módszertanJóslat).

2.1. Az életciklus és az életciklus-modell fogalma

IS életciklus – az az időtartam, amely attól a pillanattól kezdődik, amikor döntés születik az IP létrehozásának szükségességéről, és azzal a pillanattal ér véget, amikor teljesen kivonják a használatból. Az információs rendszer életciklusa olyan események sorozataként ábrázolható, amelyek a rendszerrel annak létrehozása és használata során következnek be.

Az életciklus-modellt úgy értjük olyan struktúra, amely meghatározza a szoftvertermék fejlesztése, üzemeltetése és karbantartása során végrehajtott folyamatok, műveletek és feladatok végrehajtási sorrendjét és kapcsolatait a rendszer teljes élettartama alatt, a követelmények meghatározásától a használat végéig. (2. dia) .

A szoftver életciklus-modellje tartalmazza (3. dia) : szakaszok, munkaeredmények az egyes szakaszokban, kulcsfontosságú események - a munka és a döntéshozatal befejezési pontjai.

Alatt színpad A szoftverkészítési folyamat részeként értendő, amely egy bizonyos időkeretre korlátozódik, és egy adott termék (modellek, szoftverkomponensek, dokumentáció) kiadásával végződik, amelyet az erre a szakaszra meghatározott követelmények határoznak meg.

Az életciklus-modell szélsőséges esetének tekinthető az úgynevezett „fekete doboz” vagy „kód és javítás” modell, ami tulajdonképpen a modell hiányát jelenti. Ebben az esetben a szoftverfejlesztési folyamat racionális szakaszait nem lehet azonosítani, mivel nincs tervezés és munkaszervezés.

Jelenleg a következő életciklus-modellek ismertek és használatosak:

Kaszkád modell(jellemző az 1970-1980 közötti időszakra);

Lépésenkénti modell köztes vezérléssel(jellemző az 1980-1985 közötti időszakra);

Spirál modell(jellemző az 1986 utáni időszakra)

2.2. Kaszkád életciklus modell

1970-ben Winston Royce szoftverszakértő közzétett egy széles körben elismert cikket, amelyben kifejtette nézeteit a később vízesés-modellként ismertté vált technikáról. (4. dia) .

Ezt követően ezt a modellt számos szabályozási dokumentum szabályozta, különösen az Egyesült Államok Védelmi Minisztériumának jól ismert Dod-STD-2167A szabványa és a GOST 34 sorozat orosz szabványai.

Kaszkád modellelőírja a projekt minden szakaszának egymás utáni végrehajtását szigorúan rögzített sorrendben. A következő szakaszra való áttérés az előző szakaszban végzett munka teljes befejezését jelenti.

Az úgynevezett „tiszta” kaszkádmodell alapvető tulajdonságai a következők:

A rendszer követelményeinek rögzítése a vevőhöz való eljuttatás előtt;

A szakaszok egymás utáni végrehajtása.

A projekt következő szakaszára csak akkor lehet áttérni, ha az aktuális szakaszban lévő munka teljesen befejeződött, anélkül, hogy visszatérne a befejezett szakaszokhoz.

Nincs átmeneti átfedés a szakaszok között

Nincs visszatérés az előző szakaszokhoz

Az eredmények csak a fejlesztés végén érhetők el.

A kaszkádmodell használatának előnyei a következők:

minden szakaszban teljes tervdokumentációt állítanak elő, amely megfelel a teljesség és a következetesség kritériumainak;

a logikai sorrendben végrehajtott munkaszakaszok lehetővé teszik az összes munka befejezésének ütemezését és a kapcsolódó költségeket.

Ennek a megközelítésnek az a fő hátránya, hogy a rendszer létrehozásának folyamata soha nem illeszkedik teljesen egy ilyen merev sémába, mindig vissza kell térni a korábbi szakaszokhoz, és tisztázni vagy felülvizsgálni a korábban meghozott döntéseket.

A vízesés megközelítés további hátrányai:

a problémák késői felismerése. A hibák azonosítása és kiküszöbölése csak a tesztelési szakaszban történik, amely hosszú ideig tarthat, vagy soha nem fejeződik be.

a naptári ütemterv elhagyása, az eredmények megszerzésének késése;

túlzott mennyiségű dokumentáció;

képtelenség a rendszert részekre bontani (a teljes terméket egyszerre fejlesztik);

nagy a kockázata egy olyan rendszer létrehozásának, amely nem felel meg a felhasználók változó igényeinek.

Történelmileg ez az első IS életciklus-modell. Meglehetősen egyszerű információs rendszerekre használták, amikor minden alkalmazás egyetlen, funkcionálisan és információsan független blokk volt. Most a vízesés modell segítségével olyan szoftvereket lehet készíteni, amelyekre a fejlesztés legelején minden követelmény elég pontosan és maradéktalanul megfogalmazható annak érdekében, hogy a fejlesztők szabadságot kapjanak a technikailag a lehető legjobban megvalósítani.

A szoftveripar rohamos ütemben fejlődik, de nem titok, hogy a fejlesztési folyamat még mindig nagyon távol áll a tökéletestől, és számos belső probléma jellemzi. A Standish Group (www.standishgroup.com) tanulmánya szerint a szoftverprojektek kevesebb mint egyharmada sikeres, a többi vagy nem fér bele a pénzügyi és időkeretbe, vagy teljes kudarccal végződik.

Egyedül dolgozó hős
programozó egy anakronizmus.
Edward Yordon

A fent említett tanulmány szerint a kis projektek a legsikeresebbek, és minél nagyobb a projekt, annál nagyobb a kudarc kockázata. Ez azt jelzi, hogy a feladat mértékének növekedésével a vezetők nem tudják kezelni a kiosztott erőforrásokat.

Valójában a szervezet méretének növekedésétől függő irányítási komplexitás növelésének problémája korántsem új keletű, azonban a programozásban ez új formákat ölt: ha nincs elegendő erőforrás a projekt időben történő megvalósításához, akkor egyszerűen növelni kell azokat. csak súlyosbítja a problémát, és még tovább tolódik a határidő (elsõsorban humán erõforrásról beszélünk, hiszen a többi sokkal kevésbé jelentõs a programozásban).

Ezt először Frederick Brooks A mitikus ember-hold című könyvének 1975-ös megjelenése után vitatták meg komolyan, amely később klasszikussá vált. Jellemző, hogy évek óta újra kiadják, főbb rendelkezései továbbra is érvényben maradnak. Későbbi munkájában Brooks a szoftverfejlesztés összetettségének két összetevőjét azonosította: a szoftverkészítés sajátosságaiban rejlő nehézségeket és a véletlenszerűeket - ebben az összefüggésben azokat, amelyek a tudomány és a technológia fejlettségi szintjének korlátaihoz kapcsolódnak. Ez utóbbiak többé-kevésbé sikeresen leküzdhetők a tudományos és technológiai fejlődés útján, de az előbbi mindig végigkíséri a szoftverfejlesztést.

Bármely folyamat hatékony menedzselése lehetséges, feltéve, hogy a vezérlő alany megfelelően érzékeli a vezérlőobjektum állapotát és viselkedését. Ami a szoftverkészítést illeti, ez nagyon nehéz feladat, hiszen a fejlesztési folyamat pusztán intellektuális, nagyrészt kreatív tevékenység, amelyre pipeline vagy más hasonló módszerek nem alkalmazhatók. Ezért aktív kísérletek történtek a szoftverkészítés folyamatának olyan modelljének bemutatására, amely a benne rejlő jellemzőket maximálisan figyelembe tudja venni és kezelhetővé teszi.

Mérnöki megközelítésen alapuló modellek

Kódolás-hibaelhárítási modell. Ennek leírása a következő: 1) állíts fel egy feladatot; 2) a sikeres teljesítésig vagy törlésig végrehajtani; 3) ellenőrizze az eredményt; 4) szükség esetén ismételje meg az 1. lépéstől.

Természetesen egy ilyen modell semmilyen módon nem strukturálta a fejlesztési folyamatot, és értelmetlen a hatékony felhasználásának lehetőségéről beszélni, különösen nagy projekteknél.

Kaszkád modell. Az első modell, amely széles körben ismertté vált és valóban felépítette a fejlesztési folyamatot, a kaszkád vagy vízesés. Az 1968-as NATO Tudományos és Technológiai Konferenciát követően hozták létre, ahol hasonló kérdéseket tárgyaltak, és a szoftvertermék létrehozásának folyamatát egymást követő szakaszokra bontja (meg kell jegyezni, hogy már akkoriban is használták különböző fejlesztők, de a szakaszok száma és tartalma nem egységes).

Nem sokkal születése után a kaszkádmodellt Winst Royce módosította, figyelembe véve a szakaszok egymásra utaltságát és a korábbi szakaszokhoz való visszatérés szükségességét, amit például hiányos követelmények vagy a formálási hibák okozhatnak. a feladat. Ebben a „visszafordítható” formában a kaszkádmodell sokáig létezett, és számos projekt alapja volt (1. ábra).

Ennek a modellnek a gyakorlati felhasználása azonban feltárta számos hiányosságát, amelyek közül a legfontosabb az volt, hogy jobban alkalmas hagyományos típusú mérnöki tevékenységekre, mint szoftverfejlesztésre. Konkrétan az egyik legnagyobb problémának az a „hajlam” bizonyult, hogy az eredményül kapott termék és a vele szemben támasztott követelmények között esetleges ellentmondások vannak. Ennek fő oka, hogy egy teljesen megformált termék csak a fejlesztés későbbi szakaszaiban jelenik meg, de mivel a különböző szakaszokban végzett munkát általában különböző szakemberek végezték, és a projektet egyik csoportból a másikba vitték át, így az elv szerint egy törött telefonról kiderült, hogy a kimenet nem egészen az eredetileg vártnak felel meg.

V alakú modell. Pontosan a kaszkádmodell hiányosságainak kiküszöbölésére javasolták, és a V-alakú, vagy csuklós elnevezés sajátos grafikus ábrázolása miatt jelent meg (2. ábra).

A V-alakú modell lehetővé tette a szoftver minőségének jelentős javítását a tesztelésre való összpontosítása miatt, és nagymértékben megoldotta azt a problémát is, hogy a létrehozott termék megfeleljen a felállított követelményeknek, köszönhetően az ellenőrzési és tanúsítási eljárások korai szakaszában. fejlesztés (az ábrán a szaggatott vonalak a tervezési/problémafeltárási szakaszok és a tesztelés/elfogadás függőségét jelzik).

Általában azonban a V alakú modell csak a kaszkádmodell módosítása, és számos hátránya van. Különösen, mindkettő rosszul alkalmazkodik a vevői igények esetleges változásaihoz. Ha a fejlesztési folyamat hosszadalmas (esetenként akár több évig is), akkor az így létrejövő termék valóban szükségtelen lehet a vásárló számára, hiszen az igényei jelentősen megváltoztak.

A tudományos és technológiai haladás befolyásának kérdése ugyanilyen aktuális: a szoftverekkel szemben támasztott követelményeket a hardver és a szoftver területén elért tudományos és gyakorlati eredmények jelenlegi állását figyelembe véve fogalmazzák meg, de az IT szektor nagyon gyorsan fejlődik, és Az elhúzódó fejlesztési folyamat egy olyan termék megalkotásához vezethet, amely elavult technológiákon alapul, és már megjelenése előtt versenyképtelennek bizonyul.

A várható funkcionalitás tervezési mutatóinak kérdése is fontos, hiszen ezekben a modellekben ez nem más, mint feltételezés: konkrétan szinte lehetetlen meghatározni, hogy a létrehozott termék milyen adatfeldolgozási sebességet biztosít, vagy mennyi memóriát foglal el a probléma felállításának szakasza. Ha a megrendelő és a kivitelező közötti szerződés feltételeiben egyértelműen szerepelnek ilyen követelmények, akkor valószínű, hogy az így létrejövő megoldás nem fogja őket kielégíteni, bár ez csak a fejlesztés végső szakaszában válik ismertté, amikor a fő erőforrások rendelkezésre állnak. már elköltötték.

Ennek eredményeként az ügyfél kénytelen lesz beletörődni a megfontolt modellek alapján megalkotott megoldás korlátaiba, vagy többletforrást fektetni azért, hogy valóban megkapja, amire szüksége van.

A szoftverfejlesztés sajátosságait figyelembe vevő modellek

Mivel az első modelleket a hagyományos mérnöki területről kölcsönözték, nem vették teljes mértékben figyelembe a szoftvergyártás sajátosságait. A későbbi modellek azonban sokkal inkább ennek a tevékenységtípusnak a sajátosságaira összpontosítottak, amely számos alapvető különbséggel rendelkezik az anyagi világ tárgyainak felépítésétől.

Prototípus alapú modell. Tekintettel arra, hogy az ügyfél gyakran nem szoftverspecialista, általában nem érzékeli jól a „csupasz” termékleírásokat. Az ügyfél és a fejlesztő közötti információs akadály leküzdése, valamint a követelményeknek nem megfelelő termék megszerzésének kockázatának csökkentése érdekében elkezdték alkalmazni a prototípusok létrehozását célzó megközelítést, amelyek a kész rendszer teljesen vagy részben működő modelljei. . Lehetővé teszi a folyamat valamennyi résztvevője közötti kölcsönös megértés jelentős javítását a prototípusok iteratív finomításán alapuló rendszer következetes, evolúciós fejlesztésének köszönhetően.

Utóbbiak alkalmazása hasonló az építészetben a redukált épületmodellek használatához - lehetővé teszik a végeredmény megjelenítését, építésük és módosításuk sokkal kevésbé munkaigényes, mint magának az épületnek az építése és módosítása.

Azonban annak ellenére, hogy nem minden előnye van, ez a modell sem lett csodaszer. Legfőbb problémái a „megrendelő-végrehajtó” kapcsolat síkjában rejlenek: az első a lehető legrészletesebb prototípusok létrehozásában volt érdekelt, hogy csökkentse a nem megfelelő rendszer fogadásának kockázatát, míg a második számára minden új prototípus többletköltséget jelentett. időt és erőforrásokat, és ennek eredményeként - a projekt jövedelmezőségének csökkenése.

Növekményes modell. A szoftver, ellentétben például a mikroáramkörökkel, részben üzembe helyezhető, ami azt jelenti, hogy az is fejleszthető és fokozatosan eljuttatható a megrendelőhöz. Pontosan erre épül az inkrementális modell, amely magában foglalja a termék viszonylag független komponensekre történő feldarabolását, amelyeket külön fejlesztenek és helyeznek üzembe.

Ez a modell mind az ügyfél, mind a rendszeralkotó számára előnyös, mivel lehetővé teszi, hogy mindkét fél érdekeit tiszteletben tartva haladjon előre. Ennek azonban megvannak a maga hátrányai. A funkcionális blokkokra osztás általában lelassítja a folyamatot, mivel szükségessé válik ezek interakciójának biztosítása. Sok megoldásnál ez a módszer nem alkalmazható, mivel nem lehet elkülöníteni belőlük az egyes alkatrészeket, amelyek önállóan szállíthatók és működnek. Jelentősen megnövekszik a vezetők leterheltsége is a rendszer egyes összetevőivel kapcsolatos koordinációs feladatok bonyolultsága miatt, valamint megnő a már telepített és az ügyféllel együttműködő kész komponensek módosításának költsége.

Spirál modell. Barry Boehm 1988-ban javasolta, és jelentős áttörést jelentett a szoftverfejlesztés természetének megértésében, bár nagyjából két modell kombinációja: a vízesés és a prototípuskészítés (3. ábra).

Spirál modell A Boema a tervezésre összpontosít. Maga a szoftverfejlesztés a szokásos kaszkádmodell szerint csak a spirál utolsó fordulatánál történik, ezt azonban számos, prototípusok létrehozásán alapuló tervezési iteráció előzi meg - minden iteráció magában foglalja a kockázatok azonosításának és elemzésének szakaszát, valamint a legbonyolultabb feladatokat.

Mivel a spirálmodell elsősorban a tervezést fedi le, eredeti formájában nem terjedt el a szoftverkészítés teljes életciklusának menedzselésére szolgáló módszerként. Fő gondolata azonban, hogy egy projekten való munkafolyamat ugyanazon szakaszokon átmenő ciklusokból állhat, további kutatások kiindulópontjaként szolgált, és a szoftverfejlesztési folyamat legtöbb modern modelljének alapja lett.

Modern modellek

Az 1990-es évek közepére a szoftveripar kiforrott, a komplex projektek sikeresen valósultak meg az egyre népszerűbb objektum-orientált módszertannal, és a fejlesztőcsapatok olyan megközelítéseket alkalmaztak, amelyek a korábbi modellek legjelentősebb előnyeit kamatoztatták.

Objektum-orientált modell. Ez a módszertan magában foglalja egy szoftvermegoldás felépítését kész objektumokból, amelyekre meghatározzák interakciójuk szabályait, átvive az objektumokat egyik állapotból a másikba. Ez a modell, amely biztosítja, hogy a fejlesztési folyamat teljes mértékben megfeleljen az objektum-orientált módszertan (objektum-orientált elemzés, tervezés, programozás) előírásainak, hatékonyan alkalmazható nagy projektekben, valamint ahol ún. rapid development tools (RAD, Rapid Application Development) ezeken a technológiákon alapuló és kész osztálykönyvtárakat tartalmaznak.

Maguk a RAD-rendszerek azonban nem ösztönzik az objektum-orientált megoldások létrehozását. A programozók, akiket elkényeztetnek azokkal az eszközökkel, amelyek lehetővé teszik számukra, hogy néhány óra alatt termékeket hozzanak létre kész összetevőkből, amelyek korábban napok és hónapokig tartó munkát igényeltek, feleslegesnek tartják magukat a módszertan és az UML részletes tanulmányozásával, és még inkább megteszik. ne törekedjenek arra, hogy megoldásaikat újrafelhasználásra alkalmas osztályok formájában formalizálják.

Így az objektum-orientált modellt elsősorban nagyon nagy projektekben használják, ahol kellő figyelmet fordítanak az elemzési és tervezési szakaszokra, és ahol a fejlesztőket szigorúan ellenőrzik, hogy betartsák-e a megállapított szabályokat.

Iteratív modell. Ez a modell, amelyet először Philippe Kratchen javasolt 1995-ben, a spirális, növekményes, vízesés, prototípus és objektum-orientált fejlesztési módszerek fő előnyeit egyesíti (4. ábra). Nagy népszerűségre tett szert, és ilyen vagy olyan formában számos modern projektben használják.

Az iteratív modell szerint a szoftverfejlesztés életciklusának négy fő fázisa van (kezdeményezés, feltárás, építés és megvalósítás). Minden fázisban a projekt számos iteráción megy keresztül, ami működőképes verziók létrehozásához vezet: a kezdeti szakaszban prototípusokat készítenek, tisztázzák a követelményeket, és kidolgozzák a legbonyolultabb problémákat; a végsők egy termék létrehozásához, annak javításához és a funkcionalitás bővítéséhez vezetnek.

Az iteratív modell a fő fázisokon kívül további két folyamatcsoportot különböztet meg: működő (követelménykezelés, elemzés és tervezés, megvalósítás, tesztelés, telepítés) és segédfolyamatokat (konfiguráció és változáskezelés, projekt és folyamat). A folyamatok száma és lényege a fejlesztő igényeitől függően változik, lehetnek saját ciklusaik is, amelyek nem is feltétlenül felelnek meg a fő fázisoknak. A munkafolyamatok azonban mindig termékverziók létrehozását eredményezik.

Az iteratív modell, akárcsak a spirálmodell, lehetővé teszi a kockázatok sikeres kezelését. Ha a következő verzión való munka során megállapítást nyer, hogy a szükséges funkcionalitás megvalósításához szükséges munkaerőköltségek túl magasak, akkor a költségvetés túllépése és a határidők elmulasztása elkerülhető a fejlesztési prioritások és a munkaerőköltségek minden iteráció elején történő korrelációjával. Így ez a modell jól illeszkedik a legtöbb szoftverprojekthez, de előnyei különösen szembetűnőek a szabad piacra való belépésre szánt termékeken, mivel kezdetben a szekvenciális verziók kiadására helyezték a hangsúlyt.

Philip Kratchen hosszú ideje dolgozik a Rational Software-nél, amely ma már az IBM tulajdonában van. Ez az oka annak, hogy az iteratív modell a RUP (Rational Unified Process) alapja lett, amely az egyik legelterjedtebb módszer a szoftverfejlesztési folyamat integrált kezelésére. Ennek alapján fejlesztették ki a RUP fő versenytársát a Microsofttól, az MSF-et (Microsoft Solutions Framework), valamint egy hasonló megközelítést a Borlandtól - ALM (Application Lifecycle Management).

Gyors fejlesztési modellek. A modern szoftverfejlesztési módszerek számos korlátja oda vezetett, hogy a fejlesztő cégek sok tekintetben hasonlóvá váltak az óriási bürokratikus rendszerekhez. A nagyszámú formális eljárás és szabály jelenléte jelentősen szűkíti az egyes programozók cselekvési szabadságát, és egy hatalmas és ügyetlen gép fogaskerekévé változtatja. Annak ellenére, hogy az ilyen gépek meglehetősen sikeresen képesek megbirkózni az előttük álló feladatokkal, hatékonyságuk általában meglehetősen alacsony, és az egyes fejlesztők fajlagos termelékenysége olyan kicsi, hogy normálisnak tekinthető, ha egy programozó több soros kódot ír. naponta.

Az olyan gyorsfejlesztési modelleket, mint az extrém programozás, úgy tervezték, hogy kihívást jelentsenek az ilyen formalisztikus megközelítésekben. Lényegük abban rejlik, hogy elutasítanak mindent, ami szükségtelen, ami nem kapcsolódik közvetlenül a minőségi szoftvertermék létrehozásához, és csak a leghatékonyabb szoftverkészítési módszereket veszik alapul. Különös figyelmet fordítanak az ügyfelekkel való interakció, a produktív munka megszervezésére és a tesztelésre. A gyors fejlesztési ötletek közül sok nem új keletű volt, például az egységteszteket sok projektben már régóta alkalmazták, de összerakva és kötelezővé téve a használatot, pozitív hatást fejtettek ki. Ezekről a módszerekről az utóbbi időben egyre gyakrabban beszélnek, és elemeiket számos klasszikus modell kölcsönözte.

A modern körülmények között nagyon divatos megközelítés a gyors fejlődés, amelyet egyre aktívabban alkalmaznak. A fő előny az, hogy viszonylag kis fejlesztői csapatok képesek ugyanannyi idő alatt megvalósítani a projekteket, mint amennyire nagyságrendekkel nagyobb csapatoknak kell a hagyományosabb módszerek használatához.

Vannak azonban hátrányai is, különösen a gyors fejlesztés nem alkalmas nagy projektekre, és elsősorban a kis- és közepes méretű projektekre koncentrál, ráadásul hatékony felhasználása csak akkor lehetséges, ha a szoftverkészítők nagyon magas képzettséggel és jelentősséggel rendelkeznek tapasztalat.

Adaptált és kombinált modellek. Valójában a szoftverfejlesztési életciklus-modellek fejlődésével az új ötletek nem váltották fel teljesen a régieket. Helyesebb úgy tekinteni, hogy mindegyiknek megvan a maga alkalmazási köre. Emellett minden konkrét esetben kiderülhet, hogy nincs olyan technika, amely ideálisan alkalmas lenne egy adott probléma megoldására. Ebben az esetben a szoftverprojekt-menedzsereknek meg kell fontolniuk a modellek egyedi igényekhez való adaptálását vagy a különböző megközelítések elemeit tartalmazó kombinált módszerek alkalmazását. Például a gyors fejlődés sikere oda vezetett, hogy a konzervatívabb modellek átvették a leghatékonyabb technikáikat, és elkezdték ezeket folyamataik részeként alkalmazni.

a záródokumentumok bemutatása, a folyamat mérőszámai, a feladatok megkezdésének és befejezésének kritériumai, valamint a folyamat következő lépése; tesztelési módszerek kiválasztása a kiválasztott szoftverosztályhoz a tesztelési feladatok helyes végrehajtásának ellenőrzésére; speciális dokumentumsablonok kidolgozása a tesztelési folyamat dokumentálására a tesztelési folyamat minden egyes lépésére vonatkozóan.

Azok. azt feltételezik, hogy minden munkát olyan alaposan elvégzik, hogy miután elkészült, és a következő lépés is elkészült, nem kell visszatérni az előzőhöz.

A fejlesztő a köztes eredményt különféle jól ismert ellenőrzési módszerekkel ellenőrzi, és a következő folyamathoz kész szabványként rögzíti.

Ezen életciklus-modell szerint a fejlesztési folyamat munkája és feladatai általában szekvenciálisan, az ábrán látható módon történnek. A kisegítő és szervezési folyamatok (követelményellenőrzés, minőségirányítás stb.) azonban általában a fejlesztési folyamattal párhuzamosan zajlanak. Ebben a modellben a karbantartás és a hibajavítás után visszatér a kezdeti folyamathoz.

Ennek a modellnek az a sajátossága, hogy egy szoftvertermék fejlesztésének szekvenciális folyamatait rögzíti. Gyári modellre épül, ahol a termék a koncepciótól a gyártásig szakaszokon megy keresztül, majd késztermékként kerül a vevőhöz, melynek cseréjét nem biztosítják, bár cseréje más hasonló termékkel lehetséges. a panasz vagy annak egyes részei meghiúsultak.

Ennek a modellnek a hátrányai:

• a PS létrehozásának folyamata nem mindig illeszkedik egy ilyen merev formába és cselekvési sorrendbe;
• nem veszik figyelembe a felhasználók megváltozott igényeit, a külső környezet változásait, amelyek a rendszerrel szemben támasztott követelmények változását okozzák a fejlesztés során;
• nagy különbség van a hiba bevezetésének időpontja (például a tervezési szakaszban) és az észlelés időpontja (karbantartás közben) között, ami a szoftver jelentős átdolgozásához vezet.

A kaszkádmodell alkalmazásakor a következő kockázati tényezők fordulhatnak elő:

• a szoftverrel szemben támasztott követelmények nincsenek egyértelműen megfogalmazva, vagy nem veszik figyelembe az operációs rendszer, a környezet stb. fejlesztési kilátásait;
• egy nagy rendszer, amely nem teszi lehetővé az összetevők lebontását, problémákat okozhat a memóriába vagy a követelményekben nem szereplő platformokon való elhelyezéskor;
• A technológia és a követelmények gyors változása ronthatja a rendszer egyes részeinek vagy a rendszer egészének fejlesztési folyamatát;
• A fejlesztés során az erőforrások (humán, szoftver, műszaki stb.) korlátozása szűkítheti a rendszer megvalósításának egyéni lehetőségeit;

az így létrejövő termék használhatatlan lehet, ha a fejlesztők félreértik a rendszer követelményeit vagy funkcióit, vagy a tesztelés hiánya miatt. A rendszer kaszkádmodell segítségével történő megvalósításának előnyei a következők:

• az alrendszerek és a rendszer összes feladata egyszerre valósul meg (azaz egyetlen feladat sem feledkezik meg), és ez hozzájárul a köztük lévő stabil kapcsolatok és kapcsolatok kialakításához;
• egy teljesen kidolgozott, dokumentációval ellátott rendszer könnyebben karbantartható, tesztelhető, hibajavítást és változtatásokat hajthat végre nem véletlenszerűen, hanem célirányosan, kezdve a követelményekkel (például egyes funkciók hozzáadásával, cseréjével) és a folyamat megismétlésével.

A kaszkádmodell életciklus-modellnek tekinthető, amely alkalmas a szoftver első verziójának elkészítésére, a benne megvalósított funkciók tesztelésére. A karbantartás és az üzemeltetés során különféle típusú hibák fedezhetők fel, amelyek kijavítása minden folyamat megismétlését igényli, kezdve a követelmények tisztázásával.

2.2.2. Inkrementális életciklus modell

A rendszer első köztes verziója (1. kiadás) megvalósítja a követelmények egy részét, a következő verzióhoz (2. kiadás) további követelmények kerülnek hozzáadásra, és így tovább, amíg az összes követelmény teljesül, és a rendszerfejlesztési problémák meg nem oldódnak. Minden közbenső verziónál az életciklus szakaszaiban elvégzik a szükséges folyamatokat, munkákat és feladatokat, beleértve a követelmények elemzését és egy új architektúra létrehozását, amely egyidejűleg is elvégezhető.

A PS műszaki tervezésének kidolgozásának folyamatai, programozása és tesztelése, a PS összeszerelése és minősítési tesztjei minden további verzió elkészítése során kerülnek végrehajtásra.

Ennek az életciklus-modellnek megfelelően, amelynek folyamatai szinte megegyeznek a vízesés modellben leírtakkal, a középpontban valamilyen teljes köztes változat kidolgozása áll, és a fejlesztési folyamat feladatai egymás után vagy részben párhuzamosan valósulnak meg egy az egyes köztes verziójú szerkezetek száma.

A további követelményeket vagy funkciókat tartalmazó rendszer következő verziójának fejlesztési folyamatának munkái és feladatai a rendszer összes köztes verziója esetén ismételten, azonos sorrendben végrehajthatók. A karbantartási és üzemeltetési folyamatok a verziófejlesztési folyamattal párhuzamosan is megvalósíthatók úgy, hogy minden közbenső verzióban ellenőrizzük a részben megvalósított követelményeket, és így tovább, amíg a rendszer teljes verzióját meg nem szerzik. A támogató és szervezeti életciklus folyamatok általában egy rendszerváltozat fejlesztési folyamatával párhuzamosan zajlanak, és a fejlesztés végére olyan adatok gyűjtése történik meg, amelyek alapján megállapítható a legyártott rendszer teljességi szintje és minősége.

A modell alkalmazása során a következő kockázati tényezőket kell figyelembe venni:

• a követelményeket a termék értékesítése során bekövetkező változás lehetőségének figyelembevételével állítják össze;
• a rendszer minden képességét a kezdetektől fogva implementálni kell;
• a technológia és a rendszerkövetelmények gyors változásai az így létrejövő rendszerstruktúra megzavarásához vezethetnek;
• Az erőforrás-ellátás korlátai (teljesítők, pénzügyek) késleltethetik a rendszer üzembe helyezését.

Ezt az életciklus-modellt olyan esetekben célszerű használni, amikor:

• kívánatos néhány rendszerképességet gyorsan megvalósítani a termék köztes verziójának elkészítésével;
• a rendszer különálló komponensekre bomlik, amelyek független közbenső vagy késztermékként értékesíthetők;
• lehetőség van a rendszer egyes részeinek fejlesztésére fordított finanszírozás növelésére.

szoftver életciklus modellek, amelyeket nehéz használni egy konkrét projekt megszervezésekor.

Konkrétan belül életciklus modellek, amelyek egy adott iparágon vagy szervezeten belül írják elő a szoftverfejlesztés megszervezésének szabályait, pontosabban fejlesztési folyamatok. Eltérnek a szabványoktól, mindenekelőtt részletesebben és az egyének közötti kapcsolatok világos leírásában tevékenységek típusai, adatfolyamok (dokumentumok és műtermékek) meghatározása során életciklus. Elég sok ilyen modell létezik, mert valójában minden alkalommal, amikor egy szervezet meghatározza a sajátját fejlesztési folyamat, ennek a folyamatnak az alapjaként néhány szoftver életciklus modellje. Ebben az előadásban csak néhány modellt vizsgálunk meg. Sajnos nagyon nehéz olyan kritériumokat kiválasztani, amelyek alapján az ismertek bármilyen hasznos osztályozását meg lehetne adni életciklus modellek.

A legszélesebb körben ismert és sokáig használt maradt az úgynevezett kaszkád ill vízesés életciklus modell, amely vélhetően először fogalmazódott meg egyértelműen a műben, majd a XX. század 70-80-as éveiben ragadt meg az Egyesült Államok Védelmi Minisztériumának szabványaiban. Ez a modell magában foglalja a különböző szekvenciális végrehajtását tevékenységek típusai, kezdve a követelményfejlesztéstől a karbantartásig, világosan meghatározva a szakaszok közötti határokat, amelyeknél az előző szakaszban készített dokumentumok halmaza inputként kerül át a következőbe. Szóval mindenki Egyfajta tevékenység egy fázisban hajtják végre életciklus. A cikkben javasolt fejlesztési lépések sorrendje az ábrán látható. 2.2. "Klasszikus" kaszkád modell csak e séma szerint halad előre: mindent, ami a következő tevékenység elvégzéséhez szükséges, az előző munka során elő kell készíteni.

Ha azonban figyelmesen elolvassa a cikket, kiderül, hogy nem ennek a konkrét munkarendnek a követését írja elő, hanem egy iteratív folyamat modelljét mutatja be (lásd 2.3. ábra) - szekvenciális formájában ez a modell láthatóan rögzített volt. a minisztériumok tisztviselőinek és az ezekkel a minisztériumokkal szerződés alapján dolgozó cégek vezetőinek fejében. Ha ténylegesen olyan modell szerint dolgozunk, amely csak egy irányba enged mozgást, akkor a problémák általában akkor merülnek fel, ha a korai szakaszban elkövetett hibákat, hibákat fedezik fel. De még nehezebb kezelni a szoftver fejlesztésének környezetében bekövetkezett változásokat (ez lehet a követelmények változása, a vállalkozók változása, a fejlesztő vagy üzemeltető szervezet politikájának változása, az iparági szabványok változása, a versenytársak megjelenése termékek stb.).

Ezzel a modellel csak akkor lehet dolgozni, ha előre meg lehet látni a projekt előrehaladásának lehetséges viszontagságait, és az első szakaszokban gondosan összegyűjtjük és integráljuk az információkat, hogy az eredményeket később az esetleges változásoktól függetlenül felhasználhassuk. .

A komplex szoftverek fejlesztésével foglalkozó fejlesztők és kutatók körében szinte a szoftvergyártó ipar kezdeteitől fogva (lásd pl.) nagy népszerűségnek örvendenek az evolúciós vagy iteratív folyamatok modelljei, amelyek nagyobb rugalmassággal és munkaképességgel rendelkeznek. változó környezetben.

Ismétlődő vagy inkrementális modellek(több ilyen modell is ismert) az elkészített rendszer darabokra bontását jelenti, amelyeket a munka egészének vagy egy részének többszöri egymás utáni áthaladásával fejlesztenek ki.

Az első iterációnál a rendszer egy olyan darabját fejlesztik ki, amely független a többitől. Ebben az esetben a munka nagy része, vagy akár a teljes ciklusa elkészül rajta, majd kiértékelik az eredményeket és a következő iterációnál vagy az első darabot újratervezik, vagy a következőt fejlesztik, ami az elsőtől függhet, ill. az első darab revíziója valahogyan ötvöződik új funkciók hozzáadásával. Ennek eredményeként minden iterációnál lehetőség nyílik a munka közbenső eredményeinek elemzésére, valamint az összes érintett, köztük a felhasználók reakcióira, és a következő iterációknál korrekciós változtatásokra. Minden iteráció tartalmazhat egy teljes halmazt tevékenységek típusai- a követelmények elemzésétől a következő szoftver üzembe helyezéséig.

Kaszkád modell lehetőség van visszatérni az előző lépéshez, ha szükséges felülvizsgálni annak eredményeit, iteratívvá válik.

Az iteratív folyamat feltételezi, hogy más tevékenységek nem kötődnek szorosan a fejlődés bizonyos szakaszaihoz, hanem szükség szerint hajtják végre, néha megismétlik, amíg a kívánt eredményt el nem érik.

A rugalmassággal és a változásokra való gyors reagálás képességével együtt iteratív modellek további bonyolultságot hoz projektmenedzsmentés nyomon követi annak előrehaladását. Az iteratív megközelítés alkalmazásakor sokkal nehezebbé válik a projekt jelenlegi állapotának megfelelő felmérése és a hosszú távú fejlesztések tervezése, valamint az eredmény bizonyos minőségének biztosításához szükséges időzítés és erőforrások előrejelzése.

Az iterációk gondolatának kiterjesztése az