Darba uzdevums (TOR) - oriģinālais dokuments, kas ir par pamatu programmas izstrādei un testēšanai vai automatizēta sistēma. Programmas un programmatūras darba uzdevums ir izstrādāts atbilstoši prasībām. TK attīstības pamatā visbiežāk ir līgums.
Programmas TOR ir izstrādāts, pirmkārt, tiem cilvēkiem, kuri vēlāk izstrādās programmatūras produktu. Tāpat kā jebkuram citam programmas TOR, tam ir jābūt ārkārtīgi skaidram un nesatur divdomīgu formulējumu un pēc iespējas pilnīgāk jāapraksta visas Pasūtītāja prasības un vēlmes attiecībā uz topošo programmu, taču neaizmirstiet, ka programmētāji ir radoši cilvēki un viņiem ne vienmēr ir viegli apgūt 150 tehniskā teksta loksnes.pie varas.
Kam uzticēt programmas tehnisko specifikāciju rakstīšanu
Vēlos pievērsties izplatītai kļūdai - programmatūras produkta tehniskā uzdevuma rakstīšanu uzticēt programmētājam, argumentējot ar to, ka programmētājam vēlāk būs vieglāk realizēt pašam savu tehnisko uzdevumu.
Programmas darba uzdevums jāizstrādā tehniskajam autoram! Pirmkārt, papildus zināšanām par GOST 19.201-78 ir nepieciešamas arī zināšanas par citiem standartiem (piemēram, GOST 19.106-78, GOST 19.104 - 78 utt.), Ne daudzi programmētāji zina šos GOST, un vēl mazāk piekritīs pētīt tos. Otrkārt, nepieciešamas zināšanas un pieredze tehniskajā rakstu valodā (nejaukt ar programmatūras koda rakstīšanu). Treškārt, tikai sadarbības komanda (tehniskais rakstnieks, programmētājs, projektu vadītājs) varēs izstrādāt pilnīgu tehniskais uzdevums programmai un programmatūrai.
Darba uzdevuma struktūra
ZINĀTNES UN IZGLĪTĪBAS MINISTRIJA
KRIEVIJAS FEDERĀCIJA
SEI HPE "ADYGE STATE UNIVERSITY"
FIZIKAS FAKULTĀTE
DEPARTAMENTS ASOIU
PROGRAMMATŪRAS IZVEIDES ATSAUCES NOTEIKUMI
PRODUKTS
IEVADS…………………………………………………………………………. ... 3
1. ATTĪSTĪBAS PAMATS…………………………………………….. ...…4
1.1. Dokuments, uz kura pamata tiek veikta izstrāde……………………………..4
1.2. Organizācija, kas apstiprinājusi izstrādes pamatu, un tās apstiprināšanas datums4
1.3. Izstrādes tēmas nosaukums………………………………………………….4
2. ATTĪSTĪBAS MĒRĶIS………………………………………………………..5
2.1. Programmas efektivitātes un kvalitātes kritēriji………………………………..5
5
3. PRASĪBAS PROGRAMMAI………………………………………………………6
3.1. Veiktspējas prasības……………………………….6
3.1.1. Veicamo funkciju sastāvs…………………………………………………….6
3.1.2. Ievades un izvades datu organizācija……………………………………….6
3.1.3. Laika raksturlielumi un atmiņas apjoms………………………6
3.2. Uzticamības prasības………………………………………………………….…6
3.2.1. Prasības drošai darbībai…………………………………6
3.2.2. Ievades un izvades informācijas kontrole…………………………………..7
3.2.3. Atkopšanas laiks pēc kļūmes………………………………………..7
3.3. Ekspluatācijas apstākļi……………………………………………………………….7
3.4. Prasības sastāvam un parametriem tehniskajiem līdzekļiem…………………...7
3.5. Prasības programmēšanas valodām……………………………………..8
3.6. Prasības programmas izmantotajai programmatūrai………8
3.7. Prasības programmatūras dokumentācijai………………………………………… 8
4. TEHNISKIE UN EKONOMISKIE RĀDĪTĀJI…………………………… ..... 9
5. ATTĪSTĪBAS POSMI UN POSMI……………………………………………………9
6. KONTROLES UN PIEŅEMŠANAS KĀRTĪBA…………………………………………………9
6.1. Pārbaužu veidi…………………………………………………………………..9
6.2 Vispārīgās prasības uz pieņemšanu……………………………………………………………………………………………………………………………………………
7. ĪSTENOŠANAS POSMI…………………………………………………………......10
IEVADS
Programmatūras izstrādes pilns nosaukums: "Programma K", turpmāk tekstā "programma". Programmas īsais nosaukums ir "PC".
Pašlaik nav līdzīgu programmatūras produktu.
Izstrādātā programma tiek pielietota jebkurā uzņēmumā, kurā ir strādājošs personāls.
Šī programmatūras produkta izstrādātājs ir 4A1 grupas students Ivanovs A.V. turpmāk tekstā "izstrādātājs".
Programmatūras produkta pasūtītājs ir OJSC RTS, kuru pārstāv direktors A.M. Gūtenko.
1 ATTĪSTĪBAS PAMATS
1.1. Dokuments, uz kura pamata tiek veikta izstrāde
Darbs tiek veikts, pamatojoties uz uzdevumu disciplīnā " Teorētiskā bāze automatizēta kontrole»
1.2. Apstiprināšanas organizācija un šī dokumenta apstiprināšanas datums
Norīkojumu apstiprināja un izdeva A.V.Kozakovs, RTS OJSC tehniskās daļas vadītājs.
Kozakovs A.V.
1.3. Izstrādes tēmas nosaukums
Izstrādes tēmas nosaukums ir “Darba laika uzskaite”.
2 ATTĪSTĪBAS MĒRĶIS
Šī izstrāde ir semestra darbs disciplīnā "Automātiskās vadības teorētiskie pamati"
2.1. Programmas efektivitātes un kvalitātes kritēriji
sociālais faktors.Šī programmatūras izstrāde ir ļoti viegli apgūstama, un tā ir paredzēta ne tikai profesionāļiem, bet arī parastajiem lietotājiem, kuri strādā operētājsistēmā Windows. Ērts, intuitīvs interfeiss apvienojumā ar jaudīgu papildu attēlu un rīku padomu sistēmu ļauj strādāt ar programmu bez iepriekšējas sagatavošanās.
Atbilstība šī profila programmatūras tirgus pašreizējam stāvoklim. Atšķirībā no dārgām un sarežģītām programmām, PC ir ideāli piemērots biznesa pārstāvjiem, jo satur visu nepieciešamo, taču nav pārslogots ar bezjēdzīgām un nevajadzīgām funkcijām. Programmas izveides tehnoloģija vizuālās programmēšanas vidēs padara tās saskarni universālu un saderīgu ar operētājsistēmas Windows 95/98/2000/XP.
Ekonomiskie spēki. Programma atspoguļo vislabāko cenas un tai nodrošināto funkciju attiecību un neapšaubāmi ieņems savu nišu lētu programmu tirgū. Galvenie lietotāji būs biznesa pārstāvji, kuri vienkārši nevar samaksāt par dārgām programmām no 1C un tamlīdzīgi.
2.2. Programmas izstrādes mērķi
Šīs programmas izveidei ir vairāki tehniski un ekonomiski mērķi:
Darba laika uzskaitei nepieciešamā programmatūras produkta izveide.
Lētas alternatīvas izveide pašlaik esošajām dārgajām programmām.
Izveidojiet intuitīvu programmu ar ērtu un daudzpusīgu Windows.
Mēs pastāvīgi dzirdam par tehniskajiem uzdevumiem, to nozīmi un pareizu apkopošanu. Darba uzdevumi vietņu izveidei, darba uzdevumi dizaina projektiem, darba uzdevumi programmatūras izstrādei, darba uzdevumi šim, darba uzdevumi šim ... Vai tiešām tas ir tik svarīgi, darba uzdevums, pazīstami minēts uz kā TK? Un noskaidrosim!
Piemēram, izcelsim vienu no izplatītākajām jomām – programmu izstrādes darba uzdevuma sagatavošanu. Un, iespējams, mēs sāksim pakāpeniski atbildēt uz jautājumiem, kas rodas.
Kāpēc tehniskais uzdevums?
Atbildot uz jautājumu "kāpēc?" Ir svarīgi saprast, kas patiesībā tiek teikts. Kā jau minēts iepriekš, kā darba uzdevuma sagatavošanas piemērs tika izvēlēta programmu izstrāde. Un tas nozīmē, ka uzņēmumam, firmai, organizācijai ir reāli esoši, aktuāli uzdevumi, kurus var un vajag risināt efektīvāk, nekā tas tiek darīts šobrīd. Citiem vārdiem sakot, ir nepieciešams aizstāt cilvēku darbu, kas ir dārgs un dažādas kvalitātes, ar efektīvu un daudz lētāku programmatūras darbu.
Patiešām, darbiniekiem ir vajadzīgs atvaļinājums, viņi visi vēlas saņemt algu laikā algas, periodiski “iet slimības atvaļinājumā”, un, kā likums, neizsaka vēlmi strādāt nedēļas nogalēs. Programmu izstrāde, gluži pretēji, ne tikai nerada norādītās problēmas, ar apskaužamu regularitāti aizstājot viena otru, bet, gluži pretēji, tās atrisina!
Apskatīsim risinājumus tuvāk. Tā kā aktuālo problēmu saraksts, kuras jārisina ar programmatūras palīdzību, jau ir izveidots, ir laiks padomāt par paša risināšanas procesu. Sapulcējamies, sēžam, strīdamies, noskaidrojam, un beigās, lūk, vairāk vai mazāk kopējais atbildīgo personu viedoklis par to, ko darīs topošā programma. Tā lēnām, bet noteikti dzimst priekšnoteikums programmu izstrādes darba uzdevuma sagatavošanai.
Protams, lietas var būt pavisam citādas. Darba uzdevuma sagatavošanu uzticam programmu izstrādi piedāvājošā uzņēmuma speciālistiem. Pāris tikšanās lietišķā, bet draudzīgā gaisotnē, gatavas biksītes, veidlapas, līgumi, veidlapas. Viss ir pabeigts un visi ir laimīgi. Vismaz pagaidām.
Īpašnieks, kā saka, ir džentlmenis, un vienmēr var brīvi izvēlēties labāko variantu gan cenas, gan kvalitātes ziņā. Ideālā gadījumā, protams, ka abi ir samērīgi, taču vienmēr ir jāpieiet kompromisi. Ja cena ir pārāk zema, programmatūras izstrādes kompromiss, protams, pāriet uz strauju programmatūras kvalitātes pasliktināšanos. Taču paradoksālā kārtā tas pats notiek ar analfabētu programmu izstrādes tehnisko specifikāciju sastādīšanu. Nauda samaksāta, prece saņemta, strādā, bet ne tā.
Šeit faktiski ir acīmredzama atbilde uz jautājumu, kāpēc ir nepieciešams izstrādāt kompetentu tehnisko uzdevumu programmu izstrādei. Pāriet tālāk.
Kam paredzēta specifikācija?
Programmu izstrādes darba uzdevums ir sastādīts, pirmkārt, tiem cilvēkiem, kuri veiks tieši šo izstrādi. Attiecīgi tam ir jābūt skaidram tai personai, kura neko nezina par klientu un vēl jo vairāk par viņa uzdevumiem un problēmām. Vismaz viņš vēl nezina.
Līdz ar to programmu izstrādes darba uzdevumā būtu jāpasaka darbuzņēmējam gan par uzņēmumu, gan par mērķiem, gan par uzdevumiem. Tajā pašā laikā, jo konkrētāks ir stāsts, jo labāk - gan teicējam, tas ir, Pasūtītājam programmu izstrādei, gan klausītājam, tas ir, projekta izpildītājam.
Kopumā darba uzdevumam ir vairāki mērķi, un, lai gan tas varētu būt teikts pašā sākumā, izlaidumus labot nekad nav par vēlu. Un tātad mērķi:
- Organizācija
- Informācija
- Komunikācija
- Jurisdikcija.
Organizācija ir jāvirza uz pašu procesu, citiem vārdiem sakot, lai racionalizētu radošumu un programmas vai programmatūras pakotnes izveidi. Stingri, programmu izstrādes darba uzdevuma struktūrai jābūt skaidrai un vienlaikus kodolīgai. Kopš izlasītas 120-150, vai pat vairāk, nesagremojama tehniskā teksta lappuses, programmētāja radošā personība vienkārši nespēj. Tātad īsums ir talanta māsa.
TOR informācijas komponentei jābūt pilnīgai, bet kodolīgai.
Un atkal vienkāršs noteikums, "vajadzīgs un pietiekams". Tas, kā parasti, ir jāievēro vienmēr un visur, taču, sastādot programmu izstrādes darba uzdevumu, šis noteikums kļūst par pirmo vietu. Kompetents tehniskais uzdevums ir pirmais un pēdējais dokuments, kas programmētājam viegli saprotamā formā pastāstīs par visām klienta vēlmēm. Vai vēlaties pārvērst sava uzņēmuma vai uzņēmuma dzīvi principiāli jaunā līmenī? Tad programmu izstrādes darba uzdevums ir pats atbalsta punkts, ar kuru pasaule apgriezīsies jūsu norādītajā virzienā. Un to, redziet, nekādā gadījumā nevar atstāt novārtā.
Komunikācija ir nedaudz grūtāka. Kāpēc? Jā, jo komunikācija un pat salīdzinoši radošajā procesā vienmēr ir sarežģīta. It īpaši, ja jūs runājat dažādās valodās. Un šeit var būt vairākas valodas, precīzāk - atbilstoši projekta dalībnieku skaitam ar koda nosaukumu "programmatūras izstrāde".
Vienkārši liec:
- Klients, viņš ir Klients
- Projektu menedžeris
- Projekta izpildītāji, viņi vai viņš: programmētājs(-i)
- Citi iespējamie dalībnieki, kuriem ir viedoklis: kā to izdarīt, kā labāk un kā tam vajadzētu beigties.
Dabiski radot kopīgs projekts, šie dalībnieki ir spiesti meklēt visiem saprotamu valodu. Šī valoda ir paredzēta programmu izstrādes darba uzdevumam. Ideālā gadījumā galvenais ir izveidot sakaru kanālu starp pirmo un trešo saiti, un jo mazāk traucējumu ieviesīs otrā un ceturtā saite, jo labāks būs rezultāts, un programmu izstrāde dos vēlamo rezultātu ar minimālu nervu zudumu. .
Tātad mēs nonācām pie jurisdikcijas, starp citu pieskaroties jautājumam par "nervu zudumu". Pateicoties darba uzdevumam, iespējams spriest par programmu izstrādes rezultāta atbilstību dotajiem sākuma nosacījumiem. Jāsaka, ka īslaicīgā atmiņa cieš gan projekta pasūtītājiem, gan izpildītājiem. Pirmais aizmirst par saskaņotajām izmaksām, labojumu skaitu, ieviešanas un atkļūdošanas iespējām, bet otrs - principā par to, kas un kad viņiem vajadzēja darīt. Lai samazinātu amnēziju un tās sekas līdz minimumam, atkal nepieciešams skaidrs un konkrēts TOR programmu izstrādei!
Kā uzrakstīt tehnisko uzdevumu?
Pārliecinājušies par programmu izstrādes darba uzdevuma nepieciešamību un pat nenovērtējamību, varam sarunu turpināt. Tagad mēs esam nonākuši pie visnopietnākā jautājuma: kā sastādīt TOR, lai tas būtu kompetents, skaidrs, kodolīgs, bet konkrēts ?! Un mums nevajag neko citu.
Par to rūpējās jau senos PSRS laikos, izstrādājot veselu standartu koncepciju, ko sauc par GOST. Pārsteidzoši, ka programmu izstrāde, šie standarti arī paredz, ka jūs piekritīsit, nevar vien priecāties.
Programmu izstrādi un darba uzdevumu sagatavošanu šajā jomā regulē GOST 19.201-78 viena sistēma programmatūras dokumentācija. Tehniskais uzdevums. Prasības saturam un dizainam.
Arī vēl divi ceļveži nebūs lieki:
- GOST 2.114-95 Vienota sistēma projektēšanas dokumentācijai. Specifikācijas;
- Informācijas tehnoloģija GOST 34.602-89. Standartu komplekts automatizētām sistēmām. Darba uzdevumi automatizētas sistēmas izveidei. Šo trīsvienību, protams, var uzskatīt par "svēto svēto" tehnisko specifikāciju izstrādē un sagatavošanā gandrīz jebkurai mācību jomai. Ir, protams, citi standarti, kurus var un vajag ievērot, bet atcerēsimies "vajadzīgo un pietiekamo".
Ar ko mēs nonākam?
Atbilde: vispārīgā darba uzdevuma struktūra, tajā skaitā programmu izstrāde.
- Kas jādara projekta ietvaros;
- Kāpēc tas ir vajadzīgs un kādiem konkrētiem mērķiem;
- Kur tiks izmantots projekta rezultāts (lasīt, programmas izstrāde), kādā darbības jomā un kādā līmenī;
- Kādas prasības jāizpilda, izstrādājot programmas;
- Kas jādara, strādājot pie projekta;
- Kā rezultātu novērtēs Pasūtītājs;
- Kādi dokumenti nosaka procedūru mijiedarbībai ar projektu;
- Kas ir par pamatu, lai uzsāktu darbu pie programmatūras izstrādes projekta.
Norādītā GOST 19.201-78 otrā daļa, kas nosaka sadaļu saturu, palīdzēs detalizētāk izstrādāt programmu izstrādes uzdevumu.
Atsevišķs mūsu specifikas punkts ir programmatūras izstrāde, vēlos izcelt programmatūras prasību sadaļu. Sastādot šo sadaļu, jautājumam būtu jāpieiet formāli. Citiem vārdiem sakot, "atvērt jaunu logu", "rediģēt pašreizējo failu, izmantojot komandas no lietotāju konsolēm" un "saglabāt izmaiņas, kad galvenais programmas logs ir aizvērts" ir skaidra un formāla pieeja.
Tāpat programmu izstrādei ir jāatbilst vairākām prasībām, kas jānorāda darba uzdevumā. Šeit ir prasību saraksts:
- uz programmas veikto funkciju kopumu;
- par ievades un izvades datu organizēšanu;
- paātrināt;
- uz darbības uzticamību;
- uz atveseļošanās ilgumu kļūmju gadījumā;
- par kļūmēm, kas radušās lietotāja nepareizas darbības dēļ;
- pakalpojumu veidiem;
- uz to personāla skaitu un kvalifikāciju, kas mijiedarbojas ar programmu;
- uz tehnisko līdzekļu parametriem, uz kuriem tiks nodrošināta normāla programmas izpilde;
- avota valodām un programmēšanas kodiem, informācijas struktūrām un trešo pušu programmatūras rīkiem;
- par aizsardzību un informācijas drošību;
- marķēšanai un iesaiņošanai;
- transportēšanas un uzglabāšanas nosacījumiem.
Tāpat programmu izstrādes prasību saraksts var tikt mainīts: papildināts vai samazināts atkarībā no konkrētajiem projekta nosacījumiem.
Kas sastāda darba uzdevumu?
Ir pienācis laiks veikt inventarizāciju. Kam būtu jāuzvelk tik smaga nasta uz saviem, protams, trauslajiem pleciem - tehnisko specifikāciju sagatavošana programmu izstrādei. Protams, projekta vadītājs! tieši šī persona ar pārmērīgu darbu paver ceļu uz Izpildītāja un Pasūtītāja kopīgu laimi, harmoniju un savstarpēju sapratni.
Likumsakarīgi, ka vadītāja darbs ir ne mazāk radošs kā programmētāja, un, lai izvairītos no radošā haosa un nekārtībām, nepieciešams arī skaidrs dizains. Noliksim savās vietās visu, kas saistīts ar projektu vadītāja funkcijām izstrādes laikā:
- Projekta uzdevuma izvirzīšana;
- Tehniskās realizācijas prasību veidošana un precizēšana;
- Prasību formulēšana izstrādātajai programmai;
- Posmu saskaņošana, to ilgums un dokumentācijas sagatavošana;
- Programmēšanas valodu un kodu norāde;
- Pasūtītāja veikto tehnisko specifikāciju sastādīšana, aktualizēšana un apstiprināšana.
Neskatoties uz šo funkciju šķietamo vienkāršību, tikai neliela daļa vadītāju spēj tās labi veikt. un, lai neviens netiktu atzīts par vainīgu, nepieciešams apstiprināt darba uzdevumu ar abu pušu pārstāvju parakstiem, ko norāda Programmu izstrādes līguma nosacījumi.
Nu šīs ballītes ir jāvadās pēc GOST 19.201-78, kas nav ne vairāk, ne mazāk, bet gandrīz 30 gadus vecs.
saistītās ziņas
Jēdziens "reversā inženierija" ir agrākā jēdziena mūsdienīgs formulējums - kopēšana, uzlabošana ... Attīstoties datortehnoloģijām, ...
Būtībā ar informāciju tehnoloģijas Cilvēce ir saskārusies un ar to saskaras katrā savas dzīves solī. Vienkārši…
Reinženierijas koncepcija radās 90. gados kā jēgpilna atbilde uz problēmām, kas radās masu automatizācijas laikā ...
17.11.2014
Jebkurš darbs sākas ar uzdevumu, un tehniskā rakstnieka darbam jāsākas ar tehnisku uzdevumu. Atliek tikai noskaidrot, kas tas ir un kāpēc mums tas ir vajadzīgs. Izlasiet Kimberlijas Čanas rakstu, lai nenokļūtu tādā pašā situācijā kā izstrādātājs no mūsu jau iemīļotās komiksu sērijas.
Kādi ir programmatūras izstrādes darba uzdevumi?
Lielākā daļa izstrādātāju dod priekšroku darbam ar programmatūras izstrādes specifikāciju, jo šajā dokumentā parasti ir ietverta šāda informācija:
- Pilns programmatūras mērķa un funkcionalitātes apraksts;
- Sīkāka informācija par to, kā programma darbosies attiecībā uz ātrumu, reakcijas laiku, pieejamību, pārnesamību, uzticamību, atkopšanas ātrumu utt.;
- Opcijas, kā lietotāji izmantos programmatūru;
- lietojumprogrammas mijiedarbības ar aparatūru vai citām programmām noteikšana;
- Nefunkcionālas prasības (piemēram, veiktspējas prasības, kvalitātes standarti vai dizaina ierobežojumi)
Kāpēc tas ir svarīgi?
TOR ļauj izstrādātājiem skaidri saprast programmatūras mērķus un to, uz ko koncentrēties. Turklāt tas:
Kā uzrakstīt TOR programmatūras izstrādei?
TOR rakstīšanai nav standarta metodes, taču mēs varam sniegt dažus padomus:
Izveidojiet shēmu
Ja jums vēl nav veidnes, tās var atrast tiešsaistē. Izmantojiet veidni, lai izveidotu dokumenta kontūru. Pārveidojiet to, lai tas atbilstu jūsu organizācijas vajadzībām.
Darba uzdevumu plāni atšķiras atkarībā no organizācijas un tās procesiem. Daži no tiem var būt vienkārši, citi ir detalizētāki un sarežģītāki.
Šeit ir vienkārša programmatūras TOR plāna piemērs:
- Piemērošanas joma
- Sistēmas pārskats
- Saites
- Definīcijas
- Lietošanas piemēri
- Funkcionālās prasības
- Nefunkcionālas prasības
Pēc plāna izveidošanas varat uzrakstīt specifikāciju. Šeit ir daži padomi:
Izvēlieties rakstīt labāk
Rakstniekam jābūt izcilām komunikācijas prasmēm. Specifikācijas mērķis ir, lai ikviens to varētu saprast. Viss, kas paliek neskaidrs vai pārprasts, var novest pie ne pārāk patīkamām sekām. Daudzi pieņem, ka tehniskā rakstnieka iesaistīšana procesā palīdz novērst pārpratumus. Ir rakstnieki, kas ir pieredzējušāki nekā izstrādātāji, kuriem ir precizitātes un skaidrības talants. Tehniskie rakstnieki zina, kā savākt un apstrādāt pareizo informāciju; viņi arī zina, kā paziņot klientu prasībām.
Padariet informāciju vizuāli
Attēls var ietaupīt 1000 vārdus. Iekļaujiet vizuālu informāciju, piemēram, tabulas un grafikus, lai labāk nodotu idejas.
Nedokumentējiet pārāk daudz
Centieties neiekļaut dokumentā vienumus, kas nav jādokumentē. TOR var kļūt pārāk garš, tāpēc izvairieties no liekas informācijas.
Izveidojiet TOR tiešsaistes versiju un atjauniniet to
Tiklīdz uzdevumi ir pabeigti vai ja notiek izmaiņas personāla vai procesos, TOR būs jāatjaunina. Šī iemesla dēļ saglabājiet virtuālo versiju — tas palīdzēs nodrošināt, ka visa komanda saņem atjauninātu dokumentu par jebkurām izmaiņām.
Š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
Darba uzdevumi ir sastādīti saskaņā ar GOST 19.106-78 uz 11. un 12. formāta lapām saskaņā ar GOST 2.301-68, kā likums, 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, tam tiek izdots papildinājums. Darba uzdevuma papildinājuma saskaņošana un apstiprināšana notiek tādā pašā veidā, kā noteikts darba uzdevumā.
Sākotnējā izstrādes stadijā nav iespējams ņemt vērā visas detaļas. 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ācija, teksta sadalīšana struktūrvienībās, apakšnodaļās, rindkopās un apakšpunktos. 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 2004.gada 15.marta Līgums (vēstule u.c.) Nr.666 (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 OAO Supersoft Bļumkins ģenerāldirektors Ivans Aronovičs, turpmāk tekstā Būvuzņēmējs, par tādu un tādu martu. 2008. gads.
Ir ērti izmantot GOST 34.602-89 sadaļu "Vispārīga informācija", 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.