Š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
Techninė užduotis surašytas 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.
Kramskoy Roman IT-09-2
Laboratorijos Nr.3
Programinės įrangos sistemos reikalavimų formalizavimas naudojant naudojimo atvejo diagramą
Tikslas : išmokti analizuoti ir formalizuoti klientų reikalavimus naudojant UML, planuoti darbus ir sudaryti techninės įrangos produkto kūrimo techninę užduotį.
Darbo eiga
Studijuoti teorinę informaciją.
Atlikti kliento reikalavimų programinio produkto kūrimui analizę ir formalizavimą pagal individualią užduotį.
Sukurkite naudojimo atvejo diagramą ir užpildykite naudojimo atvejo aprašymą.
Atlikti programinio produkto kūrimo darbų planavimą.
Parengti programinės įrangos produkto kūrimo technines užduotis.
Padarykite išvadas apie programinės įrangos produkto kūrimo modelio pasirinkimą.
Reikalavimai darbo turiniui
Darbo pavadinimas.
Tikslas.
Individualios užduoties formulavimas.
Naudojimo atvejų schema su jos aprašymu (ypatingą dėmesį atkreipkite į naudojimo atvejų ir programinės įrangos sistemos vartotojų vaidmenų aprašymo išsamumą).
Programinės įrangos produkto kūrimo techninės sąlygos (ypatingą dėmesį atkreipkite į programinės įrangos produkto kūrimo darbų planavimą, etapų formulavimą naudojant žodyno terminus ir visą dalykinę sritį, taip pat programinės įrangos naudotojų vaidmenų apibūdinimą sistema).
Išvados apie programinės įrangos produkto kūrimo modelio pasirinkimą.
Techninė užduotisplėtrai„PMC užaeksperimentinių duomenų apdorojimo ir aproksimavimo automatizavimas»
Plėtros priežastys
Kūrimo pagrindas – baigiamojo darbo „PMC eksperimentinių duomenų apdorojimo ir aproksimavimo automatizavimui“ tema ir dėstytojų disciplina.
Specialioji dalis: Skiriamųjų tinklelių atpažinimo ir aproksimacijos programinės įrangos kūrimas.
Plėtros tikslas
Programinės įrangos paketas skirtas eksperimentiniams duomenims apdoroti ir aproksimuoti ir turi atlikti šias funkcijas:
Atpažinti vaizdą;
Atlikti vaizdo išlyginimą;
Pasirinkite dalijimo mazgus.
Programinės įrangos gaminio reikalavimai
Diegiant ir naudojant informacinę sistemą reikia atsižvelgti į funkcinių charakteristikų, projekto patikimumo, techninės įrangos parametrų, informacijos ir programinės įrangos suderinamumo reikalavimus.
Atlikimo reikalavimai
Programinės įrangos paketas turi atlikti šias funkcijas:
Vaizdo atpažinimas (raiška ne mažesnė nei 600×300 DPI);
Skiriamųjų mazgų parinkimas (ne daugiau 1000 mazgų) ;
Skiriamųjų mazgų koordinačių skaičiavimas (0,01 mm tikslumu);
Duomenų masyvo formavimas (ne ilgiau kaip 30 sekundžių);
Vaizdo išlyginimas (2 ar daugiau aproksimavimo metodų, priklausomai nuo kreivių ar paviršių);
Rezultato išsaugojimas (daugiau nei 3 formatai).
Patikimumo reikalavimai
Programinės įrangos produktas turi veikti stabiliai ir nesukelti operacinės sistemos gedimų kritinėse situacijose. Gedimo atveju turėtų būti siunčiami teisingi pranešimai, nurodantys tolesnius veiksmus. Norint išvengti klaidų, būtina turėti PMK veikimo vadovą.
Programinės įrangos produktas turi užtikrinti įvesties ir išvesties informacijos kontrolę, kad atitiktų nurodytus duomenų formatus.
Programinės įrangos produktas turi užtikrinti klaidingų vartotojo veiksmų apdorojimą, išduodant atitinkamus pranešimus.
Patikimas kuriamo PMC veikimas bus užtikrintas naudojant modernius kompiuterius, griežtai laikantis rekomendacijų. Draudžiama ištrinti bet kokius projekto failus, prieiga prie jų turi būti apribota.
Lentelių atsarginės kopijos turėtų būti sukurtos, kad prireikus jas būtų galima atkurti.
Veikimo sąlygos
Eksploatavimo sąlygos turi atitikti sanitarinius ir techninius kompiuterių veikimo standartus. Dirbti su kompiuteriu leidžiami darbuotojai, turintys pakankamai žinių toje srityje. Šiam programinės įrangos paketui valdyti reikalingas 1 asmuo.
Techninių priemonių sudėties ir parametrų reikalavimai
Minimalūs programinės ir techninės įrangos reikalavimai normaliam programos veikimui:
Procesorius: AMD arba Intel, kurio dažnis yra 1 GHz ar didesnis;
RAM: 256 Mb ir daugiau;
OS: Windows XP ir naujesnė versija;
Monitorius: SVGA monitorius;
HDD talpa: laisvos vietos ne mažiau 500 Mb;
Kiti reikalavimai: tinklo plokštė, klaviatūra, pelė.
Informacijos ir programinės įrangos suderinamumo reikalavimai
Programinės įrangos sistema veikia naudojant „Windows XP“ ir naujesnes versijas. Programinės įrangos produktas sukurtas naudojant Sharp C programų kūrimo įrankį.
Dokumentacijos programos reikalavimai
Preliminari programos dokumentacijos sudėtis nustatoma pagal GOST 19.101-77. Žemiau pateikiamas programos dokumentų ir jų turinio sąrašas.
Programos tekstas yra programos įrašas su reikalingais paaiškinimais ir komentarais.
Programos aprašymas – informacija apie programos loginę struktūrą ir veikimą.
Testavimo programa ir metodika yra reikalavimai, kuriuos reikia patikrinti testuojant programą, taip pat kontrolės tvarka ir metodai.
Techninės užduotys – šis dokumentas.
Aiškinamasis raštas – algoritmo schema, bendras algoritmo ar programos veikimo aprašymas, taip pat priimtų techninių ir techninių bei ekonominių sprendimų pagrindimas.
Eksploatacijos dokumentai - programos aprašymas, vartotojo vadovas.
Etapai ir raidos etapai
Kūrimas atliekamas keliais etapais pagal GOST 19.101-77 ir apima etapus, parodytus 1.5 lentelėje.
Lentelė – Vystymo etapai
|
Terminas | ||
|
Techninė užduotis |
Programinės įrangos reikalavimų analizė ir įforminimas, darbų planavimas |
|
|
Preliminarus dizainas |
Programinės įrangos projektavimo išankstinis projektavimas naudojant UML: naudojimo atvejų diagramos, klasių diagramos ir sekos diagramos |
|
|
Techninis projektas |
Darbinės programinės įrangos versijos su pagrindine funkcija diegimas; testavimas |
|
|
darbo juodraštis |
Programinės įrangos taisymas ir papildymas; dokumentacijos rengimas |
|
|
Įgyvendinimas |
Programinės įrangos diegimo ir priežiūros priemonių kūrimas |
Kontrolės ir priėmimo tvarka
Eksperimentinių duomenų apdorojimo ir aproksimavimo darbų automatizavimo PMC turi atitikti užsakovo keliamus reikalavimus ir atitikti visus keliamus funkcinius reikalavimus.
Programinės įrangos gaminio valdymas atliekamas tokia tvarka.
– sukurtos programinės įrangos funkcionalumo tikrinimas;
– programos reakcijos į įvairius vartotojo veiksmus tikrinimas;
– išvesties duomenų patikrinimas;
– išėjus iš programos operacinė sistema turėtų ir toliau tinkamai veikti.
Sukurtos sistemos pritaikymas susideda iš jos testavimo darbo vietoje po programinės įrangos produkto nustatymo.
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. Sukūrimo sąlygos automatizuota sistema. Š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ą;
- prie parametrų techninėmis priemonėmis, kuris užtikrins normalų programos veikimą;
- š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 ...
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 Reikalavimai techninių priemonių sudėčiai ir parametrams………………………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“.