Š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ā.
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ādiem un tādiem. 2008. gada marts.
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.
Kramskoy romiešu IT-09-2
Laboratorijas Nr.3
Programmatūras sistēmas prasību formalizēšana, izmantojot lietošanas gadījumu diagrammu
Mērķis : iemācīties analizēt un formalizēt klientu prasības, izmantojot UML, veikt darba plānošanu un izstrādāt darba uzdevumu programmatūras produkta izveidei.
Darba gaita
Studiju teorētiskā informācija.
Veikt klienta prasību analīzi un formalizāciju programmatūras produkta izstrādei atbilstoši individuālajam uzdevumam.
Izstrādājiet lietošanas gadījumu diagrammu un aizpildiet lietošanas gadījuma aprakstu.
Veikt darba plānošanu programmatūras produkta izveidei.
Izstrādāt darba uzdevumu programmatūras produkta izveidei.
Izdarīt secinājumus par modeļa izvēli programmatūras produkta izveidei.
Prasības darba saturam
Amata nosaukums.
Mērķis.
Individuāla uzdevuma formulēšana.
Lietošanas gadījumu diagramma ar tās aprakstu (īpašu uzmanību pievērsiet lietošanas gadījumu un programmatūras sistēmas lietotāju lomu apraksta pilnīgumam).
Programmatūras produkta izveides darba uzdevums (īpašu uzmanību pievērsiet programmatūras produkta izveides darba plānošanai, posmu formulēšanai, izmantojot glosārija terminus un priekšmetu jomu kopumā, kā arī programmatūras lietotāju lomu aprakstu sistēma).
Secinājumi par modeļa izvēli programmatūras produkta izveidei.
Tehniskais uzdevumsattīstībai"PMC priekšaeksperimentālo datu apstrādes un tuvināšanas automatizācija»
Attīstības iemesli
Izstrādes pamatā ir individuālā uzdevuma tēma promocijas darbam "PMC eksperimentālo datu apstrādes un aproksimācijas automatizācijai" un mācībspēku disciplīna.
Speciālā daļa: Programmatūras izstrāde sadalošo režģu atpazīšanai un tuvināšanai.
Attīstības mērķis
Programmatūras pakotne ir paredzēta eksperimentālo datu apstrādei un tuvināšanai, un tai jāveic šādas funkcijas:
atpazīt attēlu;
Veikt attēla izlīdzināšanu;
Atlasiet dalīšanas mezglus.
Prasības programmatūras produktam
Ieviešot un izmantojot informācijas sistēmu, jāņem vērā prasības attiecībā uz funkcionāliem raksturlielumiem, projekta uzticamību, aparatūras parametriem, informācijas un programmatūras savietojamību.
veiktspējas prasības
Programmatūras pakotnei ir jāveic šādas funkcijas:
Attēlu atpazīšana (izšķirtspēja ne mazāka par 600×300 DPI);
Sadalošo mezglu izvēle (ne vairāk kā 1000 mezgli) ;
Dalīšanas mezglu koordinātu aprēķināšana (ar precizitāti 0,01 mm);
Datu masīva veidošana (ne vairāk kā 30 sekundes);
Attēla izlīdzināšana (2 vai vairākas tuvināšanas metodes atkarībā no līknēm vai virsmām);
Rezultāta saglabāšana (vairāk nekā 3 formāti).
Uzticamības prasības
Programmatūras produktam ir jādarbojas stabili, un tas ārkārtas situācijās nedrīkst izraisīt operētājsistēmas kļūmes. Kļūmes gadījumā jāizdod pareizi ziņojumi, norādot turpmākās darbības. Lai novērstu kļūdu rašanos, ir nepieciešama PMK darbības rokasgrāmata.
Programmatūras produktam ir jānodrošina ievades un izvades informācijas kontrole, lai nodrošinātu atbilstību noteiktiem datu formātiem.
Programmatūras produktam ir jānodrošina kļūdainu lietotāja darbību apstrāde ar atbilstošu ziņojumu izsniegšanu.
Izstrādātā PMC uzticama darbība tiks nodrošināta, izmantojot mūsdienīgus datorus, stingri ievērojot ieteikumus. Aizliegts dzēst jebkādus projekta failus, piekļuve tiem ir jāierobežo.
Tabulas jādublē, lai vajadzības gadījumā tās varētu atjaunot.
Ekspluatācijas apstākļi
Ekspluatācijas apstākļiem jāatbilst sanitārajiem un tehniskajiem standartiem datoru darbībai. Darbs ar datoru ir atļauts darbiniekiem ar pietiekamu zināšanu līmeni attiecīgajā jomā. Lai darbinātu šo programmatūras pakotni, ir nepieciešama 1 persona.
Prasības tehnisko līdzekļu sastāvam un parametriem
Minimālās prasības programmatūrai un aparatūrai lietojumprogrammas normālai darbībai:
Procesors: AMD vai Intel ar frekvenci 1 GHz vai augstāku;
RAM: 256 Mb un vairāk;
OS: Windows XP un jaunāka versija;
Monitors: SVGA monitors;
HDD ietilpība: brīva vieta ne mazāk kā 500 Mb;
Citas prasības: tīkla karte, tastatūra, pele.
Prasības informācijas un programmatūras saderībai
Programmatūras sistēma darbojas operētājsistēmā Windows XP un jaunākās versijās. Programmatūras produkts ir izveidots, izmantojot Sharp C lietojumprogrammu izstrādes rīku.
Dokumentācijas programmas prasības
Programmas dokumentācijas provizoriskais sastāvs ir noteikts saskaņā ar GOST 19.101-77. Zemāk ir saraksts ar programmas dokumentiem un to saturu.
Raidījuma teksts ir programmas ieraksts ar nepieciešamajiem paskaidrojumiem un komentāriem.
Programmas apraksts - informācija par programmas loģisko uzbūvi un darbību.
Pārbaudes programma un metodika ir prasības, kas jāpārbauda, testējot programmu, kā arī kontroles procedūra un metodes.
Darba uzdevums – šis dokuments.
Paskaidrojums - algoritma shēma, vispārīgs algoritma vai programmas darbības apraksts, kā arī pieņemto tehnisko un tehnisko un ekonomisko risinājumu pamatojums.
Darbības dokumenti - aplikācijas apraksts, lietotāja rokasgrāmata.
Posmi un attīstības stadijas
Izstrāde tiek veikta vairākos posmos saskaņā ar GOST 19.101-77 un ietver 1.5. tabulā norādītos posmus.
Tabula - Attīstības posmi
|
Nodošanas laiks | ||
|
Tehniskais uzdevums |
Programmatūras prasību analīze un formalizēšana, darba plānošana |
|
|
Sākotnējais dizains |
Programmatūras izstrādes iepriekšēja izstrāde, izmantojot UML: lietošanas gadījumu diagrammas, klašu diagrammas un secības diagrammas |
|
|
Tehniskais projekts |
Programmatūras darba versijas ar galveno funkcionalitāti ieviešana; testēšana |
|
|
darba projekts |
Programmatūras labošana un pabeigšana; dokumentācijas izstrāde |
|
|
Īstenošana |
Programmatūras ieviešanas un uzturēšanas pasākumu izstrāde |
Kontroles un pieņemšanas procedūra
Eksperimentālo datu apstrādes un tuvināšanas darba automatizēšanas PMC ir jāatbilst pasūtītāja prasībām un jāatbilst visām izvirzītajām funkcionālajām prasībām.
Programmatūras produkta kontrole tiek veikta šādā secībā.
– izstrādātās programmatūras funkcionalitātes pārbaude;
– pārbaudīt programmas reakciju uz dažādām lietotāja darbībām;
– izejas datu pārbaude;
– pēc iziešanas no programmas operētājsistēmai jāturpina darboties pareizi.
Izveidotās sistēmas pieņemšana sastāv no tās testēšanas darba vietā pēc programmatūras produkta uzstādīšanas.
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 norādī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ā to izdarīt 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 izveidei automatizēta sistēma. Š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 parametriem tehniskajiem līdzekļiem, kas nodrošinās normālu programmas darbību;
- 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ā ...
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 tehnisko līdzekļu sastāvam un parametriem………………………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 iespējā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.