Sziasztok, kedves Khabroviták! Szerintem érdekes lesz valakinek emlékezni arra, hogy milyen fejlesztési, megvalósítási és használati modelleket szoftver korábban is létezett, mely modelleket használják leginkább most, miért és mi is ez valójában. Ez lesz az én kis témám.
Tulajdonképpen mi az szoftver életciklusa- események sorozata, amelyek a rendszerrel annak létrehozása és további felhasználása során fordulnak elő. Más szóval, ez az idő bármely létrehozásának kezdeti pillanatától számítva szoftver termék fejlesztésének és megvalósításának végéig. Életciklus szoftver modellként ábrázolható.
Szoftver életciklus modell- egy szoftvertermék fejlesztése, használata és karbantartása során végrehajtott cselekvési folyamatokat és feladatokat tartalmazó struktúra.
Ezek a modellek 3 fő csoportra oszthatók:
- Mérnöki megközelítés
- A feladat sajátosságait figyelembe véve
- Modern gyorsfejlesztési technológiák
Kódolási és hibakezelési modell
Teljesen egyszerű modell egyetemistákra jellemző. A legtöbb diák e modell szerint fejleszt, mondjuk, laboratóriumi munkát.Ez a modell a következő algoritmussal rendelkezik:
- A probléma megfogalmazása
- Teljesítmény
- Az eredmény ellenőrzése
- Ha szükséges, menjen az első pontra
A vízesés szoftver életciklus-modellje (vízesés)
Ennek a módszernek az algoritmusa, amelyet az ábrán mutatok be, számos előnnyel rendelkezik az előző modell algoritmusához képest, de számos súlyos hiányosságait.Előnyök:
- A projekt szakaszainak szekvenciális végrehajtása szigorúan rögzített sorrendben
- Lehetővé teszi a termék minőségének értékelését minden szakaszban
- A szakaszok közötti visszacsatolás hiánya
- Nem felel meg a szoftvertermékfejlesztés valós feltételeinek
Kaszkád modell köztes vezérléssel (Whirlpool)
Ez a modell algoritmusában majdnem egyenértékű az előző modellel, de van Visszacsatolás az életciklus minden szakaszában, miközben nagyon jelentős hátrányt generál: 10-szeres fejlesztési költségek növekedése. A modellek első csoportjába tartozik.V modell (fejlesztés teszteléssel)
Ez a modell közelebb áll modern módszerek Az algoritmusnak azonban még van néhány hiányossága. Ez az extrém programozás egyik fő gyakorlata.
Modell alapú prototípus fejlesztés
Ez a modell prototípus- és termékprototípus-készítésen alapul.prototípus elkészítése a szoftver életciklusának korai szakaszában használják:
- A tisztázatlan követelmények tisztázása (UI prototípus)
- Válasszon egyet a számos koncepcionális megoldás közül (forgatókönyvek megvalósítása)
- A projekt megvalósíthatóságának elemzése
- Vízszintes és függőleges
- Eldobható és evolúciós
- papír és storyboardok
függőleges prototípusok - építészeti megoldások ellenőrzése.
Egyszer használatos prototípusok - a gyors fejlesztés érdekében.
evolúciós A prototípusok az evolúciós rendszer első közelítései.
A modell a második csoportba tartozik.
Spirális szoftver életciklus modell
A spirálmodell egy olyan szoftverfejlesztési folyamat, amely a tervezést és a növekményes prototípuskészítést egyaránt ötvözi az alulról felfelé és alulról felfelé építkező koncepciók előnyeinek ötvözésére.
Előnyök:
- Gyors eredmények
- A versenyképesség növelése
- A követelmények megváltoztatása nem jelent problémát
- A színpadi szabályozás hiánya
Köszönöm szépen a figyelmet!
Annotáció.
Bevezetés.
1. A szoftver életciklusa
Bevezetés.
Riley programozási folyamat lépései
Bevezetés.
1.1.1. A probléma megfogalmazása.
1.1.2. Megoldás tervezés.
1.1.3. Algoritmus kódolás.
1.1.4. Program támogatás.
1.1.5. Szoftver dokumentáció.
Következtetés az 1.1. bekezdéshez
1.2. A ZhTsPO meghatározása Lehman szerint.
Bevezetés.
1.2.1 A rendszer meghatározása.
1.2.2. Végrehajtás.
1.2.3. Szolgáltatás.
Következtetés az 1.2. ponthoz.
1.3. Az életciklus program fázisai és munkái Boehm szerint
1.3.1. kaszkád modell.
1.3.2. A kaszkádmodell közgazdasági alátámasztása.
1.3.3. A kaszkádmodell továbbfejlesztése.
1.3.4. Az életciklus fázisainak meghatározása.
1.3.5. A projekt alapmunkái.
Irodalom.
Bevezetés
A számítógépek ipari alkalmazása és a programok iránti növekvő igény sürgető feladatokat szabott a számok jelentős növelésére szoftverfejlesztési termelékenység, a programok tervezésének és tervezésének ipari módszereinek kidolgozása, szervezési, műszaki, műszaki, gazdasági és szociálpszichológiai technikák, minták és módszerek átadása az anyagtermelés szférájából a számítógépek szférájába. Komplex megközelítés a szoftverfejlesztési, üzemeltetési és karbantartási folyamatokhoz számos sürgető problémát vetett fel, amelyek megoldása megszünteti a programok tervezésének "szűk keresztmetszeteit", csökkenti a befejezési időt, javítja a meglévő programok kiválasztását és adaptálását, ill. talán meghatározza a beágyazott számítógépekkel rendelkező rendszerek sorsát.
A nagy szoftverprojektek fejlesztésének gyakorlatában gyakran nincs egységes megközelítés a munkaerőköltségek, a munkavégzési feltételek és az anyagköltségek értékelésére, ami gátolja a szoftverfejlesztés termelékenységének növelését, végső soron a szoftver életciklusának hatékony kezelését. Mivel bármilyen programból termék lesz (kivéve talán az oktatási, makettprogramokat), a gyártási megközelítésnek sok tekintetben hasonlónak kell lennie az ipari termékek előállításához, és a szoftvertervezési kérdések rendkívül fontossá válnak. . Ez az ötlet a B.U. Boehm "Szoftvermérnöki tervezés", amelyre ezt írtuk lejáratú papírok. Ebben a könyvben a szoftvertervezés egy szoftvertermék tervének elkészítésének folyamatát jelenti.
1 A szoftver életciklusa
BEVEZETÉS
Az LCPE egy folyamatos folyamat, amely attól a pillanattól kezdődik, amikor döntés születik a szoftver létrehozásának szükségességéről, és azzal a pillanattal ér véget, amikor azt teljesen kivonják a működésből.
Számos megközelítés létezik a szoftver életciklusának (SLLC) fázisainak és tevékenységeinek, a programozási folyamat lépéseinek, a vízesés és a spirálmodellek meghatározására. De mindegyik tartalmaz közös alapvető összetevőket: problémafelvetés, megoldástervezés, megvalósítás, karbantartás.
A leghíresebb és legteljesebb talán az életciklus Boehm szerinti felépítése, amely nyolc fázisból áll. Később részletesebben is bemutatjuk.
Az egyik lehetséges opció lehet a Lehman szerinti felső szint leírása, amely három fő fázist foglal magában, és a legáltalánosabb esetben az életciklus-program leírását jelenti.
És a változatosság kedvéért itt vannak a programozási folyamat lépései, amelyeket D. Riley mutat be a „Modula-2 nyelv használata” című könyvében. Ez az ötlet szerintem nagyon egyszerű és ismerős, és ezzel kezdjük is.
1.1 Riley programozási folyamat lépései
Bevezetés
A programozási folyamat négy lépésből áll (1. ábra):
problémafelvetés, i.e. megfelelő elképzelés szerzése arról, hogy a programnak milyen feladatot kell végrehajtania;
egy már felvetett probléma megoldásának megtervezése (általában egy ilyen megoldás kevésbé formális, mint a végleges program);
programkódolás, azaz a megtervezett megoldás gépen végrehajtható programmá fordítása;
programtámogatás, azaz a program hibáinak kijavításának és az új szolgáltatások hozzáadásának folyamatban lévő folyamata.
Rizs. 1. Négy programozási lépés.
A programozás attól a pillanattól kezdődik, amikor felhasználó, azaz akinek szüksége van egy programra a probléma megoldásához, az problémát jelent rendszerelemző. A felhasználó és a rendszerelemző közösen határozza meg a problémameghatározást. Ez utóbbit ezután áthelyezik algoritmus ki a felelős a megoldás megtervezéséért. A megoldás (vagy algoritmus) olyan műveletek sorozata, amelyek végrehajtása egy probléma megoldásához vezet. Mivel az algoritmust gyakran nem adaptálják gépen történő végrehajtásra, le kell fordítani gépi programmá. Ezt a műveletet a kódoló hajtja végre. A program későbbi módosításaiért a fenntartó a felelős. programozó. És a rendszerelemző, és az algoritmus, és a kódoló, és a kísérő programozó – mind programozók.
Nagy szoftverprojekt esetén jelentős lehet a felhasználók, rendszerelemzők és algoritmusok száma. Ezenkívül előre nem látható körülmények miatt szükségessé válhat a korábbi lépésekhez való visszatérés. Mindez további érvként szolgál a gondos szoftvertervezés mellett: minden lépés eredménye legyen teljes, pontos és érthető.
1.1.1 A probléma megfogalmazása
A programozás egyik legfontosabb lépése a probléma beállítása. Szerződésként működik a felhasználó és a programozó(k) között. Mint egy jogilag rosszul megfogalmazott szerződés, a rossz küldetésnyilatkozat is haszontalan. Jó problémafelvetés esetén mind a felhasználó, mind a programozó egyértelműen és egyértelműen reprezentálja az elvégzendő feladatot, azaz. ebben az esetben a felhasználó és a programozó érdekeit is figyelembe veszik. A felhasználó megtervezheti a még el nem készült szoftver használatát, a tudása alapján. A probléma jó megfogalmazása szolgál alapul a megoldás kialakításához.
A probléma megfogalmazása (program specifikáció); lényegében annak pontos, teljes és érthető leírását jelenti, hogy mi történik egy adott program végrehajtásakor. A felhasználó általában úgy tekint a számítógépre, mint egy fekete dobozra: számára nem mindegy, hogyan működik a számítógép, de fontos, hogy a számítógép meg tudja csinálni azt, ami a felhasználót érdekli. A hangsúly az ember és a gép közötti interakción van.
A jó problémanyilatkozat jellemzői:
Pontosság, azaz minden kétértelműség kizárása. Nem lehet kérdés, hogy egy adott bemenetre mi lesz a program kimenete.
teljesség, azaz egy adott bemenet összes lehetőségének mérlegelése, beleértve a hibás vagy váratlan bemenetet is, és a megfelelő kimenet meghatározása.
Világosság, azaz A felhasználó és a rendszerelemző számára is érthetőnek kell lennie, hiszen a problémafelvetés az egyetlen szerződés közöttük.
A pontosság, teljesség és egyértelműség követelményei gyakran ellentmondanak egymásnak. Igen, sok jogi dokumentumokat nehezen érthetőek, mert olyan formális nyelven íródnak, amely lehetővé teszi, hogy ezeket vagy azokat a rendelkezéseket a lehető legnagyobb pontossággal, a legjelentéktelenebb eltérések kizárásával fogalmazzák meg. Például egyes kérdések a vizsgadolgozatokon olykor olyan pontosan vannak megfogalmazva, hogy a hallgató több időt tölt a kérdés megértésével, mint a megválaszolásával. Ráadásul előfordulhat, hogy a tanuló egyáltalán nem fogja fel a kérdés fő jelentését a sok részlet miatt. A legjobb problémafelvetés az, amelyik mindhárom követelmény egyensúlyát eléri.
A problémafelvetés szabványos formája.
Tekintsük a következő problémameghatározást: "Írjon be három számot, és adja ki a számokat sorrendben."
Egy ilyen kijelentés nem felel meg a fenti követelményeknek: sem nem pontos, sem nem teljes, sem nem érthető. Valóban, soronként egyet kell beírni a számokat, vagy az összes számot egy sorban? A "sorrendben" kifejezés a legnagyobbtól a legkisebbig, a legkisebbtől a legnagyobbig történő rendezést jelenti, vagy ugyanazt a sorrendet, amelyben bevitték.
Nyilvánvaló, hogy egy ilyen kijelentés sok kérdésre nem ad választ. Ha minden kérdésre figyelembe vesszük a választ, akkor a problémafelvetés bőbeszédű és nehezen érthetővé válik. Ezért D. Riley a használatát javasolja alapforma, amely maximális pontosságot, teljességet, tisztaságot biztosít, és a következőket tartalmazza:
feladat neve (sematikus definíció);
általános leírás (a feladat rövid ismertetése);
hibák (a szokatlan beviteli lehetőségek kifejezetten vannak felsorolva, hogy megmutassák a felhasználóknak és a programozóknak, hogy a gép milyen műveleteket hajt végre ilyen helyzetekben);
példa ( jó példaátadhatja a probléma lényegét, valamint szemléltetheti a különféle eseteket).
Példa. A probléma megfogalmazása szabványos formában.
CÍM
Rendezzen három egész számot.
LEÍRÁS
Három egész szám bevitele és kimenete, a legkisebbtől a legnagyobbig rendezve.
Három egész szám kerül beírásra, soronként egy szám. Ebben az esetben az egész szám egy vagy több egymást követő decimális számjegy, amelyet egy pluszjel „+” vagy egy mínusz „-” előzhet meg.
A három beírt egész szám megjelenik, és mindhárom ugyanabban a sorban jelenik meg. A szomszédos számokat szóköz választja el. A számok a legkisebbtől a legnagyobbig, balról jobbra jelennek meg.
1) Ha háromnál kevesebb számot ad meg, a program további bevitelre vár.
2) Az első háromtól eltérő bemeneti sorokat figyelmen kívül hagyja.
Tekintsük a szoftver életciklusát (SW), pl. létrehozásának és alkalmazásának folyamata az elejétől a végéig. Az életciklus a szoftver megjelenésének tudatosításának pillanatától kezdődik, és a teljes elavultság pillanatával ér véget. Ez a folyamat több szakaszból áll: követelmények és specifikációk meghatározása, tervezés, programozás és karbantartás.
Az első szakaszt, a követelmények és előírások meghatározását rendszerelemzési szakasznak nevezhetjük. Telepítve vannak rajta Általános követelmények Szoftver: megbízhatóság, gyárthatóság, korrektség, egyetemesség, hatékonyság, információkonzisztencia stb.
Kiegészülnek a vevői igényekkel, ideértve a tér-idő korlátokat, a szükséges funkciókat és képességeket, működési módokat, pontossági és megbízhatósági követelményeket stb., vagyis a rendszer leírása a felhasználó szemszögéből készül.
Amikor meghatározzák specifikációk(követelmények és paraméterek összessége, amelyeknek a szoftvernek meg kell felelnie) a szoftver funkcióinak pontos leírása, a beviteli és köztes nyelvek fejlesztése és jóváhagyása, az egyes alrendszerek kimeneti információinak formája, lehetséges interakció más szoftverekkel Megtörténik a rendszerek ismertetése, a szoftverbővítéshez és -módosításhoz szükséges eszközök megadása, az interfészek fejlesztése a szerviz és a fő alrendszerek, az adatbázis-problémák megoldása, az alapvető algoritmusok jóváhagyása.
Ennek a szakasznak az eredménye a működési és funkcionális specifikációk, amelyek a szoftver konkrét leírását tartalmazzák. A specifikáció kidolgozása az ügyfelekkel állandó kapcsolatban álló rendszerelemzők gondos munkáját követeli meg, akik a legtöbb esetben nem tudnak egyértelmű és reális követelményeket megfogalmazni.
A működési specifikációk információkat tartalmaznak a szoftver sebességéről, a szükséges memóriaköltségekről technikai eszközökkel, megbízhatóság stb.
A funkcionális specifikációk meghatározzák azokat a funkciókat, amelyeket a szoftvernek teljesítenie kell, pl. azt határozzák meg, hogy a rendszer mit tegyen, nem pedig azt, hogyan tegye.
A specifikációnak teljesnek, pontosnak és világosnak kell lennie. A teljesség szükségtelenné teszi a szoftverfejlesztőknek, hogy munkájuk során más információkat is beszerezzenek az ügyfelektől, kivéve a specifikációban foglaltakat. A pontosság nem tesz lehetővé különböző értelmezéseket. Az egyértelműség azt jelenti, hogy mind az ügyfél, mind a fejlesztő könnyen érthető, egyértelmű értelmezés mellett.
A specifikációk jelentése:
1. A specifikációk a szoftverfejlesztés feladata, megvalósításuk pedig a fejlesztő törvénye.
2. A specifikációk a szoftver készenlétének ellenőrzésére szolgálnak.
3. A specifikációk a szoftverdokumentáció szerves részét képezik, megkönnyítik a szoftver karbantartását és módosítását,
A második szakasz a szoftvertervezés. Ezen a ponton:
1. A szoftver szerkezetének kialakítása és a specifikációkban meghatározott algoritmusok kialakítása.
2. A modulok összetételét az algoritmussémák tanulmányozása alapján hierarchikus szintre bontással állapítjuk meg.
3. Az információs tömbök szerkezete kiválasztásra kerül.
4. A modulok közötti interfészek rögzítettek.
A színpad célja a szoftverkészítés összetett feladatainak hierarchikus felosztása kevésbé bonyolult részfeladatokra. Az ebben a szakaszban végzett munka eredménye az egyes modulok specifikációi, amelyek további bontása nem megfelelő.
Harmadik szakasz - programozás. Ebben a szakaszban a modulok programozásra kerülnek. az előző szakaszban kapott tervezési megoldásokat programok formájában valósítják meg. Külön blokkokat fejlesztenek ki és kapcsolnak a létrehozandó rendszerhez. Az egyik feladat az tájékozott választás programozási nyelvek. Ugyanebben a szakaszban a számítógép típusának jellemzőivel kapcsolatos összes probléma megoldódik.
Negyedik szakasz - szoftveres hibakeresés A rendszer minden követelményét, minden szerkezeti elemét tesztelni kell az adatok annyi lehetséges kombinációján, amennyit a józan ész és a költségvetés lehetővé tesz. A szakasz magában foglalja a programok hibáinak azonosítását, a szoftver működésének ellenőrzését, valamint a specifikációknak való megfelelést.
Ötödik szakasz - kíséret, azok. a hibák kijavításának folyamata, a rendszer minden elemének összehangolása a felhasználó igényei szerint, minden szükséges javítás és változtatás elvégzése.
A szoftverfejlesztés megkezdése előtt marketinget kell végezni.
Marketing a létrehozott szoftvertermék (műszaki, szoftver, felhasználói) követelményeinek tanulmányozására készült. A meglévő analógokat és a versengő termékeket is tanulmányozzák. Az anyag, a munka és pénzügyi források, valamint hozzávetőleges fejlesztési idővonalak. A szoftverfejlesztés szakaszait a GOST 19.102-77 írja le. Ennek megfelelően adjuk meg a neveket és Rövid leírás minden szakaszban (lásd 1. táblázat). Ez a nemzetközi szabvány meghatározza a programok és a programdokumentáció fejlesztési szakaszait számítógépek, komplexek és rendszerek, céljuktól és hatókörüktől függetlenül.
Asztal 1
A fejlesztés szakaszai, a szoftverkészítési munka szakaszai és tartalma
Életciklus egy modell egy szoftverrendszer létrehozásához és használatához. Különböző állapotokat tükröz szoftver rendszer, kezdve attól a pillanattól kezdve, hogy felmerül az igény erre a szoftverrendszerre és a létrehozásáról szóló döntésre, és a szoftverrendszer teljes kivonásáig.
Az ISOIES 12207 nemzetközi szabvány életciklus keretrendszert határoz meg, amely tartalmazza a szoftverfejlesztés során elvégzendő folyamatokat, tevékenységeket és feladatokat. E szabvány szerint a szoftver életciklusa három folyamatcsoporton alapul:
a fő életciklus-folyamatok, azaz a beszerzés, ellátás, fejlesztés, üzemeltetés és karbantartás;
segédfolyamatok, amelyek biztosítják a fő folyamatok végrehajtását, azaz a dokumentációt, az ellenőrzést, a tanúsítást, a minőségértékelést és egyebeket;
szervezeti folyamatok, azaz projektmenedzsment, projekt infrastruktúra kialakítása és képzése.
A fejlesztés magában foglalja az összes olyan munkát, amely a meghatározott követelményeknek megfelelő szoftver létrehozására irányul. Ez magában foglalja a tervezési és üzemeltetési dokumentáció elkészítését, a szoftvertermékek teljesítményének és minőségének teszteléséhez szükséges anyagok elkészítését.
A fejlesztési folyamat főbb szakaszai:
vevői igények elemzése;
tervezés;
megvalósítás (programozás).
Az üzemeltetési folyamat része a szoftverek üzembe helyezésének munkája, ideértve a munkahelyek konfigurálását, a személyzet képzését, az üzemeltetési problémák lokalizálását és okainak elhárítását, a szoftver módosítását a megállapított előírásokon belül és a rendszerkorszerűsítési javaslatok elkészítését.
Minden folyamatot bizonyos feladatok és megoldási módszerek, valamint kiindulási adatok és eredmények jellemeznek.
A szoftver életciklusa rendszerint iteratív jellegű, vagyis a szakaszok a legkorábbiaktól kezdve valósulnak meg, amelyek ciklikusan ismétlődnek a külső feltételek változó követelményeinek és a korlátozások bevezetésének megfelelően.
Szoftver életciklus modellek
Számos életciklus-modell létezik, amely meghatározza a fejlesztési szakaszok végrehajtásának sorrendjét és a szakaszról szakaszra való átlépés kritériumait. Eddig két életciklus-modellt használnak a legszélesebb körben: lépcsőzetesés spirál.
A korábban meglévő homogénben információs rendszerek ah minden alkalmazás egyetlen egység volt. Az ilyen alkalmazások fejlesztésére a vízesés életciklus-modellt, más néven klasszikus vagy vízesés.
A vízesés modell használatakor a fejlesztést szakaszok sorozatának tekintették, és a következő alsó szakaszba való átmenet csak akkor történik meg, ha a jelenlegi szakaszban az összes munka befejeződött. Nyilvánvaló, hogy a vízesés-modellben a fejlesztés a rendszer szintjén kezdődik, és elemzésen, tervezésen, kódoláson, tesztelésen és karbantartáson keresztül halad.
1. ábra - A vízesés modell kidolgozásának főbb állomásai
1. A rendszerelemzés meghatározza az egyes elemek szerepét a számítógépes rendszerben és az elemek egymás közötti kölcsönhatását. Mivel a szoftvert egy nagy rendszer részének tekintjük, az elemzés az összes rendszerelemre vonatkozó követelmények meghatározásával kezdődik. A rendszerelemzés igénye egyértelműen megnyilvánul, amikor kialakul a szoftver interfésze más elemekkel, pl. hardverrel vagy adatbázisokkal. Ugyanebben a szakaszban kezdődik a projekttervezési feladatok megoldása. A projekttervezés során meghatározzák a tervezési munkák körét és azok kockázatát, a szükséges munkaerőköltségeket, kialakítják a munkafeladatokat, munkarendet.
A követelményelemzés egyetlen szoftverelemre vonatkozik. Ebben a szakaszban az egyes elemek funkcióit, jellemzőit és interfészét meghatározzuk és részletezzük. Ugyanebben a szakaszban a projekttervezési probléma megoldása is elkészül.
2. A tervezés a következőkből áll:
szoftver architektúrák;
a szoftver moduláris felépítése;
a szoftver algoritmikus felépítése;
adatstruktúrák;
bemeneti/kimeneti interfész (bemeneti/kimeneti adatlapok).
A tervezési problémák megoldása során a fő figyelmet a jövőbeni szoftvertermék minőségére fordítják.
3. A kódolás vagy fejlesztés a tervezés eredményeinek programkódba fordításából áll.
4. A tesztelés egy program végrehajtása a szoftvertermék funkcióinak, logikájának és megvalósítási formájának hibáinak azonosítására.
5. A karbantartás olyan változtatások bevezetése az üzemeltetett szoftverben, amelyek célja:
hibajavítások;
alkalmazkodás a szoftveren kívüli környezet változásaihoz;
szoftverfejlesztés a vevői igényeknek megfelelően.
A vízesés modell használatának előnyei:
tervet és ütemtervet ad mindenkinek projekt szakaszaiban, ezzel racionalizálva a fejlődés menetét;
minden szakaszban a projektdokumentáció teljes készlete készül, amelynek teljességét és következetességét ellenőrzik;
a logikai sorrendben végzett munka szakaszai lehetővé teszik az összes munka befejezésének ütemezését és a kapcsolódó költségeket.
A kaszkádmodell jól bevált épületinformációs rendszerekben, amelyekhez a fejlesztés legelején a rendszerben lévő összes követelmény elég pontosan megfogalmazható, például komplex számítási rendszerek, különféle valós idejű rendszerek stb.
A vízesés modell hátrányai:
a valódi projektek gyakran eltérést igényelnek a lépések szokásos sorrendjétől;
a vízesés modell a szoftverrel szemben támasztott kezdeti követelmények pontos megfogalmazásán alapul, azonban bizonyos esetekben a valóságban a projekt elején a megrendelő igényei csak részben határozódnak meg;
A projekt megvalósításának eredményei csak az összes munka befejezése után állnak a megrendelő rendelkezésére.
Tekintettel arra, hogy a szoftverfejlesztési folyamatban folyamatosan vissza kell térni az előző szakaszokhoz és tisztázni vagy felülvizsgálni a korábban meghozott döntéseket, a vízesés modellen alapuló valós szoftverfejlesztési folyamatot az alábbi diagrammal ábrázolhatjuk (2. ábra).
2. ábra - A szoftverfejlesztési folyamat a vízesés modell alapján
A szoftver életciklusa hat szakaszból áll:
- követelményelemzés;
– az előírások meghatározása;
– tervezés;
– kódolás;
– tesztelés;
- kíséret.
Követelményelemzés. A szoftverfejlesztésben rendkívül fontos. Az ebben a szakaszban elkövetett hibák a következő szakaszok hibátlan végrehajtása esetén is oda vezethetnek, hogy a kifejlesztett szoftvertermék nem felel meg a gyakorlati követelményeknek, az alkalmazási körnek. Ahhoz, hogy ebben a szakaszban versenyképes termékeket hozzanak létre, egyértelmű válaszokat kell kapni a kérdésekre. következő kérdéseket:
Mit kell tennie a programnak?
– Melyek azok a valódi problémák, amelyek megoldásához hozzá kell járulnia?
- Mik a bemeneti adatok?
Mi legyen a kimenet?
Milyen erőforrásokkal rendelkezik a tervező?
A specifikációk meghatározása. Leírás- egy program, adatelem vagy egyéb objektum tulajdonságainak, jellemzőinek és funkcióinak pontos és teljes formai leírása. Ez a szakasz bizonyos mértékig az előző szakasz eredményeiből következő következtetések megfogalmazásának tekinthető. A programkövetelményeket specifikációk halmazaként kell bemutatni, amelyek kifejezetten meghatározzák a jövőbeli program teljesítményét. Ilyen jellemzők lehetnek a végrehajtási sebesség, a felhasznált memória mennyisége, az alkalmazás rugalmassága stb.
Tervezés. Ebben a szakaszban létrejön a program általános struktúrája, amelynek meg kell felelnie az előírásoknak; eltökélt Általános elvek kezelése és interakciója a program különböző összetevői között.
Kódolás. Ez abból áll, hogy a tervezési nyelven írt struktúrákat lefordítja a programozási nyelvre.
Tesztelés. Ebben a szakaszban a programok átfogó ellenőrzésére kerül sor.
Kíséret. Ez a rendszer működési fázisa. Bármennyire is kifinomult a programtesztelés, sajnos a nagy szoftverrendszerekben rendkívül nehéz abszolút minden hibát kiküszöbölni. Ennek a szakasznak az első feladata a működés közben feltárt hibák kiküszöbölése. A karbantartás során azonban ez nem minden. A program üzemeltetési tapasztalatainak karbantartás során végzett elemzése lehetővé teszi az egyes részeken „szűk keresztmetszetek” vagy sikertelen tervezési döntések feltárását. Szoftver csomag. Egy ilyen elemzés eredményeként döntés születhet a kidolgozott rendszer javítását célzó munkák elvégzéséről. A támogatás magában foglalhatja a konzultációkat, a rendszerhasználók képzését, a felhasználók azonnali tájékoztatását a rendszer új verzióiról. A karbantartási szakasz minősége nagymértékben meghatározza a szoftvertermék kereskedelmi sikerét.
Tesztelés. A program ellenőrzésének három szempontja van:
- helyesség;
– végrehajtási hatékonyság;
- számítási bonyolultság.
Az érvényesítés ellenőrzi, hogy a program pontosan azt csinálja-e, amire szánták. Az algoritmus matematikai tökéletessége nem garantálja a programba való fordítás helyességét. Ugyanígy sem a fordítói diagnosztikai üzenetek hiánya, sem a kapott eredmények ésszerű megjelenése nem ad kellő garanciát a program helyességére. Az érvényesítés általában egy tesztsorozat tervezéséből és futtatásából áll. Emellett a programok kiszámításához esetenként lehetőség van a kapott megoldások összehasonlítására egy már ismert megoldással. Általában nem adhatsz közös megoldás hogy teszteljük a program helyességét.
A számítási komplexitás ellenőrzése általában egy algoritmus bonyolultságának kísérleti elemzéséből vagy két vagy több, ugyanazt a problémát megoldó algoritmus kísérleti összehasonlításából áll.
Egy implementáció hatékonyságának tesztelése azt jelenti, hogy megtaláljuk a módját, hogy egy megfelelő programot gyorsabban fusson, vagy kevesebb memóriát használjon. A program fejlesztése érdekében az algoritmus felépítése során áttekintjük a megvalósítás eredményeit. Nem mindent figyelembe véve lehetséges opciókés a programoptimalizálási irányok, itt van néhány hasznos módszer a programvégrehajtás sebességének növelésére.
Az első módszer a következő szabályon alapul. Az összeadás és kivonás gyorsabb, mint a szorzás és az osztás. Az egész számok aritmetika gyorsabb, mint a valós számok. Tehát X+X jobb, mint 2*X, ahol * a szorzójel. Egész számokkal végzett műveletek végrehajtása során emlékezni kell arra, hogy a kettes számrendszer használata miatt a kettő többszörösei számokkal való szorzás helyettesíthető a megfelelő számú eltolással balra.
A második módszer a redundáns számítások eltávolítása.
A megvalósítás hatékonyságának tesztelésének harmadik módja egyes fordítók azon képességén alapul, hogy kódokat hoznak létre a logikai kifejezések kiértékeléséhez, így a kiértékelés leáll, amikor az eredmény nyilvánvalóvá válik. Például az A vagy B vagy C kifejezésben, ha A igaz, akkor a B és C változók már nem kerülnek ellenőrzésre. Így időt takaríthat meg, ha az A, B, C változókat úgy rendezi el, hogy az első változó legyen a legvalószínűbb, az utolsó pedig a legkevésbé.
A negyedik technika a ciklusok megszüntetése.
Az ötödik technika a ciklusok kigöngyölítése.
Ez nem az optimalizálási módszerek teljes listája. Íme csak a legnyilvánvalóbbak. Ezenkívül meg kell jegyezni, hogy nem mindig szükséges a gyorsaságra való törekvésben részt venni, mivel ez leggyakrabban rontja a programok olvashatóságát. Abban az esetben, ha az erősítés „elhanyagolható”, aligha érdemes ezt előnyben részesíteni a program áttekinthetősége és olvashatósága helyett.