Šis standarts nosaka datoru, kompleksu un sistēmu programmas vai programmatūras produkta izstrādes tehnisko specifikāciju konstruēšanas un izpildes kārtību neatkarīgi no to mērķa un apjoma.
Standarts pilnībā atbilst ST SEV 1627-79.
Dizaina noteikumi
Tehniskais uzdevums sastādīts saskaņā ar GOST 19.106-78 uz 11. un 12. formāta lapām saskaņā ar GOST 2.301-68, parasti, neaizpildot lapas laukus. Lapu (lapu) numurus norāda lapas augšējā daļā virs teksta.
Apstiprinājuma lapa un titullapa
Apstiprinājuma lapa un titullapa ir sastādītas saskaņā ar GOST 19.104-78.
Informatīvo daļu (abstraktu un saturu), izmaiņu reģistrācijas lapu var neiekļaut dokumentā.
Izmaiņas un papildinājumi
Lai veiktu izmaiņas vai papildinājumus darba uzdevumā turpmākajos programmas vai programmatūras produkta izstrādes posmos, tiek izdots tā papildinājums. Darba uzdevuma papildinājuma saskaņošana un apstiprināšana tiek veikta tādā pašā veidā, kā noteikts darba uzdevumā.
Ņem vērā visas detaļas sākuma stadija attīstība nav iespējama. Praksē šī pieeja tiek izmantota diezgan bieži. Sadaļā "Izstrādes posmi un posmi" ir skaidri jānorāda iespēja veikt izmaiņas un papildinājumus darba uzdevumā: "Šī darba uzdevuma sadaļu saturu var mainīt un papildināt, vienojoties ar Pasūtītāju. "
Darba uzdevuma sadaļu sastāvs
Darba uzdevumā jāiekļauj šādas sadaļas:
- ievads; attīstības pamatojums; attīstības mērķis; prasības programmai vai programmatūras produktam; prasības programmatūras dokumentācijai; tehniskie un ekonomiskie rādītāji; attīstības stadijas un stadijas; kontroles un pieņemšanas kārtība; darba uzdevumā atļauts iekļaut pieteikumus.
Atkarībā no programmas vai programmatūras produkta īpašībām ir atļauts precizēt sadaļu saturu, ieviest jaunas sadaļas vai apvienot dažas no tām. Stingri vienojoties ar klientu. Pasūtītāja piekrišana ir jāatspoguļo darba uzdevuma tekstā.
Kā apmācību programmu izmantosim reālu programmu ar grafisku lietotāja interfeisu, kas nodrošina iespēju veikt vairākas šablona funkcijas (piemēram, vienkāršs teksta redaktors).
Ievads
Sadaļā ir norādīts programmas vai programmatūras produkta nosaukums, īss darbības jomas apraksts un objekts, kurā programma vai programmatūras produkts tiek izmantots.
Pamatnoteikums darbam ar tekstu ir detalizēta, teksta sadalīšana struktūrvienības, apakšiedaļas, rindkopas un apakšpunktus. Teksta satura rādītājam būs skaidra struktūra, kas ļaus ērti atrast nepieciešamo materiālu. Dokumenta teksts kļūs strukturēts un viegli lasāms. Izveidot apakšsadaļas:
Programmas nosaukums
Nosaukums - "Teksta redaktors darbam ar rtf failiem."
Īss darbības jomas apraksts
Programma paredzēta lietošanai specializētās nodaļās Klienta telpās.
Atsevišķu priekšmetu saturs ne vienmēr ir skaidrs. Grūtību gadījumā tai jāvēršas formāli. Rediģēšanu var veikt darba uzdevuma saskaņošanas ar Klientu stadijā.
Attīstības iemesli
Sadaļā jāiekļauj:
Dokuments (dokumenti), uz kura pamata tiek veikta izstrāde; organizācija, kas apstiprinājusi šo dokumentu, un tā apstiprināšanas datums; vārds un (vai) simbols attīstības tēmas.
Apakšsadaļā jāiekļauj Līgumā ietvertā informācija.
Pamats attīstībai
Izstrādes pamats ir Līgums (vēstule u.c.) Nr.000, kas datēts ar 01.01.01 (ienākošais Nr.tādi un tādi no tādiem un tādiem). Līgums tika saskaņots ar Valsts vienotā uzņēmuma "Spetstyazhmontazhstroyselkhozavtomatika" direktoru Ivanovu Petru Ivanoviču, turpmāk tekstā Pasūtītājs, un apstiprināts ar ģenerāldirektora Bļumkina Ivana Aronoviča, turpmāk tekstā - Izpildītājs, par tādu un tādu 2008.gada martu. .
Ir ērti izmantot sadaļu " Galvenā informācija» GOST 34.602-89, jo izstrādātājam ir visas tiesības papildināt un dzēst darba uzdevuma sadaļas pēc saviem ieskatiem. Vienlaikus iepriekš norādītā informācija ir ietverta Līgumā. Tas, vai tie būtu jānorāda darba uzdevumā, ir atkarīgs no konkrētā gadījuma.
Izstrādes tēmas nosaukums un simbols
Izstrādes tēmas nosaukums ir “Teksta redaktora izstrāde darbam ar rtf failiem”.
Izstrādes tēmas (tēmas koda) simbols ir “RTF-007”.
Attīstības mērķis
Sadaļā jānorāda programmas vai programmatūras produkta funkcionālais un darbības mērķis.
Funkcionālais mērķis
Programmas funkcionālais mērķis ir nodrošināt lietotājam iespēju strādāt ar teksta dokumentiem rtf formātā.
Apakšsadaļā jānorāda programmas "palielināts" funkcionālais mērķis. Sīkāka informācija - funkciju saraksts utt. - tiks sniegta zemāk attiecīgajās sadaļās.
Iegūstiet pilnu tekstuDarbības mērķi var interpretēt diezgan plaši. Kur, kā, kam, ar ko programma jādarbina?
Tāda paša izmēra gumiju var veiksmīgi izmantot uz Žiguļiem un Volgas, bet ne uz Kamaz. Un otrādi. Bet katram konkrētajam gumijas izmēram var noteikt tā darbības mērķi.
Pieņemsim formālu pieeju:
Darbības mērķis
Programma jādarbojas specializētās nodaļās Klienta telpās.
Programmas galalietotājiem ir jābūt Klienta objektu attiecīgo nodaļu darbiniekiem.
Prasības programmai vai programmatūras produktam
Sadaļā jāiekļauj šādas apakšsadaļas:
veiktspējas prasības; uzticamības prasības; lietošanas noteikumi; prasības tehnisko līdzekļu sastāvam un parametriem; prasības informācijas un programmatūras saderībai; prasības marķēšanai un iesaiņošanai; prasības transportēšanai un uzglabāšanai; īpašas prasības.
Ja ir standarti, kas satur vispārīgas (tehniskas) prasības programmai, sistēmai vai produktam, piemēram, “GOST. Automatizētas informācijas mērīšanas sistēmas. Vispārējās (tehniskās) prasības”, tehnisko specifikāciju izstrāde ir ievērojami vienkāršota. Lielākā daļa norādītā standarta satura tiek vienkārši pārrakstīta darba uzdevumā.
veiktspējas prasības
Apakšnodaļā jānorāda prasības izpildāmo funkciju sastāvam, ievades un izvaddatu organizācijai, laika raksturlielumiem utt.
Prasības veicamo funkciju sastāvam
Programmai ir jānodrošina iespēja veikt šādas funkcijas:
1. Funkcijas jauna (tukša) faila izveidei.
2. esoša faila atvēršanas (ielādēšanas) funkcijas.
4. Funkcijas pašreizējā faila rediģēšanai, izmantojot operētājsistēmas starpliktuvi.
5. funkcijas, lai saglabātu failu ar sākotnējo nosaukumu.
6. funkcijas faila saglabāšanai ar nosaukumu, kas atšķiras no oriģinālā.
7. funkcijas pašreizējā faila satura nosūtīšanai pa e-pastu, izmantojot ārēju klienta pasta programmu.
8. Funkcijas tiešsaistes palīdzības parādīšanai virknes formātā (padomi).
9. tiešsaistes palīdzības sistēmas funkcijas.
10. funkcijas programmas nosaukuma, programmas versijas, autortiesību un izstrādātāju komentāru parādīšanai.
Klišeja "iespējot izpildīt" attiecas uz mūsdienu programmatūru, kas izstrādāta ar grafisku lietotāja interfeisu. Norādītie programmatūras rīki lielākoties"Tukšgaita" (dīkstāve), gaidot operatora darbības.
Prasības ievaddatu organizēšanai
Programmas ievades dati jāorganizē kā atsevišķi specifikācijai atbilstoši rtf faili.
Norādītā formāta faili ir jāievieto (saglabā) lokālā vai noņemamā datu nesējā, kas formatēta atbilstoši operētājsistēmas prasībām.
Nedrīkst atvērt nevienu cita formāta failu, bet ar paplašinājumu rtf.
Faili http:///file. rtf vai ftp:///file. rtf nevajadzētu atvērt. Ja failu sistēma ir formatēta kā FAT32, nevajadzētu atvērt failus no lokālā vai noņemamā datu nesēja, kas formatēts, piemēram, ext3 formātā.
Prasības izvaddatu organizēšanai
Skatiet sadaļu Ievades organizācijas prasības.
Prasības ir tādas pašas kā izvaddatu organizēšanai. Pats gadījums, kad jāapvieno abi tehniskā uzdevuma punkti.
Laika prasības
Programmas laika raksturlielumiem nav prasību.
Jānoskaidro, vai Pasūtītājs izvirza prasības programmas ātrumam, piemēram, cik ilgi programmai jāsāk, jāatver un jāaizver noteikta izmēra faili. Ja Pasūtītājs norāda konkrētus skaitļus, jāpārliecinās un tehnisko līdzekļu sastāva un parametru prasībās jāiekļauj superdators 2500 USD vai vairāk. Tiesa, šāda summa būs jāpamato. Ja laika raksturlielumi Klientam nav fundamentāli, jāraksta par atteikšanos no laika raksturlielumu prasībām (sk. formulējumu augstāk).
Uzticamības prasības
Apakšnodaļā jānorāda prasības drošas darbības nodrošināšanai (stabilas darbības nodrošināšana, ievades un izvades informācijas kontrole, atkopšanas laiks pēc atteices u.c.).
Uzticamība ir smalka un ļoti bīstama lieta. Bet funkciju saraksts un to atteices režīmi, saskaņā ar 1.3.2. GOST 24.701-86, jāsastāda Pasūtītājam un jāsaskaņo ar Izpildītāju. Visticamāk, ka no Klienta kaut ko saprotamu sagaidīt nebūs iespējams. Ir vērts paskaidrot Pasūtītājam, ka programmas uzticama darbība ir atkarīga ne tik daudz no Izpildītāja, cik no aparatūras un operētājsistēmas uzticamības, kā arī ieteikt Pasūtītājam vairākus stingrus pasākumus, lai uzlabotu pakalpojuma uzticamību un stabilitāti. programma.
Iegūstiet pilnu tekstuPrasības uzticamas (ilgtspējīgas) programmas darbības nodrošināšanai
Programmas uzticama (ilgtspējīga) darbība ir jānodrošina, Pasūtītājam īstenojot organizatorisko un tehnisko pasākumu kopumu, kuru saraksts ir norādīts zemāk:
organizācija nepārtrauktās barošanas avots tehniskie līdzekļi; izmantojot licencētu programmatūru; regulāra Krievijas Federācijas Darba un sociālās attīstības ministrijas ieteikumu īstenošana, kas izklāstīti 01.01.2001. dekrētā "Par starpnozaru standarta laika standartu apstiprināšanu personālo datoru un biroja iekārtu uzturēšanai un programmatūras uzturēšanai"; regulāra atbilstība GOST prasībām. Informācijas aizsardzība. Programmatūras pārbaude datorvīrusu klātbūtnei.
Sarakstam var pievienot vēl desmitiem. normatīvie dokumenti. Sākotnējās darba uzdevuma apstiprināšanas laikā Klientam, visticamāk, sāks parādīties tieksme uz kompromisu.
Iespējama humānāka pieeja. Par uzticamību (tomēr sistēmas saskaņā ar to pašu GOST) var uzskatīt noteiktas i-tās funkcijas bezatteices izpildi noteiktā laika intervālā. Par programmas uzticamas darbības kritēriju iesakām Klientam uzskatīt šādu rādītāju: Klients stundas laikā atver un aizver failu 100 reizes. Ja programma neizdodas noteiktajā laika intervālā, tiek uzskatīts, ka uzticamības prasības ir izpildītas.
Ja Pasūtītājs beidzot pārliecinās, ka uzticamība ir atkarīga ne tik daudz no Izpildītāja, cik no tehnisko līdzekļu un operētājsistēmas uzticamības, un pamāja ar roku, sadaļā jāieraksta šāda frāze:
Nav izvirzītas prasības, lai nodrošinātu programmas uzticamu (ilgtspējīgu) darbību.
Atveseļošanās laiks pēc neveiksmes
Atkopšanas laiks pēc kļūmes, ko izraisījis aparatūras strāvas padeves pārtraukums (citi ārēji faktori), nevis nāvējoša operētājsistēmas atteice (nevis avārija), nedrīkst pārsniegt tik daudz minūšu, atkarībā no aparatūras un programmatūras darbības apstākļiem.
Atkopšanas laiks pēc kļūmes, ko izraisījusi aparatūras nepareiza darbība, nāvējoša operētājsistēmas atteice (avārija), nedrīkst pārsniegt laiku, kas nepieciešams aparatūras problēmu novēršanai un programmatūras pārinstalēšanai.
Ārkārtas situāciju sarakstu arī sastāda Pasūtītājs un saskaņo ar Izpildītāju. Patiesībā šis ir laiks pārstartēt operētājsistēmu, ja kļūme nav letāla, to nav izraisījusi operētājsistēmas avārija vai tehnisko līdzekļu kļūme.
Neveiksmes operatora nepareizas darbības dēļ
Programmas kļūmes ir iespējamas nepareizu operatora (lietotāja) darbību dēļ, mijiedarbojoties ar operētājsistēmu. Lai izvairītos no programmas kļūmēm iepriekšminētā iemesla dēļ, jums jāpārliecinās, ka galalietotājs strādā, nepiešķirot viņam administratīvās tiesības.
Ekspluatācijas apstākļi
Apakšsadaļā jānorāda darbības apstākļi (apkārtējā gaisa temperatūra, relatīvais mitrums utt. izvēlētajiem datu nesēju veidiem), kādos noteiktas īpašības, kā arī pakalpojuma veids, nepieciešamais personāla skaits un kvalifikācija.
Klimatiskie ekspluatācijas apstākļi
Klimatiskie apstākļi darbībai, kurā jānodrošina noteiktie raksturlielumi, pēc to ekspluatācijas apstākļiem jāatbilst tehnisko līdzekļu prasībām.
Programma lieliski darbosies no plus 5 līdz plus 35 ° C pie relatīvā mitruma 90% un atmosfēras spiediena 462 mm. rt. Art., jo šādi apstākļi aptuveni atbilst mūsdienu datoru darbības apstākļiem nerūpniecisks izpildi. Bet, tiklīdz darba uzdevums ir konkrēts un uzdevums ir apstiprināts, Pasūtītājs iegūst lielisku iespēju piespiest Izpildītāju veikt klimatiskās pārbaudes pilnā apmērā uz Izpildītāja rēķina.
Prasības pakalpojumu veidiem
Skatīt Prasības programmas uzticamas (ilgtspējīgas) darbības nodrošināšanai.
Programmai nav nepieciešama nekāda veida apkope.
Pakalpojumu veidi aizņemami no apakšsadaļas "Prasības drošas (ilgtspējīgas) darbības nodrošināšanai".
Ja Pasūtītājs, vienojoties par darba uzdevumu, atsaucas uz resursu trūkumu vai vēlmi veikt visa veida apkopi saviem spēkiem, ir jēga ierosināt programmatūras uzturēšanas darba uzdevuma izstrādi. par atsevišķu naudu atsevišķā līgumā. Atteikt - programma jāuzskata par bez uzraudzības.
Prasības personāla skaitam un kvalifikācijai
Programmas darbībai nepieciešamais minimālais personāla skaits ir vismaz 2 štata vietas - sistēmas administrators un programmas gala lietotājs - operators.
Sistēmas administratoram jābūt augstākam specializētā izglītība un operētājsistēmas ražotāja sertifikāti. Sistēmas administratora veikto uzdevumu sarakstā jāiekļauj:
Iegūt tehnisko līdzekļu darbspējas uzturēšanas uzdevuma pilnu tekstu; sistēmas programmatūras rīku - operētājsistēmas uzstādīšanas (instalēšanas) un darbspējas uzturēšanas uzdevumi; programmas instalēšanas (instalēšanas) uzdevums.Programmas gala lietotājam (operatoram) jābūt praktiskām iemaņām darbā ar operētājsistēmas grafisko lietotāja interfeisu.
Personālam jābūt sertificētam II kvalifikācijas grupai elektrodrošībā (darbam ar biroja tehniku).
Ja apstiprinātajā darba uzdevumā nav visbūtiskākās (treknrakstas) frāzes, Pasūtītājam ir tiesības pieprasīt no Izpildītāja operētājsistēmas grafiskā lietotāja interfeisa darbības rokasgrāmatas izstrādi, atsaucoties uz to, ka operators "netiek galā" ar programmu.
Personālam, kuram nav II kvalifikācijas grupas elektrodrošībā, nav tiesību pat pietuvoties datoram un biroja tehnikai.
Prasības tehnisko līdzekļu sastāvam un parametriem
Apakšnodaļā norādīts nepieciešamais tehnisko līdzekļu sastāvs, norādot to galvenos tehniskos raksturlielumus.
Ir nepieciešams izvēlēties aprīkojumu, kas nav sliktāks par to, uz kura tiks veikta izstrāde. Loģiski ir pieprasīt, lai Pasūtītājs aprīkojumu nodrošina ne vēlāk kā norādītajā termiņā. Mēs, protams, runājam par datoru.
Aparatūrā jāiekļauj ar IBM saderīgs personālais dators (PC), kurā ietilpst:
Procesors Pentium-1000 ar takts frekvenci, GHz - 10, ne mazāk; mātesplate ar FSB, GHz - 5, ne mazāk; RAM tilpums, Tb - 10, ne mazāk; un tā tālāk…
Prasības informācijas un programmatūras saderībai
Apakšnodaļā jānorāda prasības informācijas struktūrām ievades un izvades un risinājumu metodēm, pirmkodiem, programmēšanas valodām un programmas izmantotajiem programmatūras rīkiem.
Ja nepieciešams, informācija un programmas ir jāaizsargā.
Prasības informācijas struktūrām un risinājuma metodēm
Faila informācijas struktūrā jāiekļauj teksts, kas satur rtf formāta specifikācijas nodrošināto marķējumu.
Nav prasības informācijas struktūrām (failiem) ievadē un izvadē, kā arī risinājuma metodēm.
Prasības pirmkodiem un programmēšanas valodām
Programmas pirmkodiem jābūt ieviestiem C++ valodā. Borland C++ Buider vide jāizmanto kā integrēta programmas izstrādes vide.
Prasības programmas izmantotajai programmatūrai
Programmas izmantotajai sistēmas programmatūrai jābūt pārstāvētai licencētai lokalizētai operētājsistēmas versijai. Atjaunināšanas pakotni atļauts izmantot tā un tā.
Prasības informācijas un programmu aizsardzībai
Informācijas un programmu aizsardzībai nav izvirzītas prasības.
No šādām prasībām būtu jāizvairās. Informācijai un programmām ir iespējams nodrošināt zināmu aizsardzības līmeni, taču nav iespējams nodrošināt drošību. Klients, visticamāk, to apzinās un nebūs neatlaidīgs.
Marķēšanas un iepakošanas prasības
Programma tiek piegādāta kā programmatūras produkts - izplatīšanas (ārējā optiskā) datu nesējā (CD).
Mēs runājam par izplatīšanas nesēja - programmatūras produkta marķēšanu un iepakošanu (sk. GOST 19.004-80).
Marķēšanas prasība
Programmatūras produktam jābūt marķētam ar izstrādātāja uzņēmuma preču zīmi, tipu (nosaukumu), versijas numuru, sērijas numurs, izgatavošanas datums un Krievijas valsts standarta atbilstības sertifikāta numurs (ja tāds ir).
Marķējums jāpieliek programmatūras produktam drukas veidā izgatavotas uzlīmes veidā, ņemot vērā GOST 9181-74 prasības.
Marķējuma kvalitāti pārbauda vismodernākajos veidos - vispirms marķējumu mēģina nomazgāt ar ūdeni, tad ar benzīnu un citiem organiskiem šķīdinātājiem. Lai par nekvalitatīvu marķējumu atbild poligrāfijas uzņēmums. Izpildītāja uzdevums ir slēpties aiz atbilstības sertifikāta (pieprasīt sertifikātu no printeriem).
Iepakojuma prasības
Programmatūras produkta iepakošana jāveic ražotāja iepakojuma konteinerā.
Tas ir ražotājs. Uzņēmējs nevar un nedrīkst uzņemties lielāku atbildību nekā konteinera ražotājs.
Iepakošanas nosacījumi
Programmatūras produkta iepakošana jāveic slēgtās ventilējamās telpās temperatūrā no +15 līdz +40 °C un relatīvajā mitrumā ne vairāk kā 80%, ja vidē nav agresīvu piemaisījumu.
Klients saņems atbilstoša izskata programmatūras produktu. Gadījumā, ja programmatūras produkts tiks atgriezts neatbilstošā veidā (skrāpējumi, plaisas un citi defekti), Izpildītājs varēs iesniegt pretenziju par Pasūtītāja iepakojuma nosacījumu pārkāpumu un programmatūras produktu nepieņemt.
Iepakošanas pasūtījums
Programmatūras produkti, kas sagatavoti iepakošanai, tiek ievietoti konteinerā, kas ir kaste, kas izgatavota no gofrētā kartona (GOST 7376-89 vai GOST 79 saskaņā ar konteinera ražotāja rasējumiem).
Iegūstiet pilnu tekstuProgrammatūras produkts ir iepakots, izmantojot vākus, kas izgatavoti no ūdensnecaurlaidīgas plēves ar obligātu ķīmiski neagresīva desikantu (silikagēla) klātbūtni.
Lai aizpildītu brīvo vietu, iepakošanas konteinerā ievieto gofrētā kartona vai polistirola paliktņus.
Darbības dokumentācija jāievieto patērētāja iepakojumā kopā ar programmatūras produktu.
Uz amortizācijas materiāla augšējā slāņa ir uzlikta piegādes dokumentācija - iepakojuma saraksts un iepakojuma saraksts.
Patērētāju iepakojums ir jāpārlīmē ar līmlenti 6-70 saskaņā ar GOST.
Programmatūras produkti, kas iepakoti patērētāju konteineros, jānovieto uz paletes, jāsasien ar lenti, lai nezaudētu kravas formu, un iepakoti polietilēna plēvē M 0,2, lai pasargātu no mitruma.
Palešu kastē jāiekļauj nosūtīšanas dokumentācija, ieskaitot iepakošanas sarakstu saskaņā ar GOST.
Iepakojuma izmēri nedrīkst pārsniegt 1250 x 820 x 1180 mm.
NETO svars - ne vairāk kā 200 kg.
BRUTO svars - ne vairāk kā 220 kg.
Apakšsadaļā parādīta iesaiņošanas secība no iepriekš izstrādāta dokumenta dažos tehniskajiem līdzekļiem. Programmatūras produkta kontekstā tas izskatās nedaudz neparasti. Runāt vienkāršā krieviski - pilnīga blēņa.
Prasības transportēšanai un uzglabāšanai
Apakšnodaļā programmatūras produktam jānorāda transportēšanas apstākļi, uzglabāšanas vietas, uzglabāšanas apstākļi, uzglabāšanas apstākļi, uzglabāšanas periodi dažādos apstākļos.
Apakšnodaļā ir paredzēti transportēšanas un uzglabāšanas nosacījumi no iepriekš izstrādāta dokumenta līdz dažiem tehniskajiem līdzekļiem. Tas attiecas arī uz iepakojuma prasībām. Programmatūras produkta kontekstā tas izskatās nedaudz neparasti.
Klientam nav tiesību pārkāpt transportēšanas un uzglabāšanas nosacījumus. Izpildītājs varēs atteikties no programmatūras produkta atgriešanas Pasūtītājam, pamatojoties uz to, ka programmatūras produkta neatbilstošs izskats ir transportēšanas un uzglabāšanas nosacījumu neievērošanas rezultāts.
Pārvadāšanas un uzglabāšanas nosacījumi
Programmatūras produktu pārvadāšanas konteinerā ir atļauts pārvadāt ar visiem transporta līdzekļiem (arī gaisa kuģu apsildāmos spiediena nodalījumos bez attāluma ierobežojuma). Pārvadājot dzelzceļa vagonos, sūtījuma veids ir mazs, maza tonnāža.
Programmatūras produkta transportēšanas un uzglabāšanas laikā ir jānodrošina aizsardzība pret putekļiem un nokrišņiem. Nav atļauts sagāzt programmatūras produktu. Transportēšanas klimatiskie apstākļi ir norādīti zemāk:
- apkārtējā gaisa temperatūra, °С - no plus 5 līdz plus 50; atmosfēras spiediens, kPa - tāds un tāds; relatīvais mitrums 25°C.
Īpašas prasības
Programmai jānodrošina mijiedarbība ar lietotāju (operatoru), izmantojot grafisko lietotāja interfeisu, kas izstrādāts saskaņā ar operētājsistēmas ražotāja ieteikumiem.
Šī standarta izstrādātāji raudzījās nākotnē. Šajos gados nebija programmu ar grafisku lietotāja interfeisu.
Prasības programmatūras dokumentācijai
Sadaļā jānorāda programmas dokumentācijas sākotnējais sastāvs un, ja nepieciešams, īpašas prasības tai.
Programmas dokumentācijas sastāvu nodrošina GOST 19.101-77.
Programmas dokumentācijas sākotnējais sastāvs
Programmas dokumentācijā jāiekļauj:
Tehniskais uzdevums; programma un pārbaudes metodes; sistēmas programmētāja rokasgrāmata; operatora rokasgrāmata; operatīvo dokumentu izraksts.
Programma un pārbaudes procedūras būs nepieciešamas, lai parādītu Pasūtītājam, ka Izpildītāja izstrādātā programma atbilst saskaņotā un apstiprinātā darba uzdevuma prasībām. Pēc kopīgu (pieņemšanas) testu veikšanas Pasūtītājs un Izpildītājs paraksta Darba pieņemšanas (nodošanas) aktu. Un līdz ar to darbs tiks slēgts, Līguma nosacījumi ir izpildīti.
Saskaņā ar 2.6. GOST 19.101-77 “Atļauts apvienot noteikta veida darbības dokumentus (izņemot operatīvo dokumentu izrakstu un veidlapu). Nepieciešamība apvienot šos dokumentus ir norādīta darba uzdevumā. Apvienotajam dokumentam tiek piešķirts viena no apvienotajiem dokumentiem nosaukums un apzīmējums.
Programmas dokumentācija, kas iekļauta provizoriskajā sarakstā, ir jāsagatavo saskaņā ar GOST 19.106-78 prasībām.
Tehniskie un ekonomiskie rādītāji
Paredzamā ekonomiskā efektivitāte netiek aprēķināta.
Paredzamais programmas izmantošanas skaits gadā ir 365 darba sesijas vienā darba vietā.
Sadaļā jānorāda: paredzamā ekonomiskā efektivitāte, paredzamā gada nepieciešamība, attīstības ekonomiskās priekšrocības salīdzinājumā ar labākajiem pašmāju un ārvalstu paraugiem vai analogiem.
Iegūstiet pilnu tekstuPieņemsim, ka Pasūtītājs ar programmu aprīko duci darbu. Darbuzņēmējs par attīstību pieprasīja 1000 USD. Klients darbstacijās varēja instalēt trešās puses programmatūras produktu, maksājot 500 USD par izplatīšanas komplektu un 100 USD par licenci. darba vieta.
Attīstības ekonomiskie ieguvumi
Attīstības ekonomiskās priekšrocības salīdzinājumā ar labākajiem vietējiem un ārvalstu analogiem būs:
darba vietu skaits
attīstību
ekonomiskie ieguvumi
Posmi un attīstības stadijas
Sadaļā tiek noteikti nepieciešamie izstrādes posmi, posmi un darba saturs (izstrādājamo, saskaņojamo un jāapstiprina programmas dokumentu saraksts), kā arī parasti izstrādes grafiks un noteikti izpildītāji.
Attīstības posmus un posmus regulē GOST 19.102-77. GOST 19.102-77 neliedz izslēgt atsevišķus darba posmus, kā arī atsevišķu darba posmu kombināciju.
Attīstības stadijas
Izstrāde jāveic trīs posmos:
Tehnisko specifikāciju izstrāde; darba dizains; īstenošana.
Attīstības stadijas
Darba uzdevuma izstrādes stadijā ir jāpabeidz šī darba uzdevuma izstrādes, saskaņošanas un apstiprināšanas posms.
Detalizētā projekta stadijā jāveic šādi darba posmi:
Programmas izstrāde; programmas dokumentācijas izstrāde; programmas testēšana.
Īstenošanas stadijā ir jāpabeidz izstrādes posms - programmas sagatavošana un nodošana.
Darba uzdevuma izstrādes stadijā jāveic šādi darbi:
Problēmas formulēšana; tehnisko līdzekļu prasību definēšana un precizēšana; prasību noteikšana programmai; programmas un tās dokumentācijas posmu, posmu un izstrādes termiņu noteikšana; programmēšanas valodu izvēle; darba uzdevuma saskaņošana un apstiprināšana.
Programmas izstrādes stadijā ir jāveic darbs pie programmas programmēšanas (kodēšanas) un atkļūdošanas.
Programmas dokumentācijas izstrādes stadijā programmas dokumentu izstrāde jāveic saskaņā ar GOST 19.101-77 prasībām ar nosacījumu par šī tehniskā uzdevuma programmas dokumentācijas sākotnējais sastāvs.
Programmas testēšanas posmā ir jāveic šādi darba veidi:
Programmas (GOST, šķiet, drukas kļūda - “pasūtījums”) un pārbaudes metožu izstrāde, saskaņošana un apstiprināšana; pieņemšanas testu veikšana; programmas un programmas dokumentācijas pielāgošana, pamatojoties uz pārbaudes rezultātiem.
Programmas sagatavošanas un nodošanas stadijā ir jāveic darbs pie programmas un programmas dokumentācijas sagatavošanas un nodošanas ekspluatācijā Pasūtītāja objektos.
Kontroles un pieņemšanas procedūra
Sadaļā jānorāda pārbaužu veidi un Vispārīgās prasības pieņemt darbu.
Pārbaudes veidi
Pieņemšanas testi ir jāveic Klienta objektā noteiktajos termiņos ...
Programmas akcepttestēšana jāveic saskaņā ar Izpildītāja izstrādāto (ne vēlāk kā līdz tādam datumam) Programmu un pārbaudes metodēm, par kurām ir saskaņots Pasūtītājs.
Pieņemšanas pārbaužu norisi Pasūtītājs un Izpildītājs dokumentē Pārbaudes protokolā.
Vispārīgās prasības darbu pieņemšanai
Uz Pārbaudes protokola pamata Izpildītājs kopā ar Pasūtītāju paraksta Programmas pieņemšanas un nodošanas ekspluatācijā aktu.
Lietojumprogrammas
Darba uzdevuma pielikumos, ja nepieciešams, sniedziet:
- pētījumu un citu izstrādi pamatojošo darbu sarakstu; algoritmu shēmas, tabulas, apraksti, pamatojumi, aprēķini un citi dokumenti, kurus var izmantot izstrādē; citi attīstības avoti.
Ja ir, kāpēc gan to neatnest. Un noteikti izveidojiet GOST sarakstu, uz kura pamata jāveic attīstība. Piemēram:
- GOST 19.201-78. Darba uzdevums, prasības saturam un noformējumam; un tā tālāk...
Efektīvs instruments organizācijas vadības struktūru projektēšanā un racionalizācijā ir modelēšana, kas ļauj atrast labākos variantus to izbūvei, prognozēt to attīstību, veikt esošās struktūras stāvokļa operatīvo diagnostiku un konstatēt tās atbilstību reālajiem ražošanas un tehnoloģiskajiem apstākļiem, izvērtēt dažādus. Organizatoriskās struktūras veidošanas iespējas, kad tiešie eksperimenti ir neiespējami vai sarežģīti, kā arī ekonomiski neizdevīgi un dažreiz neiespējami.
Sistēmas mēroga projektēšanas stadijā viens no galvenajiem uzdevumiem ir konstrukcijas projektēšanas uzdevums. Attiecībā uz sistēmām cilvēks-mašīna, visizplatītākais ir gadījums, kad tiek doti sistēmas uzbūves principi, veicamās funkcijas un sistēmas sastāvdaļas. Tad optimālās struktūras sintezēšanas uzdevums ir noteikt veikto AS funkciju kopas optimālo kartēšanu uz savstarpēji saistītu elementu kopu.
Programma, ar kuru tiek īstenots šis kursa projekts, ir paredzēta šādu veidu problēmu risināšanai. Lai AC izlemj i uzdevumi (atkarībā no AS mērķa tie var būt plānošanas, grāmatvedības, dokumentu sagatavošanas u.c. uzdevumi). AS ietver j elementi (mezgli): tie var būt uzņēmuma apakšvienības, datortīkla mezgli utt. AS uzdevumi ir jāsadala pa elementiem atbilstoši atlasītajiem kritērijiem un ierobežojumiem.
Sadalot AS uzdevumus pēc tā elementiem, parasti tiek izmantoti šādi optimizācijas kritēriji (objektīvās funkcijas):
Kopējo izmaksu samazināšana visu problēmu risināšanai;
Kopējā laika samazināšana visu problēmu risināšanai;
Problēmu risināšanas maksimālā laika samazināšana (minimizēts laiks, līdz kuram tiks atrisināts pēdējais uzdevums);
Maksimāli palielināt kopējo peļņu no visu problēmu risināšanas.
Izvēloties optimālo opciju AS uzdevumu sadalei pēc tā elementiem, parasti tiek ņemti vērā šādi ierobežojumi:
Par resursu (naudas vai jebkura cita) izmaksām, kas saistītas ar visu uzdevumu risināšanu;
Par kopējo visu AS uzdevumu risināšanas laiku;
Lai ielādētu atsevišķus AS elementus.
Var izmantot arī citus ierobežojumus (piemēram, par resursu izmaksām atsevišķos AS elementos, uz konkrētu problēmu risināšanas laiku utt.).
1.3 Programmas loģiskās struktūras apraksts
Programma sastāv no procedūrām un funkcijām, kas nolasa sākotnējos datus, aprēķina iespējamās iespējas uzdevumu sadalei starp mezgliem atbilstoši ierobežojumam un atrod labāko variantu. Programmas algoritms blokshēmas veidā parādīts 1. pielikumā.
Programma darbojas šādi. Pēc programmas lejupielādes un palaišanas, izmantojot failu projektu1. exe, ekrānā parādās logs “Pirmā konkrētā problēma optimālās struktūras sintezēšanai”, kurā ir trīs vienas rindas teksta redaktori mezglu un uzdevumu skaita maiņai, risināmo uzdevumu skaita un mezglu skaita ievadīšanai. , tabulas problēmu risināšanai iztērētā laika un naudas vērtību ievadīšanai atbilstošajos mezglos, teksta pogas problēmas stāvokļa rediģēšanai un risinājuma meklēšanai, galvenā izvēlne.
Apsveriet galvenās izvēlnes saturu, kas sastāv no trim vienumiem:
Uz izvēlnes vienumu Fails Iekļautas 4 komandas:
Jauns -- atlasot šo vienumu, tiek notīrīts programmas galvenais logs jauna nosacījuma ievadīšanai.
Atvērt - izvēloties šo vienumu, var atvērt atskaites failu ar iepriekš atrastiem risinājumiem;
Izeja - Izvēloties šo vienumu, programma tiek aizvērta.
Uz izvēlnes vienumu Komandas Iekļautas 4 komandas:
Mainīt dimensiju – maina masīva izmēru atbilstoši lietotāja ievadītajam uzdevumu un mezglu skaitam;
Lēmumu matrica - atver veidlapu ar vispārīgu risinājumu;
Optimāls risinājums – veic uzdevuma optimālā risinājuma meklēšanu, attēlojot rezultātus galvenās formas apakšējā daļā (tikai visu vērtību pilnīgas ievadīšanas gadījumā atbilstoši dotajam nosacījumam);
Efektivitātes kritērijs - veic efektivitātes kritērija meklēšanu, parādot to programmas galvenajā logā.
Uz izvēlnes vienumu PALĪDZĪBA ir iekļautas divas komandas:
Contenta – atver logu ar ceļvedi, kā lietot programmu un kā atrisināt problēmu;
Par programmu – tiek atvērts logs ar vispārīgu informāciju par programmu un tās izstrādātājiem.
Vadības pogas, kas atrodas galvenajā logā, veic tādas pašas darbības kā attiecīgās galvenās izvēlnes komandas.
Logā "Pirmā īpašā optimālās struktūras sintēzes problēma" cilnē "Problēmas izklāsts" lietotājam jāievada šādi sākotnējie dati:
starp mezgliem sadalāmo uzdevumu skaits;
mezglu skaits, starp kuriem tiks sadalīti uzdevumi;
laika izmaksu (naudas izmaksu) matricas elementu vērtības;
naudas izmaksu matricas elementu vērtības (laika izmaksas);
Pēc visu sākotnējo datu ievadīšanas un pogas nospiešanas Lēmumu matrica vai atbilstošo izvēlnes vienumu, ekrānā parādīsies otrs logs, kurā ir viena vadības poga: labi, noklikšķinot uz tā, tiks aizvērts atbildes logs.
Kad nospiežat pogu Optimāls risinājums Optimālais risinājums tiek parādīts veidlapas apakšā.
Kad nospiežat pogu Efektivitātes kritērijs veidlapā tiek parādīta efektivitātes kritērija vērtība.
Kad nospiežat pogu Izeja, programma iziet.
Projektēšanas beigās ir nepieciešams sekot līdzi lietotāja darbam RAID sistēmas pārvaldībā.
UzstādīšanaRAID. Savienojot RAID sistēmu ar datoru un pēc nepieciešamo draiveru iestatīšanas, lietotājam ir jāiestata RAID darbība vajadzīgajā režīmā (RAID0,RAID1,RAID3 utt.). Pēc tam darbam gatavā diska vieta jāsadala nepieciešamajos sējumos (starpsienās). Iestatīšanas beigās jums jāpārbauda visas sistēmas darbība.
Vadība/DiagnostikaRAID. Ja lietotājs vēlas apskatīt sistēmas stāvokli vai mainīt kādus parametrus, programmatūrai ir informatīvi jāparāda sistēmas stāvoklis un jānodrošina ērts interfeiss sistēmas iestatījumu maiņai. Tajā pašā laikā, kā tas bieži notiek, administrators strādā ar datoru, kurā RAID ir instalēts attālināti (piemēram, no mājām), tāpēc programmatūrai ir jānodrošina autorizēta (droša) piekļuve, lai pārvaldītu sistēmu tīklā.
Kļūda apstrādē. Sistēmai ir pienākums nekavējoties informēt administratoru par kļūdām RAID darbībā. Tā kā pats RAID kontrolleris nevar signalizēt par kļūdu, programmatūrai ir jāspēj nepārtraukti uzraudzīt RAID, vai tajā nav kļūdu.
Programmatūras dokumentācija. Sistēmai ir jābūt pilnībā saprotamai lietotājam. Taču, neskatoties uz to, grūtību gadījumā lietotājam ātri jāatrod nepieciešamā dokumentācija gan par programmatūras darbību, gan par RAID ierīci un tās darbības režīmiem.
Dizaina daļa
Sistēmas prasības
Pamatojoties uz uzdevumu un veikto priekšizpēti, tika formulētas prasības izstrādājamai sistēmai.
Veikto funkciju sastāvs
Izveidotajam programmatūras produktam ir jānodrošina šādas funkcionālas darbības:
Tikko iegādātas RAID sistēmas sākotnējā iestatīšana;
RAID sistēmas stāvokļa ikdienas uzraudzība;
Esošas sistēmas konfigurācijas maiņa (diska pārvaldnieks, diska vietas pārvaldība, RAID kontrollera iestatījumi);
Iespēja attālināti vadīt sistēmu no cita datora;
Administratora paziņojums par RAID sistēmas darbības traucējumiem un kļūmēm.
Uzticamības prasības
Tā kā sistēmai jādarbojas attālināti, ir jāievieš autorizācijas sistēma un aizsardzība pret nesankcionētu sistēmas izmantošanu. Lai novērstu tīklā pārsūtītās paroles pārtveršanu, visas paroles tiks saglabātas šifrētā veidā.
Ekspluatācijas nosacījumi un prasības tehnisko līdzekļu sastāvam un parametriem
Administrējot RIAD sistēmu attālināti, ir jāpalaiž divi programmatūras moduļi - viens datorā ar RAID sistēmu, otrs administratora datorā.
Galvenā sistēmas lietošanas prasība ir nepieciešamība pastāvīgi darboties programmatūras modulim, kas palaists datorā ar RAID sistēmu. Ja šis modulis tiks apturēts, tad bez tā nebūs iespējams izveidot savienojumu ar RAID sistēmu un nebūs iespējams uzraudzīt RAID darbību (sūtīt paziņojumu par darbības traucējumiem un uzturēt RAID darbības vēstures failus).
TCP/IP protokols tiek izmantots, lai sazinātos starp diviem programmatūras moduļiem. Tāpēc, lai varētu attālināti strādāt ar RAID sistēmu, abiem datoriem ir nepieciešams konfigurēts tīkls. Administrējot RAID sistēmu no lokālā datora, tīkla savienojums nav nepieciešams.
Apakšsadaļā "Prasības funkcionālajiem raksturlielumiem" jānorāda prasības izpildāmo funkciju sastāvam, ievades un izvades datu organizācijai, laika raksturlielumiem utt.
1. Redaktoram jāstrādā vairāku logu grafiskā režīmā un jāatbalsta gan tastatūra, gan "peles" manipulators.
2. Lietotājam pēc vēlēšanās ir jābūt iespējai iestatīt mēroga lauku katram logam.
3. Minimizētājam jānodrošina, lai minimālais ceļš tiktu atrasts, izlaižot tikai vienu reizi katras detaļas daudzstūra kontūras katras malas izvietojuma zonā.
4. Atrastais ceļš ir jāparāda ekrānā dažādos režīmos.
5. Informācija par kontūru izvietojumu un ģenerēto maršrutu var tikt saglabāta minimizera lokālajā datu bāzē.
6. Jānodrošina datu bāzes grafiskais skats ar iespēju dzēst no tās vai iekopēt to norādītās vietas aktīvajā logā ar pieejamo maršrutu.
7. Informāciju par atrašanās vietu un ģenerēto maršrutu var attēlot šādas struktūras ģeometriskās informācijas faila veidā: ...
8. Detaļu kontūru virsotņu uzskaitījumam atbilstošajā izvaddatnes deskriptorā jāatbilst ģenerētajam griešanas maršrutam.
9. Programmai kā ievade jāizmanto ģeometriskās informācijas fails, kura pirmā daļa būs izvietojuma laukuma taisnstūris.
10. Programmai jānodrošina izvadfaila apskate.
Darba beigas -
Šī tēma pieder:
Programmatūras izstrādes tehnoloģija
Vietnes vietnē lasiet: "Programmatūras izstrādes tehnoloģija" ...
Ja jums ir nepieciešams papildu materiāls par šo tēmu vai jūs neatradāt to, ko meklējāt, mēs iesakām izmantot meklēšanu mūsu darbu datubāzē:
Ko darīsim ar saņemto materiālu:
Ja šis materiāls jums izrādījās noderīgs, varat to saglabāt savā lapā sociālajos tīklos:
| čivināt |
Visas tēmas šajā sadaļā:
Prasības informācijas un programmatūras saderībai
Apakšsadaļā "Prasības informācijai un programmu savietojamībai" jānorāda prasības informācijas struktūrām pie ievades un izvades un risinājuma metodēm, pirmkodiem
Prasību līgums
Vienošanās par prasībām sastādīšana - pirmās daļas otrās daļas mērķis laboratorijas darbi. Tāpat vienošanās par prasībām ir kursa darba otrā sadaļa. Zemāk ir dota op
Īss produkta apraksts
Īsi aprakstīts un galvenie noteikumi produkta galvenās funkcionālās īpašības. Ja programmatūras produkts ir esoša paplašinājums, tiek raksturotas tikai tā jaunās īpašības.
Produkta rezultāta sastāvdaļas
AT šajā sadaļā ir sniegta tabula, kas ir līdzīga vai līdzvērtīga 2.1. tabulai. Šajā gadījumā tika izmantota iepriekš sagatavota drukas forma, kas samazina informācijas sagatavošanas laiku.
Noraidītie pieteikumi
Ja mērķis ir pārveidot vai paplašināt produktu vai aizstāt produktu ar zināmām kļūdām, plānojiet tajā brīdī konstatēto kļūdu labošanu. Tāpēc šajā punktā
Izslēgtie plāna vienumi
Ja ir nepieciešami kādi plānošanas norādījumi īpašas īpašības un programmatūras iespējas, kuras nevar nodrošināt, ja produkts ir izstrādāts atbilstoši citām prasībām
Iekļautie plāna vienumi
Ja nepieciešamību izveidot produktu pamato kāds dokuments, piemēram, produkta izlaišanas plāns, partijas izlaišanas plāns vai uzdevuma apraksts, tad tiek norādīta vai nu konkrēta vieta no katra dokumenta, vai
Lietotāju prasību saraksts
Preces pircēji ir norādīti un paskaidrots, kāpēc viņiem tā nepieciešama. Šajā sadaļā ir norādīts arī produkta paredzamais kalpošanas laiks. Parasti tas būs iekārtas kalpošanas laiks
Apsvērtās alternatīvas
Īss apraksts par šīs attīstības alternatīvām, kas tika apsvērtas un noraidītas, kā arī noraidīšanas iemesli. Ja programmas ir jāiegādājas, paskaidrojiet, kāpēc tās nav jāiegādājas
Ienākumi no ieguldījumiem
Peļņa, ko dos produkta radīšana, tiek noteikta terminos, kas atbilst paredzētajam organizācijas mērķim. Piemērs. ABC Services sagaida finanšu pārdošanu
Sistēmas programmatūra
Sistēmas programmatūra ir visa pārējā programmatūra, tostarp operētājsistēmas, kompilatori, utilītas, lietojumprogrammu pakotnes utt. Tā ir programmatūra
Funkciju vispārīgie raksturojumi
Visu produktu nepieciešams uzskatīt par vienu funkcionālu moduli, lai apakšsadaļu skaits būtu mazs. Ja nav iespējams adekvāti aprakstīt produktu, nesadalot to atsevišķos funkcionālos
Ārējie ierobežojumi
Uzskaita visus ierobežojumus, kuru darbības joma ir plašāka nekā MT darbības joma; tas ietver, piemēram, nozares ierobežojumus vai produktu sēriju ierobežojumus. Var ielaist iekšā
Saderības ierobežojumi
Vienmēr ir jāņem vērā vairāki saderības aspekti: avota valoda, mašīnas valoda, datu un ziņojumu formāti, pārskatu formāti, saraksta formāti un darba kontroles valodas (JCT) formāti.
Programmatūras ierobežojumi
Ja nepieciešams, tiek norādīta operētājsistēma, ar kuru jādarbojas piedāvātajam programmatūras produktam, kā arī citi programmatūras rīki, ar kuriem tas ir jāpievieno procesā.
Aparatūras ierobežojumi
Dota programmatūras produkta darbībā izmantoto ierīču tabula. Katrai ierīcei ir norādīts nepieciešamais minimālais, nominālais un maksimālais skaits. Nominālvērtība ir optimālā
Darba rezultāti
Visi programmatūras produkta vai funkcionālā moduļa izejas dati ir aprakstīti pēc to satura un mērķa - atskaites, faili, ieraksti, datu lauki, ziņojumi, tabulas, karodziņi. Vajadzētu
Procesi
Tiek aprakstītas programmatūras produkta veiktās darbības, kas tiek uzskatītas kopumā vai funkcionālie moduļi kā melna kaste (vai melno kastu komplekts). Vismaz ar iestatījumu
Uzticamība
Programmatūras uzticamība tiek saprasta kā spēja atjaunot normālu darbību kļūdu un iekārtu atteices gadījumā. Lietotāju datu aizsardzība ir ārkārtīgi svarīga. sl
Restartēt
Norādītas iespējas, kas nodrošina datu saglabāšanu un izmantošanu, atsākot darbību pēc avārijas pārtraukuma, piemēram, restartējot no kontrolpunkta. Piemērs 1. Programma
Klientu atbilstība
Ir norādītas īpašības, kas ļauj programmatūras produktam vai tā izvadei atbilst īpašām prasībām. Ja iespējams, uzskaitiet moduļus, kas var neatbilst t
Darbības īpašības
Ir norādīts galvenais mainīgais vai galvenais princips, pēc kura jānovērtē programmas efektivitāte; norāda atbilstošo vērtību vai vērtību diapazonu šim mainīgajam. Ch
Lietošanas ērtums
Ir aprakstītas īpašības, kas padara mijiedarbību "cilvēks - mašīna" ērtu cilvēkam. Piemēri ir bezmaksas ievades formāts, interaktīvais režīms, sintaktiskā saderība, iespējama
Apkopes vienkāršība
Ir aprakstīti pasākumi, lai nodrošinātu moduļu identificējamību, ja šī problēma nav atrisināta ar standartu. Piemērs 1. Katrs avota un objekta modulis tiks nodrošināts ar programmatūras šifru.
Restartējiet lietotāja interfeisu
Piemērs. Sistēmas stāvoklis visiem aktīvajiem lietotājiem (ieskaitot atvienotus, bet joprojām darbojas) periodiski tiek saglabāts diskā (ar intervālu, kas norādīts laika definīcijā
Lietotāja saskarnes īpašības
Piemērs. Pieņemot, ka iekārtā darbojas tikai ASK un atkopšanas parametru raksturo viens kontrolpunkts 1 minūtē, katra instrukcija ir jāizpilda vai
Lietotāja interfeisa darbības joma
Piemērs. Tipiskā ASK sesijā lietotājs bez programmēšanas pieredzes pieslēdzas sistēmai, izmantojot termināli, un iesaistās dialogā, kurā definē:
Lietotāja interfeisa algoritms
Piemērs. ASK izpilda katru komandu interpretācijas režīmā un nekavējoties; tādējādi komandu uzkrāšana nav atļauta (izņemot atmiņas komandas, kas tiks aplūkotas turpmāk).
Aparatūras ierobežojumi
Piemērs. Papildus VSOS ILSAM nepieciešamajām ierīcēm (sk. 2.4.1 b un c) korekcijas procesoram būs nepieciešamas 2.3. tabulā norādītās ierīces. 2.3. tabula — Ierīces
Iekšējie ierobežojumi
Ir svarīgi noteikt ne tikai to, kāda būs prece, bet arī kāda tā nebūs. Ierobežojums ir līdzeklis (vai iespēja), ko lietotājs pamatoti varētu sagaidīt, bet kurš
Atsauces dokumenti
Atsevišķi tiek norādīts katrs plānošanas vai tehniskais dokuments, uz kuru ST ir saite. Katram šādam dokumentam faktiski ir jābūt (un tas nedrīkst būt netieši norādīts nākotnē) un
Resursi īstenošanas nodrošināšanai
Sistēmas uzstādīšanai nepieciešamie resursi tiek noteikti kopā ar resursiem, kas aprakstīti sadaļā 2.5.
Informācijas nesēji
Nosaka visu programmatūras produkta izplatīto komponentu atmiņas ierīču veidu (piemēram, magnētiskā lente, ko raksturo celiņu skaits un ieraksta blīvums
Nepieciešamās attiecības
Tiek noteiktas prasības, ko šis programmatūras produkts izvirza citiem projektiem vai funkcijām. dota īss apraksts par katrai prasībai un norāda posmu, kurā to var uzstādīt
Nodrošinātās attiecības
Šī sadaļa pēc struktūras ir līdzīga iepriekšējai, taču tajā ir ietvertas prasības, ko šim izstrādājumam uzliek citi produkti. Katrai 2.6.1.2. iedaļas prasībai ir jāatbilst laika prasībai
Tehniskās revīzijas komisija
Katrai TA būtu jāiesaka izveidot Tehniskā audita komisiju (TRC), norādot katra komisijas locekļa darba vietu un uzvārdu, ja iespējams, kā arī iecelšanu.
Pārbaudes līmeņi
Testēšanas programmas var organizēt trīs posmos, veikt trīs režīmos un ietvert desmit kategorijas (sk. 5. sadaļu "Testēšana"). Šī informācija tiek sniegta tabulas veidā. Par ka
Atsauces salīdzināšanai
Ir noteiktas atsauces sistēmas, ar kurām jāveic salīdzinājums. Šīs sistēmas raksturlielumi ir norādīti relatīvās vienībās. Ja nav standarta salīdzināšanai
Paziņojums par kalendāra datumu maiņu
Piemērs. Projekta nosaukums: Produktu izstrāde ASK Projekta kods: C013. Produkta kods: L301A. Produkta nosaukums: ASK
Rakstīšanas specifikācijas
Specifikāciju rakstīšana ir otrās laboratorijas pirmās daļas mērķis. Arī specifikācijas ir kursa darba trešā sadaļa. Specifikācijas stadijā,
Vispārīgie testēšanas principi
Testēšanas posms parasti veido pusi no sistēmas izveides izmaksām finansiālā izteiksmē. Slikti plānota testēšana ievērojami palielina izstrādes laiku.
Programmatūras produktu testēšanas organizēšana
Testēšana tiek saprasta nevis kā atkļūdošana, kuras mērķis ir noteikt, kāpēc programmā rodas konkrēta kļūda un novērst tās cēloņus, bet gan pašu defektu esamības fakta konstatēšanas process.
Programmatūras produktu testēšanas veidi. Pārbaudes posmi
Parasti pārbaudes tiek veiktas vairākos posmos, kas atdalīti pēc laika. Pirmais posms ir A klases testi, kas tiek veikti programmēšanas fāzes beigās.
Programmu pārbaudes režīmi
Pārbaudes atšķiras atkarībā no tā, kurš tos veic. Galvenā ideja ir testa funkcijas neatkarība no izstrādes funkcijas. Pārbaudes režīms I nozīmē pilnu
Programmatūras produktu testa kategorijas
Testa posmi norāda, kad testi tiek veikti, un režīmi nosaka, kurš tos veic. Testu kategorijas nosaka testu būtību un mērķi. Pārdomāts dalījums un
Testēšanas tehnoloģija, ekvivalences klases
Viens veids, kā izpētīt uzdoto jautājumu, ir izpētīt testēšanas stratēģiju, ko sauc par melnās kastes stratēģiju, uz datiem balstītu testēšanu vai testēšanu.
Celtniecības testi
Testēšanas process ietver: 1) unikāla numura piešķiršanu katrai ekvivalences klasei; 2) jaunu testu izstrāde, no kuriem katrs tiek aptverts
Vispārīgi noteikumi
1.1. Dokumenta struktūra un dizains ir izveidots saskaņā ar GOST 19.105-78. 1.2. Sistēmas programmētāja rokasgrāmatā jāiekļauj šādas sadaļas:
Programmas struktūra
Programma Reader Workstation sastāv no šādām sastāvdaļām: 1) zcon - lietojumprogramma, kas realizē Z39.50 klienta funkcijas; 2) zgate-CGI-
Programmas instalēšana
Šajā dokumentā failu nosaukumu piešķiršanai tiek izmantota ISO/IEC 9945-1 definētā sintakse. Tajos operētājsistēmas kas neatbalsta norādīto failu nosaukumu piešķiršanas veidu lietojumprogrammās
Programmas pārbaude
Programma tiek pārbaudīta pēc tās izpildes metodes. Sakarā ar to, ka īpašie nosacījumi programmas lietošanai (Z39.50 serveru adreses, datu bāzu nosaukumi, atbalstīti
Papildus iespējas
Programmas papildu funkcija ir iespēja dinamiski kontrolēt ierakstu prezentācijas formu, skatot tos pilnā formātā (“Detalizēta informācija”), izmantojot
Ziņojumi sistēmas programmētājam
5.1. tabulā parādīti ziņojumi, ko sistēmas programmētājs var saņemt iestatīšanas, programmas pārbaudes laikā, kā arī lietotājs programmas izpildes laikā.
KRIEVIJAS FEDERĀCIJAS IZGLĪTĪBAS UN ZINĀTNES MINISTRIJA
FEDERĀLĀS VALSTS BUDŽETA AUGSTĀKĀS IZGLĪTĪBAS IESTĀDES SERDOBSKAS NODAĻA
"PENZA VALSTS UNIVERSITĀTE"
"Aplikācijas izstrāde hiperbolisko vienādojumu risināšanai, izmantojot režģa metodi Microsoft Visual Studio 2013 vidē"
SKAIDROJUMS
Uz kursa darbs disciplīnā "Programmatūras izstrādes tehnoloģijas"
Pabeidza: students gr.13PKS1
Dranicins E.A.
Pieņemts: skolotājs
Ju.S. Kiseļeva
abstrakts
Paskaidrojuma piezīme: 22 lapas, 7 zīmējumi, 4 avoti, 2 pielikumi.
Pētījuma objekts ir hiperbolisko vienādojumu atrisināšana.
Darba mērķis ir izstrādāt programmu, kas atrisinās hiperboliskos vienādojumus, izmantojot režģa metodi.
Paveiktā darba rezultātā ir izstrādāta programma, kas ļauj aprēķināt hiperbolisko vienādojumu atrisinājumu.
Rakstot programmu, tika izmantota Microsoft Visual Studio 2013 programmēšanas vide.
Ievads. 5
1 Domēna analīze. 6
2 Darba uzdevumi. 7
2.1. Izstrādes pamats. 7
2.2. Attīstības mērķis. 7
2.3. Programmas prasības. 7
2.3.1. Veiktspējas prasības.. 7
2.3.2. Prasības tehnisko līdzekļu sastāvam un parametriem. 7
2.3.3. Informācijas un programmatūras saderības prasības. 7
2.4. Prasības programmatūras dokumentācijai. 7
2.5. Posmi un attīstības stadijas. 8
2.6. Pārbaudes un pieņemšanas procedūra. 8
3 Programmas apraksts.. 9
3.1 Vispārīga informācija. 9
3.2. Funkcionalitāte. 9
3.3. Loģiskās struktūras apraksts.. 9
3.4 Izmantotie tehniskie līdzekļi. 10
4.1 Testa objekts. 11
4.2. Pārbaudes mērķis. 11
4.3. Programmas prasības. 11
4.4. Prasības programmatūras dokumentācijai. 11
4.5. Pārbaudes līdzekļi un procedūra. 12
4.6. Pārbaudes metodes. 12
5 Lietojumprogrammas apraksts. 13
Secinājums. 14
Izmantoto avotu saraksts. 15
PROGRAMMAS TEKSTS... 16
TESTA REZULTĀTI.. 21
Ievads
Hiperboliskais vienādojums - klase diferenciālvienādojumi privātajos atvasinātajos instrumentos. Tos raksturo tas, ka Košī problēma ar sākotnējiem datiem, kas norādīti uz neraksturīgas virsmas, ir unikāli atrisināma. Slavenākais piemērs ir viļņu vienādojums. Jebkurš pirmās kārtas daļējais diferenciālvienādojums ir arī hiperbolisks.
Microsoft Visual Studio ir jauna Microsoft izstrāde, kas ļauj izveidot lietojumprogrammas, kas darbojas .net platformā. Šīs platformas īpatnība slēpjas plašā pakalpojumu klāstā, kas ir pieejams dažādās programmēšanas valodās. Tajā pašā laikā pakalpojumi tiek īstenoti starpposma koda veidā, kas nav atkarīgs no pamatā esošās arhitektūras. Iespējams, šādas platformas izveides galvenais mērķis bija aprīkot izstrādātājus ar īpašām uz pakalpojumiem orientētām lietojumprogrammām, kas varētu darboties jebkurā platformā, sākot no personālais dators un beidzot ar mobilo ierīci.
Microsoft Visual Studio apvieno milzīgu skaitu funkciju, kas ļauj izstrādāt visu Windows versiju, tostarp 8, internetu, SharePoint, dažādas mobilās ierīces un mākoņtehnoloģijas. Visual Studio ievieš jaunu izstrādātāju vidi, kas atvieglo lietojumprogrammu izveidi. Microsoft Visual Studio ir atjaunināta un vienkāršota programmatūras vide, kas nodrošina augstu veiktspēju bez aparatūras atkarības. Un šī studija, iespējams, ir piemērota lietojumprogrammas izstrādei.
Domēna analīze
Šīs izstrādes priekšmeta joma ir hiperbolisko vienādojumu atrisināšana, proti, atrisināšana ar režģa metodi.
Praksē izmantotās metodes Hiperbolisko vienādojumu risināšanai iedala divās grupās - viļņu vienādojumos un dažādos vienādojumos, kas iegūti no Maksvela vienādojumiem. Viļņu vienādojumi ir vienādojumi, kas apraksta virkņu, membrānu un tā tālāk vibrācijas. Dažādi vienādojumi, kas iegūti no Maksvela vienādojumiem, kas apraksta elektromagnētisko lauku. Tas var būt iestatījums attiecībā uz kādu no vektoriem , skaitot tikai vienu no vektora komponentiem, kas atšķiras no nulles (tas ir, kad vienādojums kļūst skalārs).
Hiperboliskā vienādojuma risinājuma apraksts ar režģa metodi: uzdevums ir atrast funkciju u(x,t), kas apmierina doto vienādojumu (d^2*u/d*t^2)=c^2*(d ^2*u/d*x^ 2) pie x1< x < x2, t1 < t <= t2, начальным условиям u(x,0) = f(x), d u(x,0)/ d t = g(x) , x1<= x <= x2 и нулевыми краевыми условиями u(0,t) = u(1,t)=0. Так как замена переменных t ->ct reducē vienādojumu (1) līdz formai (d^2*u/d*t^2)=(d^2*u/d*x^2), tad turpmāk pieņemsim, ka c = 1. Lai izveidotu atšķirību shēma risinājumam mēs konstruējam problēmas domēnā D=((x,t)| x1<=x<=x2, t1<=t<=t2}, сетку xi = ih, i=0,1... n , a = h * n, tj = j*t t t , j = 0,1 ... , m, t m = T и аппроксимируем уравнение (1) в каждом внутреннем узле сетки.
Tehniskais uzdevums
Pamats attīstībai
Programma izstrādāta, pamatojoties uz skolotājas Ju.S.Kiseļevas izdoto kursa darba uzdevumu. un apstiprinājusi izglītības nodaļas vadītāja Zolotova T.A.
Attīstības mērķis
Izstrādātā programma paredzēta hiperbolisko vienādojumu risināšanai ar režģa metodi.
Programmas prasības
veiktspējas prasības
Gatavā programma nodrošina hiperbolisko vienādojumu atrisināšanu ar režģa metodi.
Ir nepieciešams organizēt ērtu lietotāja interfeisu, tostarp palīdzību par lietošanu un pielietoto metodi.