Mit tartalmaz a szoftver életciklusa. A szoftver életciklusa

A meghatározásával kell kezdenünkA szoftver életciklusa(Szoftver életciklus-modell) egy olyan időtartam, amely attól a pillanattól kezdődik, amikor döntés születik egy szoftvertermék létrehozásáról, és azzal a pillanattal ér véget, amikor azt teljesen kivonják a forgalomból. Ez a ciklus a szoftver felépítésének és fejlesztésének folyamata.

Szoftver életciklus modellek

Az életciklus modellek formájában ábrázolható. Jelenleg a leggyakoribbak:lépcsőzetes, járulékos (színpadi modell köztes vezérléssel ) és spiráléletciklus modellek.

Kaszkád modell

Kaszkád modell(eng. vízesés modell) a szoftverfejlesztési folyamat modellje, amelynek életciklusa úgy néz ki, mint egy folyamat, amely szekvenciálisan halad át a követelményelemzés, tervezés fázisain. megvalósítás, tesztelés, integráció és támogatás.

A fejlesztési folyamat végrehajtása független lépések rendezett sorozatával történik. A modell úgy rendelkezik, hogy minden további lépés az előző lépés befejezése után kezdődik. A modell minden lépésében kisegítő és szervezési folyamatokat és munkákat hajtanak végre, beleértve a projektmenedzsmentet, az értékelést és a minőségirányítást, az ellenőrzést és tanúsítást, a konfigurációkezelést és a dokumentációfejlesztést. A lépések befejezése eredményeként olyan köztes termékek keletkeznek, amelyek a következő lépésekben nem változtathatók.

Az életciklus hagyományosan a következő főbb részekre oszlikszakasz:

1. Követelményelemzés,
2. Tervezés,
3. Kódolás (programozás),
4. Tesztelés és hibakeresés,
5. Üzemeltetés és karbantartás.

A modell előnyei:

• a követelmények stabilitása a fejlesztési életciklus során;
• minden szakaszban egy teljes projektdokumentációt alakítanak ki, amely megfelel a teljesség és a következetesség kritériumainak;
• a modell lépéseinek bizonyossága és érthetősége, valamint alkalmazásának egyszerűsége;
• a logikai sorrendben végzett munka szakaszai lehetővé teszik az összes munka befejezésének ütemezését és a megfelelő erőforrásokat (pénzbeli, anyagi és emberi).

A modell hátrányai:

• a követelmények egyértelműen megfogalmazásának bonyolultsága és dinamikus változásának lehetetlensége a teljes életciklus során;
• alacsony rugalmasság a projektmenedzsmentben;
• a fejlesztési folyamat lineáris szerkezetének sorrendje, ennek eredményeként a felmerülő problémák megoldásának korábbi lépéseihez való visszatérés a költségek növekedéséhez és a munkaterv megzavarásához vezet;
• a köztes termék alkalmatlansága a használatra;
• egyedi rendszerek rugalmas modellezésének lehetetlensége;
• az építéssel kapcsolatos problémák késői észlelése az összes eredmény egyidejű integrálása miatt a fejlesztés végén;
• nem megfelelő felhasználói részvétel a rendszer létrehozásában - a legelején (a követelmények kialakítása során) és a végén (az átvételi tesztek során);
• a felhasználók a teljes fejlesztési folyamat végéig nem győződhetnek meg a kifejlesztett termék minőségéről. Nincs lehetőségük a minőség értékelésére, mert nem látják a fejlesztés késztermékét;
• a felhasználónak nincs lehetősége fokozatosan hozzászokni a rendszerhez. A tanulási folyamat az életciklus végén történik, amikor a szoftvert már üzembe helyezték;
• minden fázis előfeltétele a következő műveletek végrehajtásának, ami kockázatos választássá teszi ezt a módszert olyan rendszerek számára, amelyeknek nincs analógja, mert. nem alkalmas a rugalmas modellezésre.

A vízesés életciklus-modelljét nehéz megvalósítani a PS fejlesztésének összetettsége miatt anélkül, hogy visszatérnénk a korábbi lépésekhez, és nem változtatnánk az eredményeket a felmerülő problémák kiküszöbölése érdekében.

A kaszkádmodell hatóköre

A kaszkádmodell hatókörének korlátozását annak hiányosságai határozzák meg. Használata a következő esetekben a leghatékonyabb:

1. projektek kidolgozásakor világos, megváltoztathatatlanéletciklus a megvalósítás és a technikai módszertan által érthető követelmények;
2. olyan projekt kidolgozásakor, amely a fejlesztők által korábban kifejlesztett rendszer vagy termék felépítésére összpontosít;
3. egy meglévő termék vagy rendszer új verziójának létrehozásához és kiadásához kapcsolódó projekt kidolgozásakor;
4. egy meglévő termék vagy rendszer új platformra történő átviteléhez kapcsolódó projekt kidolgozásakor;
5. több nagy fejlesztőcsapatot érintő nagy projektek végrehajtása során.

inkrementális modell

(színpados modell köztes vezérléssel)

inkrementális modell(eng. növekedés- növelés, növekmény) lineáris lépéssorral, de több lépésben (verzióban) történő szoftver fejlesztését jelenti, pl. tervezett termékfejlesztésekkel mindaddig, amíg a szoftverfejlesztési életciklus véget ér.

A szoftverfejlesztés a szakaszok közötti visszacsatolási hurkokkal végzett iterációkban történik. A szakaszok közötti kiigazítások lehetővé teszik a fejlesztési eredmények tényleges kölcsönös hatásának figyelembevételét a különböző szakaszokban, az egyes szakaszok élettartama a teljes fejlesztési időszakra meghosszabbodik.

A projekten végzett munka elején meghatározzák a rendszerre vonatkozó összes alapvető követelményt, több és kevésbé fontos követelményre osztva. Ezt követően inkrementálisan történik a rendszer fejlesztése, hogy a fejlesztő a szoftver fejlesztése során megszerzett adatokat felhasználhassa. Minden lépésnek hozzá kell adnia bizonyos funkciókat a rendszerhez. Ebben az esetben a kiadás a legmagasabb prioritású összetevőkkel kezdődik. Amikor a rendszer részei meg vannak határozva, vegyük az első részt, és kezdjük el részletezni az ehhez legmegfelelőbb eljárással. Ugyanakkor lehetőség van a jelen munka jelenlegi követelményrendszerében befagyasztott egyéb alkatrészekre vonatkozó követelmények finomítására. Ha szükséges, később visszatérhet ehhez a részhez. Ha az alkatrész készen van, akkor azt a megrendelőhöz szállítják, aki felhasználhatja munkájában. Ez lehetővé teszi az ügyfél számára, hogy tisztázza a következő összetevőkre vonatkozó követelményeket. Aztán kidolgozzák a rendszer következő részét. Ennek a folyamatnak a legfontosabb lépései a szoftverkövetelmények egy részhalmazának egyszerű megvalósítása és a modell finomítása egy sor egymást követő kiadáson keresztül, amíg a szoftver teljesen implementálásra nem kerül.

Ennek a modellnek az életciklusa olyan összetett és összetett rendszerek fejlesztésére jellemző, amelyeknél világos elképzelés van (mind a megrendelő, mind a fejlesztő részéről), hogy mi legyen a végeredmény. A verziófejlesztés különböző okokból történik:

• az ügyfél nem tudja azonnal finanszírozni a teljes költséges projektet;
• a szükséges erőforrások hiánya ahhoz, hogy a fejlesztő egy komplex projektet rövid időn belül megvalósítson;
• a termék végfelhasználók általi szakaszos bevezetésére és fejlesztésére vonatkozó követelmények. A teljes rendszer egyidejű bevezetése elutasítást válthat ki 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, egyszerűen „nem tudnak megemészteni egy nagy darabot, ezért össze kell törni és részletekben kell adni”.

Előnyökés korlátozásokennek a modellnek (stratégiának) megegyezik a kaszkádéval (klasszikus életciklus-modell). De a klasszikus stratégiával ellentétben az ügyfél korábban láthatja az eredményeket. Az első verzió fejlesztésének és megvalósításának eredményei alapján kismértékben módosíthatja a fejlesztés követelményeit, lemondhat arról, vagy új szerződés megkötésével egy fejlettebb termék fejlesztését ajánlhatja fel.

Előnyök:

• csökkennek a változó felhasználói igények miatt felmerülő költségek, a vízesés modellhez képest jelentősen csökken az újraelemzés és a dokumentációgyűjtés;
• könnyebb visszajelzést kapni az ügyféltől az elvégzett munkáról - az ügyfelek elmondhatják észrevételeiket az elkészült alkatrészekről, és láthatják, hogy mi történt már. Mert a rendszer első részei a rendszer egészének prototípusai.
• az ügyfél képes gyorsan megszerezni és elsajátítani a szoftvert – az ügyfelek hamarabb juthatnak valódi hasznokhoz a rendszerből, mint a vízesés modellel.

A modell hátrányai:

• a vezetőknek folyamatosan mérniük kell a folyamat előrehaladását. gyors fejlődés esetén nem érdemes minden minimális verzióváltáshoz dokumentumokat készíteni;
• a rendszer szerkezete romlik, ha új komponenseket adnak hozzá - az állandó változtatások megzavarják a rendszer szerkezetét. Ennek elkerülése érdekében további időre és pénzre van szükség a refaktoráláshoz. A rossz struktúra megnehezíti és költségessé teszi a szoftver későbbi módosítását. A megszakított szoftver életciklus pedig még nagyobb veszteségekhez vezet.

A rendszer nem teszi lehetővé a felmerülő változások azonnali figyelembevételét és a szoftverkövetelmények pontosítását. A fejlesztési eredmények egyeztetése a felhasználókkal csak az egyes munkaszakaszok befejezése után tervezett pontokon történik, és a szoftverrel szemben támasztott általános követelményeket technikai feladat formájában rögzítik a létrehozásuk teljes idejére. Így a felhasználók gyakran olyan szoftvereket kapnak, amelyek nem felelnek meg valós igényeiknek.

spirál modell

Spirál modell:Életciklus - a spirál minden fordulatánál létrejön a termék következő verziója, meghatározzák a projekt követelményeit, meghatározzák a minőségét, és megtervezik a következő fordulat munkáját. Különös figyelmet fordítanak a fejlesztés kezdeti szakaszaira - elemzésre és tervezésre, ahol bizonyos műszaki megoldások megvalósíthatóságát tesztelik és prototípusok elkészítésével igazolják.

Ez a modell egy olyan szoftverfejlesztési folyamat, amely a tervezést és a szakaszos prototípuskészítést is ötvözi, hogy ötvözi az alulról felfelé és a felülről lefelé irányuló koncepciók előnyeit, hangsúlyozva az életciklus kezdeti szakaszait: az elemzést és a tervezést.Megkülönböztető tulajdonság Ez a modell kiemelt figyelmet fordít az életciklus szervezését érintő kockázatokra.

Az elemzés és tervezés szakaszában prototípusok készítésével ellenőrzik a műszaki megoldások megvalósíthatóságát és a vevői igények kielégítésének mértékét. A spirál minden egyes fordulata egy működőképes töredék vagy rendszerváltozat létrehozásának felel meg. Ez lehetővé teszi a projekt követelményeinek, céljainak és jellemzőinek tisztázását, a fejlesztés minőségének meghatározását, valamint a spirál következő fordulatának munkájának megtervezését. Így a projekt részletei elmélyülnek és következetesen konkretizálódnak, és ennek eredményeként egy ésszerű, a megrendelő tényleges igényeinek megfelelő és megvalósításra kerülő opció kerül kiválasztásra.

Életciklus a spirál minden fordulóján – a szoftverfejlesztési folyamat különböző modelljei alkalmazhatók. A végeredmény egy kész termék. A modell egy prototípus-modell képességeit ötvözi ésvízesés modell. Az iterációkkal történő fejlesztés a rendszeralkotás objektíven létező spirális ciklusát tükrözi. A munka befejezetlen befejezése minden szakaszban lehetővé teszi, hogy továbblépjen a következő szakaszra anélkül, hogy megvárná az aktuális munka teljes befejezését. A fő feladat az, hogy a rendszer felhasználóinak mielőbb működőképes terméket mutassunk meg, ezzel aktiválva a követelmények tisztázását, kiegészítését.

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 módosítását a szoftverfejlesztés során, ami a legtöbb fejlesztésre jellemző, beleértve a szabványos fejlesztéseket is;
• a modell biztosítja a rugalmas tervezés lehetőségét, mivel megtestesíti a kaszkádmodell előnyeit, ugyanakkor megengedett az iterációk ugyanazon modell minden fázisában;
• lehetővé teszi, hogy megbízhatóbb és stabilabb rendszert kapjon. Ahogy a szoftver fejlődik, a hibákat és gyengeségeket minden iterációnál megtalálják és kijavítják;
• ez a modell lehetővé teszi a felhasználók számára, hogy aktívan részt vegyenek a tervezésben, a kockázatelemzésben, a fejlesztésben, valamint az értékelési tevékenységek végrehajtásában;
• csökkenti az ügyfelek kockázatát. Az ügyfél minimális anyagi veszteséggel fejezheti be egy kilátástalan projekt kidolgozását;
• A felhasználóktól a fejlesztők felé történő visszacsatolás nagy gyakorisággal és a modell elején történik, ami biztosítja, hogy a kívánt termék kiváló minőségű legyen.

A modell hátrányai:

• ha a projekt alacsony kockázatú vagy kicsi, a modell drága lehet. A kockázatértékelés minden spirál után költséges;
• A modell életciklusa bonyolult felépítésű, így alkalmazása a fejlesztők, menedzserek és ügyfelek részéről is nehézkes lehet;
• a spirál a végtelenségig folytatódhat, mivel minden ügyfél válasza a létrehozott verzióra új ciklust generálhat, ami késlelteti a projekt befejezését;
• a köztes ciklusok nagy száma további dokumentációk feldolgozásának szükségességéhez vezethet;
• a modell használata költséges, sőt megfizethetetlen is lehet, mert idő. a tervezésre, újracélzásra, kockázatelemzésre és prototípuskészítésre fordított kiadások túlzóak lehetnek;
• nehéz lehet olyan célokat és mérföldköveket meghatározni, amelyek azt jelzik, hogy készen áll a fejlesztési folyamat folytatására a következő és

A spirálciklus fő problémája a következő szakaszba való átmenet pillanatának meghatározása. Ennek megoldására az egyes szakaszokra időkorlátokat vezetnek be.életciklus és az átállás a tervek szerint halad, még akkor is, ha nem fejeződik be minden tervezett munka.TervezésA korábbi projektek során nyert statisztikai adatok és a fejlesztők személyes tapasztalatai alapján készült.

A spirálmodell terjedelme

A spirálmodell használata a következő esetekben javasolt:

• új technológiákat alkalmazó projektek kidolgozásakor;
• új termék- vagy rendszersorozat fejlesztésekor;
• olyan projektek kidolgozásakor, amelyek várhatóan jelentős változásokat vagy kiegészítéseket tartalmaznak a követelményekben;
• hosszú távú projektek megvalósításához;
• olyan projektek kidolgozásakor, amelyek egy rendszer vagy termék minőségének és verzióinak rövid időn keresztüli bemutatását igénylik;
• projektek kidolgozásakor. amelyekhez szükséges a kockázatok felmérésével és megoldásával kapcsolatos költségek kiszámítása.

az elektrotechnikában). Ez a szabvány határozza meg az életciklus szerkezetét, amely tartalmazza azokat a folyamatokat, tevékenységeket és feladatokat, amelyeket a PS létrehozása során végre kell hajtani.

Ebben a PS szabványban (ill szoftver) számítógépes programok, eljárások és esetleg kapcsolódó dokumentációk és adatok összessége. A folyamatot egymással összefüggő műveletek halmazaként határozzák meg, amelyek bizonyos bemeneti adatokat kimeneti adatokká alakítanak át (G. Myers ezt adatfordításnak nevezi). Minden folyamatot meghatározott feladatok és megoldási módszerek jellemeznek. Az egyes folyamatok egy sor műveletre, minden művelet pedig egy feladatcsoportra van felosztva. Minden folyamatot, műveletet vagy feladatot szükség szerint egy másik folyamat kezdeményez és hajt végre, és nincsenek előre meghatározott végrehajtási sorrendek (természetesen a bemeneti adatkapcsolatok fenntartása mellett).

Meg kell jegyezni, hogy a Szovjetunióban, majd Oroszországban a szoftverek (szoftverek) létrehozását kezdetben, a múlt század 70-es éveiben a GOST ESPD szabványok (Egységes Programdokumentációs Rendszer - GOST 19.XXX) szabályozták. sorozat), amelyek az egyéni programozók által készített, viszonylag egyszerű, kis volumenű programokra koncentráltak. Jelenleg ezek a szabványok fogalmilag és formailag elavultak, érvényességük lejárt, használatuk nem megfelelő.

Az automatizált rendszerek (AS) létrehozásának folyamatait, amelyek szoftvereket is tartalmaznak, a GOST 34.601-90 "Információs technológia. Szabványkészlet automatizált rendszerekre. A létrehozás szakaszai", GOST 34.602-89 "Információs technológia. A" szabványok szabályozzák. szabványkészlet automatizált rendszerekre. Műszaki feladat automatizált rendszer létrehozásához" és a GOST 34.603-92 „Információs technológia. Az automatizált rendszerek tesztjeinek típusai". Ezeknek a szabványoknak azonban sok rendelkezése elavult, míg mások nem tükröződnek eléggé ahhoz, hogy komoly projektekhez felhasználhassák a PS létrehozásához. Ezért célszerű a modern nemzetközi szabványok alkalmazása a hazai fejlesztéseknél.

Az ISO / IEC 12207 szabványnak megfelelően az összes szoftver életciklus-folyamata három csoportba sorolható (5.1. ábra).

Rizs. 5.1.

A csoportokban öt fő folyamatot határoznak meg: beszerzés, szállítás, fejlesztés, üzemeltetés és karbantartás. Nyolc részfolyamat biztosítja a fő folyamatok végrehajtását, nevezetesen dokumentáció, konfiguráció-menedzsment, minőségbiztosítás, ellenőrzés, érvényesítés, közös értékelés, audit, problémamegoldás. A négy szervezeti folyamat biztosítja az irányítást, az infrastruktúra kiépítését, a fejlesztést és a tanulást.

5.2. A PS életciklusának főbb folyamatai

Az beszerzési folyamat a szoftvert vásárló ügyfél tevékenységeiből és feladataiból áll. Ez a folyamat a következő lépéseket tartalmazza:

1. felvásárlás kezdeményezése;
2. Pályázati javaslatok elkészítése;
3. a szerződés előkészítése és módosítása;
4. a szállító tevékenységének felügyelete;
5. a munka elfogadása és befejezése.

Az akvizíció kezdeményezése a következő feladatokat foglalja magában:

1. az ügyfél által a rendszer, szoftvertermékek vagy szolgáltatások beszerzése, fejlesztése vagy javítása során felmerülő igényeinek meghatározása;
2. döntés meghozatala meglévő szoftver beszerzésével, fejlesztésével vagy továbbfejlesztésével kapcsolatban;
3. szoftvertermék vásárlása esetén a szükséges dokumentációk, garanciák, tanúsítványok, licencek és támogatás elérhetőségének ellenőrzése;
4. az akvizíciós terv elkészítése és jóváhagyása, beleértve a rendszerkövetelményeket, a szerződés típusát, a felek felelősségét stb.

Az ajánlatoknak tartalmazniuk kell:

1. rendszerkövetelmények;
2. szoftvertermékek listája;
3. beszerzési és szerződési feltételek;
4. technikai korlátok (például a rendszer működési környezete).

Az ajánlatokat egy kiválasztott szállítónak vagy pályázat esetén több szállítónak küldik meg. A szállító az a szervezet, amely a szerződésben meghatározott feltételekkel rendszer, szoftver vagy szoftverszolgáltatás szállítására köt szerződést a megrendelővel.

A szerződés előkészítése és módosítása a következő feladatokat foglalja magában:

1. a szállító kiválasztására vonatkozó eljárás megrendelő általi meghatározása, beleértve a lehetséges szállítók ajánlatainak értékelési szempontjait is;
2. konkrét szállító kiválasztása az ajánlatok elemzése alapján;
3. előkészítés és következtetés szállítói szerződések;
4. a szerződés módosítása (szükség esetén) annak végrehajtása során.

A szállító tevékenységének felügyelete a közös értékelési és auditálási folyamatokban meghatározott intézkedésekkel összhangban történik. Az átvételi folyamat során előkészítik és elvégzik a szükséges vizsgálatokat. A szerződés szerinti munka befejezése az átvétel minden feltételének teljesítése esetén történik.

A szállítási folyamat a vevőt szoftverterméket vagy szolgáltatást szállító szállító által végzett tevékenységekre és feladatokra terjed ki. Ez a folyamat a következő lépéseket tartalmazza:

1. szállítás kezdeményezése;
2. az ajánlatokra adott válasz elkészítése;
3. a szerződés előkészítése;
4. szerződéses munka tervezése;
5. szerződéses munkák elvégzése, ellenőrzése és értékelése;
6. munkák szállítása és befejezése.

A szállítás kezdeményezése abból áll, hogy a szállító megvizsgálja az ajánlatokat, és eldönti, hogy egyetért-e a meghatározott követelményekkel és feltételekkel, vagy felajánlja-e a sajátjait (megállapodott). A tervezés a következő feladatokat tartalmazza:

1. a szállító döntése a munka önálló vagy alvállalkozó bevonásával történő elvégzésével kapcsolatban;
2. a projekt szervezeti felépítését, a felelősségi körök lehatárolását, a fejlesztési környezetre és erőforrásokra vonatkozó műszaki követelményeket, az alvállalkozók menedzselését stb. tartalmazó projektmenedzsment terv kidolgozása a szállító által.

A fejlesztési folyamat biztosítja a fejlesztő által végzett tevékenységeket, feladatokat, kiterjed a szoftverek és összetevőinek meghatározott követelmények szerinti létrehozására. Ez magában foglalja a tervezési és üzemeltetési dokumentáció elkészítését, a teljesítményvizsgálathoz szükséges anyagok elkészítését, ill szoftvertermékek minősége, a személyzet képzésének megszervezéséhez szükséges anyagok stb.

A fejlesztési folyamat a következő lépéseket tartalmazza:

1. előkészítő munka;
2. a rendszer követelményeinek elemzése;
3. rendszer architektúra tervezése;
4. szoftverkövetelmények elemzése;
5. szoftver architektúra tervezése;
6. részletes szoftvertervezés;
7. szoftver kódolás és tesztelés;
8. szoftver integráció;
9. szoftver minősítés tesztelése;
10. rendszerintegráció;
11. a rendszer minősítési tesztelése;
12. szoftver telepítés;
13. szoftver elfogadása.

Az előkészítő munka a projekt léptékének, jelentőségének és összetettségének megfelelő szoftver életciklus-modell kiválasztásával kezdődik. A fejlesztési folyamat tevékenységeinek és feladatainak összhangban kell lenniük a választott modellel. A fejlesztőnek ki kell választania, alkalmazkodnia kell a projekt feltételeihez, és alkalmaznia kell a megrendelővel egyeztetett szabványokat, módszereket és módszereket. fejlesztő eszközök, valamint munkatervet készítenek.

A rendszer követelményeinek elemzése magában foglalja annak funkcionalitásának meghatározását, egyedi követelmények, a megbízhatóság, a biztonság követelményei, a külső interfészekre vonatkozó követelmények, a teljesítmény stb. A rendszerkövetelményeket a megvalósíthatósági kritériumok és a tesztelés során ellenőrizhetőség alapján értékelik.

A rendszerarchitektúra tervezése a berendezés (hardver), a szoftver összetevőinek és a rendszert üzemeltető személyzet által végzett műveletek meghatározásából áll. A rendszer architektúrájának meg kell felelnie a rendszerkövetelményeknek és az elfogadott tervezési szabványoknak és gyakorlatoknak.

A szoftverkövetelmények elemzése magában foglalja a következő jellemzők meghatározását az egyes szoftverösszetevők esetében:

1. funkcionalitás, beleértve az alkatrész teljesítményjellemzőit és működési környezetét;
2. külső interfészek;
3. megbízhatósági és biztonsági előírások;
4. ergonómiai követelmények;
5. a felhasznált adatokra vonatkozó követelmények;
6. telepítési és átvételi követelmények;
7. a felhasználói dokumentációra vonatkozó követelmények;
8. üzemeltetési és karbantartási követelmények.

A szoftverkövetelmények értékelése a rendszer egészére vonatkozó követelményeknek való megfelelés, a megvalósíthatóság és a tesztelés során ellenőrizhetőség szempontjai alapján történik.

A szoftverarchitektúra tervezése a következő feladatokat tartalmazza az egyes szoftverösszetevők esetében:

1. a szoftverkövetelmények átalakítása olyan architektúrává, amely magas szinten határozza meg a szoftver szerkezetét és összetevőinek összetételét;
2. szoftverek és adatbázisok (DB) programinterfészek fejlesztése és dokumentálása;
3. felhasználói dokumentáció előzetes változatának kidolgozása;
4. tesztek előfeltételeinek és szoftverintegrációs tervének kidolgozása és dokumentálása.

A részletes szoftvertervezés a következő feladatokat tartalmazza:

1. a szoftverkomponensek és a köztük lévő interfészek leírása alacsonyabb szinten, amely elegendő a későbbi kódoláshoz és teszteléshez;
2. részletes adatbázisterv kidolgozása és dokumentálása;
3. a felhasználói dokumentáció frissítése (ha szükséges);
4. tesztkövetelmények és szoftverkomponensek tesztelési tervének kidolgozása és dokumentálása;

A szoftver kódolása és tesztelése a következő feladatokat tartalmazza:

1. a szoftver és az adatbázis egyes összetevőinek kódolása és dokumentálása, valamint tesztelési eljárások és adatok készletének elkészítése ezek teszteléséhez;
2. a szoftver és az adatbázis egyes összetevőinek tesztelése a rájuk vonatkozó követelményeknek való megfelelés szempontjából, majd a teszteredmények dokumentálása;
3. a dokumentáció frissítése (ha szükséges);
4. a szoftverintegrációs terv frissítése.

A szoftverintegráció biztosítja a kifejlesztett szoftverkomponensek összeállítását az aggregált komponensekre vonatkozó integrációs és tesztelési terv szerint. Minden egyes összesített komponenshez tesztcsomagokat és vizsgálati eljárásokat fejlesztenek ki, hogy teszteljék az egyes kompetenciákat a későbbi jártassági tesztelés során. A képesítési követelmény olyan kritériumok vagy feltételek összessége, amelyeknek teljesülniük kell a minősítéshez. szoftver mint megfelel a specifikációinak és készen áll a terepen történő használatra.

A szoftver minősítési tesztelését a fejlesztő a megrendelő jelenlétében végzi el (

Az üzemeltetési folyamat a rendszert üzemeltető üzemeltető szervezetének tevékenységeire és feladataira terjed ki. A műveleti folyamat a következő lépéseket tartalmazza.

1. Előkészítő munka, amely magában foglalja a következő feladatok kezelő általi elvégzését:

   1. az üzemeltetés során végzett tevékenységek és munkák tervezése, működési normák meghatározása;
   2. eljárások meghatározása a működés során felmerülő problémák lokalizálására és megoldására.
2. A szoftvertermék minden következő kiadásához működési tesztelést hajtanak végre, amely után ez a kiadás átkerül a működésbe.
3. A rendszer tényleges működése, amely a felhasználói dokumentációnak megfelelően az erre szánt környezetben történik.
4. problémák és szoftvermódosítási kérelmek elemzése (felmerült problémáról vagy módosítási kérelemről szóló üzenetek elemzése, mértékének, módosítási költségének, eredő hatásának felmérése, a módosítás megvalósíthatóságának felmérése);
5. szoftver módosítás (a szoftvertermék komponenseinek és dokumentációjának módosítása a fejlesztési folyamat szabályai szerint);
6. ellenőrzés és elfogadás (a módosítandó rendszer integritásának szempontjából);
7. szoftver átvitele más környezetbe (programok és adatok átalakítása, szoftverek párhuzamos működése a régi és az új környezetben meghatározott ideig);
8. a szoftver leszerelése a megrendelő döntése alapján az üzemeltető szervezet, a karbantartó szolgálat és a felhasználók részvételével. Ugyanakkor a szoftvertermékek és a dokumentáció a szerződésnek megfelelően archiválás alá esik.

Annotáció.

Bevezetés.

1. A szoftver életciklusa

Bevezetés.

Riley programozási folyamat lépései

Bevezetés.

1.1.1. A probléma megfogalmazása.

1.1.2. Megoldás tervezés.

1.1.3. Algoritmus kódolás.

1.1.4. Program támogatás.

1.1.5. Szoftver dokumentáció.

Következtetés az 1.1. bekezdéshez

1.2. A ZhTsPO meghatározása Lehman szerint.

Bevezetés.

1.2.1 A rendszer meghatározása.

1.2.2. Végrehajtás.

1.2.3. Szolgáltatás.

Következtetés az 1.2. ponthoz.

1.3. Az életciklus program fázisai és munkái Boehm szerint

1.3.1. kaszkád modell.

1.3.2. A kaszkádmodell gazdasági alátámasztása.

1.3.3. A kaszkádmodell továbbfejlesztése.

1.3.4. Az életciklus fázisainak meghatározása.

1.3.5. A projekt alapmunkái.

Irodalom.

Bevezetés

A számítógépek ipari alkalmazása és a programok iránti növekvő igény sürgető feladatokat szabott a számok jelentős növelésére szoftverfejlesztési termelékenység, a programok tervezésének és tervezésének ipari módszereinek kidolgozása, szervezési, műszaki, műszaki, gazdasági és szociálpszichológiai módszerek, minták és módszerek átadása az anyagtermelés szférájából a számítógépek szférájába. Komplex megközelítés a szoftverfejlesztési, üzemeltetési és karbantartási folyamatokhoz számos sürgető problémát vetett fel, amelyek megoldása megszünteti a programok tervezésének "szűk keresztmetszeteit", csökkenti a befejezési időt, javítja a meglévő programok kiválasztását és adaptálását, ill. talán meghatározza a beágyazott számítógépekkel rendelkező rendszerek sorsát.

A nagy szoftverprojektek fejlesztésének gyakorlatában gyakran nincs egységes megközelítés a munkaerőköltségek, a munkavégzési feltételek és az anyagköltségek értékelésére, ami gátolja a szoftverfejlesztés termelékenységének növelését, végső soron a szoftver életciklusának hatékony kezelését. Mivel bármilyen típusú programból termék lesz (kivéve talán az oktatási, makettprogramokat), az előállítás megközelítésének sok tekintetben hasonlónak kell lennie az ipari termékek előállításához, és a szoftvertervezési kérdések rendkívül fontossá válnak. . Ez az ötlet a B.U. Boehm "Engineering Software Design", amelyet a dolgozat megírásakor használtunk. Ebben a könyvben a szoftvertervezés egy szoftvertermék tervének elkészítésének folyamatát jelenti.

1 A szoftver életciklusa

BEVEZETÉS

Az LCPE egy folyamatos folyamat, amely attól a pillanattól kezdődik, amikor döntés születik a szoftver létrehozásának szükségességéről, és azzal a pillanattal ér véget, amikor azt teljesen kivonják a működésből.

Számos megközelítés létezik a szoftver életciklusának (SLLC) fázisainak és tevékenységeinek, a programozási folyamat lépéseinek, a vízesés és a spirálmodellek meghatározására. De mindegyik tartalmaz közös alapvető összetevőket: problémafelvetés, megoldástervezés, megvalósítás, karbantartás.

A leghíresebb és legteljesebb talán az életciklus Boehm szerinti felépítése, amely nyolc fázisból áll. Később részletesebben is bemutatjuk.

Az egyik lehetséges opció lehet a Lehman szerinti felső szint leírása, amely három fő fázist foglal magában, és a legáltalánosabb esetben az életciklus program leírását jelenti.

És a változatosság kedvéért itt vannak a programozási folyamat lépései, amelyeket D. Riley mutat be a „Modula-2 nyelv használata” című könyvében. Ez az ötlet véleményem szerint nagyon egyszerű és ismerős, és ezzel kezdjük is.

1.1 Riley programozási folyamat lépései

Bevezetés

A programozási folyamat négy lépésből áll (1. ábra):

problémafelvetés, i.e. megfelelő elképzelés szerzése arról, hogy a programnak milyen feladatot kell végrehajtania;

megoldás tervezése egy már feltett problémára (általában egy ilyen megoldás kevésbé formális, mint a végleges program);

programkódolás, azaz a megtervezett megoldás gépen végrehajtható programmá fordítása;

programtámogatás, azaz a program hibáinak kijavításának és az új szolgáltatások hozzáadásának folyamatban lévő folyamata.

Rizs. 1. Négy programozási lépés.

A programozás attól a pillanattól kezdődik, amikor felhasználó, azaz akinek szüksége van egy programra a probléma megoldásához, az problémát jelent rendszerelemző. A felhasználó és a rendszerelemző közösen határozza meg a problémameghatározást. Ez utóbbit ezután áthelyezik algoritmus ki a felelős a megoldás megtervezéséért. A megoldás (vagy algoritmus) olyan műveletek sorozata, amelyek végrehajtása egy probléma megoldásához vezet. Mivel az algoritmust gyakran nem adaptálják gépen történő végrehajtásra, le kell fordítani egy gépi programra. Ezt a műveletet a kódoló hajtja végre. A program későbbi módosításaiért a fenntartó a felelős. programozó. És a rendszerelemző, az algoritmus, a kódoló és a kísérő programozó – mind programozók.

Nagy szoftverprojekt esetén jelentős lehet a felhasználók, rendszerelemzők és algoritmusok száma. Ezenkívül előre nem látható körülmények miatt szükségessé válhat a korábbi lépésekhez való visszatérés. Mindez további érvként szolgál a gondos szoftvertervezés mellett: minden lépés eredménye legyen teljes, pontos és érthető.

1.1.1 A probléma megfogalmazása

A programozás egyik legfontosabb lépése a probléma beállítása. Szerződésként működik a felhasználó és a programozó(k) között. Mint egy jogilag rosszul megfogalmazott szerződés, a rossz küldetésnyilatkozat is haszontalan. Jó problémafelvetés esetén mind a felhasználó, mind a programozó egyértelműen és egyértelműen reprezentálja az elvégzendő feladatot, azaz. ebben az esetben a felhasználó és a programozó érdekeit is figyelembe veszik. A felhasználó megtervezheti a még el nem készült szoftver használatát, a tudása alapján. A probléma jó megfogalmazása alapul szolgál a megoldás kialakításához.

A probléma megfogalmazása (program specifikáció); lényegében pontos, teljes és érthető leírást jelent arról, hogy mi történik egy adott program végrehajtásakor. A felhasználó általában úgy tekint a számítógépre, mint egy fekete dobozra: számára nem mindegy, hogyan működik a számítógép, de fontos, hogy a számítógép meg tudja csinálni azt, ami a felhasználót érdekli. A hangsúly az ember és a gép közötti interakción van.

A jó problémanyilatkozat jellemzői:

Pontosság, azaz minden kétértelműség kizárása. Nem lehet kérdés, hogy egy adott bemenetre mi lesz a program kimenete.

teljesség, azaz egy adott bemenet összes lehetőségének mérlegelése, beleértve a hibás vagy váratlan bemenetet is, és a megfelelő kimenet meghatározása.

Világosság, azaz érthetőnek kell lennie mind a felhasználó, mind a rendszerelemző számára, hiszen a problémafelvetés az egyetlen szerződés közöttük.

A pontosság, teljesség és egyértelműség követelményei gyakran ellentmondanak egymásnak. Így sok jogi dokumentum nehezen érthető, mert olyan formális nyelvezeten készült, amely lehetővé teszi bizonyos rendelkezések maximális precizitással történő megfogalmazását, a legjelentéktelenebb eltérések kizárásával. Például egyes kérdések a vizsgadolgozatokon olykor olyan pontosan vannak megfogalmazva, hogy a hallgató több időt tölt a kérdés megértésével, mint a megválaszolásával. Ráadásul előfordulhat, hogy a tanuló egyáltalán nem fogja fel a kérdés fő jelentését a sok részlet miatt. A legjobb problémafelvetés az, amelyik mindhárom követelmény egyensúlyát eléri.

A problémafelvetés szabványos formája.

Tekintsük a következő problémameghatározást: "Írjon be három számot, és adja ki a számokat sorrendben."

Egy ilyen kijelentés nem felel meg a fenti követelményeknek: sem nem pontos, sem nem teljes, sem nem érthető. Valóban, soronként egyet kell beírni a számokat, vagy az összes számot egy sorban? A "sorrendben" kifejezés a legnagyobbtól a legkisebbig, a legkisebbtől a legnagyobbig való rendezést jelenti, vagy ugyanazt a sorrendet, amelyben bevezették őket?

Nyilvánvaló, hogy egy ilyen kijelentés sok kérdésre nem ad választ. Ha minden kérdésre figyelembe vesszük a választ, akkor a problémafelvetés bőbeszédűvé és nehezen érthetővé válik. Ezért D. Riley a szabványos űrlap használatát javasolja a probléma beállításához, amely maximális pontosságot, teljességet, egyértelműséget biztosít, és a következőket tartalmazza:

feladat neve (sematikus definíció);

általános leírás (a feladat rövid ismertetése);

hibák (a szokatlan beviteli lehetőségek kifejezetten vannak felsorolva, hogy megmutassák a felhasználóknak és a programozóknak, hogy a gép milyen műveleteket hajt végre ilyen helyzetekben);

példa (egy jó példa átadhatja a probléma lényegét, valamint szemléltetheti a különböző eseteket).

Példa. A probléma kijelentése szabványos formában.

CÍM

Rendezzen három egész számot.

LEÍRÁS

Három egész szám bevitele és kimenete, a legkisebbtől a legnagyobbig rendezve.

Három egész szám kerül beírásra, soronként egy szám. Ebben az esetben az egész szám egy vagy több egymást követő decimális számjegy, amelyet egy pluszjel „+” vagy egy mínusz „-” előzhet meg.

A három beírt egész szám megjelenik, és mindhárom ugyanabban a sorban jelenik meg. A szomszédos számokat szóköz választja el. A számok a legkisebbtől a legnagyobbig, balról jobbra jelennek meg.

1) Ha háromnál kevesebb számot ad meg, a program további bevitelre vár.

2) Az első háromtól eltérő bemeneti sorokat figyelmen kívül hagyja.

3) Ha az első három sor bármelyike ​​egynél több egész számot tartalmaz, akkor a program kilép és üzenetet ad ki.

Annotáció.

Bevezetés.

1. A szoftver életciklusa

Bevezetés.

Riley programozási folyamat lépései

Bevezetés.

1.1.1. A probléma megfogalmazása.

1.1.2. Megoldás tervezés.

1.1.3. Algoritmus kódolás.

1.1.4. Program támogatás.

1.1.5. Szoftver dokumentáció.

Következtetés az 1.1. bekezdéshez

1.2. A ZhTsPO meghatározása Lehman szerint.

Bevezetés.

1.2.1 A rendszer meghatározása.

1.2.2. Végrehajtás.

1.2.3. Szolgáltatás.

Következtetés az 1.2. ponthoz.

1.3. Az életciklus program fázisai és munkái Boehm szerint

1.3.1. kaszkád modell.

1.3.2. A kaszkádmodell közgazdasági alátámasztása.

1.3.3. A kaszkádmodell továbbfejlesztése.

1.3.4. Az életciklus fázisainak meghatározása.

1.3.5. A projekt alapmunkái.

Irodalom.

Bevezetés

A számítógépek ipari alkalmazása és a programok iránti növekvő igény sürgető feladatokat szabott a számok jelentős növelésére szoftverfejlesztési termelékenység, a programok tervezésének és tervezésének ipari módszereinek kidolgozása, szervezési, műszaki, műszaki, gazdasági és szociálpszichológiai módszerek, minták és módszerek átadása az anyagtermelés szférájából a számítógépek szférájába. Komplex megközelítés a szoftverfejlesztési, üzemeltetési és karbantartási folyamatokhoz számos sürgető problémát vetett fel, amelyek megoldása megszünteti a programok tervezésének "szűk keresztmetszeteit", csökkenti a befejezési időt, javítja a meglévő programok kiválasztását és adaptálását, ill. talán meghatározza a beágyazott számítógépekkel rendelkező rendszerek sorsát.

A nagy szoftverprojektek fejlesztésének gyakorlatában gyakran nincs egységes megközelítés a munkaerőköltségek, a munkavégzési feltételek és az anyagköltségek értékelésére, ami gátolja a szoftverfejlesztés termelékenységének növelését, végső soron a szoftver életciklusának hatékony kezelését. Mivel bármilyen típusú programból termék lesz (kivéve talán az oktatási, makettprogramokat), az előállítás megközelítésének sok tekintetben hasonlónak kell lennie az ipari termékek előállításához, és a szoftvertervezési kérdések rendkívül fontossá válnak. . Ez az ötlet a B.U. Boehm "Engineering Software Design", amelyet a dolgozat megírásakor használtunk. Ebben a könyvben a szoftvertervezés egy szoftvertermék tervének elkészítésének folyamatát jelenti.

1 A szoftver életciklusa

BEVEZETÉS

Az LCPE egy folyamatos folyamat, amely attól a pillanattól kezdődik, amikor döntés születik a szoftver létrehozásának szükségességéről, és azzal a pillanattal ér véget, amikor azt teljesen kivonják a működésből.

Számos megközelítés létezik a szoftver életciklusának (SLLC) fázisainak és tevékenységeinek, a programozási folyamat lépéseinek, a vízesés és a spirálmodellek meghatározására. De mindegyik tartalmaz közös alapvető összetevőket: problémafelvetés, megoldástervezés, megvalósítás, karbantartás.

A leghíresebb és legteljesebb talán az életciklus Boehm szerinti felépítése, amely nyolc fázisból áll. Később részletesebben is bemutatjuk.

Az egyik lehetséges opció lehet a Lehman szerinti felső szint leírása, amely három fő fázist foglal magában, és a legáltalánosabb esetben az életciklus program leírását jelenti.

És a változatosság kedvéért itt vannak a programozási folyamat lépései, amelyeket D. Riley mutat be a „Modula-2 nyelv használata” című könyvében. Ez az ötlet véleményem szerint nagyon egyszerű és ismerős, és ezzel kezdjük is.

1.1 Riley programozási folyamat lépései

A programozási folyamat négy lépésből áll (1. ábra):

problémafelvetés, i.e. megfelelő elképzelés szerzése arról, hogy a programnak milyen feladatot kell végrehajtania;

megoldás tervezése egy már feltett problémára (általában egy ilyen megoldás kevésbé formális, mint a végleges program);

programkódolás, azaz a megtervezett megoldás gépen végrehajtható programmá fordítása;

programtámogatás, azaz a program hibáinak kijavításának és az új szolgáltatások hozzáadásának folyamatban lévő folyamata.

Rizs. 1. Négy programozási lépés.

A programozás attól a pillanattól kezdődik, amikor felhasználó, azaz akinek szüksége van egy programra a probléma megoldásához, az problémát jelent rendszerelemző. A felhasználó és a rendszerelemző közösen határozza meg a problémameghatározást. Ez utóbbit ezután áthelyezik algoritmus ki a felelős a megoldás megtervezéséért. A megoldás (vagy algoritmus) olyan műveletek sorozata, amelyek végrehajtása egy probléma megoldásához vezet. Mivel az algoritmust gyakran nem adaptálják gépen történő végrehajtásra, le kell fordítani egy gépi programra. Ezt a műveletet a kódoló hajtja végre. A program későbbi módosításaiért a kísérő programozó felelős. És a rendszerelemző, az algoritmus, a kódoló és a kísérő programozó – mind programozók.

Nagy szoftverprojekt esetén jelentős lehet a felhasználók, rendszerelemzők és algoritmusok száma. Ezenkívül előre nem látható körülmények miatt szükségessé válhat a korábbi lépésekhez való visszatérés. Mindez további érvként szolgál a gondos szoftvertervezés mellett: minden lépés eredménye legyen teljes, pontos és érthető.

1.1.1 A probléma megfogalmazása

A programozás egyik legfontosabb lépése a probléma beállítása. Szerződésként működik a felhasználó és a programozó(k) között. Mint egy jogilag rosszul megfogalmazott szerződés, a rossz küldetésnyilatkozat is haszontalan. Jó problémafelvetés esetén mind a felhasználó, mind a programozó egyértelműen és egyértelműen reprezentálja az elvégzendő feladatot, azaz. ebben az esetben a felhasználó és a programozó érdekeit is figyelembe veszik. A felhasználó megtervezheti a még el nem készült szoftver használatát, a tudása alapján. A probléma jó megfogalmazása alapul szolgál a megoldás kialakításához.

A probléma megfogalmazása (program specifikáció); lényegében pontos, teljes és érthető leírást jelent arról, hogy mi történik egy adott program végrehajtásakor. A felhasználó általában úgy tekint a számítógépre, mint egy fekete dobozra: számára nem mindegy, hogyan működik a számítógép, de fontos, hogy a számítógép meg tudja csinálni azt, ami a felhasználót érdekli. A hangsúly az ember és a gép közötti interakción van.

A jó problémanyilatkozat jellemzői:

Pontosság, azaz minden kétértelműség kizárása. Nem lehet kérdés, hogy egy adott bemenetre mi lesz a program kimenete.

teljesség, azaz egy adott bemenet összes lehetőségének mérlegelése, beleértve a hibás vagy váratlan bemenetet is, és a megfelelő kimenet meghatározása.

Világosság, azaz érthetőnek kell lennie mind a felhasználó, mind a rendszerelemző számára, hiszen a problémafelvetés az egyetlen szerződés közöttük.

A pontosság, teljesség és egyértelműség követelményei gyakran ellentmondanak egymásnak. Így sok jogi dokumentum nehezen érthető, mert olyan formális nyelvezeten készült, amely lehetővé teszi bizonyos rendelkezések maximális precizitással történő megfogalmazását, a legjelentéktelenebb eltérések kizárásával. Például egyes kérdések a vizsgadolgozatokon olykor olyan pontosan vannak megfogalmazva, hogy a hallgató több időt tölt a kérdés megértésével, mint a megválaszolásával. Ráadásul előfordulhat, hogy a tanuló egyáltalán nem fogja fel a kérdés fő jelentését a sok részlet miatt. A legjobb problémafelvetés az, amelyik mindhárom követelmény egyensúlyát eléri.

A problémafelvetés szabványos formája.

Tekintsük a következő problémameghatározást: "Írjon be három számot, és adja ki a számokat sorrendben."

Egy ilyen kijelentés nem felel meg a fenti követelményeknek: sem nem pontos, sem nem teljes, sem nem érthető. Valóban, soronként egyet kell beírni a számokat, vagy az összes számot egy sorban? A "sorrendben" kifejezés a legnagyobbtól a legkisebbig, a legkisebbtől a legnagyobbig való rendezést jelenti, vagy ugyanazt a sorrendet, amelyben bevezették őket?

Nyilvánvaló, hogy egy ilyen kijelentés sok kérdésre nem ad választ. Ha minden kérdésre figyelembe vesszük a választ, akkor a problémafelvetés bőbeszédűvé és nehezen érthetővé válik. Ezért D. Riley a szabványos űrlap használatát javasolja a probléma beállításához, amely maximális pontosságot, teljességet, egyértelműséget biztosít, és a következőket tartalmazza:

feladat neve (sematikus definíció);

általános leírás (a feladat rövid ismertetése);

hibák (a szokatlan beviteli lehetőségek kifejezetten vannak felsorolva, hogy megmutassák a felhasználóknak és a programozóknak, hogy a gép milyen műveleteket hajt végre ilyen helyzetekben);

példa (egy jó példa átadhatja a probléma lényegét, valamint szemléltetheti a különböző eseteket).

Példa. A probléma megfogalmazása szabványos formában.

CÍM

Rendezzen három egész számot.

LEÍRÁS

Három egész szám bevitele és kimenete, a legkisebbtől a legnagyobbig rendezve.

Három egész szám kerül beírásra, soronként egy szám. Ebben az esetben az egész szám egy vagy több egymást követő decimális számjegy, amelyet egy pluszjel „+” vagy egy mínusz „-” előzhet meg.

A három beírt egész szám megjelenik, és mindhárom ugyanabban a sorban jelenik meg. A szomszédos számokat szóköz választja el. A számok a legkisebbtől a legnagyobbig, balról jobbra jelennek meg.

1) Ha háromnál kevesebb számot ad meg, a program további bevitelre vár.

2012. március 1-jén az Orosz Föderáció Szövetségi Műszaki Szabályozási és Metrológiai Ügynöksége elfogadta a GOST R ISO/IEC 12207-2010 „Információs technológia. Rendszer- és szoftverfejlesztés. Szoftver életciklus-folyamatok”, amely megegyezik az ISO/IEC 12207:2008 „Rendszer- és szoftverfejlesztés – Szoftver életciklus-folyamatok” nemzetközi szabvánnyal.

Ez a szabvány a bevett terminológiát használva közös keretet hoz létre a szoftver életciklus-folyamataihoz, amely iránymutatásként használható a szoftveriparban. A szabvány meghatározza azokat a folyamatokat, tevékenységeket és feladatokat, amelyeket a szoftvertermékek vagy -szolgáltatások beszerzése, valamint a szoftvertermékek szállítása, fejlesztése, rendeltetésszerű használata, karbantartása és leállítása során alkalmaznak.

Szoftver életciklus folyamatok

A szabvány hét folyamatcsoportba sorolja a szoftverrendszerek életciklusa során végrehajtható különféle tevékenységeket. Az ezeken a csoportokon belüli életciklus-folyamatok mindegyike le van írva a cél és a kívánt kimenetek, valamint az eredmények elérése érdekében végrehajtandó tevékenységek és feladatok listája alapján.

• megállapodási folyamatok - két folyamat;
• projekt szervezeti támogatási folyamatok - öt folyamat;
• projektfolyamatok - hét folyamat;
• technikai folyamatok - tizenegy folyamat;
• szoftver implementációs folyamatok - hét folyamat;
• szoftvertámogatási folyamatok - nyolc folyamat;
• szoftver-újrafelhasználási folyamatok – három folyamat.
• Fő:
  • Beszerzés (a szoftvert vásárló ügyfél tevékenységei, feladatai)
  • Szállítás (a vevőt szoftverterméket vagy szolgáltatást szállító szállító tevékenységei és feladatai)
  • Fejlesztés (a fejlesztő által végzett tevékenységek, feladatok: szoftver készítés, tervezési és üzemeltetési dokumentáció készítése, teszt- és oktatási anyagok készítése stb.)
  • Üzemeltetés (az üzemeltető – a rendszert üzemeltető szervezet – intézkedései, feladatai)
  • Karbantartás (a kísérő szervezet, azaz a karbantartó szolgálat által végzett intézkedések és feladatok). Karbantartás – a szoftver módosítása a hibák kijavítása, a teljesítmény javítása vagy a változó működési feltételekhez vagy követelményekhez való alkalmazkodás érdekében.
• Kiegészítő
  • Dokumentáció (a szoftver életciklusa során keletkezett információk formalizált leírása)
  • Konfigurációkezelés (adminisztrációs és műszaki eljárások alkalmazása a szoftver teljes életciklusa során a szoftverkomponensek állapotának meghatározására, módosításainak kezelésére).
  • Minőségbiztosítás (annak biztosítása, hogy az IS és életciklusának folyamatai megfeleljenek a meghatározott követelményeknek és jóváhagyott terveknek)
  • Ellenőrzés (annak megállapítása, hogy a szoftvertermékek, amelyek valamilyen művelet eredménye, teljes mértékben megfelelnek-e a korábbi műveletek miatti követelményeknek vagy feltételeknek)
  • Tanúsítás (a meghatározott követelményeknek és a létrehozott rendszernek a meghatározott funkcionális célnak való megfelelésének teljességének meghatározása)
  • Közös értékelés (a projekten végzett munka állapotának értékelése: az erőforrások, a személyzet, a berendezések, az eszközök tervezésének és kezelésének ellenőrzése)
  • Audit (a szerződésben foglalt követelményeknek, terveknek és feltételeknek való megfelelés megállapítása)
  • Problémamegoldás (a fejlesztés, üzemeltetés, karbantartás vagy egyéb folyamatok során feltárt problémák elemzése és megoldása, függetlenül azok eredetétől vagy forrásától)
• Szervezeti
  • Menedzsment (tevékenységek és feladatok, amelyeket a folyamatait irányító bármely fél elvégezhet)
  • Infrastruktúra létrehozása (technológia, szabványok és eszközök kiválasztása és karbantartása, a szoftver fejlesztéséhez, üzemeltetéséhez vagy karbantartásához használt hardver és szoftver kiválasztása és telepítése)
  • Fejlesztés (életciklus-folyamatok értékelése, mérése, ellenőrzése és javítása)
  • Képzés (kezdeti képzés, majd a személyzet folyamatos fejlesztése)

Mindegyik folyamat számos tevékenységet tartalmaz. A beszerzési folyamat például a következő lépéseket tartalmazza:

1. Felvásárlás kezdeményezése
2. Ajánlatok elkészítése
3. Szerződés előkészítése, módosítása
4. Szállítói felügyelet
5. Munka átvétele és elvégzése

Minden művelet számos feladatot tartalmaz. Például az ajánlatok elkészítésének tartalmaznia kell:

1. A rendszer követelményeinek kialakítása
2. Szoftvertermékek listájának kialakítása
3. Feltételek és megállapodások meghatározása
4. A műszaki korlátok leírása (rendszer működési környezet stb.)

Szoftver életciklus szakaszai, kapcsolat a folyamatok és szakaszok között

Szoftver életciklus modell- olyan struktúra, amely az életciklus során meghatározza a végrehajtás sorrendjét és a folyamatok, cselekvések és feladatok kapcsolatát. Az életciklus-modell a projekt sajátosságaitól, méretétől és összetettségétől, valamint a rendszer létrehozásának és működésének sajátos feltételeitől függ.

A GOST R ISO/IEC 12207-2010 szabvány nem kínál konkrét életciklus-modellt. Rendelkezései minden életciklus modellre, módszerre és technológiára vonatkoznak az IP létrehozására. Leírja az életciklus-folyamatok szerkezetét anélkül, hogy meghatározná, hogyan kell végrehajtani vagy végrehajtani az ezekben a folyamatokban foglalt tevékenységeket és feladatokat.

A szoftver életciklus-modellje a következőket tartalmazza:

1. szakasz;
2. A munka eredményei az egyes szakaszokban;
3. Kulcsesemények - a munka és a döntéshozatal befejezési pontjai.