Szoftverrendszerek életciklusa. Szoftver életciklus folyamatok közbenső eszköz telepítési útmutatója

A szoftver életciklusának felépítése az ISO/IEC 12207 szabványnak megfelelően három folyamatcsoporton alapul (1. ábra):

· a szoftver életciklusának főbb folyamatai (vásárlás, szállítás, fejlesztés, üzemeltetés, támogatá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).

Rizs. 1. Szoftver életciklus folyamatai.

Beszerzési folyamat(beszerzési folyamat). Cselekvésekből áll

és a szoftvert vásárló ügyfél feladatait. Ez a folyamat a következő lépéseket tartalmazza:

1) a felvásárlás kezdeményezése;

2) ajánlati 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 átvétele és befejezése.

Szállítási folyamat(szállítási folyamat). A vevőnek 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) a szállítás kezdeményezése;

2) válasz készítése az ajánlati javaslatokra;

3) a szerződés előkészítése;

4) tervezés;

5) végrehajtás és ellenőrzés;

6) ellenőrzés és értékelés;

7) a munka átadása és befejezése.

Fejlesztési folyamat(fejlesztési folyamat). Rendelkezik a fejlesztő által elvégzett intézkedésekről és feladatokról, kiterjed a szoftverek és összetevőinek meghatározott követelmények szerinti elkészítésére, ideértve a tervezési és üzemeltetési dokumentáció elkészítését, a szoftverek működőképességének és megfelelő minőségének teszteléséhez szükséges anyagok elkészítését. képzési személyzet szervezéséhez szükséges termékek, anyagok stb.

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

1) a rendszerkövetelmények elemzése;

2) rendszerarchitektúra tervezése;

3) szoftverkövetelmények elemzése;

4) szoftver architektúra tervezése;

5) részletes szoftvertervezés;

6) szoftver kódolás és tesztelés;

7) szoftverintegráció;

8) szoftver minősítési tesztelés;

9) rendszerintegráció;

10) a rendszer minősítésének tesztelése;

11) szoftver telepítés;

12) szoftver elfogadása.

Működési folyamat(működési folyamat). Az üzemeltető - a rendszert üzemeltető szervezet - intézkedéseire, feladataira terjed ki. Ez a folyamat a következő lépéseket tartalmazza:

1) működési tesztelés;

2) a rendszer működése;

3) felhasználói támogatás.

Karbantartási folyamat(karbantartási folyamat). Gondoskodik a kísérő szervezet (kísérőszolgálat) által végzett tevékenységekről, feladatokról. Ez a folyamat akkor aktiválódik, ha a szoftvertermék és a kapcsolódó dokumentáció változásait (módosításait) problémák vagy a szoftver korszerűsítésének vagy adaptálásának szükségessége okozza. Az IEEE-90 szabvány szerint a karbantartás a szoftver módosítását jelenti a hibák kijavítása, a teljesítmény javítása vagy a megváltozott működési feltételekhez való alkalmazkodás, ill.

követelményeknek. A meglévő szoftvereken végrehajtott változtatások nem sérthetik

annak integritását. A karbantartási folyamat magában foglalja a szoftver átvitelét egy másik környezetbe (migráció), és a szoftver leszerelésével ér véget.

A karbantartási folyamat a következő műveleteket foglalja magában:

1) problémák elemzése és szoftvermódosítási kérelmek;

2) szoftver módosítás;

3) ellenőrzés és átvétel;

4) szoftver átvitele másik környezetbe;

5) a szoftver leszerelése.

A segédfolyamatok csoportja a következőket tartalmazza:

Dokumentáció;

Konfiguráció-menedzsment; minőségbiztosítás;

Igazolás; tanúsítvány;

Részvételi értékelés;

Problémamegoldás.

Dokumentációs folyamat(dokumentációs folyamat). A szoftver életciklusa során keletkezett információk formalizált leírását adja. A dokumentációs folyamat a következő lépéseket tartalmazza:

1) tervezés és fejlesztés;

2) a dokumentáció kiadása;

3) dokumentációs támogatás.

Konfigurációkezelési folyamat(konfigurációkezelési folyamat). A szoftver életciklusa során adminisztratív és technikai eljárások alkalmazását foglalja magában a rendszerben lévő szoftverkomponensek állapotának meghatározására, a szoftvermódosítások kezelésére, a szoftverkomponensek állapotáról és a módosítási kérelmekről szóló jelentések leírására és elkészítésére, a teljesség, kompatibilitás és helyesség biztosítására. szoftverösszetevők, tárolás és szállítás kezelése BY. Az IEEE-90 szabvány szerint szoftverkonfiguráció alatt funkcionális és fizikai jellemzőinek összességét értjük.

a műszaki dokumentációban meghatározott és a szoftverben megvalósított jellemzőket.

A konfigurációkezelés lehetővé teszi a szoftver változásainak rendszerezését, szisztematikus figyelembevételét és ellenőrzését az életciklus minden szakaszában. A szoftverkonfiguráció kezelésének általános elveit és ajánlásait az ISO/I EC CD 12207-2: 1995 "Információs technológia – Szoftver életciklus-folyamatok. 2. rész" című szabványtervezet tartalmazza.

Configuration Management for Software". A konfigurációkezelési folyamat a következő műveleteket tartalmazza:

1) konfiguráció azonosítás;

2) konfigurációvezérlés;

3) a konfiguráció állapotának elszámolása;

4) konfiguráció értékelése;

5) kiadáskezelés és kézbesítés.

Minőségbiztosítási folyamat(minőségbiztosítási folyamat). Megfelelő biztosítékot nyújt arra, hogy a szoftver és életciklus-folyamatai megfelelnek a meghatározott követelményeknek és jóváhagyott terveknek. Szoftverminőség alatt olyan tulajdonságok összességét értjük, amelyek jellemzik a szoftver azon képességét, hogy megfeleljen a meghatározott követelményeknek. A készülő szoftver megbízható értékelése érdekében a minőségbiztosítási folyamatnak a szoftverfejlesztéshez közvetlenül kapcsolódó entitásoktól függetlenül kell történnie. Más támogató folyamatok, például ellenőrzés, érvényesítés, közös értékelés, audit és problémamegoldás eredményei felhasználhatók. A minőségbiztosítási folyamat a következő tevékenységeket foglalja magában:

1) a termékminőség biztosítása;

2) a folyamat minőségének biztosítása;

3) a rendszerminőség egyéb mutatóinak biztosítása.

Ellenőrzési folyamat(ellenőrzési folyamat). Annak megállapításából áll, hogy azok a szoftvertermékek, amelyek valamilyen művelet eredménye, teljes mértékben megfelelnek-e a korábbi műveletek által meghatározott követelményeknek vagy feltételeknek (a szűk értelemben vett ellenőrzés a szoftver helyességének formális bizonyítását jelenti).

Igazolási eljárás(érvényesítési folyamat). Ez magában foglalja a meghatározott követelmények és a létrehozott rendszer vagy szoftvertermék meghatározott funkcionális céljának való megfelelésének teljességét. A tanúsítás általában a szoftvertesztelés megbízhatóságának megerősítésére és értékelésére vonatkozik.

Részvételi értékelési folyamat(közös felülvizsgálati eljárás). Célja, hogy felmérje a projekten végzett munka és az e munkák (műveletek) végrehajtása során létrehozott szoftver állapotát. Elsősorban a projekt erőforrásai, a személyzet, a berendezések és eszközök tervezésének és irányításának ellenőrzésére összpontosít.

Ellenőrzési folyamat(auditálási folyamat). Ez a követelményeknek, terveknek és szerződési feltételeknek való megfelelés meghatározása.

Problémamegoldási folyamat(problémamegoldási folyamat). Magában foglalja a fejlesztés, üzemeltetés, karbantartás vagy egyéb folyamatok során feltárt problémák (beleértve a feltárt inkonzisztenciákat) elemzését és megoldását eredetüktől vagy forrástól függetlenül. Minden észlelt problémát azonosítani, leírni, elemezni és megoldani kell.

A szoftver életciklusának szervezeti folyamatainak csoportja a következőket tartalmazza:

Ellenőrzés;

Infrastruktúra létrehozása;

Javulás;

Új verziók kiadása;

Oktatás.

Menedzsment folyamat(menedzsment folyamat). Olyan tevékenységekből és feladatokból áll, amelyeket a folyamatait irányító bármely fél elvégezhet. Ez a fél (menedzser) felelős a termékkibocsátás kezeléséért, a projektmenedzsmentért és a kapcsolódó folyamatok feladatkezeléséért, mint például a beszerzés, szállítás, fejlesztés, üzemeltetés, karbantartás stb.

Infrastruktúra létrehozási folyamat(infrastruktúra folyamat). Tartalmazza a technológia, szabványok és eszközök kiválasztását és támogatását (karbantartását), a szoftver fejlesztéséhez, üzemeltetéséhez vagy karbantartásához használt hardverek és szoftverek kiválasztását és telepítését. Az infrastruktúrát a vonatkozó folyamatokra vonatkozó követelmények változásának megfelelően kell módosítani és karbantartani. Az infrastruktúra pedig a konfigurációkezelés egyik tárgya.

Javítási folyamat(javítási folyamat). Ez biztosítja a szoftver életciklus-folyamatainak értékelését, mérését, ellenőrzését és javítását. A szoftver életciklus-folyamatainak fejlesztése az alkalmazott technológia, a menedzsment módszerek, az eszközök kiválasztásának és a képzésnek a fejlesztésével az összes érintett szakember termelékenységének növelését célozza.

személyzet.

Tanulási folyamat(képzési folyamat). Ez magában foglalja az alapképzést és az azt követő folyamatos személyzetfejlesztést.

A tervezési módszertan céljai és célkitűzéseiÁLTAL. Fő tervezési területekÁLTAL. A teremtés szakaszaiÁLTAL.

Szoftver (Szoftver) egy intelligens termék, független attól, hogy milyen adathordozóra rögzíti, beleértve a programokat, szabályokat és a kapcsolódó adatokat, amely egy számítógépes program végrehajtási területére betöltve biztosítja annak működését.

Szoftver (Szoftvertermék) - számítógépes programok, eljárások és esetleg kapcsolódó dokumentációk és adatok összessége.

Szoftver (Szoftvertermék) - a szoftverfejlesztés eredményeként megszerzett számítógépes programok, eljárások és kapcsolódó dokumentációk és adatok bármely halmaza, amelyet a felhasználónak szállítanak [ISO/IEC 12207]. Jegyzet. A termékek közé tartoznak a közbenső termékek és a felhasználóknak, például fejlesztőknek és karbantartóknak szánt termékek.

Szoftverfejlesztés A szoftverfejlesztés egy olyan fejlesztési forma, amely a számítástechnika, az információtechnológia, a matematika és az alkalmazástudomány alapelveit alkalmazza, hogy a szoftver segítségével költséghatékony megoldásokat érjen el a gyakorlati problémákra.

Szoftver tervezés valós méretű és gyakorlati jelentőségű alkalmazások létrehozásának folyamata, amelyek megfelelnek a meghatározott funkcionalitási és teljesítménykövetelményeknek.

Programozás - ez a szoftverfejlesztési ciklus egyik tevékenysége.

A szoftverkészítés szakaszai

1. Ismerje meg a javasolt termék jellegét és alkalmazási körét.

2. Válasszon ki egy fejlesztési folyamatot, és készítsen tervet.

3. Gyűjtsd össze a követelményeket.

4. Tervezze meg és szerelje össze a terméket.

5. Végezzen terméktesztet.

6. Engedje el a terméket és támogassa.

Egy program életciklusa alatt szakaszok halmazát értjük:

A témakör elemzése és műszaki specifikációk elkészítése (interakció a megrendelővel)

A programszerkezet kialakítása

Kódolás (programkódkészlet a projektdokumentáció szerint)

Tesztelés és hibakeresés

A program megvalósítása

Program támogatás

Ártalmatlanítás

A szoftver életciklusának (LC) fogalma. Az életciklus meghatározása az ISO/IEC 12207:1995 nemzetközi szabvány szerint. Alapvető szoftver életciklus-folyamatok.

A szoftver életciklusa egy folyamatos folyamat, amely attól a pillanattól kezdődik, amikor döntés születik a létrehozás szükségességéről, és akkor ér véget, amikor teljesen kivonják a szolgáltatásból.

A szoftver életciklusa (LC) egy olyan időtartam, 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 teljesen kivonják a szolgáltatásból.

A szoftver életciklus-folyamatainak összetételét szabályozó fő szabályozó dokumentum az ISO/IEC 12207: 1995 „Information Technology – Software Life Cycle Processes” (ISO – Nemzetközi Szabványügyi Szervezet, IEC – International Electrotechnical Commission – International Commission for Standardization) nemzetközi szabvány. Elektrotechnika Meghatározza a szoftverkészítés során végrehajtandó folyamatokat, műveleteket és feladatokat tartalmazó életciklus-struktúrát.

Ebben a szabványban Szoftver (vagy szoftvertermék) Számítógépes programok, eljárások és esetleg kapcsolódó dokumentációk és adatok összességeként definiálható.

Folyamatúgy definiálható, mint egymással összefüggő műveletek halmaza (egymással összefüggő munkák halmaza), amelyek bizonyos kezdeti adatokat (bemeneti adatokat) kimenetekké (eredményekké) alakítanak át. Minden folyamatot meghatározott feladatok és megoldási módszerek, más folyamatokból nyert bemeneti adatok, eredmények jellemeznek.

Minden folyamat cselekvések sorozatára osztva, mindegyik akció– készletenként feladatokat. 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 adatok közötti kapcsolatok fenntartása mellett).

Alapvető életciklus-folyamatok :

Megrendelés (vásárlás);

Cselekvés – beszerzés kezdeményezése

Akció – ajánlati javaslatok elkészítése

Akció - a szerződés előkészítése és kiigazítása

Akció - beszállítói tevékenység felügyelete

Folyamatban elfogadás előkészítik és elvégzik a szükséges vizsgálatokat. A munka befejezése a szerződés értelmében akkor kerül sor, ha minden elfogadási feltétel teljesül

Kínálat;

Szállítás kezdeményezése

Tervezés

Fejlesztés;

A fejlesztési folyamat magában foglalja a fejlesztő által végzett tevékenységeket és feladatokat, és a következőket tartalmazza:

Előkészítő munka

Rendszerkövetelmények elemzése

Rendszer architektúra tervezés magas szinten azonosítani kell hardverének, szoftverének összetevőit és a rendszert üzemeltető személyzet által végzett műveleteket. A rendszer architektúrának meg kell felelnie a rendszerkövetelményeknek és az elfogadott tervezési szabványoknak és gyakorlatoknak.

Szoftverkövetelmények elemzése

Szoftver architektúra tervezés

Szoftver kódolás és tesztelés

Szoftver integráció

Szoftver minősítés tesztelése

Rendszerintegráció

Szoftver telepítés

Szoftver elfogadás

Kizsákmányolás; lefedi az üzemeltető - a rendszert üzemeltető szervezet - tevékenységeit, feladatait, és magában foglalja a következőket:

Előkészítő munka magában foglalja a kezelőt, aki a következő feladatokat látja el:

az üzemeltetés során végzett tevékenységek és munkák tervezése, működési normák meghatározása;

eljárások meghatározása az üzemeltetés során felmerülő problémák lokalizálására és megoldására.

Teljesítményfelmérés végrehajtása a szoftvertermék minden következő kiadása esetén történik, majd az üzembe kerül.

Rendszer működése

Felhasználói támogatás

Folyamatkíséret rendelkezik a támogató szolgálat által végzett tevékenységekről és feladatokról. alatti IEEE-90 szabványnak megfelelően kíséret a szoftver módosítására utal 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.

Előkészítő munka A támogatási szolgáltatások a következő feladatokat foglalják magukban:

a támogatási folyamat során végzett tevékenységek és munka tervezése;

eljárások meghatározása a karbantartási folyamat során felmerülő problémák lokalizálására és megoldására.

Problémák elemzése és szoftvermódosítási kérelmek

Szoftver módosítás

Ellenőrzés és átvétel

Szoftver leszerelése az ügyfél belátása szerint, az üzemeltető szervezet, a támogató szolgálat és a felhasználók részvételével történik. Ebben az esetben a szoftvertermékeket és a kapcsolódó dokumentációkat a megállapodásnak megfelelően archiválni kell.

A szoftver életciklusának (LC) fogalma. Az életciklus meghatározása az ISO/IEC 12207:1995 nemzetközi szabvány szerint. A szoftver életciklusának segédfolyamatai.

Lásd a 2. pontot

Kiegészítő életciklus-folyamatok :

Dokumentáció; a szoftver életciklusa során keletkezett információk formalizált leírása.

A dokumentációs folyamat a következő lépéseket tartalmazza:

előkészítő munka;

tervezés és fejlesztés;

dokumentáció kiadása;

kíséret

Konfiguráció-menedzsment neki; a rendszerben lévő szoftverelemek állapotának megállapítása, szoftvermódosítások kezelése, a szoftverkomponensek állapotáról és a módosítási kérelmek leírása és jelentések készítése, a szoftverek teljességének, kompatibilitásának és helyességének biztosítása, a szoftverek tárolásának és szállításának irányítása. Az IEEE - 90 szabvány szerint konfigurációt Szoftver alatt a műszaki dokumentációban meghatározott és a szoftverben megvalósított funkcionális és fizikai jellemzőinek összességét értjük.

előkészítő munka

konfiguráció azonosítása szabályokat állapít meg, amelyek segítségével egyértelműen azonosíthatók és megkülönböztethetők a szoftverkomponensek és azok verziói

konfigurációs vezérlés a javasolt szoftvermódosítások és azok összehangolt megvalósításának szisztematikus értékelésére szolgál, figyelembe véve az egyes módosítások hatékonyságát és a végrehajtás költségeit

konfigurációs állapot elszámolása (a szoftverkomponensek állapotának regisztrálását jelenti, jelentések elkészítését a szoftverkomponensek verzióinak minden végrehajtott és elutasított módosításáról). + módosítási előzmények

konfiguráció értékelése (a szoftverkomponensek funkcionális teljességének, valamint fizikai állapotának az aktuális műszaki leírásnak való megfelelőségének értékeléséből áll);

kibocsátáskezelés és ellátás (terjed a programok és dokumentáció referenciapéldányainak elkészítésére, tárolására és a felhasználókhoz való eljuttatására a szervezetben elfogadott eljárásrend szerint).

Minőségbiztosítás;

Minőségbiztosítási folyamat megfelelő garanciákat nyújt arra vonatkozóan, hogy a szoftver és életciklus-folyamatai megfelelnek a meghatározott követelményeknek és jóváhagyott terveknek. Alatt szoftver minősége Olyan tulajdonságok összessége alatt értendő, amelyek a szoftver azon képességét jellemzik, hogy megfeleljenek a meghatározott követelményeknek.

A minőségbiztosítási folyamat a következő tevékenységeket foglalja magában:

előkészítő munka

a termékminőség biztosítása, amely garantálja, hogy a szoftvertermékek és azok dokumentációja teljes mértékben megfeleljen a vevő szerződésben rögzített követelményeinek;

a szoftver életciklus-folyamatainak, a fejlesztési módszereknek, a fejlesztési környezetnek és a személyzeti képesítéseknek a szerződés feltételeinek való megfelelésének folyamatának minőségének biztosítása, biztosítva a rendszerminőség egyéb mutatóit

Igazolás; annak megállapításából áll, hogy a szoftvertermékek maradéktalanul megfelelnek-e a korábbi tevékenységek által meghatározott követelményeknek vagy feltételeknek (a szoros értelemben vett ellenőrzés a szoftver helyességének formális bizonyítását jelenti).

előkészítő munka;

igazolás;

Az ellenőrzési folyamat során a következő feltételeket ellenőrzik:

a rendszer követelményeinek következetessége és a felhasználói igények figyelembevételének mértéke;

a szállító képessége meghatározott követelmények teljesítésére;

a kiválasztott életciklus-folyamatok megfelelése a szerződés feltételeinek;

a szabványok, eljárások és fejlesztési környezet megfelelősége a szoftver életciklus-folyamatához;

a szoftvertervezési specifikációk megfelelése a meghatározott követelményeknek;

a leírás helyessége a bemeneti és kimeneti adatok tervezési specifikációiban, eseménysor, interfészek, logika;

kód megfelelés a tervezési előírásoknak és követelményeknek;

a kód tesztelhetősége és helyessége, az elfogadott kódolási szabványoknak való megfelelése;

a szoftverelemek helyes integrálása a rendszerbe;

a dokumentáció megfelelősége, teljessége és következetessége.

Tanúsítvány;

magában foglalja a meghatározott követelmények és a létrehozott rendszer vagy szoftvertermék végső funkcionális rendeltetésének való megfelelésének teljességét. A tanúsítás általában az elvégzett vizsgálatok megbízhatóságának megerősítését és értékelését jelenti. Javasoljuk, hogy a tanúsítást minden lehetséges helyzetben teszteléssel és független szakemberek bevonásával végezzék.

Részvételi értékelés(Részvételi elemzés); a projekttel és a szoftverrel kapcsolatos munka állapotának felmérésére.

Az értékelést mind a projektmenedzsment, mind a projekt műszaki megvalósításának szintjén alkalmazzák, és a szerződés teljes időtartama alatt elvégzik. Ezt a folyamatot a szerződésben részt vevő bármelyik fél elvégezheti úgy, hogy az egyik fél igazolja a másikat.

A részvételen alapuló értékelési folyamat a következő tevékenységeket tartalmazza:

előkészítő munka;

projektmenedzsment értékelése (elemzése);

műszaki értékelés.

Könyvvizsgálat;

a szerződés követelményeinek, terveinek és feltételeinek való megfelelés meghatározása. Az auditot a szerződésben érintett bármely két fél végezheti úgy, hogy az egyik fél a másikat auditálja. Az audit olyan audit (ellenőrzés), amelyet egy illetékes hatóság (személy) végez annak érdekében, hogy független értékelést adjon a szoftver vagy folyamatok meghatározott követelményeknek való megfelelésének mértékéről.

Engedély(Megoldás) problémákat.

magában foglalja a fejlesztés, üzemeltetés, karbantartás vagy egyéb folyamatok során feltárt problémák (beleértve az észlelt inkonzisztenciákat is) elemzését és megoldását eredetüktől vagy forrástól függetlenül. Minden észlelt problémát azonosítani, leírni, elemezni és megoldani kell.

A szoftver életciklusának (LC) fogalma. Az életciklus meghatározása az ISO/IEC 12207:1995 nemzetközi szabvány szerint. A szoftver életciklusának szervezeti folyamatai. A szoftver életciklus-folyamatai közötti kapcsolat.

Lásd a 2. pontot

Szervezeti életciklus folyamatok :

Ellenőrzés;

tevékenységekből (általános tevékenységekből) és feladatokból áll, amelyeket bármely, erőforrásait kezelő fél elláthat. Ez a fél (menedzser) felelős a termékkibocsátás kezeléséért, a projektmenedzsmentért és a kapcsolódó folyamatok feladatkezeléséért, mint például a beszerzés, szállítás, fejlesztés, üzemeltetés, karbantartás stb. Például egy adminisztrátor felelős a projektmenedzsmentért, szállításért, fejlesztésért, üzemeltetésért, karbantartásért stb.

Az irányítási folyamat a következő műveleteket tartalmazza:

kezelési terület előkészítése és meghatározása . A vezetőnek gondoskodnia kell arról, hogy a gazdálkodáshoz szükséges erőforrások (személyzet, berendezések és technológia) megfelelő mennyiségben a rendelkezésére álljanak;

tervezés magában foglalja legalább a következő feladatok elvégzését:

munkarend összeállítása;

költségbecslés;

a szükséges erőforrások elosztása;

a felelősség megosztása;

konkrét feladatokkal kapcsolatos kockázatok felmérése;

menedzsment infrastruktúra létrehozása.

végrehajtás és ellenőrzés;

ellenőrzés és értékelés;

befejezése.

Infrastruktúra létrehozása;

kiterjed a szoftver fejlesztéséhez, üzemeltetéséhez vagy karbantartásához használt hardverek és szoftverek kiválasztására és támogatására (technológiai támogatás), szabványokra és eszközökre, valamint a hardver és szoftver kiválasztására és telepítésére. Az infrastruktúrát a vonatkozó folyamatokra vonatkozó követelmények változásának megfelelően kell módosítani és karbantartani. Az infrastruktúra pedig a konfigurációkezelés egyik tárgya.

Javulás;

biztosítja a szoftver életciklus-folyamatainak értékelését, mérését, ellenőrzését és javítását.

Oktatás.

kiterjed az alapképzésre és az azt követő folyamatos személyzetfejlesztésre.

A szoftver életciklus-folyamatai közötti kapcsolat

Az ISO/IEC 12207 szabvány által szabályozott szoftver életciklus-folyamatait a különböző szervezetek különféle módon használhatják konkrét projektekben. A szabvány azonban különféle szempontokból kínál néhány alapvető kapcsolatrendszert a folyamatok között (1. ábra). Ezek a szempontok a következők:

szerződéses szempont;

menedzsment szempont;

működési szempont;

mérnöki szempont;

támogatási szempont.

BAN BEN szerződéses szempont A megrendelő és a szállító szerződéses kapcsolatot létesít, és ennek megfelelően hajtja végre a beszerzési és szállítási folyamatokat. BAN BEN menedzsment szempont a vevő, a szállító, a fejlesztő, az üzemeltető, a támogató szolgálat és a szoftver életciklusában érintett egyéb felek irányítják folyamataik végrehajtását. BAN BEN működési szempont a rendszert üzemeltető üzemeltető biztosítja a felhasználók számára a szükséges szolgáltatásokat. BAN BEN mérnöki szempont egy fejlesztő vagy támogatási szolgáltatás szoftvertermékek fejlesztésével vagy módosításával oldja meg a vonatkozó műszaki problémákat. BAN BEN támogatási szempont a segédfolyamatokat megvalósító szolgáltatások biztosítják a szükséges szolgáltatásokat a munka összes többi résztvevője számára.

A szabványban leírt folyamatok közötti kapcsolatok az statikus karakter . Fontosabb dinamikus kapcsolatok folyamatok és az azokat megvalósító felek között valós projektekben jönnek létre.

A szoftver életciklusának modelljének és szakaszának fogalma. Szoftverkészítési szakaszok jellemzői.

1) Nemzetközi szabvány ISO/ IEC 12207: 1995 Az életciklus-modell így határozza meg:

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

2) GOST R ISO/IEC 12207-99 Az életciklus-modell így határozza meg:

Az életciklus-modell folyamatokból, munkákból és feladatokból álló struktúra, amely magában foglalja egy szoftvertermék fejlesztését, üzemeltetését és karbantartását, és lefedi a rendszer élettartamát a követelmények megállapításától a használat végéig.

Alatt színpad Szoftverkészítés alatt a szoftverkészítési folyamat egy bizonyos időkeretben meghatározott részét értjük, amely egy adott termék (szoftvermodellek, szoftverkomponensek, dokumentáció) kiadásával végződik, és amelyet az erre a szakaszra meghatározott követelmények határoznak meg. A szoftverkészítés szakaszait a racionális tervezés és a meghatározott eredménnyel záruló munkaszervezés okán különböztetjük meg.

A szoftver életciklusa általában a következő állomásokat tartalmazza:

Szoftverkövetelmények kialakítása.

Tervezés.

Végrehajtás.

Tesztelés.

Üzembe helyezés.

Üzemeltetés és karbantartás.

Leszerelés.

A szoftver életciklus-modell fogalma. A szoftver életciklusának vízesés (kaszkád) modellje.

Lásd az 5. pontot

Az eredeti homogén IS-ben minden alkalmazás egyetlen egész volt. Az ilyen típusú alkalmazás kifejlesztéséhez a vízesés módszert alkalmazták. Fő jellemzője a teljes fejlesztés szakaszokra bontása, és az egyik szakaszból a másikba való átmenet csak az aktuális munka teljes befejezése után következik be (2. ábra). Minden szakasz a teljes dokumentáció kiadásával zárul, amely elegendő ahhoz, hogy a fejlesztést a következő szakaszban egy szakembercsoport folytathassa.

A kaszkád módszer használatának előnyei :

minden szakaszban teljes tervdokumentáció készül, amely megfelel a teljesség és a következetesség követelményeinek;

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.

A kaszkád megközelítés jól bevált az információs rendszerek felépítésében, 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 biztosítsanak a lehető legjobb műszaki megvalósításban. .

Ugyanakkor ennek a megközelítésnek számos hátránya is van, amelyek elsősorban abból fakadnak, hogy a szoftverkészítés tényleges folyamata soha nem illeszkedik teljesen egy ilyen merev sémába. A szoftver létrehozásának folyamata általában iteratív jelleg : A következő szakasz eredményei gyakran okoznak változást az előző szakaszokban kidolgozott tervezési megoldásokban. Így folyamatosan szükség van a korábbi szakaszokhoz való visszatérésre és a korábban meghozott döntések pontosítására vagy felülvizsgálatára. Ennek eredményeként a valódi szoftverkészítés folyamata más formát ölt (2. ábra).

Jelentős késés az eredmények elérésében. Az eredmények egyeztetése a felhasználókkal csak az egyes munkaszakaszok befejezése után tervezett pontokon történik, az IS-re vonatkozó követelményeket műszaki előírások formájában „befagyasztják” a létrehozásának teljes idejére. Így a felhasználók csak a rendszeren végzett munka befejezése után tehetik meg észrevételeiket. Ha a követelmények pontatlanul vannak megfogalmazva, vagy a szoftverfejlesztés hosszú ideje alatt változnak, akkor a felhasználók olyan rendszerhez jutnak, amely nem felel meg az igényeiknek. Az automatizált objektum modelljei (mind funkcionális, mind információs) jóváhagyásukkal egyidejűleg elavulhatnak.

A szoftver életciklus-modell fogalma.Gyors alkalmazásfejlesztési modell. Lásd az 5. bekezdést

Az alkalmazásszoftverek fejlesztésének egyik lehetséges megközelítése a spirális életciklus modell keretein belül az úgynevezett rapid alkalmazásfejlesztés, vagy RAD (Rapid Application Development) széles körben alkalmazott módszere. A RAD három összetevőből áll:

fejlesztők kis csoportjai (3-7 fő), akik az egyes szoftveralrendszerek tervezésén dolgoznak. Ennek oka a csapat maximális irányíthatóságának követelménye;

rövid, de gondosan kidolgozott gyártási ütemterv (legfeljebb 3 hónap);

iteratív ciklus, amelyben a fejlesztők, amint az alkalmazás elkezd formát ölteni, lekérik és beépítik a termékbe az ügyféllel való interakció során elért követelményeket.

A fejlesztőcsapatnak olyan szakemberekből kell állnia, akik tapasztalattal rendelkeznek a szoftvertervezés, -programozás és -tesztelés terén, és képesek jól együttműködni a végfelhasználóval, és javaslataikat működő prototípusokká alakítani.

A következőket különböztetik meg: a RAD fejlesztési folyamat szakaszaiban :

Üzleti modellezés . Az üzleti funkciók közötti információáramlás modellezésre kerül.

Adatmodellezés . Egy információáramlás adatobjektumok halmazára van leképezve.

Feldolgozás szimuláció . Az adatobjektumok átalakításait az üzleti funkciók megvalósításának biztosítása érdekében határozzák meg.

Alkalmazásgenerálás . 4. generációs programozási nyelveket és kész komponenseket használnak az automatizálási segédprogram felépítéséhez.

Tesztelés és összevonás . Az újrafelhasználható alkatrészek használata csökkenti a tesztelési időt.

Az egyes fő funkciókat egy külön fejlesztői csoport párhuzamosan, legfeljebb 3 hónapig fejleszti, majd integrálja a teljes rendszerbe.

A használat hátrányai RAD :

A nagy projektek jelentős humánerőforrást igényelnek a csapatok létrehozásához.

A modell csak azokra a rendszerekre alkalmazható, amelyek külön modulokra bonthatók, és amelyekben a teljesítmény nem kritikus érték.

Nem alkalmazható magas műszaki kockázatú körülmények között, pl. új technológia alkalmazásakor.

A szoftver életciklus-modell fogalma. V alakú szoftver életciklus modell.

A V-alakú életciklus modell azért jött létre, hogy segítse a projektcsapatot a rendszer további tesztelésének tervezésében. Ez a modell különös hangsúlyt fektet a termék ellenőrzésére és érvényesítésére irányuló tevékenységekre. Bemutatja, hogy a terméktesztelést a fejlesztési életciklus korai szakaszában tárgyalják, tervezik és tervezik.

A tervezési fázisban vevői átvételi tesztterv, az elemzési, tervezési fejlesztési stb. fázisban pedig rendszerelrendezési tesztterv készül. A teszttervek elkészítésének ezt a folyamatát a V alakú modell téglalapjai közötti pontozott vonal jelzi.

A V alakú modellt a kaszkádmodell variációjaként fejlesztették ki, ezért ugyanazt a szekvenciális struktúrát örökölte tőle. Minden következő fázis az előző fázis eredményeinek megszerzése után kezdődik.

A modell integrált megközelítést mutat be a szoftverfejlesztési folyamat fázisainak meghatározására. Kiemeli azokat a kapcsolatokat, amelyek a kódolást megelőző elemzési és tervezési fázisok között léteznek, majd a tesztelési fázisok következnek. A szaggatott vonalak azt jelzik, hogy ezeket a fázisokat párhuzamosan kell figyelembe venni.

Rizs. . V-életciklus modell

Az alábbiakban röviden ismertetjük a V-modell egyes fázisait, a projekttervezéstől és a követelményektől az átvételi tesztelésig:

projekt és követelménytervezés – meghatározzák a rendszerkövetelményeket, valamint azt, hogy a szervezet erőforrásait hogyan osztják fel a követelmények teljesítéséhez (szükség esetén ebben a fázisban határozzák meg a hardver és szoftver funkciókat);

termékkövetelmények és specifikációk elemzése – a jelenleg fennálló szoftverprobléma elemzése a létrehozott szoftverrendszer várható külső viselkedésének teljes specifikációjával zárul;

építészet vagy tervezés a legmagasabb szinten – meghatározza, hogy a projekt megvalósítása során hogyan kell a szoftver funkcióit felhasználni;

részletes projektfejlesztés – meghatározza és dokumentálja az algoritmusokat az architektúra fázisában definiált egyes összetevőkhöz. Ezeket az algoritmusokat később kódokká alakítják;

programkód fejlesztés – a részletes tervezési szakaszban meghatározott algoritmusokat kész szoftverré konvertálják;

egység tesztelése – minden kódolt modul hibakeresése megtörténik;

integráció és tesztelés – kapcsolatok létrehozása a korábban elemenként tesztelt modulok csoportjai között annak igazolására, hogy ezek a csoportok, valamint az egymástól függetlenül tesztelt modulok is teljesítenek az elemenkénti tesztelési szakaszban;

rendszer és átvételi tesztelés – a szoftverrendszer egészének (teljesen integrált rendszer) működésének ellenőrzése megtörténik, miután a szoftverkövetelmény-specifikációnak megfelelően a hardverkörnyezetébe került;

gyártás, üzemeltetés és támogatás – a szoftver gyártásba kerül. Ez a szakasz magában foglalja a korszerűsítést és a módosításokat is;

átvételi tesztek (az ábrán nem látható) – lehetővé teszi a felhasználó számára, hogy tesztelje a rendszer működőképességét a kezdeti követelményeknek való megfelelés érdekében. A végső tesztelés után a szoftver és a környező hardver működőképessé válik. Ezt követően a rendszer karbantartása történik.

előnyei:

A modell különös hangsúlyt fektet a tervezésre, amelynek célja a fejlesztés alatt álló termék ellenőrzése és tanúsítása a fejlesztés korai szakaszában. Az egységtesztelési szakasz érvényesíti a részletes tervet. Az integrációs és tesztelési fázisok a legmagasabb szinten valósítják meg az építészeti tervezést vagy tervezést. A rendszertesztelési szakasz megerősíti, hogy a termékkövetelmények szakasza és specifikációi megfelelően befejeződtek;

a modell biztosítja az összes beérkezett külső és belső adat hitelesítését és ellenőrzését, nem csak magának a szoftverterméknek;

a V-modellben a követelmények meghatározása a rendszertervezés, a szoftvertervezés a komponensfejlesztés előtt történik;

a modell meghatározza azokat a termékeket, amelyeket a fejlesztési folyamat eredményeként meg kell szerezni, és minden kapott adatot tesztelni kell;

a modellnek köszönhetően a projektmenedzserek nyomon követhetik a fejlesztési folyamat előrehaladását, hiszen ebben az esetben teljesen lehetséges egy idővonal használata, és az egyes fázisok befejezése mérföldkő;

A modell könnyen használható (a projekthez képest, amelyre alkalmas).

hibákat:

segítségével nem könnyű megbirkózni a párhuzamos eseményekkel;

nem veszi figyelembe a fázisok közötti iterációkat;

a modell nem írja elő a dinamikus változásokra vonatkozó követelmények bevezetését az életciklus különböző szakaszaiban;

az életciklus követelményeinek tesztelése túl későn történik, aminek következtében a projekt ütemezésének befolyásolása nélkül nem lehet változtatásokat végrehajtani;

A modell nem tartalmaz kockázatelemzést célzó intézkedéseket.

E hiányosságok kiküszöbölése érdekében a V-alakú modell módosítható úgy, hogy iteratív ciklusokat tartalmazzon, amelyek az elemzési fázison kívüli követelmények változásainak megoldására szolgálnak.

Elődjéhez, a vízesés modellhez hasonlóan a V-alakú modell is akkor működik a legjobban, ha az összes követelményinformáció előre rendelkezésre áll. A V-modell gyakori módosítása a hiányosságok kiküszöbölése érdekében az iteratív hurkok bevezetése a követelmények változásainak az elemzési fázison kívüli megoldására.

A modell alkalmazása akkor eredményes, ha rendelkezésre állnak információk a megoldás megvalósításának módjáról és a technológiáról, és a munkatársak rendelkeznek a technológiával való munkavégzéshez szükséges ismeretekkel és tapasztalattal.

A V-alakú modell kiváló választás olyan rendszerekhez, amelyek nagy megbízhatóságot igényelnek, mint például a klinikai betegfigyelő alkalmazások és az autók légzsákvezérlőinek beágyazott szoftverei.

A szoftver életciklus-modell fogalma. A szoftver életciklusának Boehm-féle spirálmodellje.

Spirál modell - az evolúciós tervezési stratégia alkalmazásának klasszikus példája. A spirálmodell (Barry Boehm, 1988) a klasszikus életciklus és prototípusgyártás legjobb tulajdonságain alapul, amelyhez egy új elem is hozzáadódik - a korábban hiányzó kockázatelemzés.

ábrán látható módon. A 3. ábrán a modell négy cselekvést határoz meg, amelyeket a hélix négy kvadránsa képvisel:

Tervezés - célok, lehetőségek és korlátok meghatározása.

Kockázatelemzés - opciók elemzése és kockázatfelismerés/kiválasztás.

Tervezés - egy következő szintű termék fejlesztése.

Értékelés - az ügyfél értékelése az aktuális tervezési eredményekről.

A spirálmodell integráló aspektusa nyilvánvaló, ha figyelembe vesszük a spirál radiális dimenzióját. Minden egyes spirális iterációval (a központtól a perifériáig haladva) a szoftver egyre teljesebb verziói készülnek.

IEEE International Standard Std 830-1993. Útmutató a szoftverkövetelmények specifikációinak kidolgozásához.

1993. december 2-án hagyta jóvá az IEEE Szabványügyi Bizottsága

Összegzés: Leírjuk a jó szoftverkövetelmény-specifikáció (SRS) tartalmát és minőségét, és bemutatunk több különböző minta SRS-tervet. Ezek az irányelvek nemcsak a fejlesztés alatt álló szoftverrel szemben támasztott követelmények meghatározását célozzák, hanem a meglévő belső és kereskedelmi szoftvertermékek kiválasztásánál is alkalmazhatók.

Kulcsszavak: szerződés, ügyfél, prototípus, szoftverkövetelmény specifikáció, szállító, rendszerkövetelmény specifikáció

Bevezetés

(A Bevezetés nem része az IEEE Std 830-1993 Útmutató a szoftverkövetelmény-specifikációk kidolgozásához.) Ez a dokumentum a szoftverkövetelmény-specifikáció létrehozásához javasolt módszereket írja le. Olyan modellen alapul, amelyben a szoftverkövetelmény-specifikációs folyamat kimenete egy egyértelmű és teljes specifikációs dokumentum. Ennek segítenie kell

a) Írja le a szoftverklienseknek, hogy pontosan mit szeretnének kapni

b) A szoftverszolgáltatók pontosan tudják, mit akar az ügyfél

c) Az egyének teljesítik a következő célokat:

1) Egy szabványos szoftverkövetelmény-specifikációs keretrendszer kidolgozása saját szervezeteik számára

2) Határozza meg saját szoftverkövetelmény-specifikációinak formátumát és tartalmát

3) Tartalmazzon további követelményeket, például minőségi ellenőrző listát vagy írói kézikönyvet.

A jó specifikációknak számos külön előnyt kell biztosítaniuk az ügyfelek, beszállítók és mások számára, például:

a) Hozzon létre megállapodást a vásárlók és a beszállítók között arról, hogy mit kell tennie a szoftvernek. Az SRS-ben meghatározott szoftver által ellátandó funkciók teljes leírása segít a potenciális felhasználónak eldönteni, hogy a szoftver megfelel-e az igényeinek, vagy hogyan kell a szoftvert módosítani az igényeinek kielégítésére.

b) Csökkentse a fejlesztési erőfeszítéseket. Az SRS elkészítése arra kényszeríti az ügyfélszervezet különböző érdekelt csoportjait, hogy szigorúan mérlegeljenek minden követelményt a tervezési fejlesztés megkezdése előtt, és csökkenti a későbbi újratervezési, újrakódolási és újratesztelési munkák mennyiségét. Az SRS követelményeinek gondos áttekintése kihagyásokat, félreértéseket és következetlenségeket tárhat fel a fejlesztés korai szakaszában, amikor ezek a problémák könnyebben javíthatók.

c) Adjon alapot a költségbecslésekhez és az ütemezéshez. A fejlesztendő termék SRS-ben meghatározott leírása reális alapot ad a projektköltségek becsléséhez, és felhasználható javaslatok egyeztetésére vagy költségbecslésre.

d) Adjon alapot a teszteléshez és ellenőrzéshez. A szervezetek sokkal hatékonyabban dolgozhatják ki saját vizsgálati és ellenőrzési terveiket, ha jó SRS-t alkalmaznak. A fejlesztési szerződés részeként az SRS keretet ad, amelyhez mérhető a megfelelés.

e) Az áthelyezés megkönnyítése. Az STP-k megkönnyítik a szoftvertermékek új felhasználókhoz való átvitelét vagy új gépekre történő telepítését. Ez megkönnyíti az ügyfelek számára a szoftverek átvitelét szervezetük más részeire, a beszállítók pedig könnyebben továbbíthatják a szoftvereket új ügyfeleknek.

f) Adjon alapot a fejlesztéshez. Mivel az SRS a terméket írja le, de a fejlesztés alatt álló projektet nem, az SRS a késztermék további fejlesztésének alapjául szolgálhat. Az SRS változhat, de ez biztosítja az alapot a folyamatos gyártásértékeléshez.

1. Áttekintés

A szabvány a szoftverkövetelmény-specifikációk létrehozásának megközelítéseit írja le. A szakasznak öt pontja van.

Az 1. pont ismerteti ennek a szabványnak a lehetőségeit.

A 3. szakasz tartalmazza a használt meghatározásokat.

A 4. pont biztosítja az SRS kidolgozásának információs alapját.

Az 5. bekezdés az SRS minden lényeges részét tárgyalja.

A szabványnak vannak olyan függelékei is, amelyek alternatív sablonokat kínálnak az SRS formátumokhoz.

1.1 képességek (hatókör)

Útmutatást ad a szoftverkövetelmény-specifikációk létrehozásához. Leírja egy jó szoftverkövetelmény-specifikáció (SRS) tartalmát és attribútumait, és bemutat néhány minta SRS-tervet.

Ezen irányelvek célja a készülő szoftver követelményeinek meghatározása. Használható belső és kereskedelmi szoftvertermékek kiválasztásában is. Azonban ezeknek az irányelveknek a már létrehozott szoftverekre történő alkalmazása kontraproduktív lehet.

Ha szoftvert építenek be egy nagy rendszerbe, például egy orvosi eszközbe, olyan problémák merülhetnek fel, amelyek kívül esnek ezen szabvány hatályán.

A szabvány leírja a termék létrehozásának folyamatát és a termék tartalmát. Termék - szoftverkövetelmény specifikáció. Egy szabvány közvetlenül használható szoftverkövetelmény-specifikáció létrehozására, vagy modellként használható egy konkrétabb szabvány meghatározásához.

A szabvány nem határoz meg semmilyen speciális módszert, terminológiát (nómenklatúrát) vagy eszközt az STS elkészítéséhez.

2 Hivatkozások

ASTM 1340-90, Standard Guide for Rapid Prototyping of Computerized Systems

IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology (ANSI).

IEEE Std 730-1989, IEEE szabvány a szoftverminőség-biztosítási tervekhez (ANSI).

IEEE Std 828-1990, IEEE szabvány a szoftverkonfiguráció kezelési tervekhez (ANSI).

IEEE Std 982.1-1988, IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).

IEEE Std 982.2-1988, IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software (ANSI).

IEEE Std 983-1986, IEEE Guide to Software Quality Assurance Planning.

IEEE Std 1002-1987, IEEE Standard Taxonomy for Software Engineering Standards (ANSI).

IEEE Std 1012-1986, IEEE szabvány a szoftverellenőrzési és érvényesítési tervekhez (ANSI).

IEEE Std 1016-1987, IEEE ajánlott gyakorlat szoftvertervezési leírásokhoz (ANSI).

IEEE Std 1028-1988, IEEE Szoftver-felülvizsgálati és auditálási szabvány (ANSI).

IEEE Std 1042-1987, IEEE Guide to Software Configuration Management (ANSI).

IEEE Std 1058.1-1987, IEEE szabvány a projektmenedzsment tervekhez (ANSI).

IEEE Std 1074-1991, IEEE Standard for Developing Software Life Cycle Processes (ANSI).

3 Definíciók

Általánosságban elmondható, hogy a jelen dokumentumban használt kifejezések definíciói megfelelnek az IEEE Std 610.12-1990.5 szabványban szereplő definícióknak. A kulcsfogalmakat az alábbiakban a jelen dokumentumban használt módon határozzuk meg.

3.1 Szerződés.

Jogilag kötelező érvényű dokumentum, amelyben az ügyfél és a szállító megállapodott. Tartalmazza a termék műszaki és szervezési követelményeit, költségét és ütemezését. A szerződés informális, de hasznos információkat is tartalmazhat, például az érintett felek kötelezettségeit vagy elvárásait.

3.2 Ügyfél.

A termékért fizető személy vagy személyek általában (de nem feltétlenül) meghatározzák a követelményeket. E dokumentum alkalmazásában a vevő és a szállító ugyanannak a szervezetnek a tagjai lehetnek.

3.3 Szállító.

Az a személy vagy emberek, akik terméket állítanak elő a vásárló számára. E dokumentum alkalmazásában ugyanannak a szervezetnek a tagjai lehetnek.

3.4 Felhasználó

Az a személy vagy személyek, akik közvetlenül a termékkel dolgoznak, vagy azzal kapcsolatba lépnek. A felhasználó(k) és az ügyfél(ek) gyakran nem ugyanaz(ok) a személy(ek).

4 Szempontok egy jó SRS előállításához

Ez a bekezdés az SRS fejlesztésének információs alapját adja. A következőket tartalmazza:

a) Az SST lényege

b) STS kontextus

c) A jó SST-k jellemzői

d) SST-k közös képzése

e) Az SRS megváltoztatásának folyamata

f) Prototípuskészítés

g) A projekt felvétele az STS-be

h) Tervezési követelmények beépítése az SRS-be

4.1 Az SRS jellege

STP - műszaki specifikáció egy különálló szoftvertermékhez, programhoz vagy programkészlethez, amely meghatározott feladatokat hajt végre egy adott környezetben. Az SRS-t egy vagy több szállító képviselője, egy vagy több ügyfél képviselője vagy mindkettő létrehozhatja. A 4.4. pont a beszállító és a megrendelő képviselőinek részvételével történő fejlesztést javasol.

A főbb kérdések, amelyeket az SSS fejlesztőjének figyelembe kell vennie:

a) Funkcionalitás. Mit kell tennie a programnak?

b) Külső interfészek. Hogyan lép kapcsolatba a szoftver az emberekkel, a rendszerhardverrel, az egyéb hardverekkel és más szoftverekkel?

c) Termelékenység. Mi a különböző szoftverfunkciók sebessége, elérhetősége, válaszideje, helyreállítási ideje stb.?

d) Tulajdonságok. Mi a hordozhatóság, helyesség, karbantarthatóság, biztonság stb.?

e) A megvalósításra vonatkozó tervezési korlátok. Bármilyen meglévő szabványkövetelmény, futásidejű nyelv, adatbázis-integritási szabályzat, erőforrás-korlátozások, futási környezet(ek) stb.?

Az SRS-fejlesztőknek kerülniük kell, hogy fejlesztési vagy projektkövetelményeket helyezzenek el az SRS-ben.

4.2 Az SRS kontextusa

Fontos figyelembe venni, hogy az SST milyen szerepet játszik az átfogó projekttervben, az IEEE Std 610.12-1990 szabványban meghatározottak szerint. A szoftver tartalmazhatja egy projekt lényegében az összes funkcióját, vagy része lehet egy nagyobb rendszernek. Ez utóbbi esetben általában létezik egy SRS, amely meghatározza a rendszer és a szoftver közötti interfészeket, és követelményeket tartalmaz az adott szoftver jellemzőire és funkcionalitására vonatkozóan. Természetesen az SST-t ebben az esetben rendszerszintű követelményekkel kell összehangolni és bővíteni.

Az IEEE Std 1074-1991 leírja a szoftver életciklusának szakaszait és az egyes szakaszokhoz tartozó megfelelő bemeneteket. Más szabványok, például a 2. szakaszban felsoroltak, a szoftver életciklusának más szakaszaira vonatkoznak, és kiegészíthetik a szoftverkövetelményeket.

Mivel az SSP-k különleges szerepet játszanak a szoftverfejlesztési folyamatban, az SSP szerző(k)nek ügyelniük kell arra, hogy ne lépjék túl e szerep határait. Ez azt jelenti, hogy az STPO

a) Pontosan azonosítania kell az összes szoftverkövetelményt. A szoftverigényeket a megoldandó probléma természete vagy a projekt speciális jellemzői határozzák meg.

b) Nem írhat le semmilyen tervezési vagy kivitelezési részletet. Ezeket a projektfejlesztési szakaszban le kell írni.

c) Nem írhat elő további korlátozásokat a szoftverre. Helyes, ha más dokumentumokban, például a minőségbiztosítási tervben is meghatározásra kerülnek. Ezért helyes, ha a létrehozott SST-k korlátozzák a tervezés hatókörét, de nem határoznak meg semmilyen tervezési részletet.

4.3 A jó SRS jellemzői

Az STP-nek a következő jellemzőkkel kell rendelkeznie

d) Helyes

e) Egyértelmű

g) Soros

h) Fontosság és/vagy stabilitás szempontjából minősített

i) Ellenőrizhető

j) Módosítható

k) Nyomon követhető

4.3.1 Helyes

Az SRS-ek akkor és csak akkor helyesek, ha minden bennük szereplő követelménynek teljesülnie kell a szoftverben. Nincs olyan eszköz vagy eljárás, amely meghatározná a helyességet. Az SRS-t össze kell hasonlítani bármely releváns magasabb szintű specifikációval, mint például a rendszerkövetelmény-specifikáció, más tervezési dokumentumok és egyéb vonatkozó szabványok a megfelelőség biztosítása érdekében. Ezenkívül az ügyfél vagy a felhasználó meghatározhatja, hogy az SRS pontosan tükrözi-e a tényleges igényeket. A nyomon követhetőség megkönnyíti ezt az eljárást és kevésbé teszi ki a hibákat (lásd 4.3.8).

4.3.2 Egyértelmű

Az SRS-ek akkor és csak akkor következetesek, ha minden kijelentésnek csak egy értelmezése van. Legalább a végtermék minden jellemzőjét egyetlen egyedi kifejezéssel kell leírni. Azokban az esetekben, amikor egy adott szövegkörnyezetben használt kifejezésnek több jelentése is lehet, fel kell venni egy szószedetbe, ahol a jelentését pontosítják.

Az SST-k a szoftver életciklusának fontos részét képezik, és az IEEE Std 1074-1991 szabványban leírtak szerint tervezésben, megvalósításban, projektvezérlésben, ellenőrzésben, tesztelésben és oktatásban használatosak. Az SRS-t egyértelműen kell értelmezni mind az SRS-t létrehozóknak, mind a használóknak. Azonban ezek a csoportok gyakran nem rendelkeznek azonos képzettséggel, ezért hajlamosak a szoftverkövetelmények eltérő értelmezésére. Azok az ábrázolások, amelyek javítják a fejlesztő követelmény-specifikációját, kontraproduktívak lehetnek a felhasználó számára, és fordítva.

4.3.2.1 A természetes nyelv buktatói

A követelményeket gyakran természetes nyelven írják le (például angolul). A természetes nyelv eredendően kétértelmű. A természetes nyelv kétértelmű használatának azonosítása érdekében az SRS-t egy független félnek felül kell vizsgálnia, hogy az esetlegesen feltárt kétértelműségeket kijavítsa.

4.3.2.2 Követelmények specifikációs nyelvei

A természetes nyelvben rejlő kétértelműség elkerülésének egyik módja az, hogy az SRS-t speciális követelmények specifikációs nyelven írjuk. A nyelvi processzorok automatikusan felismernek számos lexikai, szintaktikai és szemantikai hibát.

Az ilyen nyelveknek vannak hátrányai. Időbe telik elsajátítani őket, és sok felhasználó zavarónak találja őket. Ezenkívül ezek a nyelvek a legalkalmasabbak bizonyos követelmények kifejezésére, és bizonyos típusú rendszerekhez kapcsolódnak. Így közvetetten befolyásolhatják a követelményeket.

4.3.2.3. Képviseleti eszközök.

Általánosságban elmondható, hogy a követelmények, nyelvek és az ezeket támogató eszközök létrehozásának módszerei három általános kategóriába sorolhatók - objektumok, folyamatok, viselkedés. Az objektum-orientált megközelítések a valós objektumok, attribútumuk és az objektumok által végzett szolgáltatások szerint vannak szervezve. A folyamat alapú megközelítések a követelményeket olyan funkciók hierarchiájába rendezik, amelyek adatfolyamokon keresztül kapcsolódnak egymáshoz. A viselkedési megközelítések egy rendszer külső viselkedését valamilyen absztrakt fogalom (például megszámlálható predikátum), matematikai függvények vagy állapotgép segítségével írják le.

Az, hogy az ilyen eszközök és technikák mennyire hasznosak az STS létrehozásában, a program méretétől és összetettségétől függ. Itt nem teszünk kísérletet konkrét eszköz leírására vagy ajánlására.

E megközelítések bármelyikének alkalmazásakor jobb, ha a leírásokat természetes nyelven tartjuk. Ugyanakkor azok az ügyfelek, akik nem ismerik a nyelv jelölését, megértik az STPO-t.

4.3.3 Teljes

Az SRS-ek akkor és csak akkor teljesek, ha a következő elemeket tartalmazzák:

a) A funkcionalitásra, teljesítményre, tervezési korlátokra, teljesítményre vagy külső interfészekre vonatkozó összes alapvető követelmény. Különösen a rendszerspecifikáció által támasztott külső követelményeket kell azonosítani és figyelembe venni.

b) A szoftver minden reakciója minden lehetséges bemeneti adattípusra, minden lehetséges helyzetben. Fontos, hogy mind az érvényes, mind az érvénytelen adatértékekre reagáljanak.

4.3.3.1 TBD-k használata

A „meghatározandó” (TBD) kifejezést használó STR-ek nem teljesek, azonban néha szükségesek, és a következőket kell csatolni.

a) Azon feltételek leírása, amelyek a „meghatározandó” kifejezést eredményezik (például miért nem ismert a válasz), hogy a helyzet megoldható legyen.

b) Annak leírása, hogy mit kell tenni a „meghatározandó” kifejezés megszüntetése érdekében, ki a felelős az eltávolításért, mikor kell az eltávolítást elvégezni.

4.3.4 Következetes

Az integritás a belső integritásra utal. Ha az SRS ellentmond a magasabb szintű dokumentumoknak, például a rendszerkövetelmény-specifikációnak, akkor ez hibás (lásd 4.3.1).

4.3.4.1 Belső konzisztencia

Az SRS-ek akkor és csak akkor belsőleg konzisztensek, ha nincsenek az SRS-ekben leírt egyedi követelményeknek egymással ellentétes részhalmazai. Az STS-ben háromféle lehetséges konfliktus létezik:

a) Az objektumok meghatározott jellemzői ütközhetnek egymással. Például,

1) A kimeneti jelentés az egyik követelményben táblázatos, a másikban pedig szöveges formában írható le.

2) Az egyik követelmény előírhatja, hogy minden jelzőfénynek zöldnek kell lennie, egy másik követelménynek pedig azt, hogy minden jelzőfénynek kéknek kell lennie.

b) Logikai vagy időbeli konfliktus lehet a két meghatározott cselekvés között. Például.

1) Az egyik követelmény meghatározhatja, hogy a program két bemeneti mennyiséget adjon hozzá, egy másik pedig azt, hogy ezeket megszorozza.

2) Az egyik követelmény szerint „A” eseménynek mindig „B” eseményt kell követnie, míg egy másik követelmény szerint „A” és „B” események egyidejűleg következnek be.

3) Két vagy több követelmény is leírhatja ugyanazt az objektumot, de eltérő kifejezéseket használ az objektumra. Például egy program felhasználói beviteli kérése az egyik kérésben „prompt”-nak, a másikban „cue”-nak nevezhető. A szabványos terminológia és definíciók használata javítja a konzisztenciát.

4.3.5 Fontosság és/vagy stabilitás szerint rangsorolva

Az SRS-t fontosság és/vagy stabilitás szerint értékelik, ha minden követelménynek van egy azonosítója, amely azonosítja az adott követelmény fontosságát és/vagy stabilitását.

Általában nem minden szoftverkövetelmény egyformán fontos. Egyes követelmények kötelezőek lehetnek, különösen a kritikus alkalmazások esetében, míg mások csak kívánatosak.

Az SRS minden követelményét értékelni kell, hogy ezek a megkülönböztetések egyértelműek és egyértelműek legyenek. A követelmények azonosítása segít:

a. A fogyasztók számára az egyes követelmények pontosabb értelmezését, amely gyakran implicit feltételezéseket tár fel

b. A fejlesztők meghozzák a megfelelő tervezési döntéseket, és megfelelő figyelmet fordítanak a szoftvertermék különböző részeire.

4.3.5.1 Stabilitási fok

A követelmények azonosításának egyik módszere a stabilitás mértékét használja. A stabilitás bármely követelményben várható változások számával fejezhető ki a tapasztalatok és a szoftver által támogatott szervezetet, funkciókat és személyzetet érintő valószínű események ismeretében.

4.3.5.2 A szükségesség mértéke

A követelmények értékelésének másik módja a követelményosztályok megkülönböztetése kötelező, feltételes és opcionális.

a) Kötelező. Azt jelenti, hogy a szoftver nem lesz elfogadható, hacsak nem tartalmazza ezeket a követelményeket, és nem egyeztetik velük.

b) Feltételes. Azt jelenti, hogy ezek a követelmények javítják a szoftverterméket, de a szoftvertermék ezek nélkül is elfogadható lesz.

c) Nem kötelező. Olyan funkciók osztályára utal, amelyek figyelemre méltóak vagy nem. Ez lehetőséget ad a szállítónak, hogy olyan képességeket kínáljon, amelyek túlmutatnak az STS hatályán.

4.3.6 Ellenőrizhető

Az SRS akkor és csak akkor ellenőrizhető, ha minden benne meghatározott követelmény ellenőrizhető. Egy követelmény akkor és csak akkor ellenőrizhető, ha létezik egy véges, költséghatékony folyamat, amellyel egy személy vagy gép ellenőrizheti, hogy a szoftver megfelel-e a követelménynek. Bármilyen kétértelmű követelmény nem ellenőrizhető.

Az ellenőrizhetetlen követelmények közé tartoznak az olyan kijelentések, mint a „jól működik”, „jó emberi interfész”, „gyakran fog történni”. Ezek az állítások nem ellenőrizhetők, mert lehetetlen meghatározni a „jó”, „jó” vagy „általában” kifejezéseket. A "programnak soha nem szabad végtelen rekurzióba lépnie" állítás nem tesztelhető, mert ennek a minőségnek a tesztelése elméletileg lehetetlen.

Példa egy tesztelhető állításra

A programot az esetek 60%-ában 20 mp-en belül, az esetek 100%-ában 30 mp-en belül meg kell szakítani

Ez az állítás tesztelhető, mert konkrét, számszerűsíthető kifejezéseket használ.

Ha nem lehet olyan eljárást kifejleszteni, amely meghatározza, hogy egy adott követelmény teljesül-e a szoftverben, akkor a követelményt el kell távolítani vagy felül kell vizsgálni.

4.3.7 Módosítható

Az SRS akkor és csak akkor változtatható, ha olyan felépítése és stílusa van, hogy a követelmények bármilyen változtatása egyszerűen, teljes mértékben, következetesen és a struktúra megtartása mellett elvégezhető. Általában a változtathatóság szükséges az STPO-ban

a) Konzisztens és könnyen használható szerkezettel kell rendelkeznie tartalomjegyzékkel, indexszel és kifejezett kereszthivatkozásokkal

b) Ne legyen felesleges; vagyis ugyanaz a követelmény ne jelenjen meg több helyen az SRS-ben

c) Az egyes követelmények külön-külön történő kifejezése, nem pedig más követelményekkel keverve

A redundancia önmagában nem hiba, de könnyen hibákhoz vezethet. A redundancia néha segíthet az SRS olvashatóságában, de problémák merülhetnek fel a dokumentum módosításakor. Például, ha egy követelményt csak az egyik helyen módosítottak, ahol megjelenik, akkor az SRS félreérthetővé válik. Ha redundancia szükséges, az SRS-nek kifejezett kereszthivatkozásokat kell tartalmaznia.

4.3.8 Nyomon követhető

Az SRS akkor nyomon követhető, ha az egyes követelmények eredete világos, és ha az SRS könnyű hozzáférést biztosít az egyes követelményekhez a későbbi fejlesztés során készített dokumentációból vagy az SRS-t kiterjesztő dokumentációból. Kétféle nyomon követhetőség javasolt.

a) Nyomon követhetőség (azaz a fejlődés korábbi szakaszaira). Ez attól függ, hogy minden egyes követelmény kifejezetten hivatkozik a forrásra a korábbi dokumentumokban.

b) Továbbítási nyomon követhetőség (vagyis az SRS által generált összes dokumentumra). Ez attól függ, hogy az SRS minden egyes követelménye egyedi névvel vagy hivatkozási számmal rendelkezik.

A szoftver nyomon követhetősége különösen fontos, mivel a szoftver működési és támogatási szakaszba lép. Ahogy a kódok és a tervdokumentumok változnak, meg kell tudni azonosítani a követelmények teljes körét, amelyeket az ilyen változások érinthetnek.

4.4 Az SRS közös előkészítése

A szoftverfejlesztési folyamatnak a szállító és az ügyfél közötti megállapodással kell kezdődnie arról, hogy mit kell tennie a kész szoftvernek. Ezt az SRS formájú megállapodást közösen kell elkészíteni. Ez azért fontos, mert általában sem az ügyfél, sem a szállító nem elég képzett ahhoz, hogy egyénileg jó dokumentumot dolgozzon ki.

c) Az ügyfelek általában nem értik eléggé a szoftver létrehozási és fejlesztési folyamatát ahhoz, hogy használható szoftvert hozzanak létre.

d) A beszállítók általában nem értik eléggé az ügyfél területét ahhoz, hogy meghatározzák a kielégítő rendszer követelményeit.

Ezért az ügyfélnek és a beszállítónak együtt kell dolgoznia egy jól megírt és teljesen érthető SRS elkészítése érdekében.

Van olyan helyzet, amikor egy rendszert és annak szoftverét egyszerre fejlesztik. Ekkor a szoftver funkcionalitása, interfészek, teljesítménye és egyéb jellemzői és korlátai nem előre meghatározottak, hanem a fejlesztési folyamat során közösen, pontosabban meghatározásra kerülnek, és egyeztetés, változtatás tárgyát képezik. Ez nehezebb, de nem kevésbé fontos, mivel a 4.3. pontban leírt jellemzők elérése szükséges. Különösen azok az SRS-ek helytelenek, amelyek nem felelnek meg a szülőrendszer-specifikáció követelményeinek.

Itt nincs szó stílusról, nyelvhasználatról vagy a jó nyelv technikáiról. Ez nagyon fontos, mert az STPO-knak jó nyelvezettel kell rendelkezniük. Útmutatóként műszaki könyvkészítési kézikönyvek használhatók.

4.5 Az SRS evolúciójának fejlesztése

Az STP-k a szoftvertermékek fejlesztésével fejlődhetnek. Előfordulhat, hogy bizonyos részleteket nem mindig lehet meghatározni a projekt kezdetéig. Például előfordulhat, hogy nem lehet minden képernyőformátumot meghatározni egy interaktív programhoz a követelmények fejlesztési szakaszában. További változások következhetnek be, ha hiányzó alkatrészeket, hiányosságokat vagy hibákat fedeznek fel az SRS-ben.

Ebben a folyamatban a következő két fő szempontot kell figyelembe venni:

a) A követelményeket a lehető legteljesebben és alaposabban kell meghatározni, még akkor is, ha az evolúciós változások elkerülhetetlenek. Azt, hogy a követelmények nem teljesek, tükröződnie kell a megjegyzésekben.

b) A változások azonosítására, kezelésére, nyomon követésére és jelentésére formális változtatási folyamatot kell kezdeményezni. A követelmények jóváhagyott módosításait az SRS-ben kell szerepeltetni, hogy

1) Gondoskodjon pontos és teljes változásvezérlésről.

2) Engedélyezze az SRS aktuális és módosított részeinek megtekintését

4.6 Prototípuskészítés

A prototípuskészítést gyakran használják egy projekt követelményfejlesztési szakaszában. Számos olyan eszköz létezik, amely lehetővé teszi a rendszerprototípusok gyors és egyszerű beszerzését egy sablonból a paraméterek beállításával. Lásd még: ASTM Std 1340-90.

A prototípusok három okból hasznosak:

a) Nagyon valószínű, hogy az ügyfél meg akarja nézni a prototípust, és reagálni akar rá, ahelyett, hogy elolvasná az SRS-t és reagálna rá. Így a prototípus gyors visszacsatolást biztosít.

b) A prototípus a rendszer viselkedésének váratlan aspektusait mutatja be. Így nem csak a felmerült kérdésekre válaszol, hanem újakat is feltesz. Ez segíti az STS fejlesztés befejezését.

c) A prototípus alapú SRS-ek általában kevesebb változáson mennek keresztül a fejlesztés során, így lerövidül a fejlesztési idő.

Prototípust kell használni a szoftverkövetelmények azonosításának módjaként. Egyes jellemzők, például képernyőtípusok vagy üzenetformátumok, közvetlenül a prototípusból szerezhetők be. A prototípussal való kísérletezéssel egyéb követelmények is teljesíthetők.

4.7 Tervezés beágyazása az SRS-be

A követelmény egy rendszer külsőleg látható funkcióját vagy jellemzőjét határozza meg. A projekt a rendszer egyetlen részösszetevőjét írja le, és/vagy interfészeket más alkomponensekkel. Az SRS készítőinek világosan különbséget kell tenniük a szükséges tervezési korlátok azonosítása és egy konkrét terv megtervezése között. Vegye figyelembe, hogy az SRS minden követelménye korlátozza a tervezési alternatívákat. Ez nem jelenti azt, hogy minden követelmény tervezés.

Az SST-knek meg kell határozniuk, hogy milyen funkciókat kell végrehajtani, milyen adatokat kell előállítani, milyen eredményt kapnak, hol helyezkednek el, kinek. Az STP-knek a nyújtott szolgáltatásokra kell összpontosítaniuk. Az SRS általában nem határozhat meg projektelemeket, például a következőket:

a) A szoftver modulokra bontása

b) A funkciók elosztása a modulok között

c) A modulok közötti információáramlás vagy interakció leírása

d) Adatszerkezetek kiválasztása

4.7.1 Szükséges tervezési követelmények

Különleges esetekben bizonyos követelmények szigorúan korlátozhatják a projektet. Például az adatvédelmi vagy biztonsági követelmények közvetlenül tükröződhetnek a tervezésben. Ezek olyan követelmények, mint pl

a) Tartson néhány funkciót külön modulokban

b) Korlátozott kommunikáció engedélyezése bizonyos programterületek között

c) Ellenőrizze az adatok integritását a kritikus változók tekintetében

Az elfogadható tervezési korlátok közé tartoznak például a fizikai követelmények, a teljesítménykövetelmények, a szoftverfejlesztési szabványok támogatására vonatkozó követelmények, a szoftverminőségi szabványok.

Ezért a követelményeket pusztán külső szemszögből kell megfogalmazni. Amikor modelleket használnak a követelmények szemléltetésére, ne feledje, hogy a modell csak a külső viselkedést jelzi, és nem határozza meg a tervezést.

4.8 Projektkövetelmények beágyazása az SRS-be

Az SSP-knek a szoftverterméket kell meghatározniuk, nem a létrehozási folyamatot.

A tervezési követelmények megértést biztosítanak az ügyfél és a szállító között a szoftvergyártással kapcsolatos szerződéses kérdésekben, ezért azokat nem szabad az SRS-ben szerepeltetni. Általában ezek a pontok ilyenek

a) Költség

b) Szállítási menetrendek

c) Jelentéstételi tevékenységek

d) Szoftverfejlesztési módszerek

e) Minőségbiztosítás

f) Vizsgálatok és ellenőrzési kritériumok

g) Átvételi eljárások

A projekt követelményeit más dokumentumok határozzák meg, általában egy szoftverfejlesztési terv, egy szoftvertesztterv vagy egy munkaátvételi dokumentum.

5 SRS szakasz (az SRS részei)

Ez a rész a PTSS minden egyes szükséges részét tárgyalja. ábrán látható diagramon található szakaszok. 1 modellként szolgálhat az SST fejlesztéséhez.

1. Bemutatkozás

1.2 Alkalmazási korlátok

1.3 Kifejezések, betűszavak, rövidítések

1.5 Rövid áttekintés

2. Általános leírás

2.1 Terméklehetőségek

2.2 A termék funkciói

2.3 Felhasználói jellemzők

2.4 Korlátozások

2.5 Feltételezések és függőségek

3. Részletes követelmények (A lehetséges részletes követelmények magyarázatát lásd az 5.3.1-5.3.8. pontban. Lásd még az A. függeléket az SRS e szakaszának több különböző szerkezetére vonatkozóan)

Alkalmazások

Indexek

1. ábra STP diagram minta

Bár egy SRS-nek nem kell követnie a vázlatot, vagy nem kell használnia ezeket a szakaszcímeket, a helyes SRS-nek tartalmaznia kell az itt tárgyalt összes információt.

5.1 Bevezetés (STP 1. szakasz)

Az SRS bevezetésének rövid áttekintést kell nyújtania a teljes SRS-ről. A következő alszakaszokat kell tartalmaznia:

b) Alkalmazási korlátok

c) Definíciók, mozaikszavak (rövidítések) és rövidítések

d) Rövid áttekintés

5.1.1 Cél (1.1 az SRS-től)

Ennek az alszakasznak a következőket kell tennie:

a) Ismertesse a részletes SRS célját!

b) Határozza meg a közönséget, akinek az STS-t szánják

5.1.2 Hatály (1.2 az SRS-től)

Ennek az alszakasznak kell

c) Azonosítsa a gyártani kívánt szoftvertermék(eke)t, neve (például „Szerver DBMS”, „Jelentésgenerátor” stb.)

d) Magyarázza el, hogy a szoftverelem(ek) mit tesznek, és ha szükséges, mit nem

e) Ismertesse a meghatározandó szoftver alkalmazásait, beleértve a fontos előnyöket, objektumokat és célokat.

f) Összhangban a magasabb szintű specifikációk (pl. rendszerkövetelmény-specifikáció) hasonló állításaival, ha vannak

5.1.3 Kifejezések, mozaikszavak és rövidítések (1.3 az STPO-tól)

Ennek az alszakasznak meg kell határoznia minden olyan kifejezést, betűszót és rövidítést, amely az SRS megfelelő értelmezéséhez szükséges. Ezt az információt az SRS egy vagy több függelékére vagy más dokumentumokra való hivatkozással lehet megadni.

Ennek az alszakasznak kell

a) Adja meg az SRS-ben bárhol említett dokumentumok teljes listáját

b) Azonosítsa az egyes dokumentumokat név, szám (ha időszakos), dátum, kiadó szervezet szerint.

Ezt az információt az SRS egy vagy több függelékére vagy más dokumentumokra való hivatkozással lehet megadni.

5.1.5 Áttekintés (1.5 az STPO-tól)

Ennek az alszakasznak kell

a) Írja le, mit tartalmaz az SRS többi része!

b) Magyarázza el, hogyan épül fel az STS

5.2 Általános leírás (2. szakasz az STP-ből

Az SRS ezen szakaszában le kell írni a terméket és a követelményeket befolyásoló általános tényezőket. Ez a szakasz nem határoz meg konkrét követelményeket. Ehelyett a 3. szakaszban található részletes meghatározás alapja, és könnyebben érthetővé teszi őket.

Ez a szakasz általában a következő hat alszakaszból áll:

a) Termékleírás

b) Termékfunkciók

c) Felhasználói jellemzők

d) Korlátozások

e) Feltevések és függőségek

f) Követelmények részhalmazai

5.2.1 Termékperspektíva (2.1 az SPTO-tól)

Az STS ezen alfejezetében ezt a terméket a kapcsolódó termékek szempontjából kell figyelembe venni. Ha a termék független és teljesen autonóm, ezt itt kell feltüntetni. Ha az SRS olyan terméket határoz meg, amely egy nagyobb rendszer összetevője, ahogy ez gyakran előfordul, akkor ennek az alpontnak a nagyobb rendszer követelményeit a termék funkcionalitásához kell kapcsolnia, és meg kell határoznia a rendszer és a termék közötti interfészeket.

Hasznos lehet egy diagram, amely bemutatja a nagyobb rendszer fő összetevőit, azok interakcióit és a külső interfészeket.

Ennek az alszakasznak azt is le kell írnia, hogy a szoftver hogyan felel meg a különféle belső korlátozásoknak. Például a következőket tartalmazhatja:

a) Rendszer interfészek

b) Felhasználói felületek

c) Számítógépes hardver interfészek

d) Szoftver interfészek

e) Kommunikációs interfészek

f) Memóriakorlátozások

g) Műveletek

h) A munkaállomások kialakításának követelményei

5.2.1.1 Rendszer interfészek

A rendszerkövetelmények, az interfészleírások és a rendszermegfelelőség biztosítása érdekében minden rendszerinterfészt fel kell sorolni, és azonosítani kell a szoftverek funkcionalitását.

5.2.1.2 Felhasználói felületek

Meg kell határozni:

a) A szoftvertermék és a felhasználók közötti egyes interfészek logikai jellemzői. Tartalmaznia kell azokat a konfigurációs funkciókat (például a szükséges képernyőformátumokat, az oldalak vagy ablakok elrendezését, az üzenetek vagy menük tartalmát, a programozható funkcióbillentyűk elérhetőségét), amelyek szükségesek a szoftverkövetelmények teljesítéséhez.

b) A szoftvertermék és a terméket használó felhasználók közötti interfész optimalizálásának minden vonatkozása. Ez egyszerűen tartalmazhat egy listát arról, hogy a rendszernek mit kell tennie és mit nem szabad a felhasználó szemszögéből. Ilyen például a hosszú vagy rövid hibaüzenetek megválasztása. Más követelményekhez hasonlóan ezeknek a követelményeknek is ellenőrizhetőnek kell lenniük, például "egy 4. osztályos gépírónő 1 óra képzés után Z perc alatt el tudja látni az X funkciót" előnyösebb, mint "a gépíró el tudja látni az X funkciót" (ez is megadható a szoftverrendszer specifikációit az „Egyszerű használat” című szakaszban).

5.2.1.3 Számítógépes hardver interfészek

Itt meg kell határozni a szoftvertermék és a számítógépes rendszer hardverkomponensei közötti egyes interakciók (számlák) logikai jellemzőit. Ez magában foglalja a konfigurációs jellemzőket (portszámok, utasításkészletek stb.), olyan kérdéseket, mint a támogatott eszközök listája, támogatási módszerek, protokollok. Például egy terminál megadható úgy, hogy támogassa a teljes képernyőt, vagy támogassa a vonalat.

5.2.1.4 Szoftver interfészek

Itt meg kell határoznia az egyéb szükséges szoftvertermékek (például adatkezelő rendszer, operációs rendszer vagy matematikai csomag) használatát és más alkalmazási rendszerekkel való interfészeket (például a kintlévőség-rendszer és a főkönyvi rendszer közötti kapcsolat) . Minden szükséges szoftvertermékhez meg kell adni a következőket:

egy név

b) Mnemonikus név

c) Specifikációs szám

d) Verziószám

e) Forrás Minden interfészhez meg kell adni a következőket:

a) Egy adott termékhez kapcsolódó, egymásra hatásos programok céljának megvitatása.

b) A felület meghatározása üzenettartalom és formátum szempontjából. A helyesen regisztrált interfészekhez nem kell részletes leírás, de az interfészt leíró dokumentumra mutató hivatkozás szükséges.

5.2.1.5 Kommunikációs interfészek

Itt különféle kommunikációs interfészeket kell meghatározni, például helyi hálózati protokollokat stb.

5.2.1.6 Memóriakorlátok

Itt meg kell határoznia a RAM és ROM vonatkozó jellemzőit és jelentését.

5.2.1.7 Műveletek

Itt meg kell határozni a felhasználók által igényelt normál és speciális műveleteket, mint pl

a) A felhasználók szervezetében a dolgok különböző módjai; például a felhasználó által kezdeményezett műveletek

b) A párbeszédes cselekvések és a megválaszolatlan cselekvések időszakai

c) Adatfeldolgozást támogató funkciók

d) Biztonsági mentési és visszaállítási műveletek

MEGJEGYZÉS – Ez az elem néha a felhasználói felületek részeként van meghatározva.

5.2.1.8 A helyszín adaptációs követelményei

Itt ez szükséges

a) Határozzon meg követelményeket minden olyan adatra vagy inicializálási szekvenciára vonatkozóan, amelyek egy adott munkahelyre, feladatra vagy üzemmódra vonatkoznak, például rácsértékek, biztonsági határértékek stb.

b) Határozza meg az elvégzendő feladat vagy feladat azon jellemzőit, amelyeket módosítani kell a szoftver egy adott konfigurációhoz való konfigurálásához.

5.2.2 Termékfunkciók (2.2 az SRS-től)

Az SRS ezen alszakaszának tartalmaznia kell a szoftver által végrehajtott fő funkciók összefoglalását. Például egy számviteli program SST-je ezt az alszakaszt használhatja az ügyfélszámla-szolgáltatás, az ügyfélalkalmazás és a számlakészítés funkcióinak meghatározására anélkül, hogy megemlítené azt a nagy mennyiségű részletet, amelyet az egyes funkciók megkövetelnek.

Néha az ehhez a részhez szükséges funkció-összefoglaló közvetlenül származtatható a magasabb szintű specifikációk szakaszaiból (ha vannak ilyenek), amelyek meghatározott funkciókat rendelnek a szoftvertermékhez. Felhívjuk figyelmét, hogy az egyértelműség kedvéért:

a) A funkciókat olyan csoportokba kell rendezni, amelyek a funkciók listáját érthetővé teszik az ügyfél vagy a dokumentumot először olvasó számára.

b) Szöveges vagy grafikus módszerek használhatók a különböző funkciók és kapcsolataik bemutatására. Az ilyen diagramok nem egy termék tervezését hivatottak bemutatni, hanem egyszerűen a változók közötti logikai kapcsolatokat mutatják be.

5.2.3 Felhasználói jellemzők (2.3 az SRS-től)

Az SRS ezen alszakaszának le kell írnia azon felhasználók általános jellemzőit, akiknek a termékeket szánják, beleértve az iskolai végzettséget, a tapasztalatot és a műszaki képesítést. Ezt a részt nem szabad arra használni, hogy 22. oldal

Külső szabványok

IEEE Std 830-1993

A részletes követelmények megfogalmazásához inkább annak indokolása szükséges, hogy ezek a követelmények miért jelennek meg később az SRS 3. pontjában.

5.2.4 Megszorítások (2.4 az SRS-től)

Az SRS ezen alszakaszának általános leírást kell adnia minden olyan egyéb tényezőről, amely korlátozza a fejlesztő választását. Ezek tartalmazzák:

a) Szabályozási politika

b) Számítógépes hardver korlátozások (pl. kiválasztási időre vonatkozó követelmények)

c) Interfészek más alkalmazásokkal

d) Párhuzamos működés

e) Naplózási funkciók

f) Vezérlési funkciók

g) A magas szintű nyelvekre vonatkozó követelmények

h) Jelidőzítő interfész protokollok (pl. XON-XOFF, ACK-NACK)

i) Megbízhatósági követelmények

j) Alkalmazáskritikusság

k) Biztonsági és adatvédelmi szempontok

5.2.5 Feltételezések és függőségek (2.5 az SRS-től)

Az SRS ezen alszakasza azon tényezők listáját határozza meg, amelyek befolyásolják az SRS-ben meghatározott követelményeket. Ezek a tényezők nem korlátozzák a projektszoftvert, de bármilyen változás befolyásolhatja az SRS követelményeit. Feltételezhető például, hogy egy adott operációs rendszer elérhető lesz egy szoftvertermékhez szánt számítógépes hardveren. Ha valójában az operációs rendszer nem elérhető, az SRS-t meg kell változtatni.

5.2.6 A követelmények felosztása (2.6 az SRS-től)

Az SRS ezen alszakaszának meg kell határoznia azokat a követelményeket, amelyek a rendszer jövőbeli verzióira halaszthatók.

5.3 Speciális követelmények (STP 3. szakasz)

Az SRS ezen szakaszának kellő részletességgel kell tartalmaznia az összes szoftverkövetelményt ahhoz, hogy a fejlesztők tervezhessenek, a tesztelők pedig ellenőrizhessék a követelményeknek megfelelő rendszert. Ebben a szakaszban minden követelménynek biztosítania kell a felhasználókkal, kezelőkkel vagy más külső rendszerekkel való együttműködést. Ezeknek a követelményeknek tartalmazniuk kell legalább a rendszer összes bemenetének, a rendszer összes kimenetének és minden olyan funkciónak a leírását, amelyet a rendszer a bemenetekre válaszul vagy kimenetek előállítására hajt végre.

Mivel gyakran ez az SRS legnagyobb és legfontosabb része, a következő elveket kell alkalmazni:

a) A részletes követelményeket a jelen szabvány 4.3. pontjában leírt szabályok szerint kell megadni.

b) A részletes követelményeket kereszthivatkozásokkal kell ellátni azokra a korábbi dokumentumokra, amelyekre vonatkoznak.

c) Minden követelményt egyedileg kell azonosítani.

d) Az olvashatóság javítása érdekében kiemelt figyelmet kell fordítani a követelmények strukturálására.

Mielőtt megvizsgálná a követelmények felépítésének konkrét módjait, érdemes áttekinteni a követelmények alább bemutatott különböző szakaszait.

5.3.1 Külső interfészek

A szoftverrendszer összes be- és kimenetéről részletes leírást kell készíteni. Ez az alszakasz kiegészíti az 5.2. szakaszban található interfész leírását. Nem ismételheti meg az 5.2. szakaszban található információkat.

a) A tétel megnevezése

b) A cél leírása

c) A bemenet forrása vagy a kimenet rendeltetési helye

d) Elfogadható tartomány, pontosság és/vagy tűrések

e) Mértékegységek

f) Időzítési jellemzők

g) Kapcsolatok más bemenetekkel/kimenetekkel

h) Képernyőformátumok/szervezés

i) Ablakformátumok/szervezés

j) Adatformátumok

k) Parancsformátumok

l) Üzenetek befejezése

5.3.2 Funkciók

A funkcionális követelmények meghatározzák azokat az alapvető műveleteket, amelyeket a szoftverben végre kell hajtani a bemeneti adatok fogadásakor és feldolgozásakor, valamint a kimeneti adatok generálásakor. Általában „kell”-ként szerepelnek a funkcionális követelménydefiníció elején. "A rendszernek..."

A leírás a következőket tartalmazza:

a) A bemenő adatok érvényesítése

b) A műveletek pontos sorrendje

c) Intézkedések rendkívüli helyzetek esetén, beleértve a

1) Túlcsordulás

2) Kommunikációs lehetőségek

3) Hibakezelés és helyreállítás

d) A paraméterek befolyása

e) A bemenetek és a kimenetek közötti kapcsolatok, beleértve

1) Bemeneti/kimeneti szekvenciák

2) Képletek a bemeneti adatok kimeneti adatokká konvertálására

Meghatározható a funkcionális követelmények részfunkciókra vagy részfolyamatokra való felosztása. Ez nem jelenti azt, hogy a fejlesztés alatt álló szoftvernek ugyanaz a felosztása lesz.

5.3.3 Teljesítménykövetelmények

Ez az alszakasz a statikus és dinamikus numerikus jellemzőkre vonatkozó követelményeket határozza meg. Ezek a követelmények a következőket foglalhatják magukban:

a) A támogatandó terminálok száma

b) A támogatandó egyidejű felhasználók száma

c) A feldolgozandó információ mennyisége és típusa

A statikus numerikus jellemzőkkel szemben támasztott követelményeket néha külön szakaszba osztják, a rendszerterhelést.

A dinamikus numerikus jellemzőkkel szemben támasztott követelmények közé tartozhat például a tranzakciók és feladatok száma, a normál és csúcsterhelési feltételek mellett meghatározott időintervallumon belül feldolgozott adatmennyiség.

Mindezeket a követelményeket mértékegységben kell megadni.

Például a tranzakciók 95%-át 1 másodpercnél rövidebb idő alatt kell feldolgozni, ahelyett, hogy az operátornak várnia kellene a tranzakció befejezésére.

MEGJEGYZÉS – Az egy adott funkcióra vonatkozó számszerű korlátozások általában egy albekezdés részeként vannak megadva az adott függvény működésének leírásában.

5.3.4 Logikai adatbázis-követelmények

Itt határozzák meg az adatbázisban elhelyezendő információk logikai követelményeit. Tartalmazhat:

d) A különböző funkciók által használt információtípusok

e) Használat gyakorisága

f) Hozzáférés módjai.

g) Adat entitások és kapcsolataik

h) Integritási korlátok

i) Adattárolási követelmények

5.3.5 Tervezési korlátok

Ez meghatározza azokat a tervezési korlátokat, amelyeket más szabványok, számítógépes hardverkorlátozások stb. írhatnak elő.

5.3.5.1 Szabványoknak való megfelelés

Ennek az alszakasznak meg kell határoznia a meglévő szabványokból vagy előírásokból eredő követelményeket. A következőket tartalmazhatja:

a) Üzenetformátum

b) Adatok elnevezése

c) Számviteli eljárások

d) Audit nyomon követés

Például meghatározhat egy követelményt, hogy a szoftver naplózza a feldolgozási folyamatot. Egy ilyen protokoll szükséges bizonyos alkalmazásokhoz, hogy megfeleljenek a szabályozási vagy pénzügyi szabványok minimális követelményeinek. Egy naplózási követelmény például meghatározhatja, hogy a bérszámfejtési adatbázis minden változását rögzíteni kell egy naplófájlban a változtatások előtti és utáni értékekkel.

5.3.6 Szoftverrendszer-attribútumok

Számos szoftverjellemző szolgálhat követelményként. Fontos, hogy ezeket a követelményeket úgy határozzák meg, hogy azok objektíven ellenőrizhetők legyenek. A következő bekezdések példákat mutatnak be néhány jellemzőre.

5.3.6.1 Megbízhatóság

Ez határozza meg azokat a tényezőket, amelyek szükségesek a rendszerszoftver szükséges megbízhatóságának megállapításához a szállítás időpontjában.

5.3.6.2 Elérhetőség

Ez határozza meg azokat a tényezőket, amelyek a teljes rendszer rendelkezésre állásának bizonyos szintjének garantálásához szükségesek, például a töréspontokat, a helyreállítást és az újraindítást.

5.3.6.3 Biztonság

Olyan tényezőket határoz meg, amelyek biztosítják, hogy a szoftver védve legyen a véletlen vagy rosszindulatú hozzáférés, használat, módosítás, megsemmisítés vagy nyilvánosságra hozatal ellen. Ezen a területen az alábbiak lehetnek speciális követelmények:

a) Használjon néhány titkosítási módszert

c) Rendeljen néhány funkciót a különböző modulokhoz

d) Egyes programterületek közötti kapcsolatok korlátozása

e) Ellenőrizze az adatok integritását a kritikus változók tekintetében

5.3.6.4 Karbantarthatóság

Itt olyan szoftverparaméterek kerülnek meghatározásra, amelyek közvetlenül kapcsolódnak a szoftver egyszerű karbantartásához. Lehetnek bizonyos követelmények a modularitás, az interfészek, a komplexitás stb. meghatározásához. A követelményeket nem szabad itt közzétenni pusztán azért, mert jó tervezési gyakorlatnak tartják őket.

5.3.6.5 Hordozhatóság

Ez határozza meg azokat a szoftverparamétereket, amelyek a szoftver más gépekre és/vagy operációs rendszerekre való könnyű hordozhatóságára vonatkoznak. Tartalmazhat:

f) Gépfüggő kódú alkatrészek százalékos aránya

g) A kód százalékos aránya, amely gépfüggő

h) Bevált hordozható nyelv használata

i) Egy adott fordítóprogram vagy nyelvi részhalmaz használata

j) Egy adott operációs rendszer használata

5.3.7 A speciális követelmények rendszerezése

A nem triviális rendszerek esetében a részletes követelmények kiterjedtek lehetnek. Emiatt ajánlatos azokat úgy felépíteni, hogy könnyen érthetőek legyenek. Nincs minden rendszer számára optimális struktúra. Az SRS 3. szakasza a követelmények különböző osztályaira vonatkozó strukturálási módjait tartalmazza. Néhány struktúrát a következő alfejezetekben ismertetünk.

5.3.7.1 Rendszer mód

Egyes rendszerek az üzemmódtól függően nagyon eltérően viselkednek. Például egy vezérlőrendszer a felhasználástól függően különböző funkciókészlettel rendelkezhet: edzés, normál vagy vészhelyzet. Az üzemmódokba osztás megszervezésénél az A függelék 1. vagy 2. részében látható diagramokat használja. A választást az határozza meg, hogy az interfészek és a programvégrehajtás függ-e az üzemmódtól.

5.3.7.2 Felhasználói osztályok

Egyes rendszerek különböző funkciókat biztosítanak a különböző felhasználói osztályok számára. Például egy liftvezérlő rendszer különböző lehetőségeket kínál az utasok, a karbantartók és a tűzoltók számára. Használja az A függelék 3. szakaszában látható vázlatot a szakasz rendszerezéséhez.

5.3.7.3 Objektumok

Az objektumok valós entitások, amelyeknek a rendszeren belül van egy példánya. Például egy betegfigyelő rendszerben az objektumok betegek, érzékelők, nővérek, szobák, orvosok, gyógyszerek stb. Minden objektum (az objektum) attribútumainak és (az objektum által végrehajtott) függvényeinek halmazához van társítva. Ezek a függvények szolgáltatásokat, módszereket vagy folyamatokat is hívnak. Ennek a szakasznak a rendszerezésekor használja a vázlatot

Az A. függelék 4. szakaszában látható. Vegye figyelembe, hogy az objektumkészletek attribútumokkal és szolgáltatásokkal elválaszthatók. Osztályokként vannak csoportosítva.

5.3.7.4 Jellemzők

A szolgáltatás egy olyan rendszer által biztosított külsőleg kívánt szolgáltatás, amely bemenetek sorozatát igényelheti a kívánt kimenet előállításához. Például egy telefonrendszerben a szolgáltatások közé tartozik a városon belüli hívás, a gyorshívás és a konferenciahívás. Az egyes jellemzőket általában ütés-reakció párok sorozatában írják le. Ennek a szakasznak a rendszerezésekor használja az A függelék 5. szakaszában látható vázlatot.

5.3.7.5 Ösztönzés

Egyes rendszerek jobban szervezettek lehetnek, ha funkcióikat a hatás szempontjából írják le. Például egy repülőgép automatikus leszállórendszerének funkciói szakaszokba szervezhetők a következő hatások miatt: teljesítményvesztés, széllökés, hirtelen dőlésváltozás, túlzott függőleges sebesség stb. Ennek a szakasznak a rendszerezésekor használja az A. függelék 6. szakaszában látható vázlatot.

5.3.7.6 Válasz

Egyes rendszerek jobban szervezettek lehetnek, ha funkcióikat reakciógenerálásként írják le. Például a személyzeti számviteli rendszer funkciói szekciókba szervezhetők, amelyek megfelelnek a bérszámfejtéssel kapcsolatos összes funkciónak, megfelelnek az aktuális alkalmazotti lista létrehozásához kapcsolódó összes funkciónak stb. Használja az A. függelék 6. szakaszát (a „hatás” szót cserélje ki a „reakció” szóra).

5.3.7.7 Funkcionális hierarchia

Ha a fenti szervezeti sémák egyike sem megfelelő, a teljes funkcionalitást közös bemenetek, közös kimenetek vagy a belső adatokhoz való közös hozzáférés által szervezett funkciók hierarchiájába lehet szervezni. Adatfolyamdiagramok és adatszótárak használhatók a függvények és adatok közötti kapcsolatok bemutatására. A szakasz rendszerezéséhez használja az A függelék 7. diagramját.

5.3.8 További megjegyzések

Új követelmény meghatározásakor több, az 5.3.7.7. pontban leírt strukturálási módszert követhet. Ilyen esetekben strukturálja a részletes követelményeket több hierarchiába, a megadott rendszer speciális igényeihez igazítva. Például lásd az A függelék 8. pontját a felhasználói osztályt és szolgáltatást kombináló szervezetről. Az esetleges további követelményeket az SRS végén külön részben lehet elhelyezni.

Számos leírás, módszer és automatizált támogatási eszköz áll rendelkezésre a követelmények dokumentálásához. Értékük elsősorban a strukturáltság függvénye. Például mód szerinti rendezésnél hasznosak lehetnek az állapotgépek vagy az állapotdiagramok; objektumok szerinti strukturálásnál hasznos lehet az objektumorientált elemzés; a jellemzők szerinti strukturálásnál hasznosak lehetnek az „expozíció-válasz” sorozatok; nál nél

A funkcionális hierarchia szerinti strukturálásnál hasznosak lehetnek az adatfolyamdiagramok és adatszótárak.

Az 1-8. pontokban megadott diagramok bármelyikében a „Funkcionális követelmények”-ként említett szakaszok az anyanyelven (például angolul), pszeudokóddal, rendszerleíró nyelven vagy négy alszakaszként írhatók: Bevezetés, Bemenetek, feldolgozás, kimenetek.

5.4 Támogató információk

Az információs támogatás megkönnyíti a szoftver használatát. Magába foglalja

b) Indexek

c) Pályázatok

5.5 Függelékek

Az alkalmazások nem mindig részei a tényleges követelményspecifikációnak, és nem mindig szükségesek. Ezek közé tartozhatnak

a) Minták az input/output formátumokból, a képzési költségelemzés leírása vagy a felhasználói felmérések eredményei

b) Támogató vagy előkészítő információk, amelyek segíthetik az SRS olvasóit

c) A szoftver segítségével megoldandó problémák leírása

d) Különleges csomagolási utasítások a biztonsági, exportálási, rendszerindítási vagy egyéb követelményekhez szükséges kódhoz és információkhoz

Ha vannak mellékletek, az SRS-nek kifejezetten nyilatkoznia kell arról, hogy a mellékleteket a követelmények részének tekinti-e vagy sem.

6 A. függelék (tájékoztató jellegű)

6.1 Az STS 3. szakaszának sablonja mód szerint rendezve: 1. verzió
3 Részletes követelmények
3.1 A külső interfészekre vonatkozó követelmények



3.1.4 Kommunikációs interfészek

3.2.1 1. mód

3.2.2 2. mód
3. 2. m. m módban
3. 2. m.1 Funkcionális követelmény m.
3. 2. m.n Funkcionális követelmény m.n
3.3 Teljesítménykövetelmények
3.4 A projekt korlátozásai

3.6 Egyéb követelmények
6.2 Az STS 3. szakaszának sablonja mód szerint rendezve: 2. verzió
3. Részletes követelmények
3.1. Funkcionális követelmények
3.1.1 1. mód
3.1.1.1 Külső interfészek
3. 1.1.1.1 Felhasználói felületek
3. 1.1.1.2 Számítógépes hardver interfészek
3. 1.1.1.3 Szoftver interfészek
3. 1.1.1.4 Kommunikációs interfészek
3.1.1.2 Funkcionális követelmények
3.1.1.2.1 Funkcionális követelmény 1
3.1.1.2.n Funkcionális követelmény n
3.1.1.3 Teljesítménykövetelmények
3.1.2 2. mód
3.1.m. Mód m.
3.2 A projekt korlátozásai
3.3 A rendszerszoftver jellemzői
3.4 Egyéb követelmények
6.3 Sablon az SRS 3. szakaszához felhasználói osztályok szerint rendezve
3 Részletes követelmények

3.1.1 Felhasználói felületek
3.1.2 Számítógépes hardver interfészek
3.1.3 Szoftver interfészek
3.1.4 Kommunikációs interfészek
3.2 Funkcionális követelmények
3.2.1 1. felhasználói osztály
3.2.1.1 Funkcionális követelmény 1.1
3.2.1.n Funkcionális követelmény 1.n
3.2.2 2. felhasználói osztály
3.2.m. Felhasználói osztály m.


3.3 Teljesítménykövetelmények
3.4 A projekt korlátozásai
3.5 A rendszerszoftver jellemzői
3.6 Egyéb követelmények
6.4 Sablon az STS 3. szakaszához objektum szerint rendezve
3 Részletes követelmények
3.1 A külső interfészek követelményei
3.1.1 Felhasználói felületek
3.1.2 Számítógépes hardver interfészek
3.1.3 Szoftver interfészek
3.1.4 Kommunikációs interfészek
3.2 Osztályok/objektumok
3.2.1 Osztály/objektum 1
3.2.1.1 Attribútumok (saját vagy örökölt)
3.2.1.1.1 1. attribútum
3.2.1.1.n n attribútum
3.2.1.2 Funkciók (módszerek. Natív vagy öröklött)
3.2.1.2.1 Funkcionális követelmény 1.
3.2.1.2.m Funkcionális követelmény m
3.2.1.3 Üzenetek (fogadott vagy elküldött)
3.2.2 Osztály/objektum 2
3.2.p Osztály/tárgy p
3.3 Teljesítménykövetelmények
3.4 A projekt korlátozásai
3.5 A rendszerszoftver jellemzői
3.6 Egyéb követelmények
6.5 Sablon az STS 3. szakaszához szolgáltatások szerint rendezve
3 Részletes követelmények
3.1 A külső interfészek követelményei
3.1.1 Felhasználói felületek
3.1.2 Számítógépes hardver interfészek
3.1.3 Szoftver interfészek
3.1.4 Kommunikációs interfészek
3.2 A rendszer jellemzői
3.2.1 1. rendszerszolgáltatás
3.2.1.1 Bevezetés/cél
3.2.1.2 Ütés/reakció sorrend
3.2.1.3 Kapcsolódó funkcionális követelmények
3.2.1.3.1 Funkcionális követelmény 1
3.2.1.2.n Funkcionális követelmény n
3.2.2 2. rendszerszolgáltatás
3.2.m A rendszer jellemzője m.
3.3 Teljesítménykövetelmények
3.4 A projekt korlátozásai
3.5 A rendszerszoftver jellemzői
3.6 Egyéb követelmények
6.6 Az SRS 3. szakaszának sablonja hatás szerint rendezve
3 Részletes követelmények
3.1 A külső interfészek követelményei
3.1.1 Felhasználói felületek
3.1.2 Számítógépes hardver interfészek
3.1.3 Szoftver interfészek
3.1.4 Kommunikációs interfészek
3.2 Funkcionális követelmények
3.2.1 Hatás 1
3.2.1.1 Funkcionális követelmény 1.1
3.2.1.n Funkcionális követelmény l.n
3.2.2 Hatás 2
3.2.m Hatás m
3.2.m.1 Funkcionális követelmény m.1
3.2.m.n Funkcionális követelmény m.n
3.3 Teljesítménykövetelmények
3.4 A projekt korlátozásai
3.5 A rendszerszoftver jellemzői
3.6 Egyéb követelmények
6.7 Az SRS 3. szakaszának sablonja funkcionális hierarchia szerint
3 Részletes követelmények
3.1 A külső interfészek követelményei
3.1.1 Felhasználói felületek
3.1.2 Számítógépes hardver interfészek
3.1.3 Szoftver interfészek
3.1.4 Kommunikációs interfészek
3.2 Funkcionális követelmények
3.2.1 Információáramlás
3.2.1.1 1. adatfolyamdiagram
3.2.1.1.1 Adatentitások
3.2.1.1.2 Vonatkozó folyamatok
3.2.1.1.3 Topológia
3.2.1.2 2. adatfolyamdiagram
3.2.1.2.1 Adatentitások
3.2.1.2.2 Vonatkozó folyamatok
3.2.1.2.3 Topológia
3.2.1.n Adatfolyam diagram n
3.2.1.n.1 Adatentitások
3.2.1.n.2 Vonatkozó folyamatok
3.2.1.n.3 Topológia
3.2.2 A folyamatok leírása
3.2.2.1 1. folyamat
3.2.2.1.1 Bemeneti adat entitások
3.2.2.1.2 Folyamat algoritmus vagy képlet
3.2.2.1.3 Érintett adatentitások
3.2.2.2 2. folyamat
3.2.2.2.1 Bemeneti adat entitások
3.2.2.2.2 Folyamat algoritmus vagy képlet
3.2.2.2.3 Érintett adatentitások
3.2.2.m Folyamat m
3.2.2.m.1 Bemeneti adat entitások
3.2.2.m.2 Folyamat algoritmus vagy képlet
3.2.2.m.3 Érintett adatentitások
3.2.3 Adatszerkezeti előírások
3.2.3.1 Szerkezet 1
3.2.3.1.1 Feljegyzés típusa
3.2.3.1.2 Elemi mezők
3.2.3.2 2. szerkezet
3.2.3.2.1 Feljegyzés típusa
3.2.3.2.2 Elemi mezők
3.2.3.p Szerkezet p
3.2.4 Adatszótár
3.2.4.1 1. adatelem
3.2.4.1.1 Név
3.2.4.1.2 Bemutatás
3.2.4.1.3 Egységek/formátum
3.2.4.1.4 Pontosság/pontosság
3.2.4.1.5 Értéktartomány
3.2.4.2 2. adatelem
3.2.4.2.1 Név
3.2.4.2.2 Bemutatás
3.2.4.2.3 Egységek/formátum
3.2.4.2.4 Pontosság/pontosság
3.2.4.2.5 Értéktartomány
3.2.4.1.q q adatelem
3.2.4.q.1 Név
3.2.4.q.2 Bemutatás
3.2.4.q.3 Egység/formátum
3.2.4.q.4 Pontosság/pontosság
3.2.4.q.5 Tartomány
3.3 Teljesítménykövetelmények
3.4 A projekt korlátozásai
3.5 A rendszerszoftver jellemzői
3.6 Egyéb követelmények
6.8 Sablon az STS 3. szakaszához, amely több szervezetet mutat
3 Részletes követelmények
3.1 A külső interfészek követelményei
3.1.1 Felhasználói felületek
3.1.2 Számítógépes hardver interfészek
3.1.3 Szoftver interfészek
3.1.4 Kommunikációs interfészek
3.2 Funkcionális követelmények
3.2.1 1. felhasználói osztály
3.2.1.1 Funkció 1.1
3.2.1.1.1 Bevezetés/cél
3.2.1.1.2 Ütés/reakció sorrend
3.2.1.1.3 Kapcsolódó funkcionális követelmények
3.2.1.2 Funkció 1.2
3.2.1.2.1 Bevezetés/cél
3.2.1.2.2 Ösztönzés/válasz sorrendje
3.2.1.2.3 Kapcsolódó funkcionális követelmények
3.2.1.m. Funkció 1.m
3.2.1.m.1 Bevezetés/cél.
3.2.1.m.2 Ütés/reakció sorrend
3.2.1.m.3 Kapcsolódó funkcionális követelmények
3.2.2 2. felhasználói osztály
3.2.n Felhasználói osztály n
3.3 Teljesítménykövetelmények
3.4 A projekt korlátozásai
3.5 A rendszerszoftver jellemzői
3.6 Egyéb követelmények

• Kapcsolatban áll

A karbantartást mindig is a szoftver életciklusának egyik fő szakaszának tekintették. Már a 70-es évek közepén felismerték, hogy a karbantartás egy olyan szakasz, amely egy szoftvereszköz fejlesztési és bevezetési költségeinek több mint 50%-át teszi ki.

Az üzleti folyamatok folyamatossága és a vállalatok életéhez szükséges vállalati információk biztonsága a támogatási és karbantartási szakaszban végzett munka hatékonyságától függ.

Az olyan összetett szoftverrendszerek esetében, amelyek több verzió hosszú távú használatát és karbantartását igénylik, sürgősen szükség van életciklusuk szabályozására, szabványos profilok formalizálására és alkalmazására, valamint a programminőség tanúsítására.

A szabályozási és normatív dokumentumok felhasználása a szoftver életciklusát határozottabbá, szerkezetében, tartalmilag, minőségében és költségében kiszámíthatóbbá teszi. A dokumentáció, az információtartalom és az érthetőség határozza meg a támogató dokumentáció összetételét és minőségét.

A szoftver életciklusának leghosszabb és legfontosabb szakaszának - a szoftver karbantartásának, amely a legnagyobb idő-, munkaerő- és anyagi erőforrás-ráfordítást igénylő - helyes és hatékony megszervezése érdekében figyelembe kell venni a nemzetközi és hazai ajánlásokat. e szakasz optimális megszervezésére vonatkozó rendelkezéseket tartalmazó szabványok.

Először is elemezni kell a támogatási szakasz értelmezését a különböző szabványokban.

Az IEEE Szoftverkarbantartási Szabvány (IEEE 1219) a szoftverkarbantartást úgy határozza meg, mint egy szoftverterméknek a szervizbe adást követő módosítását a hibák kiküszöbölése, a termék teljesítményének és/vagy egyéb jellemzőinek (attribútumainak) javítása, vagy a termék használathoz való igazítása érdekében. módosított környezetben. Érdekes, hogy ez a szabvány foglalkozik a rendszer üzembe helyezése előtti karbantartási előkészítéssel is, azonban szerkezetileg ez a szabványban szereplő megfelelő információs alkalmazás szintjén történik.

Az 12207-es életciklus-szabvány (IEEE, ISO/IEC, GOST R ISO/IEC) viszont a karbantartást az egyik fő életciklus-folyamat közé sorolja. Ez a szabvány a karbantartást egy szoftvertermék kódjának és dokumentációjának módosításának folyamataként írja le, hogy megoldják a működés során felmerülő problémákat, vagy felismerjék a termék bizonyos jellemzőinek javításának szükségességét. A kihívás a termék módosítása az integritás megőrzése mellett.

Az ISO/IEC 14764 (Szoftverfejlesztési szabvány – Szoftverkarbantartás) nemzetközi szabvány az 12207-es szabványhoz hasonlóan határozza meg a szoftverkarbantartást, kiemelve a rendszer életbe lépése előtti karbantartási tevékenységek előkészítését, például tervezési kérdéseket, szabályozásokat és támogatási műveleteket.

Az alállomás üzembe helyezése után teljesítményét a műszaki leírásban meghatározott követelmények szintjén kell tartani. Ez a feladat magában foglalja a szoftverhibák és -hibák kiküszöbölését, valamint a funkcionalitás esetleges bővítését. Ezen munkák megszervezéséhez a szabványokban meghatározott rendelkezésekre kell hivatkozni.

Számos forrás, különösen az IEEE 1216 szabvány a karbantartási munkák három kategóriáját határozza meg: beállítás, adaptáció és javítás. Ezt az osztályozást frissítették az ISO/IEC 14764 szabványban egy negyedik komponens bevezetésével.

Így ma négy támogatási kategóriáról beszélünk:

1. Korrekciós támogatás a szoftvertermék tényleges hibáinak kiküszöbölésének (javításának) szükségessége miatt bekövetkezett változásokat foglalja magában. Javító támogatásra kerül sor, ha a szoftvertermék nem felel meg a megállapított követelményeknek.

2. Adaptív támogatás a szoftverterméknek a megváltozott környezethez (feltételekhez) való hozzáigazításának szükségességével függ össze. Ezek a változások a rendszer interfészre, magára a rendszerre vagy a műszaki eszközökre vonatkozó új követelmények bevezetéséhez kapcsolódnak.

3. Teljes támogatás változásokat határoz meg a szoftver teljesítményjellemzőinek és karbantarthatóságának javítása érdekében. Ezek a változtatások új funkciók biztosítását a felhasználók számára, a kísérődokumentumok fejlesztési technológiájának felülvizsgálatát vagy maguk a dokumentumok megváltoztatását eredményezhetik.

4. Megelőző támogatás a szoftvertermék potenciális (rejtett) hibáinak (rejtett) kiküszöbölésének (javításának) okozta változásokra irányul. A megelőző karbantartást általában az emberi élet biztosításával vagy védelmével kapcsolatos szoftvertermékeknél végzik.

A karbantarthatóság a szoftver minőségének egyik mutatója, egyben fontos jellemzője a vevő, a szállító és a felhasználó számára.

A szoftverrendszer karbantarthatóságát vagy karbantarthatóságát például az IEEE 610.12-90 Standard Glossary for Software Engineering Terminology, Update 2002) határozza meg, mint a karbantartás, a bővítés, az adaptálás és a meghatározott követelményeknek megfelelő beállítás egyszerűsége. Az ISO/IEC 9126-01 szabvány (Szoftverfejlesztés – Termékminőség – 1. rész: Minőségi modell, 2001) a karbantarthatóságot tekinti az egyik minőségi jellemzőnek.

A karbantarthatóságot a szoftver fejlesztése előtt meg kell határozni, azaz megfelelő megállapodást kell készíteni a megrendelő és a szállító között a rendelési folyamat „előkészítő” munkája részeként (ISO/IEC, #M12291 1200009075 GOST R ISO/ IEC) 12207#S. A fejlesztő támogatási tervet készít, amelynek tükröznie kell a szoftver karbantarthatóságát biztosító konkrét módszereket, a megfelelő erőforrásokat és a munkavégzés algoritmusát.

A szoftvereszköz minősége a szoftvertermékek karbantartásának fontos szempontja. A karbantartóknak szoftverminőség-biztosítási programmal kell rendelkezniük, amely lefedi az ISO/IEC 9126 szabványban meghatározott hat minőségi jellemzőt. A szoftverkarbantartóknak megfelelő eljárással kell rendelkezniük a szoftver jellemzőinek értékelésére (mérésére) szolgáló módszerek meghatározására, leírására, kiválasztására, alkalmazására és fejlesztésére. .

A további támogatás költségeinek csökkentése érdekében az egész fejlesztési folyamat során szükséges a karbantarthatóságot befolyásoló jellemzők meghatározása, értékelése és ellenőrzése. Az ilyen munkák rendszeres végrehajtása megkönnyíti a további karbantartást, növeli a karbantarthatóságát (mint minőségi jellemző), ezt meglehetősen nehéz elérni, mivel ezeket a jellemzőket gyakran figyelmen kívül hagyják a fejlesztés során.

Ahogyan arról korábban szó volt, a szoftverkarbantartás az életciklus költséges szakasza, melynek munkájának optimalizálása érdekében különféle módszereket kell alkalmazni a karbantartási költségek becslésére.

A támogató munkák költségeit számos különböző tényező befolyásolja. Az ISO/IEC 14764 kimondja, hogy „két legnépszerűbb módszer van a karbantartási költségek becslésére: – a parametrikus modell és a tapasztalatok felhasználása”. Leggyakrabban mindkét megközelítést kombinálják az értékelés pontosságának javítása érdekében.

Különféle módszerek léteznek a kisegítő személyzet termelékenységének belső értékelésére, a különböző támogató csoportok teljesítményének összehasonlítására. A karbantartó szervezetnek meg kell határoznia azokat a mérőszámokat, amelyek alapján a vonatkozó munkát értékelni fogják. Az IEEE 1219 és az ISO/IEC 9126-01 (Szoftverfejlesztés – Termékminőség – 1. rész: Minőségi modell, 2001) szabványok speciális mérőszámokat kínálnak, amelyek kifejezetten a karbantartási kérdésekre és a kapcsolódó programokra összpontosítanak.

A karbantartási munkákat szigorúan szabályozni és le kell írni, részletes folyamatbemeneteket és kimeneteket tartalmazva. Ezeket a folyamatokat szabványok szabályozzák IEEE 1219 és ISO/IEC 14764.

A karbantartási folyamat az IEEE 1219 szabvány szerint a szoftver üzembe helyezésének pillanatától kezdődik, és olyan kérdéseket érint, mint a karbantartási tevékenységek tervezése.

Az ISO/IEC 14764 szabvány pontosítja az 12207 életciklus-szabvány karbantartási folyamattal kapcsolatos rendelkezéseit. Az ebben a szabványban leírt karbantartási munkák hasonlóak az IEEE 1219-ben leírtakhoz, azzal a különbséggel, hogy kissé eltérő csoportosításúak.

Nézzük meg közelebbről a GOST R ISO/IEC 14764-2002 szabvány kivonatait, amely az ISO/IEC 14764 nemzetközi szabvány teljes hiteles szövegét tartalmazza.

A szoftverkarbantartási folyamatot leíró GOST R ISO/IEC 14764-2002 szabványnak megfelelően a szoftverkarbantartási folyamat részleteit dokumentálni kell, hogy a támogató személyzet egyetlen folyamaton belül járjon el. A minőségi mutatók (metrikák) rendszerének elő kell segítenie a karbantartási folyamat megvalósítását, és hozzá kell járulnia a szoftver fejlesztéséhez (korszerűsítéséhez).

A karbantartó (5.5.2.1 GOST R ISO/IEC 12207) elemzi a problémajelentést vagy a módosítási javaslatot annak szervezeti kérdésekre, a meglévő rendszerre és más rendszerekkel való interfészkapcsolatokra gyakorolt ​​hatása szempontjából.

Az elemzés alapján a fenntartónak (5.5.2.3 GOST R ISO/IEC 12207) ki kell dolgoznia a változtatás végrehajtásának lehetőségeit. A rendszer módosítása előtt a fenntartónak (lásd 5.5.2.5 GOST R ISO/IEC 12207) be kell szereznie a szerződés szerinti jóváhagyást a kiválasztott módosítási lehetőséghez, és meg kell erősítenie, hogy az elvégzett változtatás megfelel a szerződésben meghatározott követelményeknek (lásd 5.5. .4.2 GOST R ISO/IEC 12207). A fenntartónak (5.5.2.4 GOST R ISO/IEC 12207) dokumentálnia kell: hibajelentést vagy módosítási javaslatot, azok elemzésének eredményeit és a változtatások végrehajtásának lehetőségeit.

A rendszer átadásának megfelelő ellenőrzéséhez a létesítmény átadási tervét ki kell dolgozni, dokumentálni és végre kell hajtani (5.5.5.2 GOST R ISO/IEC 12207). A felhasználókat be kell vonni a tervezett munkába.

A támogató tevékenységekhez számos egyedi munkakör és gyakorlat létezik, amelyeket figyelembe kell venni a támogatás megszervezésénél. A SWEBOK (Software Engineering Body of Knowledge) a következő példákat adja az ilyen egyedi jellemzőkre.

Adás:a szoftverek fejlesztőktől a további támogatásért felelős csoporthoz, szolgáltatáshoz vagy szervezethez történő átvitelének ellenőrzött és koordinált tevékenysége.

Módosítási kérelmek elfogadása/elutasítása : A változtatási kérelmek elfogadhatók és áthelyezhetők munkába, vagy elutasíthatók különböző indokolt okok miatt - a szükséges változtatások mennyisége és/vagy összetettsége, valamint az ehhez szükséges erőfeszítések miatt. A megfelelő döntések prioritás, megvalósíthatósági értékelés, forráshiány (beleértve a fejlesztők módosítási feladatok megoldásába való bevonásának hiányát is, ha erre valós igény) alapján is meghozható a megfelelő döntés, a következőben történő megvalósítás jóváhagyott tervezése. kiadás stb.

Eszközök a karbantartó személyzet értesítésére, valamint a módosítási kérelmek és hibajelentések állapotának nyomon követésére : Végfelhasználói támogatási funkció, amely erőfeszítéseket tesz a kéréssel vagy jelentett problémával kapcsolatos módosítások szükségességének, rangsorolásának és költségének felmérésére.

Hatástanulmány:a meglévő rendszerben végrehajtott változtatások lehetséges következményeinek elemzése.

Szoftver támogatás: a felhasználókkal kapcsolatos konzultációs munka, amelyet az információigényükre válaszul végeznek, például a vonatkozó üzleti szabályokkal, ellenőrzéssel, adattartalommal és konkrét felhasználói kérdésekkel, valamint a problémákkal kapcsolatos jelentéseik (hibák, meghibásodások, váratlan viselkedés, a felhasználóval való munkavégzés szempontjainak félreértése) tekintetében. rendszer stb.); P.).

Szerződések és kötelezettségek: Ide tartozik a klasszikus szolgáltatási szint megállapodás (SLA), valamint egyéb szerződéses szempontok, amelyek alapján a támogató csoport/szolgáltatás/szervezet elvégzi a megfelelő munkát.

Ezen kívül vannak további, a karbantartási folyamatot támogató tevékenységek, amelyeket a SWEBOK olyan karbantartó személyzeti tevékenységként ír le, amelyek nem járnak kifejezett interakcióval a felhasználókkal, de szükségesek a kapcsolódó tevékenységek elvégzéséhez. Az ilyen munkák a következőket foglalják magukban: karbantartás tervezése, konfigurációkezelés, ellenőrzés és tanúsítás, szoftverminőség-értékelés, a felülvizsgálat, elemzés és értékelés különböző szempontjai, audit és felhasználói képzés. Az ilyen speciális (belső) munkákhoz hozzátartozik a kisegítő személyzet képzése is.

Az alábbi 1. táblázat rövid áttekintést nyújt az információs rendszerek karbantartásának megszervezése során alkalmazott főbb szabványokról.

1. táblázat: Szabványok az információs rendszerek karbantartása területén

Alapértelmezett	Név	Leírás	A kijáratnál
12207 IEEE, ISO/IEC, GOST R ISO/IEC	Szoftver életciklus folyamatok	Ez a nemzetközi szabvány világosan meghatározott terminológiát használva létrehozza a szoftver életciklus-folyamatainak általános keretét, amely a szoftveripar irányítására használható.	1) Részletek az azonosított hibákról és a javasolt módosításokról szóló felhasználói jelentésekből (o. 5.5.2.1 GOST R ISO/IEC 12207) 2) Kiigazítási javaslatok (o.5.5.2.3 #M12291 1200009075 GOST R ISO/IEC 12207#S ) 3) Értesítés a felhasználóknak az AS új verziójának megjelenéséről (záradék.5.5.2.5 #M12291 1200009075 GOST R ISO/IEC 12207#S ) 4) Objektum átadási terv (o.5.5.5.2 #M12291 1200009075 GOST R ISO/IEC 12207)
14764 ISO/IEC GOST R ISO IEC	Szoftver támogatás (Szoftverfejlesztési szabvány – Szoftverkarbantartás)	Ez a szabvány részletezi az 12207-ben megállapított karbantartási folyamatot ( ISO/IEC #M12291 1200009075 GOST R ISO/IEC)
9126 ISO/IEC GOST R ISO/IEC	Információs technológia. Szoftvertermékek értékelése. Minőségi jellemzők és használatukra vonatkozó irányelvek	A karbantartóknak rendelkezniük kell a szoftver minőségbiztosítási programmal hat minőségi jellemzőt, telepítve: #M12291 1200009076 GOST R ISO/IEC 9126#S. Egy szoftvereszköz karbantartása során megfelelő folyamatot kell végrehajtani az eszköz jellemzőinek értékelésére (mérésére) szolgáló módszerek azonosítására, leírására, kiválasztására, alkalmazására és fejlesztésére.	Minőségi jellemzők: 1) Funkcionalitás 2) Megbízhatóság 3) Praktikusság 4) Hatékonyság 5) Karbantarthatóság 6) Mobilitás
GOST 34.603-92	Az automatizált rendszerek tesztelésének típusai	A szabvány meghatározza az AS-tesztek típusait és általános követelményeket a lefolytatásukra. A GOST 34.601 szerint az „üzembe helyezési” szakaszban az atomerőmű teszteket végzik el annak ellenőrzésére, hogy a létrehozott atomerőmű megfelel-e a műszaki specifikáció (TOR) követelményeinek.	Minden típusú teszt megtervezéséhez dokumentumot készítenek "Tesztprogram és módszertan." Az autonóm tesztprogram a következőket jelzi: 1) lista (tesztelendő függvények; 2) a tesztobjektum és a szoftver egyéb részei közötti kapcsolatok leírása; 3) a tesztelés és az eredmények feldolgozásának feltételei, eljárása és módszerei; 4) az alkatrészek elfogadásának kritériumai a vizsgálati eredmények alapján. A próbaüzem során az alállomást végzik munkanapló, amely információkat tartalmaz az AS működési időtartamáról, meghibásodásokról, meghibásodásokról, vészhelyzetekről, az automatizálási objektum paramétereinek változásáról, a dokumentáció és a szoftver folyamatos módosításáról, valamint a műszaki berendezések beállításáról.
IEEE 1219-1998	IEEE szoftverkarbantartási szabvány (Szoftverkarbantartási szabvány)	Ez a szabvány egy iteratív folyamatot ír le a szoftver-karbantartási tevékenységek kezelésére és végrehajtására. A szabvány használatát nem korlátozza a szoftvertermék mérete, összetettsége, kritikussága vagy alkalmazása.

Az információs rendszerek fenntartásának folyamatát szabályozó, fentebb tárgyalt nemzetközi és nemzeti szabványok mellett különböző irányadó dokumentumok és vállalaton belüli (vállalati) szabványok léteznek, amelyek alapját a nemzetközi szabványok képezik. Ebben az esetben kiemelt figyelmet fordítanak a dokumentáció minőségére, amely nagymértékben meghatározza a szoftverek versenyképességét. A komplex szoftvertermékek létrehozásakor és életciklusuk biztosításakor ki kell választani a szükséges szabványokat, és létre kell hozni a teljes dokumentumkészletet, azaz egy olyan profilt, amely biztosítja az összes szakasz és karbantartási munka szabályozását.

Tekintsük az információs rendszerek karbantartására vonatkozó szabványok alkalmazását egy konkrét példán keresztül.A rendszer magas színvonalú működése megköveteli a szervezet változó üzleti folyamataihoz való folyamatos alkalmazkodást, valamint a hibákra való gyors reagálást és a hibaelhárítást. Ennek kapcsán a ZAO Firm SoftInCom vezetése úgy döntött, hogy megállapodást kell kötni az Orient Express vállalati információs rendszer (CIS) fejlesztőivel a rendszer frissítésére és karbantartására.

Az Eastern Express CIS karbantartása többféle támogatást is tartalmaz (a GOST R ISO IEC 14764-2002 szerint). Nevezetesen a korrekciós támogatás, amely a szoftvertermék tényleges hibáinak kiküszöbölésének (javításának) okozta változásokhoz kapcsolódik. Javító támogatásra kerül sor, ha a szoftvertermék nem felel meg a megállapított követelményeknek. Valamint adaptív és teljes körű támogatás, amely modernizálja a szoftverterméket.

A korrekciós támogatás igénye rendszerhibák, illetve a felhasználó által okozott hibák esetén jelentkezik. A felhasználó által okozott hibák közé tartozik például a fontos adatok véletlen törlése, ami a rendszer biztonsági mentésének szükségességéhez vezet. Rendszerhibák meglehetősen gyakran fordulnak elő, különösen új kiadások telepítése után, mivel az új kiadások meglehetősen komoly változásokat jelentenek a meglévő adatfeldolgozási technológiákban és új modulok beépítését.

Az adaptív támogatás igénye akkor merül fel, ha bármilyen üzleti folyamat működésében változás történik (promóció lebonyolítása, külső nyomtatott űrlapok megváltoztatása, központi irodából érkező megrendelések stb.), vagy olyan műveletek végrehajtása kényelmetlen, amelyek változtatásokat igényelnek. a rendszer felületén.

A teljes körű támogatás sokkal ritkábban történik, mint más típusú támogatások. Ezt akkor hajtják végre, ha sok hasonló incidens, felhasználói kérés és kívánság merül fel, valamint azt követően, hogy a CIS tervezői elemezték a rendszer képességeit.

A támogató munka négy szakaszra osztható: hibák és módosítások elemzése, módosítások végrehajtása, támogatási eredmények értékelése és elfogadása, áthelyezés másik platformra. Ezen szakaszok mindegyike meghatározott bemeneteket, kimeneteket tartalmaz, és ezeket dokumentálni kell.

A 2. táblázat bemutatja a támogatás főbb szakaszait és a kimenetet a kísérő dokumentáció bekezdésében.

2. táblázat Az információs rendszer karbantartási folyamatának szakaszai

Beviteli adat	Karbantartási szakasz	Kimenet	Kimenet a bekezdésben
A hangszóró alapváltozata, hibaüzenetek a felhasználóktól	Hibák és módosítások elemzése	Hiba vagy hiba megerősítése (nem megerősítése), példa a módosításra	Kivonatok felhasználói jelentésekből az azonosított hibákról és javítási javaslatok.
A hibanaplóban dokumentált, elfogadott módosítási javaslatok	Módosítás végrehajtása	Végrehajtott és dokumentált változtatások	A módosítandó tárgy meghatározása (a feltárt hibák naplójának elemzése és javítási javaslatok).
Elvégzett módosítások, dokumentálva az előkészített és jóváhagyott módosítások naplójában	A támogatási eredmények értékelése, elfogadása	A karbantartási szerződésben meghatározott módosítások kielégítő elvégzésének jóváhagyása	Elkészített értesítés a felhasználóknak a hangszórórendszer új verziójának megjelenéséről
Migrációs terv	Átvitel másik platformra (más környezetbe)	Elkészült az áttelepítési terv, amely értesíti a felhasználókat az áttelepítésről	A migrációs terv leírása. A felhasználó értesítése az áthelyezési tervekről és intézkedésekről.

A GOST R ISO/IEC 12207 szabvány 5.5.2.1. pontjával összhangban a karbantartónak elemeznie kell a problémáról szóló felhasználói jelentéseket. Az Orient Express CIS felhasználóitól érkező kérések regisztrálásának és rögzítésének automatizálására a MantisBT eseményregisztrációs rendszert használják. A rendszerben regisztrált adatok alapján A MantisBT létrehoz egy „Jelentés a felhasználók által azonosított hibákról” dokumentumot, amely a következő mezőket tartalmazza: eseményszám, létrehozás dátuma, kategória, az incidens lényege, javasolt megoldás.

Az elemzés alapján a fenntartónak (5.5.2.3 GOST R ISO/IEC 12207) ki kell dolgoznia a változtatások végrehajtásának lehetőségeit. Ebből a célból készül a „A VIR új alapváltozatának előkészített és jóváhagyott módosításainak naplója” című dokumentum, amely a következő adatokat tartalmazza: kategória, a támogató szervezet által azonosított hiba, a CIS felhasználók által azonosított hiba, módosítás.

Ezt követően a fenntartónak (5.5.4.2 GOST R ISO/IEC 12207) meg kell erősítenie, hogy az elvégzett változtatás megfelel a szerződésben meghatározott követelményeknek. Ebből a célból egy „Értesítés a felhasználóknak a CIS új verziójának kiadásáról” című dokumentum készül, és az új kiadás telepítéséhez való hozzájárulás megerősítése várható.

A rendszer átvitelének megfelelő ellenőrzéséhez léteznie kell

GOST 34.603-92 Az automatizált rendszerek tesztelésének típusai

IEEE 1219-1998 IEEE szabvány a szoftverkarbantartáshoz

Szoftverkarbantartás (Szoftverkarbantartás a SWEBOK-tól) // ‒ Hozzáférési mód:

A „Network” magazin 2.2001. sz. cikke „Az információs rendszerek életciklusa” // ‒ Hozzáférési mód: http://www.setevoi.ru/cgi-bin/text.pl/magazines/2001/2/44

Az információs rendszerek fejlesztésének módszertana és technológiája. Nyílt információs rendszerek profiljai // ‒ Hozzáférési mód: http://gendocs.ru/v7394/lectures_on_theory_of_information_processes_and_systems?page=9

A kiadvány megtekintéseinek száma: Kérlek várj

Barysnikova Marina Jurjevna
MSTU im. N.E. Bauman
Caf. NE-7

3. előadás

A szoftver életciklusa
rendelkezés

A szoftver életciklusa

egy olyan időszak, amely azzal kezdődik
a döntés pillanata
szoftver létrehozásának szükségessége
rendelkezés, és pillanatnyilag véget ér
teljes kivonását a szolgálatból
(IEEE Std. 610.12 – 19990 szabványos szószedet a szoftverekről
Mérnöki terminológia)

Az életciklus meghatározásában szerepet játszó alapfogalmak

A műtermékek ember által létrehozott információk
entitások – dokumentumok, meglehetősen általános értelemben
bemeneti adatként vesz részt, és azt eredményezi
a különböző tevékenységek eredményeinek minősége.
A szerep az érdeklődők absztrakt csoportja,
létrehozásában és működtetésében vesz részt
olyan rendszerek, amelyek ugyanazokat a problémákat oldják meg, vagy ugyanazokkal rendelkeznek
és ugyanazok az érdekek vele kapcsolatban
Szoftvertermék – számítógépes programok halmaza,
eljárások és esetleg kapcsolódó dokumentáció és
adat
A folyamat egymással összefüggő cselekvések összessége,
egyes bemeneti adatok kimenetté alakítása

A szoftver életciklusa az ISO/IEC 12207:1995 szabvány szerint
„Nemzetközi technológia – Szoftver életciklus-folyamatok”
(GOST ISO IEC 12207-99 Információs technológiák.
szoftver életciklusa)
Életciklus
Szervezeti
folyamatokat
Ellenőrzés
projekt
Teremtés
infrastruktúra
Értékelés és fejlesztés
életciklus
Oktatás
Alapvető
folyamatokat
Beszerzés
Kiegészítő
folyamatokat
Dokumentáció
Kínálat
Ellenőrzés
konfigurációt
Fejlesztés
Biztonság
minőség
Kizsákmányolás
Igazolás
Kíséret
Tanúsítvány
Közös
fokozat
Könyvvizsgálat
Engedély
problémákat

Szoftverbeszerzési folyamat
Meghatározza a szoftvert vásárló ügyfél műveleteit
szerződésen alapuló szoftver vagy szoftverhez kapcsolódó szolgáltatás
kapcsolatokat
A folyamat során az ügyfél a következőket hajtja végre:
akciók:
az Ön igényeinek tudatosítása a szoftverrendszerben és
vásárlással, egyedi fejlesztéssel kapcsolatos döntések meghozatala
vagy egy meglévő rendszer fejlesztése;
vonatkozó követelményeket tartalmazó ajánlati javaslatok elkészítése
rendszer, működési feltételei és műszaki
korlátozások, valamint egyéb szerződési feltételek
Az akvizíció egy rendszer megszerzésének folyamata,
szoftvertermék vagy szoftverszolgáltatás

Szállítási folyamat
Meghatározza a beszállító szervezet tevékenységeit
a megrendelő ajánlati javaslataival kapcsolatban
A folyamat a következőket tartalmazza:
a megrendelő ajánlati javaslatainak mérlegelése és azokban való szerepeltetése
a beállításokat (ha szükséges);
megállapodás készítése az ügyféllel;
a munkavégzés megtervezése (ebben az esetben a munka lehet
saját erőből vagy alvállalkozó bevonásával végzett);
a projekt szervezeti felépítésének fejlesztése, műszaki
a fejlesztési környezetre és erőforrásokra vonatkozó követelmények, intézkedések
projektmenedzsment stb.
A folyamatok végrehajtásáért a szállítási folyamat felelős
fejlesztés, üzemeltetés és (vagy) karbantartás

Fejlesztési folyamat

Meghatározza a fejlesztő által végrehajtott műveleteket
a szoftver létrehozásának folyamata és annak
alkatrészek az előírt követelményeknek megfelelően
Ez a folyamat magában foglalja, de nem kizárólagosan:
tervezési és üzemeltetési nyilvántartásba vétel
dokumentáció;
igazoláshoz szükséges anyagok előkészítése
a szoftvertermék és annak működőképessége
a minőségi előírások betartása;
anyagok fejlesztése (módszertani és oktatási),
szükséges a személyzet képzéséhez, oktatásához és
stb.

Fejlesztési folyamat

Életciklus-modell kiválasztása
Rendszerkövetelmények elemzése
Rendszer architektúra tervezés
Szoftverkövetelmények elemzése
Részletes szoftver tervezés
Szoftver kódolás és tesztelés
Szoftver integráció
Szoftver minősítés tesztelése
Rendszerintegráció
Rendszerminősítés tesztelése
Szoftver telepítés
Szoftver elfogadás

10. Rendszerkövetelmények elemzése

Ebben a szakaszban mérlegeljük a rendszer alkalmazási körét.
A fejlesztés alatt álló rendszer követelményeinek listájának tartalmaznia kell:
azon feltételek összessége, amelyek mellett üzemelni kívánják
jövőbeli rendszer (hardver és szoftver erőforrások,
biztosítva a rendszernek; működésének külső feltételei;
személyek összetétele és a hozzá kapcsolódó művek);
a rendszer által ellátott funkciók leírása;
korlátozások a fejlesztési folyamatban (irányelv teljesítési határidők
az egyes szakaszok, a rendelkezésre álló erőforrások, a szervezési eljárások
és az információ védelmét biztosító intézkedések stb.)
A rendszerkövetelmények értékelése a kritériumok alapján történik
megvalósíthatósága és ellenőrizhetősége a tesztelés során

11. Szoftverkövetelmények elemzése

A következők meghatározását foglalja magában
az egyes szoftverkomponensek jellemzői:
funkcionalitás, beleértve
teljesítmény és környezeti jellemzők
alkatrész működése
külső interfészek
megbízhatósági és biztonsági előírások;
ergonómiai követelmények
a felhasznált adatokra vonatkozó követelmények
telepítési és átvételi követelmények
felhasználói dokumentáció követelményei
üzemeltetési és karbantartási követelmények

12. Szoftver architektúra tervezés

Szoftver architektúra
alrendszerek és szoftverösszetevők leírása
rendszerek, valamint a köztük lévő kapcsolatok
Az építészet tervezésének részeként mindenki számára
A szoftverkomponens a következő feladatokat hajtja végre:
struktúra meghatározása magas absztrakciós szinten
szoftver és összetevőinek összetétele
szoftverek fejlesztése és dokumentálása
szoftver és adatbázis interfészek
egy szokás előzetes változatának kidolgozása
dokumentáció
előzetes kidolgozása és dokumentálása
tesztkövetelmények és szoftverintegrációs terv

13. Részletes szoftvertervezés (szoftverfejlesztési munkaterv)

A következő feladatokat tartalmazza:
szoftverösszetevők és interfészek leírása között
számukra elegendő mennyiségben
későbbi független kódolás és
tesztelés
részletes kidolgozása és dokumentálása
adatbázis projekt
a felhasználói dokumentáció frissítése
vonatkozó követelmények kidolgozása és dokumentálása
tesztek és szoftverkomponens tesztelési terv

14. A szoftver kódolása és tesztelése a következő feladatok megoldását foglalja magában:

fejlesztés (kódolás) és dokumentáció
minden szoftverkomponens és adatbázis, valamint
vizsgálati eljárások és adatok készlete
tesztelés
minden szoftverkomponens és adatbázis tesztelése
adatokat a rájuk vonatkozó követelmények teljesítéséhez
követelményeknek
a felhasználó frissítése (ha szükséges).
dokumentáció
szoftverintegrációs terv frissítése

15. Rendszerintegráció

az összes összeszereléséből áll
alkatrészek, beleértve a szoftvert és
berendezések és tesztelés
aggregált komponensek
Az integrációs folyamat is termel
a teljes készlet regisztrációja és ellenőrzése
rendszer dokumentációja

16. Szoftver minősítési tesztelés

jelenlétében végezze el a fejlesztő
ügyfél bizonyítani, hogy a szoftver
megfelel az előírásoknak és
körülmények között használatra kész
művelet
Ez is ellenőrzi a teljességet
műszaki és felhasználói dokumentáció és
megfelelősége a szoftverösszetevőknek

17. Szoftver telepítése és átvétele

A szoftver telepítését a fejlesztő végzi el
terv szerint abban a környezetben és azon
a szerződésben előírt berendezéseket. BAN BEN
A telepítési folyamat során a funkcionalitást ellenőrizzük
Szoftverek és adatbázisok
A szoftver elfogadása magában foglalja az eredmények értékelését
rendszer minősítési tesztelés és
az értékelési eredmények dokumentálása, amely
a megrendelő állítja elő a fejlesztő segítségével.
A szoftver végső átvitelét a fejlesztő végzi el
a megrendelőnek a szerződésnek megfelelően, biztosítva
a szükséges képzéssel és támogatással

18. Szoftver működése

A rendszer benn működik
erre a célra kialakított környezet
szokás szerint
dokumentáció
Telepítést tartalmaz
működési szabványok és
operatív elvégzése
tesztelés

19. Szoftverkarbantartás (IEEE – 90 szabvány szerint)

módosítások elvégzése a szoftveren a javítás érdekében
hibák, teljesítményjavítások ill
alkalmazkodás a megváltozott munkakörülményekhez
vagy követelményeknek
Támogató szolgáltatási funkciók:
problémák elemzése és szoftvermódosítási kérelmek
szoftvertermék módosítása
annak ellenőrzését és elfogadását
szoftver átvitele másik környezetbe
szoftverek leszerelése

20. A szoftver életciklusának támogató folyamatai

Dokumentáció
Konfiguráció-menedzsment
Minőségbiztosítás
Igazolás
Tanúsítvány
Részvételi értékelés
Könyvvizsgálat
Problémamegoldás

21. Dokumentációs folyamat

Dokumentáció - formalizált leírás
mindvégig létrehozott információk
szoftver életciklusa
Ez egy olyan műveletsor, amellyel
tervezés, tervezés, fejlesztés,
előállítani, szerkeszteni, terjeszteni és
kísérje el a mindenki számára szükséges dokumentumokat
a fejlesztésben részt vevő érintettek
Szoftverek, valamint rendszerfelhasználók számára

22. Konfigurációkezelés

A szoftver konfigurációja
funkcionális és fizikai összessége
a műszakiban megállapított jellemzőket
dokumentálása és a programokban való megvalósítása
A folyamat lehetővé teszi a rendszerezést, szisztematikusan
figyelembe veszi és szabályozza a változásokat
Szoftver az életciklus minden szakaszában
A konfigurációkezelés általános elveit és ajánlásait tükrözi
az ISO/IEC CD 12207 – 2:1995 „Információtechnológia – Szoftver” szabványban
Ciklus folyamatok. 2. rész. Szoftver konfigurációkezelés”

23. Minőségbiztosítási folyamat

Garanciát nyújt arra, hogy a szoftvertermék és
életciklus-folyamatai megfelelnek a megadottnak
követelményeknek, valamint kidolgozott és jóváhagyott
munkatervek
A minőség jellemző tulajdonságok összessége
a szoftver kielégítő képessége
minden érdeklődő igényeinek és igényeinek megfelelően
a felek
Az eljárás célja a megfelelés biztosítása
életciklus folyamatok, fejlesztési környezet és
a személyzet képzettsége a megállapított szerződés feltételei szerint
szabványok és eljárások. Ehhez léteznie kell
termékminőség, folyamatminőség és egyebek biztosítva vannak
rendszer minőségi mutatói

24. Ellenőrzés

Ez a folyamat annak megállapítására, hogy megfelel-e a jelenlegi fejlettségi állapot
ebben a szakaszban elért, ennek a szakasznak a követelményei. Folyamatban
az ellenőrzés a következő feltételeket ellenőrzi:
a rendszerkövetelmények összhangja és az igények figyelembevételének mértéke
felhasználó
a szállító azon képessége, hogy megfeleljen a meghatározott követelményeknek
a kiválasztott életciklus-folyamatok megfelelnek a szerződés feltételeinek
a szabványok, eljárások és fejlesztési környezet megfelelősége a szoftver életciklus-folyamataihoz
a tervezési előírásoknak a meghatározott követelményeknek való megfelelése
a leírás helyessége a bemenet és a kimenet tervezési specifikációiban
adatok, eseménysor, logika stb.
kód megfelelés a tervezési előírásoknak és követelményeknek
a kód tesztelhetősége és helyessége, az elfogadott szabványoknak való megfelelése
kódolás
a szoftverelemek helyes integrálása a rendszerbe
a dokumentáció megfelelősége, teljessége és következetessége
Az ellenőrzés összehasonlított műveletek összessége
a kapott életciklus eredményt a szükséges jellemzőkkel
ehhez a formális bizonyítéknak tekintett eredményhez
szoftver helyessége

25. Tanúsítás

rendelkezik a teljesség meghatározásáról
meghatározott követelményeknek való megfelelés és
létrehozott rendszert vagy szoftvert
termék sajátos
funkcionális célja
Ellenőrzés és tanúsítás – két nézet a minőségről:
ha az ellenőrzés során a szoftvert a létrehozási módja alapján értékelik,
akkor a tanúsítás a szoftverrendszert abból a szempontból veszi figyelembe
mit csinál (azaz felmérik a szoftverrendszer képességét
kielégíti a felhasználók funkcionális igényeit)

26. A szoftver életciklusának szervezeti folyamatai

Ellenőrzés
Infrastruktúra létrehozása (infrastruktúra
szoftver projekt tartalmaz technológiákat és
szabványok, valamint egy sor hardver,
szoftverek és eszközök
szoftver fejlesztése, üzemeltetése vagy karbantartása)
Javulás
Képzés (alapképzés és
későbbi állandó növekedés
a személyzet képesítése, beleértve a fejlesztést is
oktatási anyagok)

27. ESPD szabványok csoportjai

Csoport kód
0
1
2
3
4
5
6
7
8
9
Csoport név
Általános rendelkezések
Alapvető szabványok
A fejlesztési dokumentáció lebonyolításának szabályai
A gyártási dokumentáció kitöltésének szabályai
A támogatási dokumentáció végrehajtásának szabályai
Az üzemi dokumentáció végrehajtásának szabályai
A szoftverdokumentáció forgalmának szabályai
Tartalék csoportok
Egyéb szabványok
Az ESPD szabvány megnevezése a következőkből áll:
19. szám (az ESPD szabványok osztályához rendelve);
egy számjegy (a pont után), amely a szabványok osztályozási csoportjának kódját jelzi,
táblázatban feltüntetett;
egy kétjegyű szám (kötőjel után), amely a szabvány bejegyzésének évét jelzi

28. ESPD dokumentumok listája

GOST 19.001-77 ESPD. Általános rendelkezések
GOST 19.101-77 ESPD. Programtípusok és programdokumentumok
GOST 19.102-77 ESPD. Fejlesztési szakaszok
GOST 19.103-77 ESPD. Programok és programdokumentumok kijelölése
GOST 19.104-78 ESPD. Alapfeliratok
GOST 19.105-78 ESPD. A programdokumentumokra vonatkozó általános követelmények
GOST 19.106-78 ESPD. A nyomtatott programdokumentumokkal szemben támasztott követelmények
GOST 19.201-78 ESPD. Műszaki feladat. A tartalommal és a dizájnnal szemben támasztott követelmények
GOST 19.202-78 ESPD. Leírás. A tartalommal és a dizájnnal szemben támasztott követelmények
GOST 19.301-79 ESPD. Vizsgálati eljárás és módszertan
GOST 19.401-78 ESPD. Program szövege. A tartalommal és a dizájnnal szemben támasztott követelmények
GOST 19.402-78 ESPD. Program leírása
GOST 19.404-79 ESPD. Magyarázó jegyzet. A tartalommal és a dizájnnal szemben támasztott követelmények
GOST 19.501-78 ESPD. Forma. A tartalommal és a dizájnnal szemben támasztott követelmények
GOST 19.502-78 ESPD. Az alkalmazás leírása. A tartalommal és a dizájnnal szemben támasztott követelmények
GOST 19.503-79 ESPD. Rendszerprogramozói útmutató. Tartalmi követelmények és
bejegyzés
GOST 19.504-79 ESPD. Programozói útmutató
GOST 19.505-79 ESPD. Kezelési kézikönyv
GOST 19.506-79 ESPD. Nyelvi leírás
GOST 19.508-79 ESPD. Karbantartási leírás. Tartalmi követelmények és
bejegyzés
GOST 19.604-78 ESPD. A végrehajtott programdokumentumok módosításának szabályai
nyomtatott formában
GOST 19.701-90 ESPD. Algoritmusok, programok, adatok és rendszerek sémái. Egyezmények és
végrehajtási szabályokat
GOST 19.781-90. Információfeldolgozó rendszerek biztosítása

29. Az ESPD szabványok használatának előnyei

Az ESPD szabványok bevezetik a rendezés elemét
szoftver dokumentációs folyamat
(PS);
a készlet követelményei ellenére
a szabványok által biztosított szoftver dokumentációja
ESPD, lehetővé teszik további típusok hozzáadását
dokumentumok;
Az ESPD szabványok lehetővé teszik a mobilváltást
a kialakult fajok szerkezete és tartalma
követelmények alapján a programdokumentumok
ügyfél és felhasználó

30. Az ESPD szabványok hátrányai

egyetlen, „kaszkádos” életmodell felé orientáció
szoftverciklus;
egyértelmű dokumentációs irányelvek hiánya
a szoftver minőségi jellemzői;
rendszerszintű kapcsolat hiánya más meglévőkkel
életciklus-szabványok hazai rendszerei és
a termékek dokumentációja általában, például ESKD;
nem egyértelmű megközelítés a szoftver mint
kereskedelmi termékek;
a szoftver öndokumentálására vonatkozó ajánlások hiánya,
például képernyőmenük és online súgóeszközök formájában
felhasználó („segít”);
a kompozícióra, a tartalomra és a tervezésre vonatkozó ajánlások hiánya
dokumentumokkal megegyező szoftverhez
nemzetközi és regionális szabványok ajánlásait

31. GOST 34.601-90 szabvány: az automatizált rendszer létrehozásának szakaszai és szakaszai

1.
A hangszórókkal szemben támasztott követelmények kialakítása
2.
Az AC koncepció kidolgozása
3.
A tárgy tanulmányozása
A szükséges kutatómunka elvégzése
Az AC koncepció opcióinak kidolgozása és az AC koncepció opciójának kiválasztása,
megfelel a felhasználói követelményeknek
Beszámoló készítése az elvégzett munkáról
Műszaki feladat
4.
A létesítmény átvizsgálása és az atomerőmű létrehozásának szükségességének indoklása
A hangszórókkal szemben támasztott felhasználói követelmények kialakítása
Jelentés készítése a munkák befejezéséről és pályázat készítése atomerőmű fejlesztésére
Atomerőművek létrehozására vonatkozó műszaki előírások kidolgozása és jóváhagyása
Előzetes tervezés
A rendszer és részei előzetes tervezési megoldásainak kidolgozása

32.

Szabvány GOST 34.601-90: szakaszok és fázisok
automatizált rendszer létrehozása
5.
Műszaki projekt
6.
Munkadokumentáció
7.
Az atomerőmű és részei munkadokumentációjának kidolgozása
Programok kidolgozása, adaptálása
Üzembe helyezés
8.
A rendszer és részei tervezési megoldásainak kidolgozása
A hangszórórendszer és részei dokumentációjának kidolgozása
Alkatrészellátás dokumentációjának kidolgozása, kivitelezése
Tervezési feladatok kidolgozása a projekt szomszédos részein
Automatizálási objektum előkészítése
Személyzeti képzés
Komplett hangszórókészlet a mellékelt termékekkel (szoftver és hardver,
szoftver és hardver rendszerek, információs termékek)
Építési és szerelési munkák
Üzembe helyezési munkák
Előzetes vizsgálatok elvégzése
Próbaüzem lebonyolítása
Átvételi tesztek elvégzése
AC támogatás
A garanciális kötelezettségeknek megfelelő munkák elvégzése
Garancia utáni szerviz