Saskaņā ar GOST, šis standarts (atkārtoti izdots 1987. gada novembrī) nosaka datoriem, kompleksiem un sistēmām paredzētu programmu vai programmatūras produkta izstrādes tehnisko specifikāciju izveides un izpildes kārtību neatkarīgi no to mērķa un darbības jomas.
To veidojot, mums jābūt ārkārtīgi uzmanīgiem un uzmanīgiem, jo. bieži prasmīgi (un kompetenti) izstrādāti TOR nosaka visa darba panākumus. Tieši TOR tiek saskaņots ar Klientu, kurš parasti cenšas izvirzīt pēc iespējas vairāk pretrunīgu un pārmērīgu prasību. Izpildītāja uzdevums ir tieši otrādi – atvieglot sev dzīvi. Bet pēc parakstu nolikšanas abās pusēs ir par vēlu kaut ko atskaņot.
Vispārīgi noteikumi
Darba uzdevumi tiek sastādīti uz A4 un/vai A3 formāta lapām, kā likums, neaizpildot lapas laukus. Lapu (lapu) numuri ir piestiprināti lapas augšpusē virs teksta.Lai turpmākajos programmas vai programmatūras produkta izstrādes posmos veiktu izmaiņas un papildinājumus tehniskajā fonā, tam tiek izdots papildinājums. Darba uzdevuma papildinājuma saskaņošana un apstiprināšana tiek veikta tādā pašā veidā, kā noteikts darba uzdevumā.
Darba uzdevumā jāiekļauj šādas sadaļas:
- nosaukums un darbības joma;
- pamats attīstībai;
- attīstības mērķis;
- tehniskās prasības programmai vai programmatūras produktam;
- tehniskie un ekonomiskie rādītāji;
- attīstības stadijas un stadijas;
- kontroles un pieņemšanas kārtība;
- lietojumprogrammas.
Sadaļa: nosaukums un darbības joma
Nodaļā Nosaukums un darbības joma norāda programmas vai programmatūras produkta nosaukumu, īsu darbības jomas aprakstu un objektu, kurā programma vai programmatūras produkts tiek izmantots.Sadaļā Pamats izstrādei jānorāda:
- 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.
Sadaļa: Attīstības mērķis
Nodaļā Attīstības mērķis jānorāda programmas vai programmatūras produkta funkcionālais un darbības mērķis. Šeit varat aprobežoties ar vienu vai divām frāzēm. Galvenais ir skaidri definēt, kam šī programma ir paredzēta.Piemēram: Programma ir nepārtrauktas izstrādātāja automatizētās darbstacijas (AWP) kodols lineārās sistēmas automātiskās vadības sistēma (ACS), kas ļauj lietotājam atrisināt vienkāršu modeļu analīzes problēmas.
nodaļa: Programmas vai programmatūras produkta tehniskās prasības
Šajā sadaļā jāiekļauj šādas apakšsadaļas: - veiktspējas prasības;
- uzticamības prasības;
- lietošanas noteikumi;
- prasības sastāvam un parametriem tehniskajiem līdzekļiem;
- 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.
Sadaļa: Prasības funkcionālajiem raksturlielumiem.
Šeit jānorāda prasības izpildāmo funkciju sastāvam, ievades un izvaddatu organizācijai, laika raksturlielumiem utt.Piemēram : Programmai jāļauj ... aprēķināt ... izveidot ... izveidot ...
Sākotnējie dati: teksta fails ar doto ...
Izejas dati: grafiskā un teksta informācija - sistēmas analīzes rezultāti...; teksta faili - ziņojumi par ... sistēmas stāvokļa diagnostiku un ziņošanu par visām radušajām kļūdām.
uzticamības prasības. Jāprecizē 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.).
Šeit ir grūti kaut ko "uzminēt". Labākajā gadījumā var iziet variants, kurā jūsu programma darbojas tikai ar absolūti pareiziem datiem. Parasti Klients tam nepiekrīt, bet jūs varat mēģināt.
Piemēram: Programmai jāstrādā ar doto pētāmā grafika paplašināto sastopamības matricu saskaņā ar funkcionēšanas algoritmu, jādod kļūdu ziņojumi, ja sākotnējie dati ir norādīti nepareizi, jāatbalsta interaktīvais režīms lietotājam sniegto iespēju ietvaros. .
Lietošanas noteikumi. 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.
Ar šo punktu grūtības parasti nerodas. Diemžēl Klients noteikti norāda uz lietotāja profesionalitāti. Tas, protams, ir vēl viens iemesls, lai atrastu kļūdas savā programmā. Tomēr šeit varat aprobežoties ar tādām frāzēm kā "Programmas darbības apstākļi sakrīt ar IBM PC un saderīgo personālo datoru darbības nosacījumiem", "Programma ir jāizstrādā neprofesionālam lietotājam." un tā tālāk.
Prasības tehnisko līdzekļu sastāvam un parametriem. Norāda nepieciešamo tehnisko līdzekļu sastāvu, norādot to tehniskos parametrus.
Šeit galvenais ir neko neaizmirst un visu paredzēt, no vienas puses (pretējā gadījumā viņi paslīdēs kādu IBM PC / XT ar vienkrāsainu displeju un bez peles), un, no otras puses, neaiziet pārāk tālu ar paaugstinātas prasības, pretējā gadījumā Pasūtītājs atradīs pretimnākošāku Izpildītāju.
Piemēram: jums ir nepieciešams ar IBM PC saderīgs dators ar EGA (VGA) grafikas adapteri. Nepieciešamā diska vieta - vismaz 600 KB, brīvās vietas apjoms brīvpiekļuves atmiņa- ne mazāk kā 400 Kb. Vēlams, lai būtu EMS draiveris un pele.
Prasības informācijas un programmatūras saderībai. Funkcijas ir tādas pašas kā iepriekšējā punktā. Šeit jānorāda prasības informācijas struktūrām ievades un izvades un risinājumu metodēm, pirmkodiem, programmēšanas valodām. Ja nepieciešams, informācija un programmas ir jāaizsargā.
Piemēram: Programmai ir jādarbojas autonomi MS DOS versijā 3.3 vai jaunākā versijā. Pamata programmēšanas valoda ir Turbo Pascal 6.0.
Prasības marķēšanai un iesaiņošanai un prasības transportēšanai un uzglabāšanai ir diezgan eksotiskas. Vispārējā gadījumā šeit ir norādītas programmatūras produkta marķēšanas prasības, iepakošanas iespējas un metodes. Un transportēšanas un uzglabāšanas prasībās programmatūras produktam jānorāda transportēšanas nosacījumi, uzglabāšanas vietas, uzglabāšanas nosacījumi, noliktavas apstākļi, uzglabāšanas periodi dažādos apstākļos.
Īpašas prasības ir ļoti atbildīga lieta. Vislabāk ir izvairīties no tiem, cik vien iespējams. Un paziņojiet par to uzreiz.
Piemēram: Programmas laika raksturlielumiem nav īpašu prasību. Programmas kapacitatīvām īpašībām nav īpašu prasību.
Tehniskie un ekonomiskie rādītāji. Šis programmētājam visgrūtākais elements ne vienmēr ir pieejams. Tas ir nepieciešams galvenokārt tad, ja jūsu mērķis ir attaisnot veiktā darba milzīgo efektivitāti un nozīmi. Parasti šī prece Klientam darbojas ļoti labi. Vismaz tas ir labākais izstrādes laika un izmaksu pamatojums.
Šajā sadaļā jānorāda: paredzamā ekonomiskā efektivitāte, paredzamā gada nepieciešamība (piemēram: paredzamais izsaukumu skaits kompleksam kopumā gadā ir 365 darba sesijas), attīstības ekonomiskās priekšrocības salīdzinājumā ar labākajiem pašmāju un ārvalstu paraugiem vai analogiem.
Turklāt ir vēlams sniegt definīciju gan paredzamajām programmas izstrādes izmaksām, gan programmēšanas sarežģītības definīcijai.
Izstrādes posmi un posmi (par to sīkāk tiks runāts tālāk) nosaka nepieciešamos izstrādes posmus, posmus un darba apjomu (programmas dokumentu sarakstu, kas jāizstrādā, jāsaskaņo un jāapstiprina), kā arī parasti , izstrādes laika grafiku un noteikt izpildītājus.
Šeit ir aprakstītas standarta darbības. Galvenais ir pareizi noteikt laiku. Ja iespējams, mēģiniet vienmērīgi sadalīt posmus pēc laika (un daudzuma). Atcerieties, ka ne visi projekti atbilst pēdējais posms. Un ziņojumiem jābūt par katru posmu. Atcerieties arī, ka darba projekts prasīs visvairāk laika. Ja Jums nav laika noformēt dokumentāciju laikā, tad Pasūtītājam ir visas tiesības darbu vispār nepieņemt ar visām no tā izrietošajām sekām.
Galvenie un obligātie posmi un posmi ir pats darba uzdevums, sākotnējais projekts, tehniskie un darba projekti.
Sākotnējais dizains. Šajā posmā tiek detalizēti izstrādātas ievades un izejas datu struktūras, tiek noteikta to prezentācijas forma. Izstrādāts vispārīgs apraksts algoritms, pats algoritms, programmas struktūra. Tiek izstrādāts rīcības plāns programmas izstrādei un īstenošanai.
Tehniskais projekts. Tajā ir izstrādāts problēmas risināšanas algoritms, kā arī metodes sākotnējās informācijas kontrolei. Tas arī izstrādā kļūdu apstrādes rīkus un diagnostikas ziņojumu izdošanu, nosaka sākotnējo datu pasniegšanas formas un tehnisko līdzekļu konfigurāciju.
Darba projekts. Šajā posmā tiek veikta programmas programmēšana un atkļūdošana, programmas dokumentu, programmu un testēšanas metožu izstrāde. Tiek gatavoti testēšanas un atkļūdošanas piemēri. Tiek pabeigta dokumentācija un grafiskais materiāls. Parasti tiek norādīts, ka programmas izstrādes gaitā ir jāsagatavo šāda dokumentācija:
Programmas teksts;
Programmas apraksts;
Programma un testa metodika;
Lietojumprogrammas apraksts;
Lietotāja rokasgrāmata.
Tās ir standarta prasības. Ja Klients piekrīt, ka nevar iesniegt visu šo sarakstu, tas nozīmē, ka viņa nodomi attiecībā uz Jums un Jūsu preci nav nopietni.
Grafika var būt pieejama vai nebūt pieejama. Īpaši tad, kad netaisāties ziņot par sava darba rezultātiem. Bet nopietniem projektiem šis vienums ir nepieciešams.
Piemēram: Programmas izstrādes laikā ir jāsagatavo šāds grafiskais materiāls:
Tehniskie un ekonomiskie rādītāji;
Programmas struktūra;
Programmas ievaddatu prezentācijas formāts;
Algoritma vispārīgā shēma (2 lapas);
o pamata skaitļošanas algoritmi;
piemērs, kā programma darbojas.
Sadaļā Kontroles un pieņemšanas kārtība, pārbaužu veidi un Vispārīgās prasības pieņemt darbu. Ja iespējams, šajā punktā norādiet, ka "izstrādes kontrole un pieņemšana tiek veikta uz Pasūtītāja nodrošinātajām iekārtām", pretējā gadījumā jums var būt nepieciešams ņemt līdzi aprīkojumu.
Piemēram: Izstrādes kontrole un pieņemšana tiek veikta, pamatojoties uz kontroles un atkļūdošanas piemēru testiem. Tas pārbauda visu programmas funkciju izpildi.
Darba uzdevuma pielikumos, ja nepieciešams, norādīt:
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.
Programmatūras sistēmai jānodrošina datu aizsardzība pret nejaušu dzēšanu un pārveidošanu. Piekļuve datiem ir jābūt tikai datu bāzes administratoram vai instruktoram ar atbilstošām tiesībām, kas ir reģistrēts datu bāzes serverī un kuram ir atbilstošas lomas.
Lai apmācības sistēma būtu uzticama, tai jāatbilst šādām prasībām:
izstrādātajai programmai jābūt aizsardzības līdzekļiem pret lietotāju kļūdainu rīcību;
visas kļūdas jāparāda ar komentāriem vai padomiem, kā tās novērst;
nodrošināt datu drošību ārējo ierīču darbības traucējumu gadījumā.
Lai uzlabotu uzticamību, jāveic šādi pasākumi:
konfigurēt aparatūru un programmatūru atbilstoši tehniskajām prasībām;
periodiski dublējiet informāciju;
regulāri pārbaudīt datu bāzes integritāti;
uzturēt tīkla aprīkojumu.
Prasības tehnisko līdzekļu sastāvam un parametriem
Sistēmas minimālā aparatūras konfigurācija, kas nodrošina normālu apmācību sistēmas darbību, nedrīkst būt zemāka par sekojošo:
RAM 128 MB vai vairāk.
Vismaz 150 MB brīvas vietas cietajā diskā.
Prasības datoram, ko izmanto konfigurāciju izstrādei:
Procesors AMD Athlon 900 MHz vai augstāks.
RAM 256 MB vai vairāk.
Vismaz 250 MB brīvas vietas cietajā diskā.
Izmantojot automatizētu sistēmu lokālajā tīklā, vienā no datoriem ir jābūt instalētam Firebird1.5.3 serverim un jādarbojas ar iepriekš instalēto datu bāzi. Citās iekārtās jāinstalē iekārtu uzskaites sistēmas klienta lietojumprogramma.
Prasības informācijas un programmatūras saderībai
Lai darbinātu programmatūras produktu, ir nepieciešami šādi komponenti:
Microsoft® Windows® saimes operētājsistēma (ne zemāka par 2000).
Instalēti un konfigurēti programmatūras produkti MicrosoftSQLServer, IBExpert2004, Borland®C++Builder™ 6.0, Microsoft.NETFrameworkSDKv2.0.
lietošanas noteikumi
Programmai jādarbojas ar strādājošu aparatūru. Prasības kompleksā izmantotā datora un citu iekārtu ekspluatācijas apstākļiem ir noteiktas iekārtu piegādes komplektā iekļautajos tehniskajos dokumentos.
Prasības programmatūras dokumentācijai
Programmas dokumentācijā jāiekļauj šādi dokumenti.
Sistēmas administratora rokasgrāmata.
Skolotāja rokasgrāmata.
Izglītojamo ceļvedis.
Sistēmas administratora rokasgrāmatā jāiekļauj konkrētās sistēmas konfigurācijas apraksti.
Programmatūras sistēmā jāiekļauj pilnīga skolotāja rokasgrāmata ar skolotāja darba scenāriju aprakstu.
Programmatūras sistēmā jāiekļauj pilnīga rokasgrāmata praktikantam ar praktikanta darba scenāriju aprakstu.
Programmatūras sistēmas izstrādes posmi
Programmatūras sistēmas izstrāde jāorganizē sekojošos posmos.
īstenošanas plāna izstrāde;
testa plāna izstrāde;
īstenošanas plāna izstrāde.
Dizains:
programmatūras sistēmu arhitektūras loģiskā projektēšana;
datu bāzes struktūras izstrāde;
lietotāja interfeisa dizains.
Īstenošana:
izstrādātā lietotāja interfeisa ieviešana;
programmatūras sistēmas galveno funkciju ieviešana.
Sistēmas pārbaude:
strukturālā pārbaude;
funkcionālā pārbaude;
kļūdu labojumi un uzlabojumi.
Sistēmas ieviešana:
nepieciešamā aprīkojuma pieejamības pārbaude;
sistēmas uzstādīšana;
apmācību.
Sistēmas uzturēšana.
Pēc klienta pieprasījuma šī programmatūra ir izstrādāta Windows platformai. Programmai jādarbojas šīs platformas galvenajās versijās: Windows98, Windows2000, WindowsXP. Turklāt programmas servera daļai WinNT versijām jādarbojas kā pakalpojumam (darbam fonā).
Nepieciešams nodrošināt iespēju vēl vairāk palielināt sistēmas funkcijas (atvērtību attīstībai un jaunu uzdevumu savienošanas metodi).
Transportēšanas un uzglabāšanas prasības
Izstrādājamā vadības sistēma tiks piegādāta kā komplekts kopā ar RAID kontrollera pārdošanu. Tas jāieraksta atsevišķā CD-ROM, kurā būs sistēmas draiveri un nepieciešamā dokumentācija pārdotajam kontrollerim. Lai to izdarītu, lūdzu, ņemiet vērā, ka instalācijas failu lielums ir ne vairāk kā 2/3 no standarta CD-ROM (700 MB).
Īpašas prasības
Programmas servera daļai, kas analizē RAID darbību, vienmēr jādarbojas 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).
Programmas blokshēma
Viss programmatūras projekts ir balstīts uz diviem neatkarīgiem moduļiem. Kā jau minēts, viens no tiem darbojas atsevišķi datorā ar RAID sistēmu, bet otrs - administratora datorā. Īsuma labad mēs nosauksim pirmo moduli aģents, un otrais - Pārvaldnieks.
Pārvaldnieks– programmas lietotāja puse, kurā ir programmas interfeiss, sākotnējās instalēšanas vednis un palīdzības sadaļa. Pārvaldnieks pārvaldīs RAID sistēmu aģents.
Aģents galvenokārt kalpo komandu pārsūtīšanai no vadītājs RAID sistēma un otrādi. Arī Aģents nodarbosies ar RAID uzraudzību (log faila glabāšanu) un kļūdu gadījumā ziņošanu administratoram.
Tīkls
Rīsi. 1.2. Programmas GUIRAIDManager galvenā struktūra
Visa darba darba pamatstruktūra kopumā ir parādīta attēlā. 1.2. Tas parāda dažādas iespējas abu moduļu darbībai. Aģents Un Pārvaldnieks:
Aģents(C3 ) darbojas datorā un analizē RAID masīva darbību R2 ;
Pārvaldnieks no attālā datora C2 vai C4) var savienot tīklā ar A gentom(C3), lai kontrolētu RAID masīva darbību R2 ;
Pārvaldnieks Un Aģents palaist vienā datorā C1, lai pārvaldītu RAID masīva darbību R2 . Šai opcijai nav nepieciešams tīkla savienojums.
Ievades un izvades datu struktūra
Galvenā datu apmaiņa sistēmā kopumā notiek pa diviem kanāliem:
starp Pārvaldnieks Un aģents tīklā, izmantojot TCP / IP protokolu (komandas vadītājs un atbildes aģents);
starp aģents un RAID kontrolieris, izmantojot RS-232 interfeisu (kontrollera nopratināšana un atbildes no tā).
Datu apmaiņas vispārīgā shēma projektā ir ilustrēta att. 1.3.
Rīsi. 1.3. Datu apmaiņa programmā GUIRAIDManager
Datu formāts starp Pārvaldnieks Un aģents, kā arī starp aģents un RAID kontrolleris ir aprakstīts sadaļā “Moduļa datu formāts Aģents» no šīs sadaļas.
Mans uzdevums šajā projektā ir izstrādāt moduli Aģents. Tāpēc sīkāk aplūkosim datu apmaiņu modulī Aģents starp Pārvaldnieks un RAID kontrolieris. Modulāra struktūra aģents attēlā parādīts. 1.4
Rīsi. 1.4. Datu apmaiņa aģenta modulī
Šī diagramma parāda, ka dati starp Pārvaldnieks Un aģents iziet caur moduli datu saņemšanai un pārsūtīšanai tīklā. Lai pārbaudītu savienojamību vadītājsšis modulis izmanto autorizācijas bloku. Visi saņemtie dati tiek parsēti komandu apstrādātāja blokā vadītājs. Atkarībā no komandas veida informācija tiek saņemta vai nu iestatījumu blokā, vai vēstures failu blokā, vai RAID statusa aptaujas modulī. Pēdējais kalpo, lai nosūtītu komandas RAID kontrollerim un saņemtu no tā atbildes. Ja pieprasījuma laikā rodas kļūda vai kontroliera atbilde satur kritisku ziņojumu, paziņojumu modulis informēs administratoru par šo kļūdu.
Apakšsadaļā "Prasības informācijai un programmu savietojamībai" jānorāda prasības informācijas struktūrām ievades un izvades un risinājuma metodēm, pirmkodiem, programmēšanas valodām un programmas izmantotajiem programmatūras rīkiem. Ja nepieciešams, informācija un programmas ir jāaizsargā.
Piemērs. Datorā jādarbojas operētājsistēmai, kas nav jaunāka par Windows 98/NT 4.0. Informācijas savietojamības prasība jānodrošina, strādājot ar noteiktas struktūras ģeometriskās informācijas failiem kā ievades un izvades informāciju.
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ļā:
veiktspējas prasības
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.
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 vispārīgi jēdzieni 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
IN š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 interfeisa ī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 "Automatizēts darba vieta lasītājs" sastāv no šādām sastāvdaļām: 1) zcon - aplikācija, 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ītie punkti
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ā.