Tarkvaraarendus on võimatu ilma nn tarkvara elutsükli mõistmiseta. Tavakasutaja võib-olla ei pea seda teadma, küll aga on soovitav põhistandardid selgeks õppida (milleks see vajalik on, sellest räägitakse hiljem).
Mis on elutsükkel formaalses mõttes?
Iga inimese elutsükli all on tavaks mõista selle olemasolu aega, alates arenguetapist kuni hetkeni. täielik ebaõnnestumine alates kasutamisest valitud kasutusvaldkonnas kuni rakenduse täieliku kasutusest eemaldamiseni.
Lihtsamalt öeldes on infosüsteemid programmide, andmebaaside või isegi operatsioonisüsteemide kujul nõutud ainult siis, kui andmed ja nende pakutavad võimalused on asjakohased.
Arvatakse, et elutsükli definitsioon ei kehti mitte mingil moel testimisrakenduste, näiteks beetaversioonide puhul, mis on töös kõige ebastabiilsemad. Tarkvara elutsükkel ise sõltub paljudest teguritest, millest üks peamisi rolle mängib keskkond, milles programmi hakatakse kasutama. Siiski võib eristada üldtingimused kasutatakse elutsükli mõiste määratlemisel.
Esialgsed nõuded
- probleemi sõnastus;
- tulevase tarkvara vastastikuste nõuete analüüs süsteemile;
- disain;
- programmeerimine;
- kodeerimine ja koostamine;
- testimine;
- silumine;
- tarkvaratoote juurutamine ja hooldus.
Tarkvaraarendus koosneb kõigist ülalnimetatud etappidest ja ei saa läbi ilma vähemalt üheta. Kuid selliste protsesside kontrollimiseks kehtestatakse spetsiaalsed standardid.
Tarkvara elutsükli protsessi standardid
Selliste protsesside tingimused ja nõuded eelnevalt kindlaks määravate süsteemide hulgast saab täna nimetada ainult kolme peamist:
- GOST 34.601-90;
- ISO/IEC 12207:2008;
- Oracle CDM.
Teise jaoks rahvusvaheline standard on olemas venekeelne vaste. See on GOST R ISO / IEC 12207-2010, mis vastutab süsteemide ja tarkvaratehnika eest. Aga elutsükkel tarkvara, mida on kirjeldatud mõlemas reeglis, on sisuliselt identne. Seda seletatakse üsna lihtsalt.
Tarkvara tüübid ja värskendused
Muide, enamiku praegu tuntud multimeediumiprogrammide jaoks on need peamised konfiguratsiooniseadete salvestamise vahendid. Seda tüüpi tarkvara kasutamine on muidugi üsna piiratud, kuid samade meediumipleieritega töötamise üldiste põhimõtete mõistmine ei tee paha. Ja sellepärast.
Tegelikult on neil tarkvara elutsükkel ainult mängija enda versiooni või koodekite ja dekooderite installimise värskendusperioodi tasemel. Ja heli- ja videotranskooderid on iga heli- või videosüsteemi olulised atribuudid.
Näide põhineb FL Studiol
Algselt kandis virtuaalset stuudio-sekvenaatorit FL Studio nime Fruity Loops. Eluring Tarkvara esmases modifikatsioonis on aegunud, kuid rakendust on mõnevõrra muudetud ja see on omandanud praeguse kuju.
Kui me räägime elutsükli etappidest, siis alguses seati ülesande püstitamise etapis mitu kohustuslikku tingimust:
- trummimooduli loomine, mis sarnaneb rütmimasinatele nagu Yamaha RX, kuid kasutades ühekordseid sämpleid või stuudiotes otse salvestatud WAV-seeriaid;
- integreerimine Windowsi operatsioonisüsteemidesse;
- võimalus projekti eksportida WAV-, MP3- ja OGG-vormingus;
- projekti ühilduvus lisarakendusega Fruity Tracks.
Arendusetapis kasutati C-programmeerimiskeelte tööriistu. Kuid platvorm nägi välja üsna primitiivne ega lubanud lõppkasutajale nõutav kvaliteet heli.
Sellega seoses pidid arendajad testimise ja silumise etapis järgima Saksa korporatsiooni Steinbergi teed ja rakendama peamise helidraiveri nõuetes Full Duplex-režiimi tuge. Heli kvaliteet on muutunud kõrgemaks ja võimaldab muuta tempot, helikõrgust ja rakendada reaalajas täiendavaid FX-efekte.
Selle tarkvara elutsükli lõpuks loetakse esimese väljalaskmiseks ametlik versioon FL Studio, millel erinevalt oma esivanematest oli juba täisväärtuslik sekvenseriliides, millel oli võimalus muuta parameetreid virtuaalsel 64-kanalilisel mikseripuldil koos piiramatu heli- ja MIDI-palade lisamisega.
See ei olnud piiratud. Projektihalduse etapis võeti kasutusele Steinbergi välja töötatud VST-vormingus pistikprogrammide ühendamise tugi (kõigepealt teine ja seejärel kolmas versioon). Ligikaudselt võib programmiga ühenduda iga virtuaalne süntesaator, mis toetab VST-hosti.
Pole üllatav, et peagi võib iga helilooja kasutada "raudsete" mudelite analooge, näiteks kunagise populaarse Korg M1 helikomplekte. Edasi veel. Moodulite, nagu Addictive Drums või universaalse Kontakt-plugina kasutamine võimaldas taasesitada professionaalsetes stuudiotes kõigi liigendusvarjunditega salvestatud tõeliste instrumentide elavaid helisid.
Samal ajal püüdsid arendajad saavutada maksimaalset kvaliteeti, luues toe ASIO4ALL draiveritele, mis osutusid täisdupleksrežiimist kõrgemaks. Sellest lähtuvalt suurenes ka bitikiirus. Praeguseks on eksporditud helifaili kvaliteet 192 kHz diskreetimissagedusel 320 kbps. See on professionaalne heli.
Mis puutub esialgsesse versiooni, siis selle elutsüklit võib nimetada täiesti lõppenuks, kuid selline väide on suhteline, kuna rakendus on muutnud ainult nime ja saanud uusi funktsioone.
Arenguväljavaated
Millised on tarkvara elutsükli etapid, on juba selge. Kuid selliste tehnoloogiate arendamine väärib eraldi mainimist.
Ütlematagi selge, et ükski tarkvaraarendaja ei ole huvitatud põgusa toote loomisest, mis tõenäoliselt ei jää turule mõneks aastaks. Tulevikus vaatavad kõik selle pikaajalist kasutamist. Seda on võimalik saavutada erinevatel viisidel. Kuid reeglina taanduvad peaaegu kõik neist värskenduste või programmide uute versioonide väljaandmisele.
Isegi Windowsi puhul on selliseid trende palja silmaga näha. On ebatõenäoline, et täna on vähemalt üks kasutaja, kes kasutab selliseid süsteeme nagu modifikatsioonid 3.1, 95, 98 või Millennium. Nende elutsükkel lõppes pärast XP versiooni väljaandmist. Kuid NT-tehnoloogiatel põhinevad serveriversioonid on endiselt asjakohased. Isegi Windows 2000 pole tänapäeval mitte ainult väga ajakohane, vaid ületab isegi mõnede installi- või turvaparameetrite osas uusimaid arenguid. Sama kehtib nii NT 4.0 süsteemi kui ka Windows Server 2012 spetsiaalse modifikatsiooni kohta.
Kuid seoses nende süsteemidega deklareeritakse endiselt toetust kõrge tase. Kuid omal ajal sensatsiooniline Vista kogeb selgelt tsükli langust. See ei osutus mitte ainult lõpetamata, vaid selle turvasüsteemis oli nii palju vigu ja lünki, et võib vaid aimata, kuidas selline vastuvõetamatu lahendus tarkvaraturule pääses.
Aga kui me räägime sellest, et mis tahes tüüpi tarkvara (haldus või rakendus) arendamine ei seisa paigal, on see ainult võimalik.. Tänapäeval ei ole see ju ainult arvutisüsteemid ja mobiilseadmed milles rakendatavad tehnoloogiad on sageli arvutisektorist ees. Kaheksal tuumal põhinevate protsessorikiipide tekkimine - kui mitte kõige rohkem parim näide? Kuid mitte iga sülearvuti ei saa sellise riistvaraga kiidelda.
Mõned lisaküsimused
Tarkvara elutsükli mõistmise kohta võib öelda, et see lõppes mingil konkreetsel ajahetkel, see on väga tinglik, sest tarkvaratoodetel on endiselt olemas nende loonud arendajate tugi. Pigem viitab lõpp pärandrakendustele, mis nõuetele ei vasta kaasaegsed süsteemid ja ei saa oma keskkonnas töötada.
Aga isegi arvestades tehniline progress paljud neist võivad peagi muutuda vastuvõetamatuks. Siis peate tegema otsuse, kas avaldada värskendused või vaadata täielikult läbi kogu kontseptsioon, mis algselt tarkvaratootesse kaasati. Sellest ka uus tsükkel, mis hõlmab algtingimuste, arenduskeskkonna muutmist, testimist ja võimalikku pikaajalist rakendamist mingis piirkonnas.
Kuid tänapäeval eelistatakse arvutitehnoloogias automatiseeritud juhtimissüsteemide (ACS) väljatöötamist, mida kasutatakse tootmises. Isegi operatsioonisüsteemid kaotavad võrreldes spetsiaalsete programmidega.
Samad Visual Basicul põhinevad keskkonnad on endiselt palju populaarsemad kui Windowsi süsteemid. Ja me ei räägi üldse UNIX-süsteemide rakendustarkvarast. Mida ma saan öelda, kui peaaegu kõik sama Ameerika Ühendriikide sidevõrgud töötavad ainult nende jaoks. Muide, sellel platvormil loodi algselt ka sellised süsteemid nagu Linux ja Android. Seetõttu on UNIXil tõenäoliselt palju rohkem väljavaateid kui teistel toodetel kokku.
Kogusumma asemel
Jääb veel lisada, et sel juhul antud ainult üldised põhimõtted ja tarkvara elutsükli etapid. Tegelikult võivad isegi esialgsed ülesanded väga oluliselt erineda. Sellest tulenevalt võib erinevusi täheldada ka muudel etappidel.
Kuid tarkvaratoodete arendamise põhitehnoloogiad koos nende hilisema hooldusega peaksid olema selged. Ülejäänu osas tuleks arvestada loodava tarkvara spetsiifikat, keskkondi, milles see peaks töötama ning lõppkasutajale või tootmisele pakutavate programmide võimalusi ja palju muud.
Lisaks võivad elutsüklid mõnikord sõltuda arendusvahendite asjakohasusest. Kui näiteks mõni programmeerimiskeel vananeb, ei hakka keegi selle põhjal programme kirjutama ja veelgi enam - juurutama neid automatiseeritud süsteemid tootmise juhtimine. Siin ei tõuse esiplaanile isegi mitte programmeerijad, vaid turundajad, kes peavad arvutituru muutustele õigeaegselt reageerima. Ja selliseid spetsialiste pole maailmas nii palju. Kõige nõutavam on kõrgelt kvalifitseeritud personal, kes suudab turuga kursis olla. Ja just nemad on sageli nn "hallid kardinalid", kellest sõltub mõne IT-valdkonna tarkvaratoote edu või ebaõnnestumine.
Kuigi nad ei saa alati aru programmeerimise olemusest, suudavad nad selgelt kindlaks määrata tarkvara elutsükli mudelid ja nende kasutamise kestuse, lähtudes selle valdkonna globaalsetest trendidest. Tõhus juhtimine annab sageli käegakatsutavamaid tulemusi. Jah, vähemalt PR-tehnoloogiad, reklaam jne. Mõnda rakendust kasutajal ei pruugi vaja minna, aga kui seda aktiivselt reklaamitakse, installib kasutaja selle. See on juba nii-öelda alateadvuse tasand (sama 25. kaadri efekt, kui info pannakse kasutaja mõistusesse temast sõltumata).
Muidugi on sellised tehnoloogiad maailmas keelatud, kuid paljud meist isegi ei taipa, et neid saab siiski kasutada ja alateadvust teatud viisil mõjutada. Mida väärt on uudistekanalite või internetilehekülgede “zombimine”, rääkimata võimsamate vahendite kasutamisest, näiteks infraheliga kokkupuutumisest (seda kasutati ühes ooperilavastuses), mille tulemusena võib inimene kogeda hirmu või ebapiisavad emotsioonid.
Tarkvara juurde tagasi tulles tasub lisada, et mõned programmid kasutavad käivitamisel kasutaja tähelepanu köitmiseks helisignaali. Ja uuringud näitavad, et sellised rakendused on elujõulisemad kui teised programmid. Loomulikult pikeneb ka tarkvara elutsükkel, olenemata sellest, mis funktsioonile see algselt määratud oli. Ja seda kasutavad kahjuks paljud arendajad, mis tekitab kahtlusi selliste meetodite seaduslikkuses.
Kuid meie asi ei ole seda hinnata. Võimalik, et lähitulevikus töötatakse välja vahendid selliste ohtude tuvastamiseks. Siiani on see vaid teooria, kuid mõnede analüütikute ja ekspertide sõnul varem praktilise rakendamise väga vähe on jäänud. Kui nad juba loovad inimaju närvivõrkude koopiaid, siis mida ma saan öelda?
Riis. 5.2.
Need aspektid on:
- lepinguline aspekt, milles klient ja tarnija sõlmivad lepinguline suhe ning rakendama hankimis- ja tarneprotsesse;
- juhtimisaspekt, mis hõlmab tarkvara elutsüklis osalevate isikute (tarnija, tellija, arendaja, operaatori jne) juhtimistoiminguid;
- toimimise aspekt, mis hõlmab operaatori tegevust süsteemi kasutajatele teenuste osutamisel;
- inseneriaspekt, mis sisaldab arendaja või tugiteenuse tegevust tarkvaratoodete arendamise või muutmisega seotud tehniliste probleemide lahendamiseks;
- tugiprotsesside rakendamisega kaasnev toe aspekt, mille kaudu tugiteenused osutavad vajalikke teenuseid kõigile teistele töös osalejatele. Selles aspektis võib välja tuua tarkvara kvaliteedijuhtimise aspekti, sealhulgas kvaliteedi tagamise protsessid, verifitseerimine, sertifitseerimine, ühishindamine ja audit.
Organisatsiooniprotsesse teostatakse ettevõtte tasandil või kogu organisatsiooni kui terviku tasandil, luues aluse tarkvara elutsükli protsesside juurutamiseks ja pidevaks täiustamiseks.
5.6. Tarkvara elutsükli mudelid ja etapid
Tarkvara elutsükli mudeli all mõistetakse struktuuri, mis määrab täitmisjärjekorra ning protsesside, toimingute ja ülesannete seose kogu tarkvara elutsükli jooksul. Elutsükli mudel sõltub projekti spetsiifikast, ulatusest ja keerukusest ning konkreetsetest tingimustest, milles süsteem luuakse ja töötab.
ISO/IEC 12207 standard ei paku konkreetset olelustsükli mudelit ja tarkvara arendusmeetodeid. Selle sätted on ühised kõigi tarkvaraarenduse olelustsükli mudelite, meetodite ja tehnoloogiate jaoks. Standard kirjeldab tarkvara elutsükli protsesside struktuuri, kuid ei täpsusta, kuidas nendes protsessides sisalduvaid tegevusi ja ülesandeid rakendada või täita.
Iga konkreetse tarkvara elutsükli mudel määrab selle loomise protsessi olemuse, mis on ajas järjestatud, omavahel seotud ja etappidena (faasidena) ühendatud tööde kogum, mille rakendamine on vajalik ja piisav, et luua tarkvara, mis vastab nõuetele. määratud nõuded.
Tarkvara loomise etappi (faasi) mõistetakse tarkvara loomise protsessi osana, mis on piiratud teatud ajaraamiga ja lõpeb konkreetse toote (tarkvaramudelid, tarkvarakomponendid, dokumentatsioon jne) väljalaskmisega, mis on määratud kindlaksmääratud nõuetega. selle etapi jaoks. Tarkvara loomise etapid eristatakse ratsionaalse planeerimise ja töökorralduse kaalutlustel, lõpetades täpsustatud tulemustega. Tarkvara elutsükkel sisaldab tavaliselt järgmisi etappe:
- tarkvaranõuete kujundamine;
- projekteerimine (süsteemiprojekti väljatöötamine);
- teostus (võib jaotada alametappideks: detailne projekteerimine, kodeerimine);
- testimine (võib jagada eraldiseisvaks ja terviklik testimine ja integratsioon)
- kasutuselevõtt (elluviimine);
- käitamine ja hooldus;
- dekomisjoneerimine.
Mõned eksperdid tutvustavad täiendavat algetappi - teostatavusuuring süsteemid. See viitab tarkvarale ja riistvarasüsteemile, mille jaoks tarkvara luuakse, ostetakse või muudetakse.
Tarkvaranõuete kujunemise etapp on üks olulisemaid ja määrab suurel määral (isegi määrava!) kogu projekti edu. Selle etapi algus on kinnitatud ja heakskiidetud süsteemiarhitektuuri hankimine, mis hõlmab põhilepinguid funktsioonide jaotamise kohta riist- ja tarkvara vahel. See dokument peaks sisaldama ka kinnitust tarkvara toimimise üldise idee kohta, sealhulgas peamisi lepinguid funktsioonide jaotamise kohta isiku ja süsteemi vahel.
Tarkvaranõuete kujundamise etapp sisaldab järgmisi etappe.
- Projektieelse töö planeerimine. Etapi põhiülesanneteks on arengueesmärkide määratlemine, esialgne majanduslik hindamine projekt, töögraafiku koostamine, ühise töörühma loomine ja koolitamine.
- Automatiseeritud organisatsiooni (objekti) tegevuse uuringu läbiviimine, mille raames viiakse läbi tulevasele süsteemile esitatavate nõuete esialgne väljaselgitamine, organisatsiooni struktuuri määramine, organisatsiooni sihtfunktsioonide loetelu määramine, analüüsimine. funktsioonide jaotus osakondade ja töötajate kaupa, tuvastades funktsionaalsed interaktsioonid osakondade vahel, infovood osakondade sees ja nende vahel, organisatsioonivälised objektid ja välised infomõjud, organisatsiooni tegevuse automatiseerimise olemasolevate vahendite analüüs.
- "NAGU ON" ("nagu on") mudel, mis kajastab organisatsiooni hetkeseisu küsitluse ajal ja võimaldab mõista organisatsiooni toimimist, samuti tuvastada kitsaskohad ja sõnastada ettepanekuid organisatsiooni parandamiseks. olukord;
- "TO-BE" mudel ("nagu see peaks olema"), mis peegeldab organisatsiooni töö uute tehnoloogiate ideed.
Organisatsiooni (objekti) tegevuse mudeli koostamine, mis näeb ette uuringumaterjalide töötlemise ja kahte tüüpi mudelite ehitamise:
Iga mudel peaks sisaldama organisatsiooni tegevuse terviklikku funktsionaalset ja informatsioonilist mudelit, samuti (vajadusel) mudelit, mis kirjeldab organisatsiooni käitumise dünaamikat. Pange tähele, et konstrueeritud mudelid on iseseisva praktilise tähtsusega, olenemata sellest, kas ettevõte arendab ja juurutab infosüsteemi, kuna neid saab kasutada töötajate koolitamiseks ja ettevõtte äriprotsesside täiustamiseks.
Tarkvaranõuete kujundamise etapi lõpetamise tulemuseks on tarkvara spetsifikatsioonid, funktsionaalsed, tehnilised ja liidese spetsifikatsioonid, mille puhul kinnitatakse nende täielikkus, kontrollitavus ja teostatavus.
Projekteerimisetapp sisaldab järgmisi samme.
Tarkvarasüsteemi projekti väljatöötamine. Selles etapis antakse vastus küsimusele "Mida peaks tulevane süsteem tegema?", nimelt: süsteemi arhitektuur, selle funktsioonid, välised tingimused toimimine, liidesed ja funktsioonide jaotus kasutajate ja süsteemi vahel, nõuded tarkvarale ja infokomponentidele, esinejate koosseis ja arendusaeg, tarkvara silumisplaan ja kvaliteedikontroll.
Süsteemiprojekti aluseks on projekteeritud süsteemi mudelid, mis on üles ehitatud "TO-BE" mudelile. Süsteemiprojekti väljatöötamise tulemuseks peaks olema kinnitatud ja kinnitatud tarkvaranõuete spetsifikatsioon: funktsionaalsed, tehnilised ja liidese spetsifikatsioonid, mille puhul on kinnitatud nende täielikkus, kontrollitavus ja teostatavus.
- Detailse (tehnilise) projekti väljatöötamine. Selles etapis viiakse läbi tegelik tarkvara projekteerimine, sealhulgas süsteemi arhitektuur ja detailne projekteerimine. Seega antakse vastus küsimusele: "Kuidas ehitada süsteem nii, et see vastaks nõuetele?"
Detailse projekteerimise tulemuseks on kontrollitud tarkvara spetsifikatsiooni väljatöötamine, sealhulgas:
- tarkvarakomponentide hierarhia moodustamine, andmete ja juhtimise moodulitevahelised liidesed;
- iga tarkvarakomponendi spetsifikatsioon, nimi, eesmärk, eeldused, suurused, kõnede jada, sisend- ja väljundandmed, ekslikud väljundid, algoritmid ja loogikalülitused;
- füüsiliste ja loogiliste andmestruktuuride moodustamine kuni üksikute väljade tasemeni;
- arvutusressursside jaotamise plaani väljatöötamine (keskprotsessorite aeg, mälu jne);
- nõuete täielikkuse, järjepidevuse, teostatavuse ja kehtivuse kontrollimine;
- esialgne integreerimis- ja silumisplaan, kasutusjuhend ja vastuvõtutesti plaan.
Detailprojekti valmimine on otsast lõpuni
Annotatsioon.
Sissejuhatus.
1. Tarkvara elutsükkel
Sissejuhatus.
Riley programmeerimisprotsessi sammud
Sissejuhatus.
1.1.1. Probleemi sõnastamine.
1.1.2. Lahenduse disain.
1.1.3. Algoritmi kodeerimine.
1.1.4. Programmi tugi.
1.1.5. Tarkvara dokumentatsioon.
Järeldus punkti 1.1 kohta
1.2. ZhTsPO määratlus Lehmani järgi.
Sissejuhatus.
1.2.1 Süsteemi määratlus.
1.2.2. Rakendamine.
1.2.3. Teenindus.
Järeldus punkti 1.2 kohta.
1.3. Elutsükliprogrammi faasid ja tööd vastavalt Boehmile
1.3.1. kaskaadmudel.
1.3.2. Majanduslik põhjendus kaskaadmudel.
1.3.3. Kaskaadmudeli täiustamine.
1.3.4. Elutsükli faaside määratlus.
1.3.5. Põhitöö projektiga.
Kirjandus.
Sissejuhatus
Arvutite tööstuslik rakendamine ja kasvav nõudlus programmide järele on seadnud kiireloomulised ülesanded selle oluliseks suurendamiseks tarkvaraarenduse tootlikkus, tööstuslike meetodite arendamine programmide kavandamiseks ja kujundamiseks, organisatsiooniliste, tehniliste, tehniliste, majanduslike ja sotsiaalpsühholoogiliste meetodite, mustrite ja meetodite ülekandmine materjali tootmise sfäärist arvutite sfääri. Kompleksne lähenemine tarkvara arendamise, käitamise ja hooldamise protsessidele esitas mitmeid pakilisi probleeme, mille lahendamine kõrvaldab programmide kujundamise "pudelikaelad", lühendab valmimisaega, parandab valikut ja kohandamist. olemasolevaid programme ja võib-olla määrata manustatud arvutitega süsteemide saatuse.
Suurte tarkvaraprojektide arendamise praktikas sageli puudub ühtne lähenemine tööjõukulude, töötähtaegade ja materjalikulude hindamisele, mis takistab tarkvaraarenduse tootlikkuse tõusu ning lõppkokkuvõttes - tõhus juhtimine tarkvara elutsükkel. Kuna mis tahes tüüpi programmist saab toode (välja arvatud võib-olla õppe-, makettprogrammid), peaks lähenemine selle tootmisele olema paljuski sarnane tööstustoodete tootmise lähenemisviisiga ja tarkvara kujundamise küsimused muutuvad äärmiselt oluliseks. . See idee on aluseks B.U. Boehm "Software Engineering Design", mida kasutasime selle kirjutamiseks referaat. Selles raamatus viitab tarkvara disain tarkvaratoote disaini loomise protsessile.
1 Tarkvara elutsükkel
SISSEJUHATUS
LCPE on pidev protsess, mis algab hetkest, mil tehakse otsus tarkvara loomise vajaduse kohta ja lõpeb hetkel, mil see täielikult kasutusest kõrvaldatakse.
Tarkvara elutsükli (SLLC) faaside ja tegevuste, programmeerimisprotsessi etappide, kose- ja spiraalmudelite määratlemiseks on mitu lähenemisviisi. Kuid need kõik sisaldavad ühiseid põhikomponente: probleemi püstitus, lahenduse kavandamine, rakendamine, hooldus.
Kõige kuulsam ja täiuslikum on võib-olla Boehmi järgi elutsükli struktuur, mis sisaldab kaheksat faasi. Täpsemalt tutvustatakse seda hiljem.
Üheks võimalikuks variandiks võib olla Lehmani järgi ülemise taseme kirjeldus, mis sisaldab kolme põhifaasi ja kujutab kõige üldisemal juhul elutsükli programmi kirjeldust.
Ja vahelduseks on siin D. Riley raamatus “Using the Modula-2 Language” esitatud programmeerimisprotsessi sammud. See idee on minu meelest väga lihtne ja tuttav ning alustame sellest.
1.1 Riley programmeerimisprotsessi etapid
Programmeerimisprotsess koosneb neljast etapist (joonis 1):
probleemipüstitus, st. adekvaatse ettekujutuse saamine sellest, millist ülesannet programm peaks täitma;
juba püstitatud probleemile lahenduse kavandamine (üldiselt on selline lahendus vähem formaalne kui lõplik programm);
programmi kodeerimine ehk kavandatud lahenduse tõlkimine masinas täidetavaks programmiks;
programmi tugi, st. käimasoleva programmi vigade parandamise ja uute funktsioonide lisamise protsess.
Riis. 1.Neli programmeerimisetappi.
Programmeerimine algab hetkest, mil kasutaja, st. keegi, kes vajab probleemi lahendamiseks programmi, tekitab probleemi süsteemianalüütik. Kasutaja ja süsteemianalüütik määratlevad probleemiavalduse ühiselt. Viimane kantakse seejärel üle algoritmist kes vastutab lahenduse kavandamise eest. Lahendus (või algoritm) on toimingute jada, mille täitmine viib ülesande lahendamiseni. Kuna algoritm pole sageli kohandatud masinas täitmiseks, tuleks see tõlkida masinaprogrammiks. Seda toimingut teostab kodeerija. Kaasasolev programmeerija vastutab hilisemate programmi muudatuste eest. Ja süsteemianalüütik ja algoritmist, kodeerija ja kaasas olev programmeerija – nad kõik on programmeerijad.
Suure tarkvaraprojekti puhul võib kasutajate, süsteemianalüütikute ja algoritmide arv olla märkimisväärne. Lisaks võib ettenägematute asjaolude tõttu osutuda vajalikuks naasta eelmiste sammude juurde. Kõik see on lisaargument hoolika tarkvaradisaini kasuks: iga etapi tulemused peaksid olema täielikud, täpsed ja arusaadavad.
1.1.1 Probleemi kirjeldus
Programmeerimise üks olulisemaid samme on probleemi seadmine. See toimib lepinguna kasutaja ja programmeerija(te) vahel. Nagu juriidiliselt halvasti koostatud leping, on ka halb missioonikirjeldus kasutu. Hea probleemipüstituse korral esindavad nii kasutaja kui ka programmeerija selgelt ja ühemõtteliselt sooritatavat ülesannet, s.t. sel juhul arvestatakse nii kasutaja kui programmeerija huve. Kasutaja saab plaanida kasutada tarkvara, mida pole veel loodud, lähtudes teadmisest, et ta suudab. Probleemi hea sõnastus on selle lahenduse kujunemise aluseks.
Probleemi sõnastamine (programmi spetsifikatsioon); sisuliselt tähendab täpset, täielikku ja arusaadavat kirjeldust selle kohta, mis konkreetse programmi täitmisel juhtub. Tavaliselt vaatab kasutaja arvutit kui musta kasti: tema jaoks pole oluline, kuidas arvuti töötab, vaid oluline on, et arvuti saaks teha seda, millest kasutaja huvitab. Fookuses on inimese ja masina vaheline suhtlus.
Hea probleemiavalduse omadused:
Täpsus, st. igasuguse ebaselguse välistamine. Ei tohiks olla kahtlust, milline on programmi väljund mis tahes sisendi jaoks.
täielikkus, st. kõigi antud sisendi võimaluste, sealhulgas vigase või ootamatu sisendi kaalumine ja sobiva väljundi määramine.
Selgus, st. see peaks olema arusaadav nii kasutajale kui ka süsteemianalüütikule, kuna probleemi avaldus on nende vahel ainus leping.
Tihti on täpsuse, täielikkuse ja selguse nõuded vastuolus. Seega on paljud juriidilised dokumendid raskesti arusaadavad, kuna need on kirjutatud formaalses keeles, mis võimaldab sõnastada teatud sätted ülima täpsusega, välistades ka kõige ebaolulisemad lahknevused. Näiteks mõned küsimused eksamitöödel on mõnikord nii täpselt sõnastatud, et õpilasel kulub rohkem aega küsimuse mõistmisele kui sellele vastamisele. Pealegi ei pruugi õpilane detailide rohkuse tõttu küsimuse peamist tähendust üldse hoomata. Parim probleemipüstitus on see, mis saavutab kõigi kolme nõude tasakaalu.
Probleemi avalduse standardvorm.
Mõelge järgmisele ülesande lausele: "Sisestage kolm numbrit ja sisestage numbrid järjekorras."
Selline väide ei vasta ülaltoodud nõuetele: see ei ole täpne, täielik ega arusaadav. Tõepoolest, kas numbrid tuleb sisestada üks rea kohta või kõik numbrid ühel real? Kas väljend "järjekorras" tähendab järjestust suurimast väikseimani, väikseimast suurimani või sama järjekorda, milles need sisestati.
On ilmne, et selline väide ei vasta paljudele küsimustele. Kui võtta arvesse vastused kõikidele küsimustele, muutub probleemipüstitus sõnaliseks ja raskesti mõistetavaks. Seetõttu teeb D. Riley ettepaneku kasutada probleemi püstitamiseks standardvormi, mis tagab maksimaalse täpsuse, täielikkuse, selguse ja sisaldab:
ülesande nimi (skemaatiline definitsioon);
üldkirjeldus (kokkuvõteülesanded);
vead (ebatavalised sisestusvalikud on selgelt loetletud, et näidata kasutajatele ja programmeerijatele toiminguid, mida masin sellistes olukordades teeb);
näide ( hea näide võib anda edasi probleemi olemust, aga ka illustreerida erinevaid juhtumeid).
Näide. Probleemi avaldus standardvormis.
PEALKIRI
Sorteeri kolm täisarvu.
KIRJELDUS
Kolme täisarvu sisend ja väljund, sorteeritud väikseimast suurimani.
Sisestatakse kolm täisarvu, üks arv rea kohta. Sel juhul on täisarv üks või mitu järjestikust arvu kümnendkohad, millele võib eelneda plussmärk "+" või miinusmärk "-".
Kolm sisestatud täisarvu väljastatakse, kõik kolm kuvatakse samal real. Kõrvuti asetsevad numbrid on eraldatud tühikuga. Numbrid kuvatakse väikseimast suurimani, vasakult paremale.
1) Kui sisestatakse vähem kui kolm numbrit, ootab programm täiendavat sisestust.
Tarkvara elutsükkel - ajavahemik, mis algab hetkest, mil tehakse otsus tarkvaratoote loomise vajaduse kohta ja lõpeb selle täieliku kasutusest kõrvaldamise hetkel.
Tarkvara elutsükli protsessid:
Põhiline,
abiteenistus,
Organisatsiooniline.
Peamine:
1. Omandamine - tarkvara ostva kliendi toimingud ja ülesanded;
2. Tarne - tarnija tegevus ja ülesanded, kes tarnib klienti tarkvaratoote või -teenusega;
3. Arendus - arendaja poolt teostatavad tegevused ja ülesanded: tarkvara loomine, projekteerimis- ja töödokumentatsiooni teostamine, test- ja koolitusmaterjalide koostamine;
4. Toimimine - süsteemi haldava organisatsiooni operaatori tegevused ja ülesanded;
5. Hooldus – tarkvaras muudatuste tegemine vigade parandamiseks, jõudluse parandamiseks või muutuvate töötingimuste või nõuetega kohanemiseks.
Abiseade:
1. Dokumentatsioon - tarkvara elutsükli jooksul loodud teabe formaliseeritud kirjeldus;
2. Konfiguratsioonihaldus – haldus- ja tehniliste protseduuride rakendamine kogu tarkvara elutsükli jooksul tarkvarakomponentide oleku kindlaksmääramiseks, selle modifikatsioonide haldamiseks;
3. Kvaliteedi tagamine - tarkvara ja selle elutsükli protsesside vastavuse tagamine kindlaksmääratud nõuetele ja kinnitatud plaanidele;
4. Kontrollimine – tarkvaratooted vastavate eelnevate toimingute tõttu täielikult nõuetele või tingimustele kindlakstegemine;
5. Sertifitseerimine - kindlaksmääratud nõuete ja loodud süsteemi nende konkreetsele funktsionaalsele otstarbele vastavuse määramine;
6. Ühishindamine – projekti töö seisu hindamine: ressursside, personali, seadmete, tööriistade planeerimise ja juhtimise kontroll;
7. Audit - lepingu nõuetele, plaanidele ja tingimustele vastavuse kindlakstegemine;
8. Probleemide lahendamine - arenduse, ekspluatatsiooni, hoolduse või muude protsesside käigus avastatud probleemide analüüs ja lahendamine, sõltumata nende päritolust või allikast.
Organisatsiooniline:
1. Juhtimine - tegevused ja ülesanded, mida saab teha iga osapool, kes juhib oma protsesse;
2. Infrastruktuuri loomine - tehnoloogia valik ja hooldus, standardid ja tööriistad, tarkvara arendamiseks, käitamiseks või hooldamiseks kasutatava riist- ja tarkvara valimine ja installimine;
3. Parendamine - elutsükli protsesside hindamine, mõõtmine, kontroll ja täiustamine;
4. Koolitus – personali esmane väljaõpe ja sellele järgnev pidev professionaalne areng.
2002. aastal avaldati süsteemi elutsükli protsesside standard (ISO/IEC 15288 Süsteemi elutsükli protsessid). Standardi väljatöötamisse kaasati spetsialiste erinevatest valdkondadest: süsteemitehnika, programmeerimine, kvaliteedijuhtimine, personalitöö, turvalisus jne. praktiline kogemus süsteemide ehitamine valitsus-, kaubandus-, sõjaväe- ja akadeemilistes organisatsioonides. Standard on rakendatav paljudele süsteemide klassile, kuid selle põhieesmärk on toetada arvutisüsteemide loomist.
Vastavalt ISO/IEC 15288 seeriale tuleks elutsükli struktuuri kaasata järgmised protsessirühmad:
1. Lepingulised protsessid:
omandamine (majasisesed lahendused või välise pakkuja lahendused);
Tarne (siselahendused või välistarnija lahendused);
2. Ettevõtte protsessid:
Kontroll keskkond ettevõtted;
Investeeringute juhtimine;
IP elutsükli juhtimine;
Ressursihaldus;
Kvaliteedi kontroll;
3. Disainiprotsessid:
Projekti planeerimine;
Projektide hindamine;
Projekti kontroll;
Riskide juhtimine;
Konfiguratsiooni juhtimine;
Infovoo juhtimine;
Otsuste tegemine.
4. Tehnilised protsessid:
Nõuete määratlemine;
Nõuete analüüs;
Arhitektuuri arendamine;
rakendamine;
Integratsioon;
Kontrollimine;
Üleminek;
Sertifitseerimine;
ekspluateerimine;
Saatja;
Utiliseerimine.
5. Eriprotsessid:
Ülesannetest ja eesmärkidest lähtuvate seoste määratlemine ja loomine.
IP-tarkvara põhiolelustsükli protsesside loomine (ISO/IEC 15288)
| Protsess (protsessi täitja) | Tegevused | Sissepääs | Tulemus |
| Omandamine (klient) | - Algatamine - Pakkumisettepanekute koostamine - Lepingu ettevalmistamine - Tarnija tegevuse kontroll - IP vastuvõtmine | - Otsus alustada tööd IP juurutamisega - Kliendi tegevuste uuringu tulemused - IP turu / hanke analüüsi tulemused - Tarne / arendusplaan - IP terviklik test | - IS-i rakendamise teostatavusuuring - IS-i lähteülesanne - Tarne-/arendusleping - Tööetappide vastuvõtuaktid - Vastuvõtukatsetuste akt |
| Kohaletoimetamine (IS arendaja) | - Algatamine - Pakkumistele vastamine - Lepingu ettevalmistamine - Teostuse planeerimine - IP tarnimine | - IS lähteülesanne - Juhtkonna otsus arenduses osaleda - Hanke tulemused - IS lähteülesanne - Projekti juhtimisplaan - Väljatöötatud IS ja dokumentatsioon | - otsus arenduses osaleda - Kommertspakkumised/ pakkumine - Tarne-/arendusleping - Projekti juhtimisplaan - Rakendamine/kohandamine - Aktsepteerimistesti aruanne |
| Arendus (IS arendaja) | - Ettevalmistus - IS-i nõuete analüüs - IS-i arhitektuuri projekteerimine - Tarkvaranõuete arendus - Tarkvaraarhitektuuri projekteerimine - Tarkvara detailne projekteerimine - Tarkvara kodeerimine ja testimine - Tarkvara integreerimine ja tarkvara kvalifikatsiooni testimine - IS-i integreerimine ja IS-kvalifitseeritud testimine | - IS-i lähteülesanne - IS-i lähteülesanne, olelusringi mudel - IS-i alamsüsteemid - Tarkvarakomponentide nõuete spetsifikatsioonid - Tarkvaraarhitektuur - Tarkvarakujunduse üksikasjalikud materjalid - Tarkvara integratsiooniplaan, testid - IS-i arhitektuur, tarkvara, dokumentatsioon IS-i jaoks, testid | - Kasutatav elutsükli mudel, arendusstandardid - Tööplaan - Alamsüsteemide koostis, riistvarakomponendid - Tarkvarakomponentidele esitatavate nõuete spetsifikatsioonid - Tarkvarakomponentide koostis, liidesed andmebaasiga, tarkvara integreerimise plaan - Andmebaasi projekt, tarkvaravahelise liidese spetsifikatsioonid komponendid, nõuded testidele - Moodulitekstid Tarkvara, autonoomse testimise aktid - Tarkvarakompleksi TOR-i nõuetele vastavuse hindamine - Tarkvara, andmebaasi nõuetele vastavuse hindamine, tehniline kompleks ja dokumentide komplekt vastavalt TOR-i nõuetele |
Süsteemi arendamise etapid (ISO/IEC 15288)
CPC: looge projekti "Queue" lähtetingimused saidil www.mastertz.ru
Tarkvara elutsükli mudelid:
1. kaskaad,
2. spiraal,
3. iteratiivne.
Kaskaadmudel elutsükli (“juga mudel”, inglise kose mudel) pakkus välja 1970. aastal Winston Royce. See näeb ette projekti kõigi etappide järjestikuse rakendamise rangelt fikseeritud järjekorras. Üleminek järgmisele etapile tähendab töö täielikku lõpetamist eelmises etapis.
Nõuete kujundamise etapis määratletud nõuded on rangelt dokumenteeritud lähteülesande vormis ja fikseeritud kogu projekti arendamise ajaks.
Iga etapp kulmineerub täieliku dokumentatsioonikomplekti avaldamisega, millest piisab arenduse jätkamiseks teise arendusmeeskonna poolt.
|
|
spiraalne mudel(inglise spiraalmudel) töötas välja 1980. aastate keskel Barry Boehm. See põhineb Edward Demingi klassikalisel PDCA (plan-do-check-act) tsüklil. Selle mudeli kasutamisel luuakse tarkvara mitmes iteratsioonis (spiraalpöördes) prototüüpimise teel.
Prototüüp on aktiivne tarkvarakomponent, mis rakendab üksikuid funktsioone ja väliseid liideseid.
Iga iteratsioon vastab tarkvara fragmendi või versiooni loomisele, mille juures määratakse projekti eesmärgid ja omadused, hinnatakse saadud tulemuste kvaliteeti ning planeeritakse järgmise iteratsiooni tööd.
Riis. 21. Tarkvara elutsükli spiraalmudel
Igas iteratsioonis hinnatakse järgmist:
1. Projekti tingimuste ja maksumuse ületamise risk;
2. Vajadus sooritada veel üks iteratsioon;
3. süsteemi nõuetest arusaamise täielikkuse ja täpsuse aste;
4. Projekti lõpetamise otstarbekus.
Üks näide spiraalmudeli rakendamisest on RAD.
RAD-i põhiprintsiibid:
1. Tööriistakomplekti eesmärk peaks olema arendusaja minimeerimine;
2. Prototüübi loomine kliendi nõudmiste selgitamiseks;
3. Arendustsükkel: iga toote uus versioon põhineb kliendipoolsel hinnangul eelmise versiooni töö tulemusele;
4. Versiooniarenduse aja minimeerimine valmismoodulite ülekandmise ja uuele versioonile funktsionaalsuse lisamisega;
5. Arendusmeeskond peab tegema tihedat koostööd, iga liige peab olema valmis täitma mitmeid kohustusi;
6. Projektijuhtimine peaks minimeerima arendustsükli kestust.
Iteratiivne mudel: kaskaad- ja spiraalmudelite loomulik areng on viinud nende lähenemiseni ja moodsa iteratiivse lähenemise tekkeni, mis on nende mudelite ratsionaalne kombinatsioon.
Riis. 22. Tarkvara elutsükli iteratiivne mudel
Tarkvara elutsükkel
Tarkvara elutsükkel on ajavahemik, mis algab hetkest, mil tehakse otsus tarkvaratoote loomise vajaduse kohta ja lõpeb selle täieliku kasutusest kõrvaldamise hetkel. (IEEE Std 610.12)
Tarkvara elutsükli (LC) etappide kindlaksmääramise vajadus tuleneb arendajate soovist parandada tarkvara kvaliteeti läbi optimaalse arendusjuhtimise ja erinevate kvaliteedikontrolli mehhanismide kasutamise igas etapis alates ülesannete seadmisest kuni tarkvara loomiseni. Tarkvara elutsükli kõige üldisem esitus on mudel põhietappide - protsesside kujul, mis hõlmavad:
Süsteemianalüüs ja tarkvaranõuete põhjendamine;
Eelnev (eskiis) ja detailne (tehniline) tarkvara projekteerimine;
Tarkvarakomponentide arendamine, nende integreerimine ja tarkvara silumine üldiselt;
Tarkvara testimine, proovitöö ja replikatsioon;
Tarkvara regulaarne töö, töö hooldus ja tulemuste analüüs;
Tarkvara hooldus, selle muutmine ja täiustamine, uute versioonide loomine.
See mudel on üldtunnustatud ja vastab nii kodumaisele reguleerivad dokumendid tarkvaraarenduse valdkonnas ja välismaised. Tehnoloogilise ohutuse tagamise seisukohalt on soovitatav üksikasjalikumalt kaaluda elutsükli etappide kujutamise tunnuseid välismaistes mudelites, kuna just välistarkvara on kõige tõenäolisem tarkvaravigade kandja. sabotaaži tüüp.
Tarkvara elutsükli standardid
GOST 34.601-90
ISO/IEC 12207:1995 (Vene analoog – GOST R ISO/IEC 12207-99)
Elutsükli mudelite graafiline esitus võimaldab visuaalselt esile tõsta nende omadusi ja mõningaid protsesside omadusi.
Esialgu loodi elutsükli kaskaadmudel, milles saadud tulemusi kasutades algasid üksteise järel suuremad etapid varasemad tööd. See näeb ette projekti kõigi etappide järjestikuse rakendamise rangelt fikseeritud järjekorras. Üleminek järgmisele etapile tähendab töö täielikku lõpetamist eelmises etapis. Nõuete kujundamise etapis määratletud nõuded on rangelt dokumenteeritud lähteülesande vormis ja fikseeritud kogu projekti arendamise ajaks. Iga etapp kulmineerub täieliku dokumentatsioonikomplekti avaldamisega, millest piisab arenduse jätkamiseks teise arendusmeeskonna poolt. Mis tahes nõude ebatäpsus või sellest tulenev vale tõlgendamine toob kaasa asjaolu, et peate "tagasi kerima" projekti varasesse faasi ja nõutav läbivaatamine mitte ainult ei löö projektimeeskonda ajakavast välja, vaid viib sageli ka kulude kvalitatiivne suurenemine ja võimalik, et projekt lõpetatakse sellisel kujul, nagu see algselt kavandati. Kose mudeli autorite peamine eksitus on eeldus, et projekteerimine läbib kogu protsessi ühe korra, kavandatud arhitektuur on hea ja hõlpsasti kasutatav, teostuse disain on mõistlik ning teostuses esinevad vead on hõlpsasti kõrvaldatavad testimine. See mudel eeldab, et kõik vead koonduvad juurutusse ja seetõttu toimub nende kõrvaldamine komponentide ja süsteemi testimise ajal ühtlaselt. Seega ei ole suurte projektide kosemudel kuigi realistlik ja seda saab efektiivselt kasutada vaid väikeste süsteemide loomiseks.
Kõige spetsiifilisem on elutsükli spiraalmudel. See mudel keskendub iteratiivsele protsessile esialgsed etapid disain. Nendel etappidel kontseptsioonid, nõuete spetsifikatsioonid, esialgne ja detailne disain. Igal voorul täpsustatakse töö sisu ja koondatakse loodava tarkvara välimus, hinnatakse saadud tulemuste kvaliteeti ning planeeritakse järgmise iteratsiooni tööd. Igas iteratsioonis hinnatakse järgmist:
Projekti tingimuste ja maksumuse ületamise risk;
Vajadus sooritada teine iteratsioon;
süsteemi nõuete mõistmise täielikkuse ja täpsuse aste;
Projekti lõpetamise otstarbekus.
Tarkvara elutsükli standardimine toimub kolmes suunas. Esimest suunda korraldavad ja stimuleerivad Rahvusvaheline Standardiorganisatsioon (ISO – International Standard Organisation) ja Rahvusvaheline Elektrotehnikakomisjon (IEC – International Electro-technical Commission). Sellel tasemel toimub enamlevinud, rahvusvahelise koostöö jaoks oluliste tehnoloogiliste protsesside standardimine. Teist suunda arendab USA-s aktiivselt Elektri- ja Elektroonikainseneride Instituut (IEEE - Institute of Electrotechnical and Electronics Engineers) koos Ameerika Rahvusliku Standardi Instituudiga (ANSI). ISO/IEC ja ANSI/IEEE standardid on enamasti soovitusliku iseloomuga. Kolmandat suunda stimuleerib USA kaitseministeerium (Department of Defense-DOD). DOD standardid on kohustuslikud ettevõtetele, kes töötavad USA kaitseministeeriumi nimel.
Kompleksse süsteemi, eriti reaalajas süsteemi tarkvara kavandamiseks on soovitatav kasutada kogu süsteemi hõlmavat elutsükli mudelit, mis põhineb kõigi kuulsad teosed vaadeldavate põhiprotsesside raames. See mudel on mõeldud kasutamiseks erinevate tarkvaraprojektide planeerimisel, ajakavastamisel, haldamisel.
Selle olelustsükli mudeli etappide kogum on soovitav jagada kaheks osaks, mis erinevad oluliselt protsesside iseärasuste, tehniliste ja majanduslike omaduste ning neid mõjutavate tegurite poolest.
Elutsükli esimeses osas toimub süsteemianalüüs, tarkvara projekteerimine, arendus, testimine ja testimine. Tööde valik, nende keerukus, kestus ja muud omadused nendel etappidel sõltuvad oluliselt objektist ja arenduskeskkonnast. Selliste sõltuvuste uurimine erinevate tarkvaraklasside puhul võimaldab ennustada uute tarkvaraversioonide töögraafikute koostist ja põhiomadusi.
Elutsükli teine osa, mis kajastab tarkvara toimimise ja hoolduse toetamist, on suhteliselt nõrgalt seotud objekti ja arenduskeskkonna omadustega. Nendel etappidel on tööde ulatus stabiilsem ning nende keerukus ja kestus võivad oluliselt erineda ning sõltuda tarkvara massilisest rakendusest. Iga elutsükli mudeli puhul on tarkvarasüsteemide kõrge kvaliteedi tagamine võimalik vaid reguleeritud mudeli kasutamisel tehnoloogiline protsess igal neist etappidest. Sellist protsessi toetavad arendusautomaatika tööriistad, mida on soovitav valida olemasolevate hulgast või luua arvestades arendusobjekti ja sellele adekvaatset tööde nimekirja.
