Techninė užduotis (TOR) – originalus dokumentas, kuris yra programos kūrimo ir testavimo pagrindas arba automatizuota sistema. Programos ir programinės įrangos techninė užduotis parengta pagal reikalavimus. TK kūrimo pagrindas dažniausiai yra sutartis.
Programos TOR visų pirma sukurtas tiems žmonėms, kurie vėliau kurs programinės įrangos produktą. Kaip ir bet kuris kitas programos TOR, jis turi būti itin aiškus ir be dviprasmiškų formuluočių bei turėtų kuo išsamiau aprašyti visus Užsakovo reikalavimus ir pageidavimus kuriamai programai, tačiau nepamirškite, kad programuotojai yra kūrybingi žmonės ir jiems ne visada lengva įvaldyti 150 lapų techninio teksto.pagal galią.
Kam patikėti programos techninių specifikacijų rašymą
Norėčiau atkreipti dėmesį į dažnai pasitaikančią klaidą – programinės įrangos produkto techninės užduoties rašymą patikėti programuotojui, argumentuojant, kad vėliau programuotojui bus lengviau įgyvendinti savo techninę užduotį.
Programos technines užduotis turėtų parengti techninis autorius! Pirma, be žinių apie GOST 19.201-78, būtina žinoti ir kitus standartus (pavyzdžiui, GOST 19.106-78, GOST 19.104 - 78 ir kt.), nedaug programuotojų žino šiuos GOST, o dar mažiau sutiks. studijuoti juos. Antra, reikalingos techninės rašytinės kalbos žinios ir patirtis (nepainioti su programinės įrangos kodo rašymu). Trečia, tik bendradarbiaujanti komanda (techninis rašytojas, programuotojas, projektų vadovas) galės sukurti visą techninė užduotis programai ir programinei įrangai.
Techninės užduoties struktūra
MOKSLO IR ŠVIETIMO MINISTERIJA
RUSIJOS FEDERACIJA
SEI HPE „ADIGĖS VALSTYBĖS UNIVERSITETAS“
FIZIKOS FAKULTETAS
DEPARTAMENTAS ASOIU
PROGRAMINĖS ĮRANGOS KŪRIMO SĄLYGOS
PRODUKTAS
ĮVADAS…………………………………………………………………………. ... 3
1. PLĖTROS PAGRINDAS…………………………………………….. ...…4
1.1. Dokumentas, kurio pagrindu vykdoma plėtra…………………………..4
1.2. Organizacija, patvirtinusi kūrimo pagrindą, ir jos patvirtinimo data4
1.3. Plėtros temos pavadinimas…………………………………………………….4
2. PLĖTROS TIKSLAS………………………………………………………..5
2.1 Programos veiksmingumo ir kokybės kriterijai…………………………………..5
5
3. REIKALAVIMAI PROGRAMAI………………………………………………………6
3.1 Veiklos reikalavimai……………………………….6
3.1.1 Atliekamų funkcijų sudėtis…………………………………………………….6
3.1.2 Įvesties ir išvesties duomenų organizavimas……………………………………….6
3.1.3 Laiko charakteristikos ir atminties dydis………………………6
3.2 Patikimumo reikalavimai………………………………………………………….…6
3.2.1 Reikalavimai patikimam veikimui…………………………………6
3.2.2 Įvesties ir išvesties informacijos valdymas…………………………………..7
3.2.3 Atkūrimo laikas po gedimo………………………………………..7
3.3 Eksploatavimo sąlygos……………………………………………………………………………………………
3.4 Sudėčiai ir parametrams keliami reikalavimai techninėmis priemonėmis…………………...7
3.5 Reikalavimai programavimo kalboms……………………………………….8
3.6 Programos naudojamai programinei įrangai keliami reikalavimai………8
3.7 Reikalavimai programinės įrangos dokumentacijai………………………………………… 8
4. TECHNINIAI IR EKONOMINIAI RODIKLIAI…………………………… ..... 9
5. PLĖTROS ETAPAI IR ETAPAI………………………………………………..9
6. KONTROLĖS IR PRIĖMIMO TVARKA………………………………………………9
6.1 Bandymų tipai…………………………………………………………………..9
6.2 Bendrieji reikalavimai iki priėmimo………………………………………………………………………………………………
7. ĮGYVENDINIMO ETAPAI……………………………………………………………......10
ĮVADAS
Visas programinės įrangos kūrimo pavadinimas: „Programa K“, toliau – „programa“. Trumpas programos pavadinimas yra „PC“.
Šiuo metu nėra panašių programinės įrangos produktų.
Sukurta programa taikoma bet kurioje įmonėje, kurioje yra dirbantis personalas.
Šio programinės įrangos produkto kūrėjas yra 4A1 grupės studentas Ivanovas A.V. toliau – kūrėjas.
Programinės įrangos produkto klientas yra OJSC RTS, atstovaujama direktoriaus A.M. Gutenko.
1 PLĖTROS PAGRINDAS
1.1 Dokumentas, kurio pagrindu vykdoma plėtra
Darbas atliekamas pagal disciplinos užduotį " Teorinis pagrindas automatizuotas valdymas»
1.2 Patvirtinanti organizacija ir šio dokumento patvirtinimo data
Užduotį patvirtino ir išdavė RTS OJSC techninio skyriaus vadovas A. V. Kozakovas.
Kozakovas A.V.
1.3 Vystymo temos pavadinimas
Plėtros temos pavadinimas – „Darbo laiko apskaita“.
2 PLĖTROS TIKSLAS
Ši plėtra yra semestro darbas disciplinoje „Automatinio valdymo teoriniai pagrindai“
2.1 Programos efektyvumo ir kokybės kriterijai
socialinis veiksnys.Šią programinę įrangą labai lengva išmokti ir ji skirta ne tik profesionalams, bet ir paprastiems vartotojams, dirbantiems Windows sistemoje. Patogi, intuityvi sąsaja kartu su galinga pagalbinių paveikslėlių ir patarimų sistema leidžia dirbti su programa be išankstinio pasiruošimo.
Atitiktis esamai šio profilio programinės įrangos rinkos būklei. Kitaip nei brangios ir sudėtingos programos, kompiuteris idealiai tinka verslo atstovams, nes jame yra viskas, ko jiems reikia, tačiau jis nėra perkrautas nenaudingomis ir nereikalingomis funkcijomis. Programos kūrimo vizualinio programavimo aplinkoje technologija daro jos sąsają universalią ir suderinamą su Operacinės sistemos Windows 95/98/2000/XP.
Ekonominės jėgos. Programa reprezentuoja geriausią kainos ir jai teikiamų funkcijų santykį ir neabejotinai užims savo nišą pigių programų rinkoje. Pagrindiniai vartotojai bus verslo atstovai, kurie tiesiog negali mokėti už brangias programas iš 1C ir panašiai.
2.2 Programos kūrimo tikslai
Kuriant šią programą siekiama kelių techninių ir ekonominių tikslų:
Programinės įrangos produkto, reikalingo darbo valandų fiksavimui, sukūrimas.
Sukurti pigią alternatyvą šiuo metu esamoms brangioms programoms.
Sukurkite intuityvią programą naudodami patogią ir universalią „Windows“.
Nuolat girdime apie technines užduotis, jų svarbą ir teisingą kompiliavimą. Svetainių kūrimo techninė užduotis, projektavimo projektų techninė užduotis, programinės įrangos kūrimo techninė užduotis, techninė užduotis šiam tikslui, techninė užduotis šiam tikslui ... Ar tai tikrai taip svarbu, techninė užduotis, pažįstama kaip TK? Ir išsiaiškinkime!
Pavyzdžiui, išskirkime vieną iš labiausiai paplitusių sričių – programų rengimo techninės užduoties rengimą. Ir galbūt pamažu pradėsime atsakyti į kylančius klausimus.
Kodėl techninė užduotis?
Atsakant į klausimą "kodėl?" Svarbu suprasti, kas iš tikrųjų sakoma. Kaip jau buvo nurodyta aukščiau, kaip techninės užduoties rengimo pavyzdys buvo pasirinktas programų kūrimas. O tai reiškia, kad įmonė, įmonė, organizacija turi realias esamas, esamas užduotis, kurias galima ir reikia spręsti efektyviau, nei tai daroma šiuo metu. Kitaip tariant, brangų ir įvairios kokybės žmonių darbą būtina pakeisti efektyviu ir daug pigesniu programiniu darbu.
Iš tiesų, darbuotojams reikia atostogų, jie visi nori laiku gauti atlyginimą darbo užmokesčio, periodiškai „išeiti į nedarbingumo atostogas“ ir, kaip taisyklė, nereikšti noro dirbti savaitgaliais. Programų kūrimas, priešingai, ne tik nesukelia nurodytų problemų, pavydėtinu reguliarumu pakeisdamas viena kitą, bet, priešingai, jas išsprendžia!
Pažvelkime atidžiau į sprendimus. Kadangi dabartinių problemų, kurias reikia išspręsti per programinę įrangą, sąrašas jau yra sudarytas, laikas pagalvoti apie patį sprendimo procesą. Susirenkame, sėdime, ginčijamės, išsiaiškiname, o galų gale, štai, daugmaž bendra atsakingų asmenų nuomonė, ką veiks būsima programa. Taip lėtai, bet užtikrintai gimsta prielaida parengti programų kūrimo techninę užduotį.
Žinoma, viskas gali būti visiškai kitokia. Techninės užduoties rengimą patikime programų kūrimą siūlančios įmonės specialistams. Pora susitikimų dalykiškoje, bet draugiškoje atmosferoje, paruoštos trumputės, blankai, sutartys, anketos. Viskas baigta ir visi laimingi. Bent jau kol kas.
Savininkas, kaip sakoma, yra džentelmenas, visada gali laisvai pasirinkti geriausią variantą tiek kainos, tiek kokybės atžvilgiu. Žinoma, idealu, kad abu būtų proporcingi, bet visada reikia eiti į kompromisus. Jei kaina yra per maža, programinės įrangos kūrimo kompromisas natūraliai pereina į staigų programinės įrangos kokybės pablogėjimą. Tačiau paradoksalu, bet tas pats atsitinka ir su neraštingu programų kūrimo techninių specifikacijų rengimu. Pinigai sumokėti, prekė gauta, veikia, bet ne taip.
Tiesą sakant, atsakymas į klausimą, kodėl reikia parengti kompetentingą techninę užduotį programoms kurti, yra akivaizdus. Pirmyn.
Kam skirta specifikacija?
Programų rengimo sąlygos pirmiausia sudaromos tiems žmonėms, kurie vykdys šią plėtrą. Atitinkamai, žmogui, kuris nieko nežino apie klientą, o juo labiau – apie jo užduotis ir problemas, turėtų būti aišku. Bent jau jis dar nežino.
Vadinasi, programų rengimo sąlygos rangovui turėtų pasakyti apie įmonę, tikslus ir užduotis. Tuo pačiu, kuo konkretesnė istorija, tuo geriau – tiek pasakotojui, tai yra Užsakovui kuriant programas, ir klausytojui, tai yra projekto vykdytojui.
Apskritai techninė užduotis turi keletą tikslų, ir nors tai galėjo būti pasakyta pačioje pradžioje, ištaisyti trūkumus niekada nevėlu. Taigi, tikslai:
- Organizacija
- Informacija
- Bendravimas
- Jurisdikcija.
Organizacija turėtų būti nukreipta į patį procesą, kitaip tariant, racionalizuoti programos ar programinės įrangos paketo kūrybiškumą ir kūrimą. Griežtai tariant, programų rengimo techninių užduočių struktūra turėtų būti aiški ir glausta. Perskaičius 120-150 ar net daugiau puslapių nesuvirškinamo techninio teksto, programuotojo kūrybinga asmenybė tiesiog negali. Taigi trumpumas yra talento sesuo.
Informacinis TOR komponentas turėtų būti išsamus, bet glaustas.
Ir vėl paprasta taisyklė „būtina ir pakanka“. Jos, kaip įprasta, reikia laikytis visada ir visur, tačiau rengiant programų kūrimo techninę užduotį ši taisyklė tampa svarbiausia. Kompetentinga techninė užduotis yra pirmasis ir paskutinis dokumentas, kuriame programuotojui lengvai suprantama forma papasakos apie visus kliento pageidavimus. Ar norite paversti savo įmonės ar įmonės gyvenimą iš esmės nauju lygiu? Tada programų kūrimo užduotys yra pats atramos taškas, kuriuo pasaulis pasisuks jūsų nurodyta kryptimi. Ir to, matote, jokiu būdu negalima pamiršti.
Bendravimas yra šiek tiek sunkesnis. Kodėl? Taip, nes bendravimas ir netgi gana kūrybiniame procese visada yra sudėtingas. Ypač jei kalbi skirtingomis kalbomis. Ir čia gali būti kelios kalbos, tiksliau – pagal projekto dalyvių skaičių, kodiniu pavadinimu „programinės įrangos kūrimas“.
Paprasčiau pasakius:
- Klientas, jis yra Klientas
- Projekto vadovas
- Projekto vykdytojai, jie arba jis: programuotojas (-ai)
- Kiti galimi dalyviai, turintys nuomonę: kaip tai padaryti, kaip tai padaryti geriau ir kuo tai turėtų baigtis.
Natūraliai kuriant bendras projektas, šie dalyviai priversti ieškoti visiems suprantamos kalbos. Ši kalba yra skirta programų kūrimo užduotims. Idealiu atveju svarbiausia yra sukurti ryšio kanalą tarp pirmosios ir trečiosios nuorodos ir kuo mažiau trukdžių įveda antroji ir ketvirtoji nuorodos, tuo geresnis bus rezultatas, o programų kūrimas duos norimą rezultatą su minimaliu nervų praradimu. .
Taigi mes priėjome prie jurisdikcijos, beje, palietę „nervų praradimo“ klausimą. Techninės užduoties dėka galima spręsti apie programų kūrimo rezultato ir pateiktų pradinių sąlygų atitikimą. Reikia pasakyti, kad trumpalaikė atmintis nukenčia ir projekto užsakovams, ir vykdytojams. Pirmieji pamiršta sutartą kainą, pakeitimų skaičių, diegimo ir derinimo galimybes, o antrieji – iš esmės, ką ir kada turėjo padaryti. Norint sumažinti amneziją ir jos pasekmes iki minimumo, vėlgi būtinas aiškus ir konkretus TOR programoms kurti!
Kaip parašyti techninę užduotį?
Įsitikinus programų kūrimo techninės užduoties būtinumu ir net neįkainojamumu, pokalbį galime tęsti toliau. Dabar priėjome prie rimčiausio klausimo: kaip sudaryti TOR, kad jis būtų kompetentingas, aiškus, glaustas, bet konkretus ?! Ir mums nieko daugiau nereikia.
Tuo buvo pasirūpinta dar senovėje SSRS, sukūrus visą standartų koncepciją, vadinamą GOST. Stebėtina, kad programų kūrimas, šie standartai taip pat numato, kad sutiksite, negalite džiaugtis.
Programų rengimą ir techninių užduočių rengimą šioje srityje reglamentuoja GOST 19.201-78 viena sistema programinės įrangos dokumentacija. Techninė užduotis. Reikalavimai turiniui ir dizainui.
Be to, dar du vadovai nebus nereikalingi:
- GOST 2.114-95 Vieninga projektinės dokumentacijos sistema. Specifikacijos;
- GOST 34.602-89 informacinės technologijos. Automatizuotų sistemų standartų rinkinys. Automatizuotos sistemos sukūrimo techninė užduotis. Šią trejybę, žinoma, galima laikyti „šventųjų šventąja“ kuriant ir rengiant technines specifikacijas beveik bet kuriai temai. Žinoma, yra ir kitų standartų, kuriais galima ir reikia vadovautis, bet prisiminkime „būtina ir pakankamai“.
Kuo mes baigiame?
Atsakymas: bendra techninių užduočių struktūra, įskaitant programų kūrimą.
- Ką reikia padaryti įgyvendinant projektą;
- Kodėl to reikia ir kokiais konkrečiais tikslais;
- Kur bus panaudotas projekto rezultatas (skaitymas, programos kūrimas), kokioje veiklos srityje ir kokiu lygiu;
- Kokius reikalavimus turi tenkinti kuriant programas;
- Ką reikia padaryti dirbant su projektu;
- Kaip rezultatą įvertins Klientas;
- Kokie dokumentai nustato sąveikos su projektu tvarką;
- Koks yra pagrindas pradėti darbą su programinės įrangos kūrimo projektu.
Antroji nurodyto GOST 19.201-78 dalis, kurioje nurodomas skyrių turinys, padės išsamiau parengti programų kūrimo užduotis.
Atskiras mūsų specifikos punktas yra programinės įrangos kūrimas, norėčiau pabrėžti programinės įrangos reikalavimų skyrių. Sudarant šį skyrių į klausimą reikėtų žiūrėti formaliai. Kitaip tariant, „atidaryti naują langą“, „redaguoti dabartinį failą komandomis iš vartotojo pultų“ ir „išsaugoti pakeitimus, kai pagrindinis programos langas uždaromas“ yra aiškus ir formalus požiūris.
Taip pat programų kūrimas turi atitikti daugybę reikalavimų, kurie turi būti nurodyti techninėje užduotyje. Čia yra reikalavimų sąrašas:
- į programos atliekamų funkcijų rinkinį;
- dėl įvesties ir išvesties duomenų organizavimo;
- pagreitinti;
- į veikimo patikimumą;
- į atkūrimo trukmę gedimų atveju;
- apie gedimus dėl neteisingų vartotojo veiksmų;
- į paslaugų rūšis;
- personalo, bendraujančio su programa, skaičių ir kvalifikaciją;
- į techninių priemonių, kuriomis bus užtikrinamas normalus programos veikimas, parametrus;
- šaltinio kalboms ir programavimo kodams, informacijos struktūroms ir trečiųjų šalių programinės įrangos įrankiams;
- dėl apsaugos ir informacijos saugumo;
- ženklinimas ir pakavimas;
- transportavimo ir sandėliavimo sąlygas.
Taip pat programų rengimo reikalavimų sąrašas gali būti keičiamas: papildomas arba mažinamas priklausomai nuo konkrečių projekto sąlygų.
Kas rengia technines užduotis?
Atėjo laikas įvertinti. Kas turėtų užkrauti tokią sunkią naštą ant savo, be abejo, trapių pečių - techninių specifikacijų rengimui programų kūrimui. Žinoma, projekto vadovas! būtent šis žmogus pervargdamas atveria kelią bendrai Rangovo ir Užsakovo laimei, harmonijai ir tarpusavio supratimui.
Natūralu, kad vadovo darbas yra ne mažiau kūrybiškas nei programuotojo, o norint išvengti kūrybinio chaoso ir netvarkos, reikia ir aiškaus dizaino. Viską, kas susiję su projektų vadovo funkcijomis kūrimo metu, sudėkime į savo vietas:
- Projekto užduoties nustatymas;
- Techninio įgyvendinimo reikalavimų formavimas ir patikslinimas;
- Reikalavimų parengtai programai formulavimas;
- Etapų derinimas, jų trukmė, dokumentacijos rengimas;
- Programavimo kalbų ir kodų nurodymas;
- Techninių specifikacijų rengimas, atnaujinimas ir tvirtinimas Kliento.
Nepaisant iš pažiūros šių funkcijų paprastumo, tik nedidelė dalis vadovų sugeba jas gerai atlikti. ir kad niekas nebūtų pripažintas kaltu, būtina patvirtinti techninę užduotį su abiejų šalių atstovų parašais, nurodyta Programų rengimo sutarties sąlygose.
Na, o šios partijos turi vadovautis GOST 19.201-78, kuri yra nei daugiau, nei mažiau, bet beveik 30 metų.
susijusių pranešimų
Sąvoka „atvirkštinė inžinerija“ yra moderni buvusios sąvokos formuluotė – kopijavimas, tobulinimas... Tobulėjant kompiuterinėms technologijoms, ...
Iš esmės, su Informacinės technologijosŽmonija susidūrė ir susiduria kiekviename savo gyvenimo žingsnyje. Tiesiog…
Pertvarkymo koncepcija gimė 90-aisiais kaip prasmingas atsakas į problemas, iškilusias masinio automatizavimo metu ...
17.11.2014
Bet koks darbas prasideda nuo užduoties, o techninio rašytojo darbas turi prasidėti nuo techninės užduoties. Belieka tik išsiaiškinti, kas tai yra ir kodėl mums to reikia. Perskaitykite Kimberly Chan straipsnį, kad nepatektumėte į tą pačią situaciją kaip kūrėjas iš mūsų jau pamėgtos komiksų serijos.
Kokie yra programinės įrangos kūrimo įgaliojimai?
Dauguma kūrėjų nori dirbti su programinės įrangos kūrimo specifikacija, nes šiame dokumente paprastai yra:
- Išsamų programinės įrangos paskirties ir funkcionalumo aprašymą;
- Išsami informacija apie tai, kaip programa veiks, atsižvelgiant į greitį, reakcijos laiką, prieinamumą, perkeliamumą, patikimumą, atkūrimo greitį ir kt.;
- Parinktys, kaip vartotojai naudos programinę įrangą;
- Nustatyti, kaip programa sąveikaus su aparatine įranga ar kitomis programomis;
- Nefunkciniai reikalavimai (pavyzdžiui, veikimo reikalavimai, kokybės standartai arba dizaino apribojimai)
Kodėl tai svarbu?
TOR leidžia kūrėjams aiškiai suprasti programinės įrangos tikslus ir į ką atkreipti dėmesį. Be to, tai:
Kaip parašyti TOR programinės įrangos kūrimui?
Nėra standartinio TOR rašymo metodo, tačiau galime duoti patarimų:
Sukurkite schemą
Jei dar neturite šablono, juos galite rasti internete. Norėdami sukurti dokumento kontūrą, naudokite šabloną. Pakeiskite jį, kad atitiktų jūsų organizacijos poreikius.
Referencinių planų sąlygos skiriasi priklausomai nuo organizacijos ir jos procesų. Kai kurie iš jų gali būti paprasti, kiti išsamesni ir sudėtingesni.
Štai paprasto programinės įrangos TOR plano pavyzdys:
- Taikymo sritis
- Sistemos apžvalga
- Nuorodos
- Apibrėžimai
- Naudojimo pavyzdžiai
- Funkciniai reikalavimai
- Nefunkciniai reikalavimai
Sukūrę planą galite parašyti specifikaciją. Štai keletas patarimų:
Pasirinkite rašyti geriau
Rašytojas turi turėti puikius bendravimo įgūdžius. Specifikacijos tikslas – kad ją suprastų visi. Viskas, kas lieka neaišku ar nesuprasta, gali sukelti ne itin malonių pasekmių. Daugelis mano, kad techninio rašytojo įtraukimas į procesą padeda išvengti nesusipratimų. Yra rašytojų, labiau patyrusių nei kūrėjų, turinčių tikslumo ir aiškumo talentą. Techniniai rašytojai žino, kaip rinkti ir apdoroti reikiamą informaciją; jie taip pat žino, kaip pranešti apie klientų poreikius.
Padarykite informaciją vizualiai
Vaizdas gali sutaupyti 1000 žodžių. Norėdami geriau perteikti idėjas, įtraukite vaizdinę informaciją, pvz., lenteles ir grafikus.
Nedokumentuokite per daug
Stenkitės neįtraukti į dokumentą dalykų, kurių nereikia dokumentuoti. TOR gali tapti per ilgas, todėl venkite perteklinės informacijos.
Sukurkite internetinę TOR versiją ir nuolat ją atnaujinkite
Atlikus užduotis arba pasikeitus personalui ar procesams, TOR reikės atnaujinti. Dėl šios priežasties pasilikite virtualią versiją – tai padės užtikrinti, kad visa komanda gaus atnaujintą dokumentą dėl bet kokių pakeitimų.
Šis standartas nustato kompiuterių, kompleksų ir sistemų programos ar programinės įrangos produkto kūrimo techninių specifikacijų sudarymo ir vykdymo tvarką, neatsižvelgiant į jų paskirtį ir apimtį.
Standartas visiškai atitinka ST SEV 1627-79.
Dizaino taisyklės
Darbo užduotys sudaromos pagal GOST 19.106-78 11 ir 12 formato lapuose pagal GOST 2.301-68, kaip taisyklė, nepildant lapo laukų. Lapų (puslapių) numeriai užrašomi viršutinėje lapo dalyje virš teksto.
Patvirtinimo lapas ir titulinis lapas
Patvirtinimo lapas ir titulinis lapas sudaromi pagal GOST 19.104-78.
Į dokumentą negali būti įtraukta informacinė dalis (santrauka ir turinys), pakeitimų registracijos lapas.
Pakeitimai ir papildymai
Norint atlikti techninės užduoties pakeitimus ar papildymus vėlesniuose programos ar programinės įrangos produkto kūrimo etapuose, išleidžiamas jo priedas. Techninės užduoties papildymo derinimas ir tvirtinimas vykdomas taip pat, kaip nustatyta techninėje užduotyje.
Pradiniame kūrimo etape neįmanoma atsižvelgti į visas detales. Praktikoje šis metodas naudojamas gana dažnai. Skiltyje „Kūrimo etapai ir etapai“ turėtų būti aiškiai nurodyta galimybė keisti ir papildyti techninę užduotį: „Šių techninių užduočių skilčių turinys gali būti keičiamas ir papildomas susitarus su Užsakovu. “
Techninės užduoties skyrių sudėtis
Darbo užduotyse turėtų būti šie skyriai:
įvadas;
plėtros pagrindas;
plėtros tikslas;
reikalavimai programai ar programinės įrangos produktui;
reikalavimai programinės įrangos dokumentacijai;
techniniai ir ekonominiai rodikliai;
raidos etapai ir etapai;
kontrolės ir priėmimo tvarka;
į techninę užduotį leidžiama įtraukti paraiškas.
Priklausomai nuo programos ar programinės įrangos produkto savybių, leidžiama patikslinti skyrių turinį, įvesti naujas dalis arba kai kurias iš jų sujungti. Griežtai susitarus su klientu. Kliento sutikimas turi atsispindėti techninės užduoties tekste.
Kaip mokymo programą naudosime realią programą su grafine vartotojo sąsaja, kuri suteikia galimybę atlikti kelias šablono funkcijas (pavyzdžiui, paprastą teksto rengyklę).
Įvadas
Skyriuje nurodomas pavadinimas, trumpas programos ar programinės įrangos produkto apimties aprašymas ir objektas, kuriame programa ar programinės įrangos produktas yra naudojamas.
Pagrindinė darbo su tekstu taisyklė – detalizavimas, teksto skaidymas į struktūrinius vienetus, poskyrius, pastraipas ir pastraipas. Teksto turinys bus aiškios struktūros, todėl bus lengva rasti reikiamą medžiagą. Dokumento tekstas taps struktūrizuotas ir lengvai skaitomas. Sukurti poskyrius:
Programos pavadinimas
Pavadinimas – „Teksto rengyklė darbui su rtf failais“.
Trumpas taikymo srities aprašymas
Programa skirta naudoti specializuotuose skyriuose Kliento patalpose.
Atskirų daiktų turinys ne visada aiškus. Iškilus sunkumams, reikėtų kreiptis formaliai. Redaguoti galima susitarimo su Klientu etape.
Plėtros priežastys
Skyriuje turėtų būti:
dokumentas (dokumentai), kurio pagrindu vykdoma plėtra;
šį dokumentą patvirtinusi organizacija ir jo patvirtinimo data;
vardas ir (arba) simbolis plėtros temomis.
Poskyryje turi būti nurodyta Sutartyje esanti informacija.
Plėtros pagrindas
Plėtros pagrindas – 2004 m. kovo 15 d. Sutartis (laiškas ir kt.) Nr. 666 (gaunamas Nr. toks ir toks iš tokio ir tokio). Su Valstybinės vieningos įmonės „Spetstyazhmontazhstroyselkhozavtomatika“ direktoriumi Ivanovu Petru Ivanovičiumi (toliau – Užsakovas) buvo sutarta ir patvirtinta OAO „Supersoft Blyumkins“ generalinio direktoriaus Ivano Aronovičiaus (toliau – Rangovas) dėl tokių ir kitų. 2008 m. kovo mėn.
Patogu naudoti GOST 34.602-89 skiltį „Bendroji informacija“, nes kūrėjas turi visą teisę savo nuožiūra papildyti ir ištrinti techninės užduoties dalis. Kartu aukščiau nurodyta informacija yra nurodyta Sutartyje. Ar jie turėtų būti pateikti techninėje užduotyje, priklauso nuo konkretaus atvejo.