Tarkvara kujundamise metoodika üks põhimõisteid on selle tarkvara elutsükli (SO) kontseptsioon. Tarkvara elutsükkel on pidev protsess, mis algab hetkest, mil tehakse otsus selle loomise vajaduse kohta ja lõpeb selle täieliku kasutusest kõrvaldamise hetkega.
Peamine tarkvara elutsüklit reguleeriv regulatiivne dokument on rahvusvaheline standard ISO/IEC 12207 (ISO - International Organisation of Standardization, IEC - International Electrotechnical Commission). See määratleb elutsükli struktuuri, mis sisaldab protsesse, tegevusi ja ülesandeid, mida tarkvara loomisel tuleb täita. Selles standardis Tarkvara (tarkvaratoode) määratletud komplektina arvutiprogrammid, protseduurid ja võimalikud seotud dokumendid ja andmed. Protsess on määratletud kui omavahel seotud toimingute kogum, mis muudab mõned sisendandmed väljundandmeteks. Iga protsessi iseloomustavad kindlad ülesanded ja meetodid nende lahendamiseks, teistest protsessidest saadud sisendandmed ja tulemused.
Tarkvara elutsükli struktuur vastavalt ISO/IEC 12207 standardile põhineb kolmel protsesside rühmal:
· tarkvara elutsükli põhiprotsessid (ost, tarnimine, arendus, käitamine, tugi);
· abiprotsessid, mis tagavad põhiprotsesside elluviimise (dokumentatsioon, konfiguratsioonihaldus, kvaliteedi tagamine, verifitseerimine, sertifitseerimine, hindamine, audit, probleemide lahendamine);
· organisatsioonilised protsessid (projektijuhtimine, projekti infrastruktuuri loomine, elutsükli enda määratlemine, hindamine ja täiustamine, koolitus).
Tarkvara elutsükli mudelid
Elutsükli mudel– struktuur, mis määrab elluviimise järjestuse ning etappide ja sooritatavate etappide suhte kogu elutsükli jooksul. Elutsükli mudel sõltub tarkvara spetsiifikast ja konkreetsetest tingimustest, milles viimane luuakse ja töötab. Peamised elutsükli mudelid on järgmised.
1. Kaskaadmudel(kuni XX sajandi 70. aastateni) määrab järjestikuse ülemineku järgmisse etappi pärast eelmise lõpetamist.
Seda mudelit iseloomustab üksikute mitteseotud ülesannete automatiseerimine, mis ei nõua teabe integreerimist ja ühilduvust, tarkvara, tehnilist ja organisatsioonilist liidest.
Väärikust: head näitajad arendusaja ja usaldusväärsuse osas üksikute probleemide lahendamisel.
Viga: ei kohaldata suurte ja keerukate projektide puhul süsteeminõuete varieeruvuse tõttu pika projekteerimisperioodi jooksul.
2. Iteratiivne mudel(XX sajandi 70-80ndad) vastab "alt-üles" disainitehnoloogiale. Võimaldab pärast järgmise etapi lõpetamist iteratiivselt naasta eelmistele etappidele;
Mudel näeb ette üksikute probleemide jaoks saadud projektlahenduste üldistamist süsteemiülesteks lahendusteks. Sel juhul on vaja eelnevalt sõnastatud nõuded üle vaadata.
Väärikus: võimalus projektis kiiresti muudatusi teha.
Viga: suure iteratsioonide arvuga pikeneb projekteerimisaeg, tekivad lahknevused projekteerimislahendustes ja dokumentatsioonis ning loodava tarkvara funktsionaalne ja süsteemiarhitektuur läheb sassi. Vajadus vana süsteemi ümberkujundamiseks või uue süsteemi loomiseks võib tekkida kohe pärast juurutamise või käitamisetappi.
3. Spiraalmudel(XX sajandi 80-90ndad) vastab "ülalt-alla" disainitehnoloogiale. Hõlmab tarkvara prototüübi kasutamist, mis võimaldab tarkvara laiendamist. Süsteemi ülesehitus kordab tsükliliselt teed nõuete täpsustamisest programmikoodi täpsustamiseni.
Süsteemiarhitektuuri kavandamisel määratakse esmalt kindlaks funktsionaalsete alamsüsteemide koosseis ja lahendatakse kogu süsteemi hõlmavad probleemid (integreeritud andmebaasi korraldamine, teabe kogumise, edastamise ja säilitamise tehnoloogia). Seejärel sõnastatakse üksikud probleemid ja töötatakse välja nende lahendamise tehnoloogia.
Programmeerimisel töötatakse kõigepealt välja pea tarkvara moodulid, ja seejärel - moodulid, mis täidavad üksikuid funktsioone. Esmalt tagatakse moodulite interaktsioon omavahel ja andmebaasiga ning seejärel algoritmide realiseerimine.
Eelised:
1. iteratsioonide arvu ja sellest tulenevalt parandamist vajavate vigade ja ebakõlade arvu vähendamine;
2. projekteerimisaja vähendamine;
3. projekti dokumentatsiooni koostamise lihtsustamine.
Viga: kõrged nõuded kogu süsteemi hõlmava hoidla kvaliteedile (ühine disainiandmebaas).
Spiraalmudel on aluseks kiire rakenduste arendamise tehnoloogiad või RAD-tehnoloogia (rapid application development), mis hõlmab tulevase süsteemi lõppkasutajate aktiivset osalemist selle loomise protsessis. Infotehnoloogia peamised etapid on järgmised:
· Infostrateegia analüüs ja planeerimine. Kasutajad osalevad koos spetsialistide arendajatega probleemse piirkonna tuvastamisel.
· Disain. Kasutajad osalevad arendajate juhendamisel tehnilises projekteerimises.
· Ehitus. Arendajad kujundavad tarkvara tööversiooni, kasutades 4. põlvkonna keeli;
· Rakendamine. Arendajad koolitavad kasutajaid uues tarkvarakeskkonnas töötama.
Tarkvara elutsükkel
Tarkvara elutsükkel on ajavahemik, mis algab hetkest, mil tehakse otsus tarkvaratoote loomise vajaduse kohta ja lõpeb hetkel, mil see täielikult kasutusest kõrvaldatakse. (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 probleemi määratlemisest kuni tarkvara loomise toeni. Tarkvara elutsükli kõige üldisem esitus on mudel põhietappide - protsesside kujul, mis hõlmavad:
Süsteemianalüüs ja tarkvaranõuete põhjendamine;
Tarkvara esialgne (kavand) ja detailne (tehniline) projekteerimine;
Tarkvarakomponentide arendamine, nende integreerimine ja tarkvara kui terviku silumine;
Testid, proovioperatsioon ja tarkvara replikatsioon;
Tarkvara regulaarne töö, toimimise tugi 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 see on võõras tarkvara on kõige tõenäolisem sabotaaži tüüpi tarkvaravigade kandja.
Tarkvara elutsükli standardid
GOST 34.601-90
ISO/IEC 12207:1995 (venekeelne vaste – GOST R ISO/IEC 12207-99)
Elutsükli mudelite graafiline esitus võimaldab selgelt esile tuua nende tunnused ja mõned protsesside omadused.
Algselt 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 kindlaksmääratud nõuded on rangelt dokumenteeritud tehniliste kirjelduste vormis ja salvestatakse kogu projekti arenduse jooksul. Iga etapp kulmineerub täieliku dokumentatsioonikomplekti avaldamisega, mis on piisav, et võimaldada arendustegevuse jätkamist teisel arendusmeeskonnal. Mis tahes nõude ebatäpsus või selle vale tõlgendamine toob kaasa asjaolu, et on vaja "tagasi kerida" projekti varajasesse faasi ja nõutav ümbertöötamine mitte ainult ei lükka projektimeeskonda graafikust välja, vaid viib sageli ka töökvaliteedi tõusuni. kulud ja võimalusel projekti lõpetamine sellisel kujul, nagu see algselt kavandati. Kose mudeli autorite peamisteks väärarusaamadeks on eeldused, et projekt läbib kogu protsessi ühe korra, projekteeritud arhitektuur on hea ja lihtsalt kasutatav, teostusdisain on mõistlik ning teostuses esinevad vead on testimise teel hõlpsasti kõrvaldatavad. See mudel eeldab, et kõik vead koonduvad juurutusse ja seetõttu toimub nende kõrvaldamine komponentide ja süsteemi testimise käigus ühtlaselt. Seega ei ole kose mudel suurte projektide jaoks kuigi realistlik ja seda saab tõhusalt kasutada ainult väikeste süsteemide loomiseks.
Kõige spetsiifilisem on spiraalse elutsükli mudel. See mudel keskendub iteratiivsele protsessile esialgsed etapid disain. Nendel etappidel luuakse järjestikku kontseptsioonid, nõuete spetsifikatsioonid, eel- ja detailprojektid. Igal käigul tehakse selgeks töö sisu ja kontsentreeritakse loodava tarkvara välimus, hinnatakse saadud tulemuste kvaliteeti ning planeeritakse järgmise iteratsiooni tööd. Igas iteratsioonis hinnatakse järgmist:
Projekti tähtaegade ja kulude ületamise oht;
Vajadus sooritada teine iteratsioon;
süsteeminõ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 rahvusvahelise koostöö jaoks oluliste kõige üldisemate tehnoloogiliste protsesside standardimine. Teist suunda arendab USA-s aktiivselt elektri- ja elektroonikainseneride instituut (IEEE) koos Ameerika riikliku standardiinstituudiga (ANSI). ISO/IEC ja ANSI/IEEE standardid on oma olemuselt peamiselt soovituslikud. Kolmandat suunda stimuleerib USA kaitseministeerium (DOD). DOD standardid on kohustuslikud USA kaitseministeeriumis töötavatele ettevõtetele.
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, ajastamisel ja 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 viiakse läbi süsteemianalüüs, tarkvara projekteerimine, arendus, testimine ja testimine. Töö ulatus, 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 käitamise ja hoolduse toetamist, on suhteliselt nõrgalt seotud objekti ja arenduskeskkonna omadustega. Tööde ulatus nendel etappidel on stabiilsem, kuid nende töömahukus ja kestus võivad oluliselt erineda ning sõltuda tarkvara laialdasest kasutusest. Iga olelustsükli mudeli puhul eraldis Kõrge kvaliteet tarkvarasüsteemid on võimalik ainult siis, kui igas nimetatud etapis kasutatakse reguleeritud tehnoloogilist protsessi. Seda protsessi toetavad arenduse automatiseerimise tööriistad, mis on soovitav valida olemasolevate hulgast või luua need arendusobjekti ja sellele adekvaatse tööde loeteluga arvestades.
Teema: Klassikalised ja paindlikud LCPP mudelid: määratlus, kirjeldus, eripära, etappide järjestus. LCPP mudeli valimise meetodid erinevate ainevaldkondade tarkvara väljatöötamisel.
Teabeallikas https://www.intuit.ru/studies/courses/3632/874/print_lecture/14297
Tarkvara elutsükli mudelid ja etapid
Tarkvara elutsükli mudeli all mõistetakse struktuuri, mis määratleb protsesside, toimingute ja ülesannete täitmise ja seosed 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 elutsükli mudelit ja tarkvara arendusmeetodeid. Selle sätted on üldised kõigi olelustsükli mudelite, meetodite ja tarkvaraarendustehnoloogiate kohta. Standard kirjeldab tarkvara elutsükli protsesside struktuuri, kuid ei täpsusta, kuidas nendes protsessides sisalduvaid toiminguid ja ülesandeid rakendada või sooritada.
Iga konkreetse tarkvara elutsükli mudel määrab selle loomise protsessi olemuse, mis on ajas järjestatud, omavahel seotud ja etappideks (faasideks) kombineeritud tööde kogum, mille realiseerimine 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 kindla ajaraamiga ja lõpeb konkreetse toote (tarkvaramudelid, tarkvarakomponendid, dokumentatsioon jne) väljalaskmisega, mis on määratud nõuetega. selle etapi jaoks määratud. Tarkvara loomise etapid eristatakse ratsionaalse planeerimise ja kindlate tulemustega lõppeva töö korraldamise kaalutlustel. Tarkvara elutsükkel sisaldab tavaliselt järgmisi etappe:
- tarkvaranõuete kujundamine;
- disain (arendus süsteemi projekt);
- teostus (võib jaotada alaetappideks: detailplaneering, kodeerimine);
- testimine (võib jaotada eraldiseisvaks ja integreeritud testimiseks ja integreerimiseks);
- kasutuselevõtt (elluviimine);
- käitamine ja hooldus;
- dekomisjoneerimine.
Mõned eksperdid tutvustavad täiendavat algetappi - teostatavusanalüüs süsteemid. Siin peame silmas riist- ja tarkvarasüsteemi, mille jaoks tarkvara luuakse, ostetakse või muudetakse.
Tarkvaranõuete kujundamise etapp on üks olulisemaid ja määrab olulisel (isegi otsustaval!) määral kogu projekti edukuse. Selle etapi alguseks on kinnitatud ja kinnitatud süsteemiarhitektuuri hankimine, sealhulgas põhikokkulepped funktsioonide jaotamise kohta riist- ja tarkvara vahel. See dokument peab sisaldama ka kinnitust üldine idee tarkvara toimimise kohta, sh põhilepingud funktsioonide jaotamise kohta isiku ja süsteemi vahel.
Tarkvaranõuete koostamise etapp sisaldab järgmisi etappe.
- Tööde planeerimine enne projekti kallal töötamist. Etapi põhieesmärgid on arengueesmärkide määramine, esialgne majanduslik hinnang projekt, töögraafiku koostamine, ühise töörühma loomine ja koolitamine.
- Automatiseeritud organisatsiooni (objekti) tegevuse uuringu läbiviimine, mille raames viiakse läbi tulevase süsteemi nõuete esialgne väljaselgitamine, organisatsiooni struktuuri kindlaksmääramine, organisatsiooni sihtfunktsioonide loetelu kindlaksmääramine, funktsioonide jaotuse analüüs osakondade ja töötajate vahel, osakondadevaheliste funktsionaalsete interaktsioonide tuvastamine, infovood osakondade sees ja vahel, organisatsioonivälised objektid ja välised infomõjud, organisatsiooni tegevuse automatiseerimise olemasolevate vahendite analüüs.
- mudel “NAGU IS” (“nagu on”), mis kajastab organisatsiooni hetkeseisu uuringu toimumise hetkel ja võimaldab mõista organisatsiooni toimimist, samuti tuvastada kitsaskohad ja sõnastada ettepanekud organisatsiooni parandamiseks. olukord;
- mudel "TO-BE" ("kuidas see peaks olema"), peegeldades organisatsiooni uute tehnoloogiate ideed.
Organisatsiooni (objekti) tegevuse mudeli koostamine, mis hõlmab uuringumaterjalide töötlemist ja kahte tüüpi mudelite koostamist:
Iga mudel peaks sisaldama organisatsiooni tegevuse terviklikku funktsionaalset ja infomudelit, samuti (vajadusel) organisatsiooni käitumise dünaamikat kirjeldavat mudelit. Pange tähele, et konstrueeritud mudelitel on iseseisev praktiline tähendus, olenemata sellest, kas ettevõttes hakatakse infosüsteemi välja töötama ja juurutama, kuna nende abil on võimalik koolitada töötajaid ja täiustada ettevõtte äriprotsesse.
Tarkvaranõuete genereerimise etapi läbimise tulemuseks on tarkvara spetsifikatsioonid, funktsionaalsed, tehnilised ja liidese spetsifikatsioonid, mille puhul kinnitatakse nende täielikkus, kontrollitavus ja teostatavus.
Projekteerimisetapp sisaldab järgmisi etappe.
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 töötingimused, liidesed ja funktsioonide jaotus kasutajate ja süsteemi vahel, nõuded tarkvarale. ja infokomponendid, esinejate koosseis ja tähtajad määratakse arendus, 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 peab 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, moodulitevahelised liidesed andmete ja halduse jaoks;
- iga tarkvarakomponendi spetsifikatsioon, nimi, eesmärk, eeldused, mõõtmed, kõnede jada, sisend- ja väljundandmed, vead väljundid, algoritmid ja loogikalülitused;
- füüsiliste ja loogiliste andmestruktuuride moodustamine kuni üksikute väljade tasemeni;
- arvutusressursside (keskprotsessori aeg, mälu jne) jaotamise plaani väljatöötamine;
- nõuete täielikkuse, järjepidevuse, teostatavuse ja kehtivuse kontrollimine;
- integreerimise ja silumise esialgne plaan, kasutusjuhendi ja vastuvõtutestimise plaan.
Detailprojekteerimise etapi lõpetamine on projekti otsast lõpuni või projekti kriitiline plokkide kaupa analüüs.
Teostuse etapp – järgmiste tööde lõpetamine.
Iga alamprogrammi kontrollitud üksikasjaliku spetsifikatsiooni väljatöötamine (plokk mitte rohkem kui 100 algse kõrgetasemelise keelekäsuga).
Välised spetsifikatsioonid peavad sisaldama järgmist teavet:
- mooduli nimi - näitab nime, mida kasutatakse mooduli kutsumiseks (mitme sisendiga mooduli puhul peavad iga sisendi jaoks olema eraldi spetsifikatsioonid);
- funktsioon – antakse mooduli poolt täidetava funktsiooni või funktsioonide definitsioon;
- moodulile edastatud parameetrite loend (arv ja järjekord);
- sisendparameetrid – kõigi mooduli poolt tagastatud andmete täpne kirjeldus (tuleb määratleda mooduli käitumine mis tahes sisendtingimuste korral);
- välised efektid (teate printimine, päringu lugemine terminalist jne).
- Mooduliloogika projekteerimine ja moodulite programmeerimine (kodeerimine).
- Moodulite õigsuse kontrollimine.
- Moodulite testimine.
- Andmebaasi kirjeldus tasemele individuaalsed parameetrid, tähemärki ja bitte.
- Sisseastumiskatsete plaan.
- Kasutusjuhend.
- Integreerimise ja silumise esialgne plaan. Järgmiste etappide sisu langeb põhimõtteliselt kokku tarkvara elutsükli vastavate protsessidega. Üldjuhul eristatakse tehnoloogilisi etappe lähtuvalt mõistlikust ja ratsionaalsest planeerimisest ja töökorraldusest. Võimalik seos tööetappide ja tarkvara elutsükli protsesside vahel on näidatud joonisel.
Riis. 1.
Tarkvara elutsükli mudelite tüübid
Kose mudel (klassikaline elutsükkel)
See mudel võlgneb oma välimuse W. Royce'ile (1970). Mudelil on ka teine nimi – juga. Mudeli eripära on see, et üleminek järgmisele etapile toimub alles pärast seda, kui eelmise etapi töö on täielikult lõpetatud; Läbitud etappide eest raha ei tagastata.
Riis. 2.
Väljatöötatud tarkvarale esitatavad nõuded, mis määratakse kindlaks koostamise ja analüüsi etappides, on rangelt dokumenteeritud tehniliste kirjelduste kujul ja salvestatakse kogu projekti arendamise ajaks. Iga etapp lõpeb täieliku dokumentatsiooni (TOR, EP, TP, RP) avaldamisega, millest piisab arenduse jätkamiseks teise arendusmeeskonna poolt. Selle lähenemise puhul on arenduse kvaliteedi kriteeriumiks tehniliste kirjelduste täitmise täpsus. Arendajate põhirõhk on optimaalsete väärtuste saavutamisel tehnilised omadused arendatud tarkvara - jõudlus, hõivatud mälu maht jne.
Eelised kaskaadmudel:
- igas etapis koostatakse täielik projektdokumentatsiooni komplekt, mis vastab täielikkuse ja järjepidevuse kriteeriumidele;
- loogilises järjestuses teostatavad tööde etapid võimaldavad planeerida kõigi tööde valmimise ajastust ja vastavaid kulusid.
Kaskaadkäsitlus on end hästi tõestanud tarkvarasüsteemide ehitamisel, millele saab kõik nõuded täielikult ja selgelt sõnastada juba projekti alguses. Kuni seda kõike kontrollivad standardid ja erinevad riiklikud vastuvõtukomisjonid, töötab skeem hästi.
Puudused kaskaadmudel:
- Vead tuvastatakse ja kõrvaldatakse alles testimisetapis, mis võib võtta palju aega;
- tegelikud projektid nõuavad sageli kõrvalekaldeid standardsest sammude järjestusest;
- tsükkel põhineb tarkvarale esitatavate esialgsete nõuete täpsel sõnastamisel, tegelikkuses on projekti alguses kliendi nõudmised vaid osaliselt kindlaks määratud;
- töö tulemused on tellijale kättesaadavad alles pärast projekti valmimist.
PS elutsükli iteratiivne mudel
Kasvamisega kommertsprojektid Selgus, et alati ei ole võimalik tulevase süsteemi disaini üksikasjalikult välja töötada, kuna süsteemi loomise ajal muutuvad selle toimimise paljud aspektid dünaamilistes tegevusvaldkondades (äris). Arendusprotsessi oli vaja muuta, et tagada vajalike paranduste tegemine pärast mis tahes arendusetapi lõppu. Nii tekkis PS elutsükli iteratiivne mudel, mida nimetatakse vahepealse juhtimisega mudeliks või faaside tsüklilise kordumisega mudeliks.
Riis. 3.
Iteratiivses mudelis saab disaini ja programmeerimise puudujääke hiljem kõrvaldada, naastes osaliselt eelmisesse etappi. Mida madalam on veatuvastusmäär, seda kallim on selle parandamine. Kui kodeerimisetapis vigade avastamiseks ja kõrvaldamiseks kuluv jõupingutus võtta üheks, siis nõuete väljatöötamise etapis on vigade tuvastamise ja kõrvaldamise kulud 5-10 korda väiksemad ning vigade tuvastamise ja kõrvaldamise kulud hooldusetapp on 20 korda väiksem, rohkem.
Riis. 4.
Sellises olukorras saab suure tähtsuse nõuete sõnastamise, spetsifikatsioonide koostamise ja süsteemiplaani koostamise etapp. Tarkvaraarhitektid vastutavad isiklikult kõigi järgnevate disainimuudatuste eest. Dokumentatsiooni maht ulatub tuhandetesse lehekülgedesse ja kooskõlastuskoosolekute arv on tohutu. Paljud projektid ei lahku kunagi planeerimise etapist, langedes "analüüsi halvatusse". Üks võimalikest viisidest selliste olukordade kõrvaldamiseks on prototüüpimine.
Paigutus
Sageli ei oska klient sõnastada nõudeid andmete sisestamiseks, töötlemiseks või väljastamiseks tulevase tarkvaratoote jaoks. Arendaja võib kahelda toote sobivuses operatsioonisüsteemiga, kasutajaga dialoogi vormis või algoritmi tõhususes. Sellistel juhtudel on soovitatav kasutada prototüüpimist. Prototüüpimise peamine eesmärk on kõrvaldada kliendi nõudmiste ebakindlus. Paigutus (prototüüpimine) on vajaliku toote mudeli loomise protsess.
Mudel võib olla järgmistes vormides.
- Paberi paigutus (joonistatud diagramm inimese ja masina dialoogist) või arvutipõhine paigutus.
- Töötav paigutus, mis rakendab mõnda nõutavat funktsiooni.
- Olemasolev programm, mille jõudlust tuleb parandada.
Nagu on näidatud joonisel, põhineb prototüüpimine korduvatel iteratsioonidel, mis hõlmavad klienti ja arendajat.
Riis. 5.
Prototüüpimise ajal toimingute jada on näidatud joonisel. Prototüüpimine algab loodavale tarkvarasüsteemile esitatavate nõuete kogumisest ja selgitamisest. Arendaja ja tellija määravad ühiselt tarkvara eesmärgid, määravad kindlaks, millised nõuded on teada ja millised on veel täpsustamisel. Seejärel viiakse läbi kiire projekteerimine. See keskendub omadustele, mis peaksid olema kasutajale nähtavad. Kiire projekteerimine viib paigutuse ehitamiseni. Paigutust hindab klient ja seda kasutatakse tarkvaranõuete selgitamiseks. Iteratsioonid jätkuvad seni, kuni makett paljastab kõik kliendi nõudmised ja võimaldab disaineril aru saada, mida on vaja teha.
Prototüüpimise eeliseks on võimalus tagada täielike süsteeminõuete kindlaksmääramine. Paigutuse puudused:
- klient võib kujundust eksitada tootega;
- arendaja võib maketi tootega ekslikult pidada.
Puuduste olemust tuleks selgitada. Kui klient näeb tarkvara töötavat versiooni, ei mõista ta enam, et tarkvara töötava versiooni otsimisel jäävad paljud kvaliteedi- ja kvaliteediprobleemid lahendamata. toetamise mugavus süsteemid. Kui arendaja sellest kliendile räägib, võib vastuseks olla nördimus ja nõudmine muuta kujundus kiiresti toimivaks tooteks. Sellel on negatiivne mõju tarkvaraarenduse juhtimisele.
Riis. 6.
Teisest küljest teeb arendaja töötava paigutuse kiireks saamiseks sageli teatud kompromisse. Näiteks programmeerimiskeel või operatsioonisüsteem ei pruugi olla kõige sobivam. Lihtsa demonstratsiooni jaoks võib kasutada ebaefektiivset (lihtsat) algoritmi. Mõne aja pärast unustab arendaja põhjused, miks need tööriistad ei sobi. Selle tulemusena integreeritakse süsteemi kaugeltki ideaalsest valikust.
Enne muude asendatud tarkvara elutsükli mudelite kaalumist kaskaadmudel, peaksime keskenduma disainistrateegiatele tarkvarasüsteemid. Tarkvara disainistrateegia määrab suuresti tarkvara elutsükli mudeli.
Tarkvara kujundamise strateegiad
Tarkvarasüsteemide kujundamiseks on kolm strateegiat:
- üksikkäik (eespool käsitletud kaskaadistrateegia) – projekteerimisetappide lineaarne jada;
- astmeline strateegia. Protsessi alguses määratletakse kõik kasutaja- ja süsteeminõuded, ülejäänud kujundus viiakse läbi versioonide jadana. Esimene versioon rakendab osa kavandatud funktsioonidest, järgmine versioon rakendab lisafunktsioone jne kuni tervikliku süsteemi saamiseni;
- evolutsiooniline strateegia. Süsteem on üles ehitatud ka versioonide jadana, kuid kõiki nõudeid pole protsessi alguses määratletud. Nõuded täpsustatakse versioonide väljatöötamisega. IEEE/EIA 12207 standardi nõuetele vastavate tarkvaradisaini strateegiate karakteristikud on toodud tabelis 1.
Inkrementaalne mudel
Inkrementaalne mudel on klassikaline näide inkrementaalsest disainistrateegiast. See ühendab järjestikuse kosemudeli elemendid iteratiivse paigutusfilosoofiaga (täiustusena pakkus välja B. Boehm kaskaadmudel). Iga siinne lineaarne jada loob kaasasoleva tarkvaralise juurdekasvu. Näiteks tekstitöötlustarkvara 1. astmes (versioonis) rakendab põhilisi failitöötlusfunktsioone, redigeerimis- ja dokumenteerimisfunktsioone; 2. astmes - keerukamad redigeerimis- ja dokumenteerimisvõimalused; 3. astmes – õigekirja- ja grammatikakontroll; neljandal sammul - lehe paigutuse võimalused.
Esimese juurdekasvu tulemuseks on baastoode, mis täidab põhinõuded (kuigi paljud abinõuded jäävad rakendamata). Järgmine juurdekasvuplaan hõlmab põhitoote muutmist, et pakkuda täiendavaid funktsioone ja funktsioone.
Oma olemuselt on inkrementaalne protsess iteratiivne, kuid erinevalt prototüüpimisest annab inkrementaalne mudel iga sammu juures töötava toote.
Sellise tarkvara elutsükli mudeli skeem on näidatud joonisel. Üks järkjärgulise lähenemise kaasaegseid rakendusi on äärmuslik programmeerimine (keskendunud väga väikestele funktsionaalsuse astmetele).
Riis. 7.
Elutsükli tarkvara spiraalmudel
Spiraalne mudel on klassikaline näide evolutsioonilise disainistrateegia rakendamisest. Mudel (autor B. Boehm, 1988) põhineb klassikalise elutsükli ja prototüüpimise parimatel omadustel, millele lisandub uus element - riskianalüüs, mis neis paradigmades puudub. Mudel määratleb neli tegevust, mida esindavad spiraali neli kvadrandit.
Riis. 8.
- Planeerimine – eesmärkide, valikute ja piirangute määratlemine.
- Riskianalüüs – võimaluste analüüs ja riskide tuvastamine/valik.
- Disain – järgmise taseme toote väljatöötamine.
- Hindamine – kliendi hinnang projekteerimise hetketulemustele.
Integreeriv aspekt spiraalne mudel on ilmne, kui võtta arvesse spiraali radiaalset mõõdet. Iga iteratsiooniga ehitatakse üha rohkem spiraali täisversioonid PS. Spiraali esimeses pöördes määratakse kindlaks esialgsed eesmärgid, võimalused ja piirangud, teadvustatakse risk ja analüüsitakse seda. Kui riskianalüüs näitab ebakindlust nõuetes, tuleb arendajale ja tellijale appi projekteerimiskvadrandis kasutatav prototüüpimine.
Simulatsiooni saab kasutada probleemsete ja täpsustatud nõuete edasiseks tuvastamiseks. Tellija hindab projekteerimistööd ja teeb muutmisettepanekud (kliendi hindamiskvadrant). Järgmine planeerimise ja riskianalüüsi faas põhineb tellija ettepanekutel. Igas spiraaltsüklis vormistatakse riskianalüüsi tulemused kujul "jätka, ärge jätkake". Kui risk on liiga suur, võidakse projekt peatada.
Enamasti spiraal jätkub, kusjuures iga samm liigutab arendajaid süsteemi üldisema mudeli poole. Iga spiraaltsükkel nõuab disaini (alumine parem kvadrant), mida saab rakendada klassikalise elutsükli või prototüüpide loomise teel. Pange tähele, et arendustegevuste arv (mis toimuvad alumises paremas kvadrandis) suureneb, kui liigume spiraali keskpunktist eemale.
Need toimingud on nummerdatud ja neil on järgmine sisu:
- – esmaste nõuete kogumine ja projekti planeerimine;
- – sama töö, kuid lähtub kliendi soovitustest;
- – esialgsetel nõuetel põhinev riskianalüüs;
- – kliendi reaktsioonil põhinev riskianalüüs;
- – üleminek integreeritud süsteemile;
- – süsteemi esialgne paigutus;
- – järgmine paigutuse tase;
- – kavandatud süsteem;
- – kliendi hinnang.
Eelised spiraalne mudel:
- kõige realistlikumalt (evolutsiooni kujul) peegeldab tarkvaraarendust;
- võimaldab selgesõnaliselt arvesse võtta riske arengu igas etapis;
- sisaldab iteratiivses arendusstruktuuris süstemaatilist lähenemisetappi;
- kasutab simulatsiooni riski vähendamiseks ja tarkvaratoodete täiustamiseks.
Puudused spiraalne mudel:
- võrdlev uudsus (puudub piisav statistika mudeli efektiivsuse kohta);
- suurenenud nõudmised kliendile;
- Raskused arendusaja jälgimisel ja juhtimisel.
Spiraalne arendusprotsessi mudel on tänapäeval kõige levinum. Selle kuulsaimad variandid on RUP (Rational Unified Process) firmalt Rational ja MSF (Microsoft Solution Framework). Modelleerimiskeelena kasutatakse UML-i (Unified Modeling Language). Süsteemi loomine peaks toimuma iteratiivselt, liikudes spiraalselt ja läbides samu etappe, selgitades igal pöördel tulevase toote omadusi. Näib, et nüüd on kõik korras: planeeritakse ainult seda, mida on võimalik ette näha, arendatakse kavandatut ja kasutajad hakkavad tootega eelnevalt tutvuma, omades võimaluse teha vajalikke muudatusi.
See nõuab aga väga suuri vahendeid. Tõepoolest, kui varem oli võimalik spetsialistide gruppe vastavalt vajadusele luua ja laiali saata, siis nüüd peavad kõik nad pidevalt projektis osalema: arhitektid, programmeerijad, testijad, juhendajad jne. õigeaegsete disainiotsuste kajastamiseks ja vajalike muudatuste tegemiseks.
Ratsionaalne ühtne protsess
Ratsionaalne ühtne protsess(Rational Unified Process, RUP) on üks parimaid tarkvaraarenduse metoodikaid. Tuginedes paljude edukate tarkvaraprojektide kogemusele, võimaldab RUP luua keerulisi tarkvarasüsteeme, mis põhinevad tööstuslikul arendusmeetodil. RUP-i arendamise taust ulatub 1980. aastate algusesse. ettevõttes Rational Software Corporation. 2003. aasta alguses omandas Rational IBM-i. Üks peamisi tugisambaid, millele RUP tugineb, on mudelite loomise protsess UML (Unified Modeling Language) abil.
RUP on üks spiraalseid tarkvaraarenduse metoodikaid. Metoodikat toetab ja arendab Rational Software. Üldteadmiste baasis kasutatakse modelleerimiskeelena ühtset modelleerimiskeelt (UML). Iteratiivne ja inkrementaalne tarkvaraarendus RUP-is hõlmab projekti jagamist mitmeks projektiks, mis viiakse läbi järjestikku ning iga arendusiteratsioon on selgelt määratletud eesmärkide kogumiga, mis tuleb iteratsiooni lõpus saavutada. Lõplik iteratsioon eeldab, et iteratsioonieesmärkide kogum peab täpselt ühtima tootekliendi määratud eesmärkide kogumiga, st kõik nõuded peavad olema täidetud.
Protsess hõlmab mudelite evolutsiooni; arendustsükli iteratsioon vastab ainulaadselt tarkvaramudeli konkreetsele versioonile. Iga iteratsioon sisaldab juhtelemente tarkvara elutsükkel: analüüs ja projekteerimine (modelleerimine), juurutamine, integreerimine, testimine, juurutamine. Selles mõttes on RUP teostus spiraalne mudel, kuigi seda kujutatakse üsna sageli tabelgraafiku kujul.
Sellel joonisel on kaks mõõdet: horisontaaltelg tähistab aega ja näitab protsessi elutsükli ajalisi aspekte; vertikaaltelg tähistab distsipliine, mis määratlevad protsessi füüsilise struktuuri. Näete, kuidas projekti rõhuasetus aja jooksul muutub. Näiteks kulutavad varased iteratsioonid rohkem aega nõuetele; hilisemates iteratsioonides pühendatakse juurutamisele rohkem aega. Horisontaalne telg moodustub ajaperioodidest – iteratsioonidest, millest igaüks on iseseisev arendustsükkel; Tsükli eesmärk on tuua lõpptootesse mingi ettemääratud käegakatsutav parendus, mis on huvirühmade seisukohast kasulik.
Riis. 9.
Ajateljel jaguneb elutsükkel neljaks põhifaasiks.
- Inception – projektikontseptsiooni kujundamine, loodava mõistmine, toote (visiooni) mõistmine, äriplaani (ärijuhtumi) väljatöötamine, programmi või osalahenduse prototüübi koostamine. See on teabe kogumise ja nõuete analüüsimise faas, mis määratleb projekti kui terviku kuvandi. Eesmärk on saada toetust ja rahastust. Viimases iteratsioonis on selle etapi tulemuseks tehniline spetsifikatsioon.
- Disain, arendus (Väljatöötamine) - planeeringu selgitamine, selle loomise mõistmine, projekteerimine, vajalike toimingute ja ressursside planeerimine, omaduste täpsustamine. Etapp lõpeb teostatava arhitektuuriga, kui kõik arhitektuursed otsused on tehtud ja riskidega arvestatud. Käivitatav arhitektuur on töötav tarkvara, mis demonstreerib põhiliste arhitektuuriotsuste rakendamist. Viimases iteratsioonis on see tehniline projekt.
- Rakendamine, süsteemi loomine (Construction) on süsteemi arhitektuurile omase funktsionaalsuse laiendamise etapp. Viimases iteratsioonis on see töötav mustand.
- Rakendamine, juurutamine (Üleminek). Toote lõpliku versiooni loomine. Toote tutvustamise faas, toote tarnimine konkreetsele kasutajale (paljundamine, tarnimine ja koolitus).
Vertikaaltelg koosneb distsipliinidest, millest igaüht saab täpsemalt kirjeldada nii sooritatavate ülesannete, nende eest vastutavate rollide, toodetega, mis ülesannetele sisendina tarnitakse ja nende teostamise käigus vabastatakse jne.
Mööda seda telge on RUP-i elutsükli võtmedistsipliinid, mida sageli nimetatakse vene keeles protsessideks, kuigi see ei vasta selle metoodika seisukohalt, mida toetavad IBM-i (ja/või kolmandate osapoolte) tööriistad.
- Ärianalüüs ja modelleerimine (Business modeling) tagab modelleerimispõhimõtete rakendamise, et uurida organisatsiooni äritegevust ja koguda selle kohta teadmisi, optimeerida äriprotsesse ja teha otsuseid nende osalise või täieliku automatiseerimise kohta.
- Nõuete haldamine seisneb huvirühmadelt teabe võtmises ja selle muutmises nõuete kogumiks, mis määratlevad arendatava süsteemi sisu ja täpsustavad ootusi, mida süsteem peaks tegema.
- Analüüs ja projekteerimine hõlmab protseduure nõuete muutmiseks vahekirjeldusteks (mudeliteks), mis näitavad, kuidas neid nõudeid tuleks rakendada.
- Rakendamine hõlmab koodiarendust, arendaja tasemel testimist ning komponentide, alamsüsteemide ja kogu süsteemi integreerimist vastavalt kehtestatud spetsifikatsioonidele.
- Testimine on pühendatud loodud toote kvaliteedi hindamisele.
- Juurutamine hõlmab tegevusi, mis toimuvad toodete klientidele tarnimisel ja toote lõppkasutajatele kättesaadavaks tegemisel.
- Konfiguratsioonihaldus ja muudatuste haldus (Configuration management) on pühendatud vahe- ja lõpptoodete sünkroniseerimisele ning nende arendamise juhtimisele projekti käigus ning varjatud probleemide leidmisele.
- Projektijuhtimine on pühendatud projekti planeerimisele, riskijuhtimisele, edenemise jälgimisele ja põhinäitajate pidevale hindamisele.
- Keskkonnajuhtimine sisaldab arengukeskkonna loomise elemente infosüsteem ja projekti tegevuste toetamine.
Olenevalt projekti spetsiifikast saab kasutada mis tahes IBM Rationali ja ka kolmandate osapoolte tööriistu. RUP soovitab projekti edukaks arendamiseks järgida kuut praktikat: iteratiivne arendus; nõuete haldamine; moodularhitektuuride kasutamine; visuaalne modelleerimine; kvaliteedikontroll; muutuste jälgimine.
RUP-i lahutamatuks osaks on artefaktid (artefact), pretsedendid (pretsedent) ja rollid (rollid). Artefaktid on mõned projekti tooted, mis luuakse või kasutatakse projektis lõpptoote kallal töötades. Pretsedendid on tegevuste jadad, mida süsteem jälgitava tulemuse saavutamiseks teeb. Tegelikult on iga üksikisiku või rühma töö tulemus artefakt, olgu selleks analüüsidokument, mudeli element, koodifail, testskript, vea kirjeldus vms. Loomise eest vastutavad teatud spetsialistid üht või teist tüüpi artefakti. Seega määratleb RUP selgelt iga arendusmeeskonna liikme kohustused – rollid – ühes või teises etapis ehk millal ja kes peaks selle või teise artefakti looma. Kogu tarkvarasüsteemi arendamise protsessi käsitletakse RUP-is kui artefaktide loomise protsessi - alates esialgsetest analüüsidokumentidest kuni käivitatavate moodulite, kasutusjuhenditeni jne.
RUP-protsesside arvutitoe jaoks on IBM välja töötanud laia valiku tööriistu:
- Ratsionaalne roos – CASE- visuaalse modelleerimise tööriist infosüsteemid, millel on koodielementide genereerimise võimalus. Toote eriväljaanne - Rational Rose RealTime - võimaldab teil saada väljundina käivitatava mooduli;
- Rational Requisite Pro on nõuete haldamise tööriist, mis võimaldab teil luua, struktureerida, prioriseerida, jälgida ja juhtida nõuete muudatusi, mis tekivad rakenduse komponentide arendamise mis tahes etapis;
- Rational ClearQuest on muudatuste haldamiseks ja projekti defektide jälgimiseks mõeldud toode (vigade jälgimine), mis integreerub tihedalt testimise ja nõuete haldamise tööriistadega ning pakub ühtset keskkonda kõigi vigade ja dokumentide omavaheliseks sidumiseks;
- Rational SoDA on toode projekti dokumentatsiooni automaatseks genereerimiseks, mis võimaldab teil määrata ettevõtte siseste dokumentide jaoks ettevõtte standardi. Samuti on võimalik viia dokumentatsioon olemasolevatele standarditele (ISO, CMM);
- Rational Purify, Rational Quantify Rational PureCoverage, – testimis- ja silumistööriistad;
- Rational Visual Quantify on jõudluse mõõtmise tööriist rakenduste ja komponentide arendajatele, kes programmeerivad C/C++, Visual Basicu ja Java keeles; aitab tuvastada ja kõrvaldada tarkvara jõudluse kitsaskohti;
- Rational Visual PureCoverage – tuvastab automaatselt koodipiirkonnad, mida ei testita;
- Rational ClearCase on tarkvara konfiguratsioonihaldustoode (Rational's Software Configuration Management, SCM), mis võimaldab kõikide projektidokumentide versioonikontrolli. Selle abil saate korraga hooldada mitut projekti versiooni, nende vahel kiiresti ümber lülituda Rational Requisite Pro toetab uuendusi ja jälgi. muudatused arendusmeeskonnale esitatavates nõuetes;
- SQA TeamTest – tööriist testimise automatiseerimine;
- Rational TestManager on testihaldussüsteem, mis koondab kõik testimisega seotud tööriistad, artefaktid, skriptid ja andmed;
- Rational Robot – tööriist testide loomiseks, muutmiseks ja automaatseks käivitamiseks;
- SiteLoad, SiteCheck – tööriistad veebisaitide toimivuse ja katkiste linkide olemasolu testimiseks;
- Rational PerformanceStudio – mõõdab ja ennustab süsteemi jõudlusnäitajaid.
Seda tootekomplekti täiustatakse ja laiendatakse pidevalt. Näiteks IBMi hiljutine toode Rational Software Architect (RSA) on osa IBMi tarkvaraarendusplatvormist – tööriistade komplektist, mis toetab tarkvarasüsteemide arendamise elutsüklit. IBM Rational Software Architect toode on mõeldud ühtse modelleerimiskeele UML 2.0 abil arendatavate tarkvarasüsteemide mudelite, peamiselt arendatava rakenduse arhitektuuri mudelite, koostamiseks. RSA aga kombineerib selliste tarkvaratoodete nagu Rational Application Developer, Rational Web Developer ja Rational Software Modeler funktsioone, võimaldades seeläbi arhitektidel ja analüütikutel luua arendatavast infosüsteemist erinevaid vaateid UML 2.0 keeles ning arendajatel arendada. J2EE, XML, veebiteenused jne.
RUP-i põhimõtteid järgides võimaldab Rational Software Architect luua vajalikke mudeleid selliste erialade töövoogudes nagu:
- ärianalüüs ja modelleerimine (äri modelleerimine);
- nõuete haldamine;
- analüüs ja disain (Analysis and Design);
- rakendamine.
Lisaks toetab Rational Software Architect mudelipõhist arendust (MDD), mis võimaldab modelleerida tarkvara erinevatel abstraktsioonitasemetel jälgitavusega.
MSF (Microsoft Solution Framework)
IT-projektidest maksimaalse kasu saamiseks andis Microsoft 1994. aastal välja juhiste komplekti tõhus disain, selle tehnoloogiate baasil ehitatud lahenduste arendamine, juurutamine ja toetamine. Need teadmised põhinevad kogemustel, mille Microsoft on selle kallal töötamise ajal omandanud suured projektid tarkvaraarenduse ja -hoolduse kohta, Microsofti konsultantide kogemused ja IT-tööstuse parim, mis hetkel on kogunenud. Kõik see on esitatud kahe omavahel seotud ja üksteist täiendava teadmusvaldkonnana: Microsoft Solutions Framework (MSF) ja Microsoft Operations Framework (MOF).
Tuleb märkida, et Microsoft on välja töötanud rakendusliku ja eriotstarbelise kasutamise tehnikad, mis põhinevad üldistel MSF-meetoditel. Lisaks sertifitseerib Microsoft eksperte spetsiaalselt MSF-i kasutamise rakendusteadmiste osas (näiteks MCTS 74-131 sertifikaat projektijuhtimise tehnikate asjatundlikkuse kohta). Enne MSF-meetodite õppimist peate esmalt kindlaks määrama, millisele MSF-rakendusele viitate.
Kõige populaarsemad Microsofti välja töötatud MSF-rakenduste valikud on:
- projektijuhtimise valdkonna lahenduste juurutamise metoodika;
- IT projektijuhtimise metoodika, mis põhineb MSF ja Agile metoodikatel.
MSF-i rakendusversioonide olulisust rõhutab asjaolu, et “puhtal versioonil” Microsoft ise MSF-i metoodikat oma IT-projektides ei kasuta. Microsoft Consulting Services projektid kasutavad hübriidset MSF ja Agile metoodikat. Hoolimata välistest olulistest erinevustest Microsofti ekspertide poolt välja töötatud MSF-i rakendatud versioonides, on nende jaoks mõeldud MSF-meetodite baas endiselt tavaline ja peegeldab iteratiivse projektijuhtimise üldisi metoodilisi lähenemisviise.
MOF on loodud selleks, et pakkuda organisatsioonidele, kes loovad Microsofti toodetel ja tehnoloogiatel põhinevaid missioonikriitilisi IT-lahendusi, tehnilisi juhiseid nende töökindluse, kättesaadavuse, toetamise mugavus(toetatavus) ja juhitavus (juhitavus). MOF tegeleb personali ja protsesside korraldusega seotud küsimustega; tehnoloogiad ja juhtimine keerulistes, hajutatud ja heterogeensetes IT-keskkondades. MOF põhineb IT Infrastructure Library (ITIL) kogutud parimatel tootmistavadel, mille on koostanud Ühendkuningriigi valitsuse agentuur Central Computer and Telecommunications Agency.
Ärilahenduse loomine ettenähtud aja ja eelarve piires nõuab tõestamist metoodiline alus. MSF pakub tõestatud metoodikaid edukate IT-lahenduste planeerimiseks, kujundamiseks, arendamiseks ja juurutamiseks. Tänu oma paindlikkusele, mastaapsusele ja jäikade juhiste puudumisele suudab MSF rahuldada igas suuruses organisatsiooni või projektimeeskonna vajadusi. MSF-i metoodika koosneb inimeste, protsesside, tehnoloogiliste elementide ja nendega seotud probleemide juhtimise põhimõtetest, mudelitest ja distsipliinidest, mis on tüüpilised enamikule projektidele. MSF koosneb kahest mudelist ja kolmest distsipliinist. Neid on üksikasjalikult kirjeldatud 5 valges raamatus. MSF-i õppimist on parem alustada mudelitega (projektimeeskonna mudel, protsessimudel) ja seejärel liikuda edasi erialade juurde (projektijuhtimise distsipliin, riskijuhtimise distsipliin, koolitusjuhtimise distsipliin).
MSF protsessimudel esindab üldist metoodikat IT-lahenduste arendamiseks ja juurutamiseks. Selle mudeli eripära on see, et tänu oma paindlikkusele ja rangelt kehtestatud protseduuride puudumisele saab seda kasutada väga paljude IT-projektide arendamisel. See mudel ühendab endas kahe standardse tootmismudeli omadused: juga ja spiraal. MSF 3.0 protsessimudelit on värskendatud veel ühega uuenduslik aspekt: see hõlmab kogu lahenduse loomise elutsüklit alates selle alguspunktist kuni selle tegeliku rakendamiseni. Selline lähenemine aitab projektimeeskondadel keskenduda lahenduse ärilisele väärtusele, kuna see tulu muutub reaalseks alles pärast juurutamise lõpetamist ja toote kasutamist.
MSF-protsess on keskendunud " verstapostidele" - projekti põhipunktidele, mis iseloomustavad selle raames mis tahes olulise (vahe- või lõpptulemuse) saavutamist. Seda tulemust saab hinnata ja analüüsida, mis eeldab vastuseid küsimustele: “Kas projektimeeskond on saanud selge arusaama projekti eesmärkidest ja ulatusest?”, “Kas tegevuskava on piisavalt koostatud?”, “Kas toode vastab kinnitatud spetsifikatsioonile?", "Kas lahendus rahuldab kliendi vajadusi?" jne.
MSF protsessimudel arvestab pidevaid muutusi projekteerimisnõuded. See eeldab, et lahenduse väljatöötamine peaks koosnema lühikestest tsüklitest, mis loovad progressiivse liikumise lahenduse kõige lihtsamatest versioonidest selle lõpliku vormini.
MSF-protsessi mudeli omadused on järgmised:
- faaside ja vahe-eesmärkide lähenemisviis;
- iteratiivne lähenemine;
- integreeritud lähenemine lahenduste loomisele ja rakendamisele.
Protsessi mudel sisaldab järgmisi arendusprotsessi põhifaase:
- kontseptsiooni väljatöötamine (Envisioning);
- planeerimine (Planeerimine);
- arendamine;
- stabiliseerimine;
- rakendamine (juurutamine).
Lisaks on suur hulk vahe-eesmärke, mis näitavad teatud edu saavutamist projekti jooksul ja jagavad suured töölõigud väiksemateks, jälgitavateks piirkondadeks. Protsessimudeli iga etapi jaoks määratleb MSF:
- mis (millised artefaktid) on selle faasi tulemus;
- mille kallal iga rolliklaster selles faasis töötab.
MSF-i raames luuakse kood, dokumentatsioon, kavandid, plaanid ja muud töömaterjalid reeglina iteratiivsetel meetoditel. MSF soovitab alustada lahenduse väljatöötamist selle põhifunktsioonide loomise, testimise ja juurutamise teel. Seejärel lisatakse lahendusele üha uusi funktsioone. Seda strateegiat nimetatakse versioonistrateegiaks. Kuigi väikeste projektide jaoks võib piisata ühe versiooni avaldamisest, on soovitatav mitte jätta kasutamata võimalust luua ühest lahendusest mitu versiooni. Uute versioonide loomisega areneb lahenduse funktsionaalsus.
Iteratiivne lähenemine arendusprotsessile eeldab paindliku dokumentatsiooni haldamise viisi kasutamist. Elavad dokumendid peavad muutuma, kui projekt areneb ja nõuded lõpptootele muutuvad. MSF pakub mitmeid standardseid dokumendimalle, mis on tootearenduse iga etapi artefaktid ning mida saab kasutada arendusprotsessi planeerimiseks ja juhtimiseks.
Lahendusel pole ärilist väärtust enne, kui see on rakendatud. Just sel põhjusel sisaldab MSF protsessimudel kogu lahenduse loomise elutsüklit, sealhulgas selle juurutamist – kuni hetkeni, mil lahendus hakkab väärtust tooma.
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. LCPO määramine 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. LCPO faasid ja töö Boehmi järgi
1.3.1. Kaskaadmudel.
1.3.2. Kaskaadmudeli majanduslik põhjendus.
1.3.3. Kaskaadmudeli täiustamine.
1.3.4. Elutsükli faaside määramine.
1.3.5. Põhitöö projektiga.
Kirjandus.
Sissejuhatus
Arvutite tööstuslik kasutamine ja kasvav nõudlus programmide järele on esitanud kiireloomulisi väljakutseid, mida tuleb oluliselt suurendada tarkvaraarenduse tootlikkus, tööstuslike planeerimis- ja programmitöö meetodite arendamine, organisatsiooniliste, tehniliste, tehniliste, majanduslike ja sotsiaalpsühholoogiliste tehnikate, mustrite ja meetodite ülekandmine materjali tootmise sfäärist arvutikasutusse. Kompleksne lähenemine tarkvara arendamise, käitamise ja hoolduse protsessidele esitas ta hulga pakilisi probleeme, mille lahendamine kõrvaldab kitsaskohad programmide kujundamisel, vähendab tööde valmimisaega, parandab olemasolevate programmide valikut ja kohandamist ning võib-olla määrab manustatud arvutitega süsteemide saatus.
Suurte tarkvaraprojektide arendamise praktikas sageli puudub ühtne lähenemine tööjõukulude, tööde tähtaegade ja materjalikulude hindamisele, mis takistab tarkvaraarenduse tootlikkuse tõusu ning lõppkokkuvõttes ka tarkvara elutsükli efektiivset juhtimist. Kuna mis tahes tüüpi programmist saab toode (v.a võib-olla hariduslikud, prototüüpprogrammid), peaks lähenemine selle tootmisele paljuski sarnanema tööstustoodete tootmise lähenemisviisiga ning programmi kavandamise küsimused muutuvad äärmiselt oluliseks. See idee on B.W. raamatu keskmes. Boehmi "Tarkvaratehnika", mida kasutasime selle kirjutamiseks kursusetöö. Selles raamatus viitab tarkvara disain tarkvaratoote disaini loomise protsessile.
1 Tarkvara elutsükkel
SISSEJUHATUS
LCPO on pidev protsess, mis algab hetkest, mil tehakse otsus tarkvara loomise vajaduse kohta ja lõpeb hetkel, mil see täielikult kasutusest eemaldatakse.
Tarkvara elutsükli (SLC) faaside ja tegevuste, programmeerimisprotsessi etappide, kaskaad- ja spiraalmudelite määramiseks 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 protsessi struktuur, mis hõlmab kaheksat faasi. Täpsemalt tutvustatakse seda edaspidi.
Üks neist võimalikud variandid Lehmanni järgi võib kasutada tipptasemel kirjeldust, mis sisaldab kolme põhifaasi ja kujutab kõige üldisemal juhul elutsükli kirjeldust.
Ja mitmekesisuse huvides tutvustame programmeerimisprotsessi etappe, mida D. Riley tutvustas raamatus “Modula-2 keele kasutamine”. See idee on minu arvates väga lihtne ja tuttav ning alustame sellest.
1.1 Riley programmeerimisprotsessi sammud
Programmeerimisprotsess koosneb neljast etapist (joonis 1):
probleemi avaldus, st. piisava arusaamise saamine sellest, millist ülesannet programm peaks täitma;
juba püstitatud probleemile lahenduse kujundamine (ü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äimasolev programmi tõrkeotsingu ja uute funktsioonide lisamise protsess.
Riis. 1.Neli programmeerimisetappi.
Programmeerimine algab hetkest, mil kasutaja, st. keegi, kes vajab probleemi lahendamiseks programmi, teatab probleemi süsteemianalüütik. Kasutaja ja süsteemianalüütik määratlevad ühiselt probleemiavalduse. Seejärel edastatakse viimane algoritmist, kes vastutab lahenduse kujundamise eest. Lahendus (või algoritm) kujutab endast toimingute jada, mille täitmine viib ülesande lahendamiseni. Kuna algoritm ei sobi sageli 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 algoritmistide hulk olla märkimisväärne. Lisaks võib ettenägematute asjaolude tõttu osutuda vajalikuks naasta eelmiste sammude juurde. Kõik see on lisaargument hoolikale tarkvara kavandamisele: iga etapi tulemused peaksid olema täielikud, täpsed ja arusaadavad.
1.1.1 Probleemi püstitus
Programmeerimise üks olulisemaid samme on probleemi määratlemine. See toimib lepinguna kasutaja ja programmeerija(te) vahel. Nagu juriidiliselt halvasti koostatud leping, on ka halvasti kirjutatud probleemipüstitus kasutu. Hea probleemipüstituse korral esindavad nii kasutaja kui ka programmeerija selgelt ja üheselt täitmist vajavat ülesannet, s.t. sel juhul arvestatakse nii kasutaja kui programmeerija huve. Kasutaja saab plaanida kasutada tarkvara, mida pole veel loodud, lähtudes teadmistest, mida see suudab. Probleemi hea sõnastus on selle lahenduse sõnastuse aluseks.
Probleemi sõnastamine (programmi spetsifikatsioon); tähendab sisuliselt täpset, täielikku ja arusaadavat kirjeldust selle kohta, mis konkreetse programmi täitmisel juhtub. Tavaliselt vaatab kasutaja arvutit kui musta kasti: tema jaoks ei ole oluline, kuidas arvuti töötab, vaid oluline on see, mida arvuti suudab teha, mis kasutajat huvitab. Sel juhul on põhitähelepanu suunatud inimese ja masina suhtlusele.
Hea probleemiavalduse omadused:
Täpsus, st. kõrvaldades igasuguse ebaselguse. 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 tahtmatu sisendi kaalumine ja sobiva väljundi määramine.
Selgus, st. see peab olema arusaadav nii kasutajale kui ka süsteemianalüütikule, kuna probleemi püstitus on nendevaheline ainuke leping.
Tihti on täpsuse, täielikkuse ja selguse nõuded vastuolus. Jah, paljud juriidilised dokumendid on raske mõista, sest need on kirjutatud formaalses keeles, mis võimaldab teatud sätted sõnastada ülima täpsusega, välistades kõik väiksemad lahknevused. Näiteks mõni küsimus eksamitöödes on mõnikord nii täpselt sõnastatud, et õpilasel kulub küsimuse mõistmisele rohkem aega kui sellele vastamisele. Pealegi ei pruugi üliõpilane detailide rohkuse tõttu isegi küsimuse peamist tähendust hoomata. Probleemi parim sõnastus on selline, mis saavutab kõigi kolme nõude tasakaalu.
Probleemi avalduse standardvorm.
Mõelge järgmisele probleemilausele: "Sisestage kolm numbrit ja väljastage numbrid järjekorras."
Selline väide ei vasta ülaltoodud nõuetele: see ei ole täpne, täielik ega arusaadav. Tõepoolest, kas numbreid tuleks sisestada üks reale või kõik numbrid ühele reale? Kas väljend "järjekorras" tähendab järjestamist suurimast väiksemani, vähimast suurimani või samas järjekorras, milles need kasutusele võeti.
Ilmselgelt ei vasta selline väide paljudele küsimustele. Kui võtta arvesse vastused kõikidele küsimustele, muutub ülesande püstitus paljusõnaliseks ja raskesti mõistetavaks. Seetõttu soovitab D. Riley kasutada probleemi püstitamiseks standardvormi, mis tagab maksimaalse täpsuse, täielikkuse, selguse ja sisaldab:
ülesande nimi (skemaatiline määratlus);
üldkirjeldus (ülesande lühikokkuvõte);
vead (ebatavalised sisestusvalikud on selgelt loetletud, et näidata kasutajatele ja programmeerijatele, milliseid toiminguid masin sellistes olukordades teeks);
näide ( hea näide võib anda edasi probleemi olemust, aga ka illustreerida erinevaid juhtumeid).
Näide. Probleemi avaldus standardvormis.
NIMI
Kolme täisarvu sortimine.
KIRJELDUS
Kolme täisarvu sisend ja väljund, sorteeritud väikseimast suurimani.
Sisestatakse kolm täisarvu, üks arv rea kohta. Täisarv on üks või mitu järjestikust kümnendkohta, millele võib eelneda plussmärk “+” või miinusmärk “–”.
Kolm sisestatud täisarvu trükitakse, kõik kolm trükitakse samale reale. 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. Etapid ja verstapostid
IS-i elutsükkel on sündmuste jada, mis toimuvad süsteemiga selle loomise ja kasutamise käigus.
Lava- tarkvara loomise protsessi osa, mis on piiratud teatud ajaraamiga ja lõpeb konkreetse toote (mudelid, tarkvarakomponendid, dokumentatsioon) väljalaskmisega, mis on määratud selle etapi nõuetega.
Elutsüklit modelleeritakse traditsiooniliselt teatud arvu järjestikuste etappidena (või etappide, faasidena). Praegu ei ole üldiselt aktsepteeritud tarkvarasüsteemi elutsükli jaotust etappideks. Mõnikord tuuakse lava esile eraldi punktina, mõnikord lisatakse see suurema lava lahutamatu osana. Ühes või teises etapis tehtavad toimingud võivad erineda. Nende etappide nimetustes pole ühtsust.
Traditsiooniliselt eristatakse järgmisi tarkvara elutsükli põhietappe:
Nõuete analüüs,
disain,
kodeerimine (programmeerimine),
Testimine ja silumine,
Kasutamine ja hooldus.
Tarkvara elutsükkel. Kaskaadmudel
kaskaadmudel (70–80 aastat) ≈ hõlmab järgmisse etappi liikumist pärast eelmise etapi töö täielikku lõpetamist,
Kaskaadimudeli peamine saavutus on etappide täielikkus. See võimaldab planeerida kulusid ja tähtaegu. Lisaks genereeritakse projektdokumentatsioon, mis on terviklik ja järjepidev.
Kose mudel on rakendatav väikestele tarkvaraprojektidele, millel on selgelt määratletud ja muutumatud nõuded. Tõeline protsess võib paljastada tõrkeid mis tahes etapis, mis viib tagasi ühele eelnevatest etappidest. Sellise tarkvaratootmise mudeliks on kaskaad-tagastus
Tarkvara elutsükkel. Vahejuhtimisega astmeline mudel
samm-sammult mudel vahepealse juhtimisega (80-85) ≈ tarkvaraarenduse iteratiivne mudel etappidevahelise tagasisideahelaga. Selle mudeli eeliseks on see, et astmetevahelised kohandused tagavad kaskaadmudeliga võrreldes väiksema töömahukuse; aga iga etapi eluiga ulatub üle kogu arenguperioodi,
Probleemi lahendamise peamised etapid
Programmeerimise eesmärk on kirjeldada andmetöötlusprotsesse (edaspidi lihtsalt protsessid).
Andmed on faktide ja ideede esitamine formaliseeritud kujul, mis sobivad edastamiseks ja töötlemiseks teatud protsessis ning teave on tähendus, mis antakse andmetele nende esitamisel.
Andmetöötlus on andmetega süstemaatilise toimingute jada sooritamine. Andmed esitatakse ja salvestatakse andmekandjatele.
Andmekandjate kogumit, mida kasutatakse igasuguseks andmetöötluseks, nimetatakse infokeskkonnaks (andmekandjaks).
Andmete kogum, mis sisaldub igal hetkel infokeskkonnas – infokeskkonna olek.
Protsessi võib defineerida kui mingi infokeskkonna järjestikuste olekute jada.
Protsessi kirjeldamine tähendab infokeskkonna olekute järjestuse määramist. Selleks, et vajalik protsess genereeritaks automaatselt igas arvutis vastavalt etteantud kirjeldusele, on vajalik selle kirjelduse vormistamine.
Tarkvara kvaliteedi kriteeriumid
Kaubandustoode (toode, -teenus) peab vastama tarbija nõudmistele.
Kvaliteet on toote (toote, teenuse) objektiivne omadus, mis näitab tarbija rahulolu astet
Kvaliteedi omadused:
Esitus– süsteem töötab ja rakendab vajalikke funktsioone.
Töökindlus– süsteem töötab tõrgeteta või tõrgeteta.
Taastavus.
Tõhusus– süsteem rakendab oma funktsioone parimal võimalikul viisil.
Majanduslik efektiivsus– lõpptoote minimaalne maksumus maksimaalse kasumiga.
Kvaliteedi omadused:
Inimfaktorit arvesse võttes- kasutusmugavus, tarkvaraga töötamise õppimise kiirus, hoolduse lihtsus, muudatuste tegemine.
Kaasaskantavus(mobiilsus) – koodi teisaldatavus teisele platvormile või süsteemile.
Funktsionaalne täielikkus– võib-olla kõige täielikum väliste funktsioonide rakendamine.
Arvutamise täpsus
Algoritmi omadused.
Tõhusus tähendab võimalust saada tulemus pärast lõpliku arvu tehteid.
Kindlus seisneb saadud tulemuste kokkulangevuses, sõltumata kasutajast ja kasutatud tehnilistest vahenditest.
Massi iseloom peitub võimaluses rakendada algoritmi tervele klassile sarnastele probleemidele, mis erinevad algandmete konkreetsete väärtuste poolest.
Diskreetsus - võimalus jagada algoritmiga ettenähtud arvutusprotsess eraldi etappideks, võimalus valida teatud struktuuriga programmi sektsioone.
Algoritmide kirjeldamise viisid
Algoritmide kirjeldamiseks (esitamiseks) on järgmised viisid:
1. sõnaline kirjeldus;
2. algoritmi kirjeldus matemaatiliste valemite abil;
3. algoritmi graafiline kirjeldus plokkskeemi kujul;
4. algoritmi kirjeldus pseudokoodi abil;
5. kombineeritud meetod algoritmi kujutamiseks, kasutades verbaalseid, graafilisi ja muid meetodeid .
6. Petri võrkude kasutamine.
Sõnaline kirjeldus algoritm on algoritmi struktuuri kirjeldus loomulikus keeles. Näiteks kodumasinatega on tavaliselt kaasas kasutusjuhend, s.t. sõnaline kirjeldus algoritmist, mille järgi seda seadet kasutada tuleks.
Graafiline kirjeldusalgoritm plokkskeemi kujul on algoritmi ülesehituse kirjeldus sideliinidega geomeetriliste kujundite abil.
Algoritmi vooskeem on ülesande lahendamise meetodi graafiline esitus, mis kasutab operatsioonide esitamiseks spetsiaalseid sümboleid.
Algoritmi plokkskeemi moodustavad sümbolid määratakse GOST 19.701-90 järgi. See GOST vastab rahvusvaheline standard algoritmide kavandamine, seetõttu mõistetakse GOST 19.701-90 järgi koostatud algoritmide vooskeemi erinevates riikides üheselt.
Pseudokood– algoritmi struktuuri kirjeldus loomulikus, kuid osaliselt formaliseeritud keeles. Pseudokood kasutab mõningaid formaalseid konstruktsioone ja tavalisi matemaatilisi sümboleid. Pseudokoodi kirjutamisel puuduvad ranged süntaksireeglid.
Mõelgem lihtsaim näide. Olgu vaja kirjeldada algoritmi kahe arvu suurima väärtuse kuvamiseks monitori ekraanil.
Joonis 1 - Algoritmi kirjelduse näide plokkskeemi kujul
Sama algoritmi kirjeldus pseudokoodis:
2. Sisestage numbrid: Z, X
3. Kui Z > X, siis väljund Z
4. Muidu väljund X
Igal loetletud algoritmide kujutamise meetoditel on eelised ja puudused. Näiteks verbaalne meetod on paljusõnaline ja puudub selgus, kuid võimaldab paremini kirjeldada üksikuid tehteid. Graafiline meetod on visuaalsem, kuid sageli on vaja mõnda operatsiooni kirjeldada verbaalses vormis. Seetõttu on keerukate algoritmide väljatöötamisel parem kasutada kombineeritud meetodit.
Algoritmide tüübid
lineaarne;
hargnemine;
tsükliline.
· Lineaarne algoritm- käskude (käskude) komplekt, mida täidetakse järjestikku üksteise järel.
· Hargnemisalgoritm- algoritm, mis sisaldab vähemalt ühte tingimust, mille kontrollimise tulemusena annab arvuti ülemineku ühele kahest võimalikust etapist.
· Round robin algoritm- algoritm, mis hõlmab sama toimingu (sama toimingu) korduvat kordamist uute algandmetega. Enamik arvutus- ja valikute loendamise meetodeid on taandatud tsüklilistele algoritmidele. Programmi tsükkel - käskude jada (seeria, tsükli keha), mida saab korduvalt täita (uute lähteandmete jaoks), kuni teatud tingimus on täidetud.
C. Andmetüübid.
Andmetüüp on väärtusvahemiku kirjeldus, mida teatud tüüpi muutuja võib võtta. Iga andmetüüpi iseloomustavad:
1. hõivatud baitide arv (suurus)
2. väärtuste vahemik, mille seda tüüpi muutuja võib võtta.
Kõik andmetüübid võib jagada järgmisteks tüüpideks:
1. liht- (skalaarne) ja kompleksne (vektor) tüüp;
2. põhiline (süsteem) ja kasutaja (kasutaja poolt määratletud).
SI-keeles moodustavad põhitüüpide süsteemi neli andmetüüpi:
1. sümboolne,
2. täisarv,
3. ühe täpsusega reaal,
4. topelttäpsus reaal.
C-programmi struktuur.
1. C++ keeleoperaatorid
Operaatorid kontrollivad programmi täitmise protsessi. C++ keeleoperaatorite komplekt sisaldab kõiki struktureeritud programmeerimise juhtkonstruktsioone.
Liitlause on piiritletud lokkis traksidega. Kõik muud väited lõpevad semikooloniga.
Tühi operaator – ;
Tühi väide on väide, mis koosneb ainult semikoolonist. See võib ilmuda kõikjal programmis, kus süntaks nõuab avaldust. Tühja avalduse täitmine ei muuda programmi olekut.
Liitoperaator – (...)
Liitlause toime seisneb selles, et selles sisalduvad laused täidetakse järjestikku, välja arvatud juhul, kui avaldus annab juhtimise selgesõnaliselt üle programmi mõnda teise kohta.
Erandi käsitlemise avaldus
proovi (<операторы> }
püüda (<объявление исключения>) { <операторы> }
püüda (<объявление исключения>) { <операторы> }
...
püüda (<объявление исключения>) { <операторы> }
Tingimuslik operaator
kui (<выражение>) <оператор 1>
Vaheta operaatorit
lüliti (<выражение>)
( juhtum<константное выражение 1>: <операторы 1>
juhtum<константное выражение 2>: <операторы 2>
...
juhtum<константное выражение N>: <операторы N>
}
Switch-lauset kasutatakse programmi täitmiseks ühe mitme alternatiivse tee valimiseks. Switch-lause hindamine algab avaldise hindamisega, misjärel viiakse juhtimine üle avaldise hinnatud väärtusega võrdse konstantse avaldisega märgitud lausele. Lüliti avaldusest väljub katkestuslause. Kui avaldise väärtus ei võrdu ühegi konstantse avaldisega, kantakse juhtimine üle vaikemärksõnaga märgitud lausele, kui see on olemas.
Silmusoperaator eeltingimusega
samal ajal (<выражение>) <оператор>
Järelseisundiga silmusoperaator
teha<оператор>samas<выражение>;
C++ keeles erineb see operaator järeltingimusega tsükli klassikalisest teostusest selle poolest, et kui avaldis on tõene, siis tsükkel jätkub, mitte ei välju tsüklist.
Step Loop Operaator
jaoks ([<начальное выражение>];
[<условное выражение>];
[<выражение приращения>])
<оператор>
Lause for keha täidetakse seni, kuni tingimusavaldis muutub vääraks (võrdub 0-ga). Alg- ja juurdekasvuavaldisi kasutatakse tavaliselt ahela parameetrite ja muude väärtuste lähtestamiseks ja muutmiseks. Algset avaldist hinnatakse üks kord enne tingimusavaldise esmakordset testimist ja juurdekasvuavaldist hinnatakse pärast iga avalduse täitmist. Kõik kolm silmuse päiseavaldist ja isegi kõik kolm saab ära jätta (jätke lihtsalt semikoolonid välja). Kui tingimusavaldis jäetakse välja, loetakse see tõeseks ja tsükkel muutub lõpmatuks.
C++ keele samm-sammult silmusoperaator on paindlik ja mugav konstruktsioon, mistõttu tsüklioperaatorit, mille eeldus on samas, kasutatakse C++ keeles üliharva, kuna enamikul juhtudel on mugavam kasutada operaatorit.
Pausi operaator
murda;
Breakoperaator katkestab lausete while, do, for ja switch täitmise. See võib sisalduda ainult nende väidete põhiosas. Juhtimine läheb pärast katkestust üle programmioperaatorile. Kui katkestuslause kirjutatakse pesastatud lausetesse while, do, for, switch, siis lõpetab see ainult seda kohe ümbritseva lause.
jätkuoperaator
jätkata;
Jätkuoperaator annab tsüklioperaatorite puhul juhtimise üle järgmisele iteratsioonile while, do. See võib sisalduda ainult nende väidete põhiosas. Do- ja while-lausetes algab järgmine iteratsioon tingimusavaldise hindamisega. Lauses for algab järgmine iteratsioon juurdekasvuavaldise hindamisega ja seejärel hindab tingimusavaldist.
Tagastamisoperaator
tagasi [<выражение>];
Tagastuslause lõpetab seda sisaldava funktsiooni täitmise ja tagastab kutsuva funktsiooni juhtimise. Juhtimine kantakse üle helistamisfunktsiooni punkti
Kui (tõve avaldis)
operaator;
Kui (tõve avaldis)
operaator_1;
operaator_2;
<логическое выражение> ? <выражение_1> : <выражение_2>;
Kui loogilise avaldise väärtus on tõene, siis hinnatakse avaldis_1, vastasel juhul avaldis_2.
lüliti (täisarvuline avaldis)
case value_1:
lause_jada_1;
case value_2:
lause_jada_2;
case value_n:
lause_jada_n;
vaikimisi:
operaatori_jada_n+1;
Filiaal vaikimisi ei saa kirjeldada. See käivitatakse, kui ükski kõrgematest avaldistest ei ole täidetud.
Silmusoperaator.
Turbo C-l on järgmised konstruktsioonid, mis võimaldavad teil tsükleid programmeerida: samas tehke samas Ja jaoks . Nende struktuuri saab kirjeldada järgmiselt:
Tingimuse kontrollimise silmus ülaosas:
Valiku operaator
Kui toimingud, mida soovite programmis teha, sõltuvad mõne muutuja väärtusest, võite kasutada operaatorit select. Kuid C++ puhul saab valikuoperaatoris muutujatena kasutada ainult numbrilisi muutujaid. Üldiselt näeb valiku operaatori kirje välja selline:
lüliti (muutuja)
{
käände väärtus1:
toimingud1
murda;
suurtähtede väärtus2:
toimingud2
murda;
...
vaikimisi:
vaiketoimingud
}
Iga haru lõppu tuleb lisada murdemärksõna. See peatab valikutoimingu käitamise. Kui te seda ei kirjuta, jätkatakse pärast toimingute teostamist ühest valikuharust toimingute täitmine järgmistest harudest. Kuid mõnikord on see valiku omadus kasulik, näiteks kui peate tegema samu toiminguid erinevaid tähendusi muutuv.
lüliti (muutuja)
{
käände väärtus1:
suurtähtede väärtus2:
toimingud1
murda;
suurtähtede väärtus3:
toimingud2
murda;
...
}
Näide valiku kasutamisest:
int n, x;
...
lüliti (n)
{
juhtum 0:
murda; //kui n on 0, siis me ei tee ühtegi toimingut
juhtum 1:
juhtum 2:
juhtum 3:
x = 3*n; //kui n on 1, 2 või 3, siis tehke mõned toimingud
murda;
juhtum 4:
x = n; //kui n on 4, siis soorita muid toiminguid
murda;
vaikimisi:
x = 0; //Kõigi muude n väärtuste puhul tehke vaiketoimingud
}
C.Cycle: tsükkel parameetriga
Üldine salvestusvorm
jaoks (parameetri lähtestamine; lõpptingimuste kontrollimine; parameetrite korrigeerimine) (
toimingute blokk;
for - parameetriline silmus (fikseeritud korduste arvuga tsükkel). Sellise tsükli korraldamiseks tuleb teha kolm toimingut:
§ parameetri lähtestamine- tsükli parameetri algväärtuse määramine;
§ lõppseisundi kontrollimine- parameetri väärtuse võrdlemine teatud piirväärtusega;
§ parameetrite korrigeerimine- parameetri väärtuse muutmine iga kord, kui ahela keha läbitakse.
Need kolm toimingut kirjutatakse sulgudesse ja eraldatakse semikooloniga (;). Tavaliselt on silmuse parameeter täisarvuline muutuja.
Parameetri lähtestamine toimub ainult üks kord – kui for-silmus hakkab täitma. Lõpetamistingimust kontrollitakse enne iga võimalikku silmuse keha täitmist. Kui avaldis muutub vääraks (võrdub nulliga), tsükkel lõpeb. Parameetrit reguleeritakse silmuse keha iga täitmise lõpus. Parameeter võib kas suureneda või väheneda.
Näide
#kaasa
int main() (
for(arv = 1; num< 5; num++)
printf("arv = %d\n",arv);
Si. Silmus eeltingimusega
Üldine salvestusvorm
while(väljend) (
toimingute blokk;
}
Kui avaldis on tõene (ei võrdu nulliga), siis käivitatakse sulgudesse suletud operatsiooniplokk, seejärel kontrollitakse avaldist uuesti. Toimingute jada, mis koosneb operatsiooniploki kontrollimisest ja täitmisest, korratakse seni, kuni avaldis muutub vääraks (võrdub nulliga). Sel juhul tsüklist väljutakse ja tsüklioperaatorile järgnev toiming sooritatakse.
Näide
int k=5;
int i=1;
int summa=0;
kuni ma<=k) {
Kuigi tsükli konstrueerimisel on vaja kaasata konstruktsioone, mis muudavad testitava avaldise väärtust nii, et see muutub lõpuks vääraks (võrdub nulliga). Vastasel juhul jookseb silmus näiteks lõputult (lõpmatu silmus).
toimingute blokk;
}
while on eeltingimusega tsükkel, mistõttu on täiesti võimalik, et tsükli keha ei täideta isegi üks kord, kui kontrollitav tingimus osutub esmakordsel kontrollimisel valeks.
Si. Järelseisundiga silmus
Loop with do...while postcondition
Üldine salvestusvorm
toimingute blokk;
) while(avaldis);
Järelseisundiga silmus
Do...while tsükkel on järeltingimusega tsükkel, kus avaldise õigsust kontrollitakse pärast kõigi lokkis sulgudega piiritletud plokki kuuluvate toimingute sooritamist Silmuse keha täidetakse seni, kuni avaldis muutub vääraks, et See tähendab, et tsükli keha koos järeltingimusega täidetakse, kuigi ainult üks kord.
Parem on kasutada do...while tsüklit juhtudel, kui vähemalt üks iteratsioon peab olema lõpule viidud või kui seisukorra kontrollimisega seotud objektide lähtestamine toimub tsükli kehas.
Näide. Sisestage arv vahemikus 0 kuni 10
#kaasa
#kaasa
int main() (
system("chcp 1251");
printf("Sisestage arv vahemikus 0 kuni 10: ");
scanf("%d", &num);
) while((nr< 0) || (num > 10));
printf("Sisestasite numbri %d", num);
getchar(); getchar();
Funktsioonide määratlemine
Vaatame funktsiooni definitsiooni kasutades näitena summafunktsiooni.
C ja C++ puhul ei pea funktsioone defineerima enne, kui neid kasutatakse, vaid need tuleb eelnevalt deklareerida. Kuid isegi pärast kõike seda tuleb see funktsioon lõpuks määratleda. Seejärel seostatakse funktsiooni prototüüp ja selle definitsioon ning funktsiooni saab kasutada.
Kui funktsioon oli eelnevalt deklareeritud, tuleb see defineerida samade tagastusväärtuste ja andmetüüpidega, vastasel juhul luuakse uus ülekoormatud funktsioon. Pange tähele, et funktsiooni parameetrite nimed ei pea olema samad.
