Szoftver életciklusa: koncepció, szabványok, folyamatok. Szoftver életciklus (Software Life Cycle) Mit tartalmaz a szoftver életciklusa

A szoftver életciklusa

Életciklus szoftver- az az időtartam, amely attól a pillanattól kezdődik, amikor döntés születik a szoftvertermék létrehozásának szükségességéről, és a teljes működésből való kivonás pillanatával ér véget. (IEEE Std 610.12)

A szoftver életciklusának (LC) szakaszainak meghatározásának szükségessége a fejlesztők azon vágya, hogy javítsák a szoftver minőségét optimális szabályozás különböző minőség-ellenőrzési mechanizmusok fejlesztése és használata minden szakaszban, a feladatok beállításától a szoftveralkotási támogatásig. A szoftver életciklusának legáltalánosabb ábrázolása egy modell alapvető szakaszok - folyamatok formájában, amelyek magukban foglalják:

Rendszerelemzés és szoftverkövetelmények indoklása;

Előzetes (vázlatos) és részletes (műszaki) szoftvertervezés;

Szoftverkomponensek fejlesztése, integrációjuk és általában a szoftverhibakeresés;

Szoftverek tesztelése, próbaüzeme és replikációja;

A szoftver rendszeres üzemeltetése, a működés karbantartása és az eredmények elemzése;

Szoftverek karbantartása, módosítása, fejlesztése, új verziók készítése.

Ez a modell általánosan elfogadott, és megfelel mind a hazai, mind a külföldi szabályozási dokumentumoknak a szoftverfejlesztés területén. A technológiai biztonság biztosítása szempontjából célszerű részletesebben átgondolni az életciklus szakaszok külföldi modellekben való ábrázolásának sajátosságait, mivel az idegen szoftver a szabotázs típusú szoftverhibák legvalószínűbb hordozói.

Szoftver életciklus-szabványai

GOST 34.601-90

ISO/IEC 12207:1995 (orosz analóg - GOST R ISO/IEC 12207-99)

Az életciklus-modellek grafikus ábrázolása lehetővé teszi azok jellemzőinek és a folyamatok egyes tulajdonságainak vizuális kiemelését.

Kezdetben az életciklus kaszkádmodelljét hozták létre, amelyben a nagyobb szakaszok egymás után kezdődtek a korábbi munka eredményeinek felhasználásával. Előí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. A követelmények kialakításának szakaszában meghatározott követelmények szigorúan dokumentálva vannak feladatmeghatározás formájában, és a projektfejlesztés teljes időtartamára rögzítve vannak. Minden szakasz a teljes dokumentáció kiadásával ér véget, amely elegendő ahhoz, hogy a fejlesztést egy másik fejlesztőcsapat folytathassa. Bármely követelmény pontatlansága vagy ebből adódó helytelen értelmezése oda vezet, hogy a projekt korai szakaszába kell "visszagurulni", és a szükséges átdolgozás nemcsak kiüti a projektcsapatot az ütemtervből, hanem gyakran minőségi költségnövekedést, és lehetőség szerint a projektet abban a formában fejezik be, ahogyan azt eredetileg kitalálták. A vízesés-modell készítőinek fő tévedése az a feltételezés, hogy a tervezés egyszer végigmegy a teljes folyamaton, a tervezett architektúra jó és könnyen használható, az implementáció tervezése ésszerű, az implementáció hibái pedig könnyen kiküszöbölhetők. tesztelés. Ez a modell azt feltételezi, hogy minden hiba az implementációban összpontosul, ezért azok kiküszöbölése egyenletesen történik a komponens- és rendszerteszt során. Így a vízesés modell a nagy projektek nem túl valósághű, és csak kis rendszerek létrehozására használható hatékonyan.

A legspecifikusabb az életciklus spirálmodellje. Ebben a modellben a figyelem a tervezés kezdeti szakaszainak iteratív folyamatára összpontosul. Ezekben a szakaszokban egymás után jönnek létre a koncepciók, a követelmények specifikációi, az előzetes és a részletes tervezés. Minden körben pontosítják a munka tartalmát és koncentrálják a készülő szoftver megjelenését, értékelik a kapott eredmények minőségét, és megtervezik a következő iteráció munkáját. Minden iterációnál a következőket értékeljük ki:

A projekt feltételeinek és költségének túllépésének kockázata;

Újabb iteráció végrehajtásának szükségessége;

A rendszer követelményeinek megértésének teljessége és pontossága;

A projekt leállításának célszerűsége.

A szoftver életciklusának szabványosítása három irányban történik. Az első irányt a Nemzetközi Szabványügyi Szervezet (ISO – Nemzetközi Szabványügyi Szervezet) és a Nemzetközi Elektrotechnikai Bizottság (IEC – International Electro-technical Commission) szervezi és ösztönzi. Ezen a szinten a legelterjedtebb, a nemzetközi együttműködés szempontjából fontos technológiai folyamatok szabványosítása valósul meg. A második irányt az Egyesült Államokban az Institute of Electrical and Electronics Engineers (IEEE – Institute of Electrotechnical and Electronics Engineers) az Amerikai Nemzeti Szabványügyi Intézettel (ANSI) közösen fejleszti aktívan. Az ISO/IEC és ANSI/IEEE szabványok többnyire tanácsadó jellegűek. A harmadik irányt az Egyesült Államok Védelmi Minisztériuma (Department of Defense-DOD) ösztönzi. A DOD szabványok kötelezőek az Egyesült Államok Védelmi Minisztériuma nevében dolgozó cégek számára.

Egy komplex rendszer, különösen a valós idejű rendszer szoftverének tervezéséhez célszerű olyan rendszerszintű életciklus-modellt alkalmazni, amely az összes ismert mű egyesítésén alapul a vizsgált alapfolyamatok keretein belül. Ezt a modellt különféle szoftverprojektek tervezésére, ütemezésére és menedzselésére szánják.

Ezen életciklus-modell szakaszainak halmazát célszerű két részre bontani, amelyek a folyamatok sajátosságaiban, műszaki és gazdasági jellemzőiben, illetve az azokat befolyásoló tényezőkben jelentősen eltérnek egymástól.

Az életciklus első részében a szoftverek rendszerelemzése, tervezése, fejlesztése, tesztelése és tesztelése történik. A művek köre, összetettsége, időtartama és egyéb jellemzői ezekben a szakaszokban jelentősen függenek a tárgytól és a fejlesztési környezettől. Az ilyen függőségek tanulmányozása a különböző szoftverosztályok esetében lehetővé teszi az új szoftververziók munkabeosztásának összetételének és fő jellemzőinek előrejelzését.

Az életciklus második része, amely a szoftverek üzemeltetésének és karbantartásának támogatását tükrözi, viszonylag gyengén kapcsolódik az objektum és a fejlesztői környezet jellemzőihez. Ezekben a szakaszokban a munkák köre stabilabb, összetettségük és időtartamuk jelentősen változhat, és a szoftver tömeges alkalmazásától függ. Bármilyen életciklus-ellátási modellhez Jó minőség szoftverrendszerek csak szabályozott használatával lehetséges technológiai folyamat ezen szakaszok mindegyikében. Egy ilyen folyamatot fejlesztési automatizálási eszközök támogatnak, amelyeket célszerű a meglévők közül kiválasztani, vagy a fejlesztési objektum és az ahhoz megfelelő munkák listájának figyelembevételével elkészíteni.

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. Alapmunka a projekten.

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 technikák, 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 programból termék lesz (kivéve talán az oktatási, makettprogramokat), a gyártási megközelítésnek 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 "Szoftvermérnöki tervezés", amelyre ezt írtuk lejáratú papírok. 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 szerintem 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;

egy már felvetett probléma megoldásának megtervezése (á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 gépi programmá. 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ő, és az algoritmus, és 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 szolgál alapul a megoldás kialakításához.

A probléma megfogalmazása (program specifikáció); lényegében annak pontos, teljes és érthető leírását jelenti, 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 A felhasználó és a rendszerelemző számára is érthetőnek kell lennie, 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, hogy bizonyos rendelkezéseket a lehető legnagyobb pontossággal, a legjelentéktelenebb eltéréseket is kizárva fogalmazzon meg. 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ű és nehezen érthetővé válik. Ezért D. Riley a szabványos űrlap használatát javasolja a probléma felállításához, amely biztosítja a maximális pontosságot, teljességet, egyértelműséget é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 ( jó példaátadhatja a probléma lényegét, valamint szemléltetheti a különféle 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.

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.

az elektrotechnikában). Ez a szabvány határozza meg a PS létrehozása során végrehajtandó folyamatokat, tevékenységeket és feladatokat tartalmazó életciklus-struktúrát.

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 úgy definiáljuk, mint egymással összefüggő műveletek összességét, amelyek bizonyos bemeneti adatokat kimeneti adatokká alakítanak át (G. Myers ezt adatfordításnak nevezi). Minden folyamatot bizonyos feladatok és megoldási módszerek jellemeznek. Az egyes folyamatok egy sor műveletre, és minden egyes művelet egy sor feladatra 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 (SW) létrehozását kezdetben, a múlt század 70-es éveiben a GOST ESPD szabványok szabályozták ( egységes rendszer szoftverdokumentáció - a GOST 19.XXX sorozat), amelyek az egyéni programozók által létrehozott, viszonylag egyszerű kis programok osztályára összpontosítottak. Jelenleg ezek a szabványok fogalmilag és formailag elavultak, érvényességük lejárt, használatuk nem célszerű.

Alkotó folyamatok automatizált rendszerek(AS), amely szoftvereket is tartalmaz, a GOST 34.601-90" szabályozza. 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. 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". Azonban ezeknek a szabványoknak sok rendelkezése elavult, míg mások nem tükröződnek eléggé ahhoz, hogy komoly projektekben lehessen felhasználni a PS létrehozására. Ezért célszerű a modern nemzetközi szabványok alkalmazása a hazai fejlesztéseknél.

Alapján ISO szabvány/ IEC 12207 szerint az összes szoftver életciklus-folyamat három csoportra van osztva (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éshozatal meglévő szoftver beszerzésével, fejlesztésével vagy továbbfejlesztésével kapcsolatban;
3. rendelkezésre állás ellenőrzése szükséges dokumentációt, garanciák, tanúsítványok, licencek és támogatás szoftvertermék vásárlása esetén;
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 miatt).

Pályázat esetén az ajánlatokat egy kiválasztott szállítónak vagy 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 kritériumait;
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. módosítások elvégzése (szükség esetén) a szerződésben 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ánlati javaslatokat, és eldönti, hogy egyetért-e a megfogalmazott követelményekkel és feltételekkel, vagy felajánlja-e a sajátját (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. tartalmazó projektmenedzsment terv kidolgozása a szállító által szervezeti struktúra projekt, felelősségmegosztás, technikai követelmények a fejlesztési környezethez és erőforrásokhoz, az alvállalkozók menedzseléséhez stb.

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. Ide tartozik a tervezési és üzemeltetési dokumentáció elkészítése, a teljesítményvizsgálathoz szükséges anyagok elkészítése, 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. Szoftverekre vonatkozó kö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 kialakítása abból áll, hogy meghatározzák berendezéseinek (hardvereinek), szoftvereinek összetevőit és a rendszert üzemeltető személyzet által végzett műveleteket. 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 annak meghatározását a következő jellemzőket minden szoftverkomponenshez:

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) programfelületeinek 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ó magában foglalja 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 vizsgálatok során. 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 konvertálá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. Ahol szoftver termékekés a dokumentáció a szerződés szerint archiválás tárgyát képezi.

A szoftver életciklusa

A szoftvertervezési módszertan egyik alapfogalma a szoftver életciklusának (szoftver életciklusának) fogalma. A szoftver életciklusa egy folyamatos folyamat, amely attól a pillanattól kezdődik, amikor döntés születik a létrehozásának szükségességéről, és a teljes működésből való kivonás pillanatával ér véget.

Fő normatív dokumentum, amely a szoftver életciklusát szabályozza, az nemzetközi szabvány ISO/IEC 12207 (ISO – Nemzetközi Szabványügyi Szervezet – nemzetközi szervezet szabványosításhoz, IEC - International Electrotechnical Commission - International Electrotechnical Commission). Meghatároz egy életciklus-struktúrát, amely tartalmazza a szoftverfejlesztés során elvégzendő folyamatokat, tevékenységeket és feladatokat. Ebben a szabványban Szoftver (szoftver termék) számítógépes programok, eljárások és esetleg kapcsolódó dokumentációk és adatok összességeként határozható meg. Folyamatúgy definiálható, mint egymással összefüggő műveletek halmaza, amelyek valamilyen bemenetet outputtá alakítanak át. Minden folyamatot meghatározott feladatok és megoldási módszerek, más folyamatokból nyert kiindulási adatok és eredmények jellemeznek.

A szoftver életciklusának felépítése az ISO/IEC 12207 szabvány szerint három folyamatcsoporton alapul:

a szoftver életciklusának főbb folyamatai (beszerzés, szállítás, fejlesztés, üzemeltetés, karbantartás);

a fő folyamatok megvalósítását biztosító segédfolyamatok (dokumentáció, konfigurációkezelés, minőségbiztosítás, ellenőrzés, tanúsítás, értékelés, audit, problémamegoldás);

· szervezeti folyamatok(projektmenedzsment, projekt infrastruktúra kialakítása, magának az életciklusnak a meghatározása, értékelése és javítása, képzés).

Szoftver életciklus modellek

Életciklus modell- olyan struktúra, amely az életciklus során meghatározza a végrehajtás sorrendjét és a szakaszok és az elvégzett szakaszok kapcsolatát. Az életciklus-modell a szoftver sajátosságaitól és azon feltételek sajátosságaitól függ, amelyek között ez utóbbi létrejön és működik. A fő életciklus-modellek a következők.

1. Kaszkádmodell(a XX. század 70-es éveiig) határozza meg a szekvenciális átmenetet a következő szakaszba az előző befejezése után.

Ezt a modellt az egyedi, egymással nem összefüggő feladatok automatizálása jellemzi, amely nem igényel információintegrációt és kompatibilitást, szoftvert, műszaki és szervezeti interfészt.

Méltóság: jó teljesítmény a fejlesztési idő és az egyéni problémák megoldásának megbízhatósága tekintetében.

Hiba: nem alkalmazható nagy és összetett projektekre a rendszerkövetelmények hosszú tervezési időszakon keresztüli változatossága miatt.

2. Iteratív modell(20. század 70-80-as évei) az „alulról felfelé irányuló” tervezési technológiának felel meg. Lehetővé teszi az iteratív visszatérést az előző szakaszokhoz a következő szakasz végrehajtása után;

A modell lehetővé teszi az egyedi feladatokra kapott tervezési megoldások rendszerszintű megoldásokká történő általánosítását. Ebben az esetben szükség van a korábban megfogalmazott követelmények felülvizsgálatára.

Méltóság: a projekt gyors módosításának képessége.

Hiba: a nagy számú iterációnál megnő a tervezési idő, eltérések mutatkoznak a tervezési megoldásokban és a dokumentációban, valamint összezavarodik a létrehozott szoftver funkcionális és rendszerarchitektúrája. A régi újratervezésének vagy létrehozásának szükségessége új rendszer közvetlenül a megvalósítási vagy üzemeltetési szakasz után következhetnek be.

3. Spirálmodell(20. század 80-90-es évek) a felülről lefelé irányuló tervezési technológiának felel meg. Olyan szoftver prototípus használatát feltételezi, amely lehetővé teszi a szoftverbővítést. A rendszer kialakítása ciklikusan megismétli a követelmények specifikációjától a programkód specifikációjáig vezető utat.

A rendszer architektúrájának megtervezésekor először meghatározzák a funkcionális alrendszerek összetételét, és megoldják a rendszerszintű kérdéseket (integrált adatbázis szervezése, információgyűjtési, továbbítási és -felhalmozási technológia). Ezután egyedi feladatokat fogalmaznak meg, és kidolgozzák a megoldásukhoz szükséges technológiát.

A programozás során először a fő programmodulok kerülnek kidolgozásra, majd az egyes funkciókat ellátó modulok. Először a modulok interakcióba lépnek egymással és az adatbázissal, majd az algoritmusok megvalósítása történik meg.

Előnyök:

1. az iterációk számának, következésképpen a javítandó hibák és következetlenségek számának csökkentése;

2. tervezési idő csökkentése;

3. a projektdokumentáció elkészítésének egyszerűsítése.

Hiba: magas minőségi követelmények a rendszerszintű adattárral szemben ( közös alap tervezési adatok).

A spirálmodell az alapja gyors alkalmazásfejlesztési technológiák vagy RAD-technológia (rapid application development), amely magában foglalja a leendő rendszer végfelhasználóinak aktív részvételét a létrehozásának folyamatában. Az információs tervezés fő szakaszai a következők:

· Információs stratégia elemzése, tervezése. A felhasználók a speciális fejlesztőkkel együtt részt vesznek a problématerület azonosításában.

· Tervezés. A felhasználók a fejlesztők irányításával vesznek részt a műszaki tervezésben.

· Tervezés. A fejlesztők megtervezik a szoftver működő verzióját a 4. generációs nyelvek használatával;

· Végrehajtás. A fejlesztők megtanítják a felhasználókat az új szoftverkörnyezetben való munkára.

Rizs. 5.2.

Ezek a szempontok a következők:

1. a szerződéses szempont, amelyben a megrendelő és a szállító szerződéses kapcsolatot létesít, és megvalósítja a beszerzési és szállítási folyamatokat;
2. menedzsment szempont, amely magában foglalja a szoftver életciklusában részt vevő személyek (szállító, vevő, fejlesztő, üzemeltető stb.) irányítási tevékenységeit;
3. az üzemeltetés szempontja, amely magában foglalja az üzemeltető azon tevékenységét, amely a rendszer felhasználóinak szolgáltatást nyújt;
4. mérnöki szempont, amely tartalmazza a fejlesztő vagy támogató szolgáltatás tevékenységét a szoftvertermékek fejlesztésével vagy módosításával kapcsolatos technikai problémák megoldása érdekében;
5. a támogatási folyamatok megvalósításához kapcsolódó támogatási szempont, amelyen keresztül a támogató szolgálatok biztosítják a szükséges szolgáltatásokat a munka összes többi résztvevője számára. Ebből a szempontból kiemelhető a szoftverminőség-menedzsment szempontja, amely magában foglalja a minőségbiztosítási folyamatokat, verifikációt, tanúsítást, közös értékelést és auditot.

A szervezeti folyamatok vállalati szinten vagy a teljes szervezet egészének szintjén valósulnak meg, megalapozva a szoftver életciklus-folyamatok megvalósítását és folyamatos fejlesztését.

5.6. A szoftver életciklusának modelljei és szakaszai

A szoftver életciklus-modell alatt olyan struktúrát értünk, amely meghatározza a végrehajtás sorrendjét, valamint a folyamatok, műveletek és feladatok kapcsolatát a szoftver életciklusa során. 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.

Az ISO/IEC 12207 szabvány nem javasol konkrét életciklus-modellt és szoftverfejlesztési módszereket. Rendelkezései a szoftverfejlesztés bármely életciklus-modelljére, módszerére és technológiájára vonatkoznak. A szabvány leírja a szoftver életciklus-folyamatainak felépítését, de nem határozza meg, hogyan kell megvalósítani vagy végrehajtani az ezekben a folyamatokban foglalt tevékenységeket és feladatokat.

Bármely konkrét szoftver életciklus-modellje meghatározza létrehozásának folyamatának jellegét, amely időben rendezett, egymással összekapcsolt és szakaszokban (fázisokban) egyesített művek összessége, amelyek megvalósítása szükséges és elegendő ahhoz, hogy olyan szoftvert hozzon létre, amely megfelel a meghatározott követelményeket.

A szoftverkészítés szakasza (fázisa) a szoftverkészítési folyamat részeként értendő, amelyet bizonyos időkeret korlátoz, és egy adott termék (szoftvermodellek, szoftverkomponensek, dokumentáció stb.) kiadásával végződik, amelyet a meghatározott követelmények határoznak meg. ehhez a szakaszhoz. A szoftverkészítés szakaszait a racionális tervezés és munkaszervezés okán különítjük el, a meghatározott eredményekkel zárva. A szoftver életciklusa általában a következő szakaszokból áll:

1. szoftverkövetelmények kialakítása;
2. tervezés (rendszerprojekt kidolgozása);
3. megvalósítás (allépésekre bontható: részletes tervezés, kódolás);
4. tesztelés (bontható önálló és komplex tesztelésre és integrációra);
5. üzembe helyezés (végrehajtás);
6. üzemeltetés és karbantartás;
7. leszerelés.

Egyes szakértők egy további kezdeti szakaszt vezetnek be - megvalósíthatósági tanulmány rendszerek. Ez arra a szoftverre és hardverrendszerre vonatkozik, amelyhez a szoftvert létrehozták, megvásárolták vagy módosítják.

A szoftverkövetelmények kialakulásának szakasza az egyik legfontosabb és nagymértékben (akár döntő!) meghatározza az egész projekt sikerét. Ennek a szakasznak a kezdete egy jóváhagyott és jóváhagyott rendszerarchitektúra átvétele, amely tartalmazza a funkciók hardver és szoftver közötti elosztására vonatkozó alapvető megállapodásokat. Ennek a dokumentumnak tartalmaznia kell a szoftver működésének általános elképzelésének megerősítését is, beleértve a főbb megállapodásokat a funkciók elosztásáról a személy és a rendszer között.

A szoftverkövetelmények kialakításának szakasza a következő szakaszokat tartalmazza.

1. Tervezési munka a projekt előtt. A szakasz fő feladatai a fejlesztési célok meghatározása, előzetes gazdasági értékelés projekt, munkaterv összeállítása, közös munkacsoport létrehozása és képzése.
2. Egy automatizált szervezet (objektum) tevékenységének felmérése, melynek keretében a jövőbeni rendszer követelményeinek előzetes azonosítása, a szervezet felépítésének meghatározása, a szervezet célfunkcióinak listájának meghatározása, elemzése a funkciók osztályok és alkalmazottak szerinti megosztása, az osztályok közötti funkcionális interakciók azonosítása, az információáramlás az osztályokon belül és közöttük, az objektumok szervezésével kapcsolatos külső és a külső információs hatások, a szervezeti tevékenységek automatizálásának meglévő eszközeinek elemzése.

Egy szervezet (objektum) tevékenységi modelljének felépítése, amely biztosítja a felmérési anyagok feldolgozását és kétféle modell felépítését:

• egy "AS-IS" ("as is") modell, amely tükrözi a szervezet jelenlegi állapotát a felmérés időpontjában, és lehetővé teszi a szervezet működésének megértését, valamint a szűk keresztmetszetek azonosítását és javaslatok megfogalmazását a helyzet;
• "TO-BE" modell ("ahogy lennie kell"), amely tükrözi a szervezet munkájának új technológiáinak gondolatát.

Mindegyik modellnek tartalmaznia kell a szervezet tevékenységeinek teljes funkcionális és információs modelljét, valamint (szükség esetén) egy olyan modellt, amely leírja a szervezet viselkedésének dinamikáját. Vegye figyelembe, hogy a megépített modelleknek van független gyakorlati érték, függetlenül attól, hogy a vállalkozás fejleszteni és megvalósítani fog-e Tájékoztatási rendszer, mert felhasználhatók az alkalmazottak képzésére és a vállalkozás üzleti folyamatainak fejlesztésére.

A szoftverkövetelmények kialakítása szakaszának lezárultának eredményeként szoftverspecifikációk, funkcionális, műszaki és interfészspecifikációk születnek, amelyek teljessége, ellenőrizhetősége és megvalósíthatósága igazolt.

A tervezési szakasz a következő lépéseket tartalmazza.

1. Szoftverrendszer projekt kidolgozása. Ebben a szakaszban választ adnak a „Mit kell jövőbeli rendszer?", nevezetesen: a rendszer architektúrája, funkciói, külső működési feltételei, interfészek és a funkciók elosztása a felhasználók és a rendszer között, a szoftverrel szemben támasztott követelmények, ill. információs összetevők, az előadók összetétele és a fejlesztési ütemterv, a szoftverhibakeresési terv és a minőségellenőrzés.

   A rendszerprojekt alapját a tervezett rendszer modelljei képezik, melyek a „TO-BE” modellre épülnek. A rendszerprojekt kidolgozásának eredménye a szoftverkövetelmények jóváhagyott és megerősített specifikációja legyen: funkcionális, műszaki és interfész specifikációk, amelyek teljessége, ellenőrizhetősége és megvalósíthatósága igazolt.

2. Részletes (műszaki) projekt kidolgozása. Ebben a szakaszban kerül sor a tényleges szoftvertervezésre, beleértve a rendszerarchitektúra tervezését és a részletes tervezést. Így a válasz a következő kérdésre: "Hogyan építsünk fel egy rendszert úgy, hogy az megfeleljen a követelményeknek?"

A részletes tervezés eredménye egy ellenőrzött szoftverspecifikáció kidolgozása, amely magában foglalja:

• szoftverkomponensek hierarchiájának kialakítása, adat- és vezérlési modulok közötti interfészek;
• az egyes szoftverkomponensek specifikációja, neve, célja, feltételezések, méretek, hívási sorrend, bemeneti és kimeneti adatok, hibás kimenetek, algoritmusokés logikai áramkörök;
• fizikai és logikai adatstruktúrák kialakítása az egyes mezők szintjéig;
• a számítási erőforrások elosztási tervének kidolgozása (központi processzorok ideje, memória stb.);
• a követelmények teljességének, következetességének, megvalósíthatóságának és érvényességének ellenőrzése;
• előzetes integrációs és hibakeresési terv, használati útmutató és elfogadási tesztterv.

A részletes tervezési szakasz befejezése a végétől a végéig