4.1. Zahtjevi za sistem u cjelini.

4.1.1. Zahtjevi za strukturu i funkcioniranje sistema.
4.1.2. Zahtjevi za brojem i kvalifikacijama osoblja sistema i načinom rada.
4.1.3. Zahtjevi za pouzdanost.
4.1.4. Sigurnosni zahtjevi.
4.1.5. Zahtjevi za ergonomiju i tehničku estetiku.
4.1.6. Zahtjevi za rad i održavanje.
4.1.7. Zahtjevi za zaštitu informacija od neovlaštenog pristupa;
4.1.8. Zahtjevi za sigurnost informacija u slučaju nezgoda.
4.1.9. Zahtjevi za zaštitu od vanjskih utjecaja.
4.1.10. Zahtjevi za čistoću patenta.
4.1.11. Svi dodatni zahtjevi.

4.2. Zahtjevi za funkcije (zadatke) koje sistem obavlja.

(popis funkcija (zadataka) koje treba automatizirati; vremenski raspored implementacije svake funkcije (zadatka); zahtjevi za kvalitetom realizacije svake funkcije (zadatka), za oblik prezentacije izlaznih informacija, za tačnost i vrijeme izvršenja, za pouzdanost izlaznih rezultata; listu i kriterijume za kvarove za svaku funkciju (zadatak) za koju su definisani zahtevi za pouzdanost)

4.3. Zahtjevi za vrste kolaterala.

4.3.1. Zahtjevi za softver sistema.

(zahtjevi za sastav, obim i metode korištenja matematičkih metoda i modela u sistemu, standardni algoritmi i algoritmi koje treba razviti)

4.3.2. Zahtjevi za podršku sistemskim informacijama.

(zahtjevi za sastav, strukturu i metode organizovanja podataka u sistemu; za razmjenu informacija između komponenti sistema; za kompatibilnost informacija sa povezanim sistemima; za korištenje sistema upravljanja bazama podataka; za strukturu procesa prikupljanja, obrade, prenošenja podatke u sistemu i predstavljanje podataka; za zaštitu podataka od uništenja tokom nesreća i nestanka napajanja sistema; praćenje, skladištenje, ažuriranje i vraćanje podataka)

4.3.3. Zahtjevi za jezičku podršku sistema.

(zahtjevi za upotrebu programskih jezika visokog nivoa, jezika interakcije korisnika i tehničkih sredstava sistema u sistemu, kao i zahtjevi za kodiranje i dekodiranje podataka, jezici za unos-izlaz podataka, jezici za manipulaciju podacima, načini opisivanja predmetno područje (informacijsko modeliranje), metode organiziranja dijaloga s korisnikom itd.)

4.3.4. Zahtjevi sistemskog softvera.

(lista licenciranih softverskih proizvoda čije je prisustvo neophodno za normalno funkcionisanje sistema)

4.3.5. Zahtjevi za tehničku podršku.

(zahtjevi za vrste tehničkih sredstava, softverskih i hardverskih sistema i drugih komponenti dozvoljenih za korištenje u sistemu; za funkcionalne, dizajnerske i operativne karakteristike sredstava tehničke podrške sistema)

4.3.6. Uslovi za organizacionu podršku.

(zahtjevi za strukturu i funkcije odjela uključenih u rad sistema ili obezbjeđenje rada; za organizaciju funkcionisanja sistema i proceduru interakcije osoblja postrojenja za automatizaciju; za zaštitu od pogrešnih radnji osoblja sistema)

G O S U D A R S T V E N N Y S T A N D A R T S O Y W A S S R

Datum uvođenja 01.01.90

Ovaj standard se primenjuje na automatizovane sisteme (AS) koji se koriste u različitim oblastima delatnosti (upravljanje, istraživanje, dizajn, itd.), uključujući njihovu kombinaciju, i utvrđuje vrste, naziv, kompletnost i oznaku dokumenata razvijenih u fazama kreiranja AS ustanovljen GOST 24.601.

Objašnjenje termina koji se koriste u ovom standardu dato je u Dodatku 1.

1. VRSTE I NAZI DOKUMENTA

1.1. Sastav tipova dokumenata razvijenih u fazi „Istraživanje i opravdanje za stvaranje AS“ utvrđuje se u skladu sa Odjeljkom. 3 GOST 24.601, na osnovu traženih rezultata ove faze.

1.2. U fazi "Zadatka" razvija se Tehnička specifikacija (TOR) za stvaranje automatiziranog sistema u skladu sa zahtjevima GOST 34.602.

Dozvoljeno je razvijanje privatnih tehničkih specifikacija za pojedinačne sisteme (podsisteme, skupove zadataka, softverske i hardverske sisteme, komponente hardvera i softvera itd.)

1.3. Vrste dokumenata razvijenih u fazama „Projekt skice“, „Tehnički projekat“, „Radna dokumentacija“ date su u tabeli. 1.

Tabela 1

1.3.1. Nazivi pojedinih dokumenata razvijenih prilikom projektovanja sistema kao celine ili njegovog dela dati su u tabeli. 2.

tabela 2

(Promijenjeno izdanje, izmjena br. 1)

napomene:

• 1. U tabeli se koriste sljedeće oznake:
  • EP - idejni projekat;
  • TP - tehnički projekat;
  • RD - radna dokumentacija;
  • ILI - rješenja za cijeli sistem;
  • OO - odluke o organizacionoj podršci;
  • TO - rješenja za tehničku podršku;
  • IO - rješenja za informatičku podršku;
  • Softver - softverska rješenja;
  • MO - softverska rješenja.
• 2. Znak X označava da pripada projektnim predračunima ili operativnoj dokumentaciji.
• 3. Nomenklatura istoimenih dokumenata utvrđuje se u zavisnosti od dizajnerskih odluka donesenih tokom kreiranja sistema

1.3.2. Vrste dokumenata za softver koji se koristi za kreiranje AS (njegovih dijelova) - prema GOST 19.101.77.

1.3.3. Vrste dokumenata za tehnička sredstva koja se koriste u stvaranju NPP (njezinih dijelova) - prema GOST 2.102 i prema GOST 2.601 u smislu operativnih dokumenata.

1.3.4. Ovisno o korištenim metodama dizajna i specifičnostima zvučnika koji se kreiraju, dozvoljeno je sljedeće:

• 1) izradi grupne i osnovne dokumente u skladu sa čl. 1, 3, 4, 6 GOST 2.113;
• 2) izdaje dokumente u posebnim samostalnim delovima koji odgovaraju odeljcima glavnog dokumenta;
• 3) proširi opseg dokumenata utvrđenih ovim standardom.

1.4. U fazama “Proizvodnja neserijskih komponenti automatizovanog sistema upravljanja” i “Puštanje u rad” razvijaju se sledeći organizacioni i administrativni dokumenti:

• 1) akt o završetku posla;
• 2) potvrdu o prijemu u probni rad;
• 3) potvrdu o prijemu u industrijski rad;
• 4) raspored rada;
• 5) nalog o sastavu prijemne komisije;
• 6) nalog za izvođenje radova;
• 7) program rada;
• 8) izveštaj o ispitivanju;
• 9) protokol o odobrenju.

2. KOMPLETNOST DOKUMENTACIJE

2.1. Spisak naziva dokumenata koji se razvijaju i njihova kompletnost za sistem i njegove delove moraju se utvrditi u tehničkim specifikacijama za izradu automatizovanog sistema (podsistema).

Bilješka. Kompletnost projektne i predračunske dokumentacije utvrđuje se u skladu sa pravilima utvrđenim sistemom projektne dokumentacije za izgradnju (SPDS).

2.2. Za svaki set mora biti sastavljena lista dokumenata.

2.3. Kompletnost dokumentacije koja osigurava razvoj, proizvodnju, prijem i ugradnju tehničke opreme u skladu je sa GOST 2.102. Kompletnost operativne dokumentacije za ova sredstva je u skladu sa GOST 2.601.

2.4. Kompletnost dokumentacije za kompjuterski softver je u skladu sa GOST 19.101.77.

2.5. Prilikom samostalnog razvoja dijela sistema, dokumenti za njega se popunjavaju u skladu sa zahtjevima ovog standarda.

3. SIMBOLI DOKUMENTA

3.1. Svaki izrađeni dokument mora dobiti nezavisnu oznaku. Dokument koji se izrađuje na različitim nosiocima podataka mora imati istu oznaku. Oznaci dokumenata napravljenih na kompjuterskim medijima dodaje se slovo „M“.

Posuđeni dokumenti zadržavaju prethodno dodijeljene oznake.

3.2. Ova pravila se ne odnose na dokumente čija su pravila označavanja regulisana državnim standardima drugih dokumentacionih sistema.

3.3. Notacija dokumenta ima sljedeću strukturu:

Pre>___________
|___________|. XX. XX. X- X. M
Oznaka sistema | | | | | |
(dijelovi sistema) | | | | | |
Šifra dokumenta | | | | |
Serijski broj jednog dokumenta | | | |
imena | | | |
Broj revizije dokumenta | | |
Broj dijela dokumenta | |
Oznaka dokumenta izrađenog mašinski |
mediji |

3.3.1. Pravila za određivanje sistema (dijela sistema) data su u Dodatku 2.

3.3.2. Šifra dokumenta sastoji se od dva alfanumerička znaka. Šifra dokumenata definisanih ovim standardom upisuje se u skladu sa kolonom 3 tabele. 2. Šifra dodatnih dokumenata formira se na sljedeći način: prvi znak je slovo koje označava vrstu dokumenta prema tabeli. 1, drugi znak je broj ili slovo koje označava serijski broj dokumenta ove vrste.

Šifra dokumenta je tačkom odvojena od prethodne oznake.

3.3.3. Redni brojevi dokumenata jednog naziva (2 znaka) dodeljuju se počevši od drugog i odvojeni od prethodne oznake tačkom.

3.3.4. Broj revizije dokumenta se dodjeljuje počevši od druge u rastućem redoslijedu od 2 do 9, a od prethodne vrijednosti je odvojen tačkom. Broj sljedećeg izdanja se dodjeljuje u slučajevima kada se prethodno izdanje zadržava (ne poništava).

3.3.5. Broj dijela dokumenta je odvojen od prethodne oznake crticom. Ako se dokument sastoji od jednog dijela, crtica se ne ubacuje i ne dodjeljuje se broj dijela dokumenta.

3.3.6. Po potrebi se upisuje atribut dokumenta koji se izvršava na računarskom mediju. Slovo “M” je tačkom odvojeno od prethodne oznake.

DODATAK 1
Informacije

OBJAŠNJENJE POJMOVA KORISTENIH U OVOM STANDARDU

Dokumentacija za automatizovani sistem- skup međusobno povezanih dokumenata koji u potpunosti opisuju sve odluke o stvaranju i radu sistema, kao i dokumenata koji potvrđuju usklađenost sistema sa zahtjevima tehničkih specifikacija i njegovu spremnost za rad (funkcionisanje).

Projektno predračunska dokumentacija za NE- dio dokumentacije NPP izrađen za izvođenje građevinskih i instalaterskih radova u vezi sa stvaranjem NEK.

Radna dokumentacija za zvučnike- dio dokumentacije za NEK neophodne za izradu, izgradnju, instalaciju i puštanje u rad automatiziranog sistema u cjelini, kao i softverskih i hardverskih, softverskih i metodoloških kompleksa i komponenti tehničke, softverske i informatičke podrške uključene u sistem.

PRAVILA ZA IMENOVANJE SISTEMA I NJIHOVIH DIJELOVA

1. Struktura oznake automatizovanog sistema ili njegovog dela ima oblik:

2. Organizacijski kod programera se dodeljuje u skladu sa Svesaveznim klasifikatorom preduzeća, institucija i organizacija (OKPO) ili prema pravilima utvrđenim industrijskom normativnom i tehničkom dokumentacijom.

3. Šifra za klasifikacijske karakteristike sistema ili njegovog dela (podsistema, kompleksa, komponente) se dodeljuje u skladu sa pravilima koja su uspostavljena u industriji na osnovu podklase 425 Sveuničkog klasifikatora proizvoda i/ili opšteg klasifikatora proizvoda. Sindikalni klasifikator podsistema i kompleksa zadataka automatizovanog sistema upravljanja - 1 84 154.

4. Serijski registarski broj sistema (dijela sistema) dodjeljuje služba razvojne organizacije, koja je odgovorna za održavanje kartoteke i oznake zapisa. Registracijski brojevi su dodijeljeni od 001 do 999 za svaki kod registracijske karakteristike.

INFORMACIJSKI PODACI

1. RAZVIJENO I UVOĐENO
Državni komitet za standarde SSSR-a
Ministarstvo instrumenata, automatizacije i sistema upravljanja SSSR-a

PERFORMERS
I.P. Vakhlakov; Ya.G. Vilenchik; N.M. Vitsyn, Ph.D. tech. nauke; F.R. Otter, Ph.D. tech. nauke; S.V. Garshina; B.A. Dyukov; L.M. Seidenberg, dr. tech. nauke; A.P. Igošin, dr. tech. nauke; Yu.B. Irz, Ph.D. tech. Nauke (voditelj teme); V.Yu. Korolev; I.A. Koroteeva; E.S. Krankov, dr. tech. nauke; IN AND. Makhnach, doktor tehničkih nauka. nauke; I.S. Mityaev; A.M. Mustafina; E.I. Nekrylov, Ph.D. tech. nauke; V.F. Popov; Npr. Savina; N.V. Stepanchikova; VC. Čistov, dr. tech. nauke; P.A. Shalaev, Ph.D. tech. nauke

2. ODOBREN I STUPAN NA SNAGU Rezolucijom Državnog komiteta SSSR-a za standarde od 24. marta 1989. godine br. 664

3. Period inspekcije - 1999; učestalost pregleda - 10 godina

4. UMJESTO GOST 24.101-80, GOST 24.102-80, RD 50-617-86

5. REFERENTNI REGULATIVNI I TEHNIČKI DOKUMENTI

Urađene su izmjene i dopune br. 1 (odobrene i stavljene na snagu Rezolucijom Državnog komiteta SSSR-a za upravljanje kvalitetom proizvoda i standarde od 29. decembra 1990. br. 3468, datum primjene 01.07.91.).

GOST 19.101-77

Grupa T55

MEĐUDRŽAVNI STANDARD

Jedinstveni sistem programske dokumentacije

VRSTE PROGRAMA I PROGRAMSKIH DOKUMENTA

Jedinstveni sistem programske dokumentacije. Vrste programa i programski dokumenti

MKS 35.080

Datum uvođenja 1980-01-01

Rezolucijom Državnog komiteta za standarde Vijeća ministara SSSR-a od 20. maja 1977. N 1268, datum uvođenja je određen 01.01.80.

IZDANJE (siječanj 2010.) sa amandmanom br. 1, odobrenim u junu 1981. (IUS 9-81).


Ovim standardom utvrđuju se vrste programa i programskih dokumenata za računare, komplekse i sisteme, bez obzira na njihovu namenu i obim.

Standard je u potpunosti usklađen sa ST SEV 1626-79.

(Promijenjeno izdanje, izmjena br. 1).

1. VRSTE PROGRAMA

1. VRSTE PROGRAMA

1.1. Program (prema GOST 19781-90) može se identificirati i koristiti samostalno i (ili) kao dio drugih programa.

1.2. Programi su podijeljeni u tipove prikazane u Tabeli 1.

Tabela 1

1.3. Dokumentacija izrađena za program može se koristiti za implementaciju i prijenos programa na medij za skladištenje podataka, kao i za izradu softverskog proizvoda.

1.2, 1.3. (Promijenjeno izdanje, izmjena br. 1).

2. VRSTE PROGRAMSKIH DOKUMENTA

2.1. Softverski dokumenti uključuju dokumente koji sadrže informacije potrebne za razvoj, proizvodnju, održavanje i rad programa.

2.2. Vrste programskih dokumenata i njihov sadržaj dati su u tabeli 2.

tabela 2

2.3. Vrste operativnih dokumenata i njihov sadržaj dati su u tabeli 3.

Tabela 3

2.4. U zavisnosti od načina implementacije i prirode aplikacije, programski dokumenti se dele na originalne, duplikate i kopije (GOST 2.102-68), namenjene razvoju, održavanju i radu programa.

2.5. Vrste programskih dokumenata razvijenih u različitim fazama i njihove šifre date su u tabeli 4.

Tabela 4

Legenda:

- dokument je obavezan;

- dokument je obavezan za komponente koje imaju samostalnu upotrebu;

- potreba za izradom dokumenta utvrđuje se u fazi izrade i odobravanja tehničkih specifikacija;

- - dokument nije sastavljen.

2.2-2.5. (Promijenjeno izdanje, izmjena br. 1).

2.6. Dozvoljeno je kombinovanje određenih vrsta operativnih dokumenata (sa izuzetkom liste operativnih dokumenata i obrasca). Potreba za kombinovanjem ovih dokumenata je naznačena u tehničkim specifikacijama. Spojenom dokumentu se dodjeljuje naziv i oznaka jednog od spojenih dokumenata.

Spojeni dokumenti moraju specificirati informacije koje moraju biti uključene u svaki dokument koji se spaja.

2.7. U fazi izrade i odobravanja tehničkih specifikacija utvrđuje se potreba izrade tehničkih specifikacija koje sadrže uslove za izradu, kontrolu i prihvatanje programa.

Tehničke specifikacije se izrađuju u fazi „Detaljni projekat“.

2.8. Potreba za izradom tehničkih specifikacija za komponente koje nisu namijenjene za samostalnu upotrebu i komplekse uključene u druge komplekse utvrđuje se u dogovoru s kupcem.

(Dodatno uveden, amandman br. 1).



Tekst elektronskog dokumenta
pripremio Kodeks dd i verificirao prema:
službena publikacija
Jedinstveni softverski sistem
dokumentacija: sub. GOST. -
M.: Standardinform, 2010

KORIŠĆENJE ZAHTEVA SERIJE GOST 19 I 34 PRILIKOM PRIPREME DOKUMENTACIJE U IT PROJEKTIMA ZA VLADNE STRUKTURE

Uvod

Nemoguće je zamisliti savremeni svijet bez alata za automatizaciju, koji se posvuda velikom brzinom implementiraju u komercijalne i državne strukture, čime se osigurava efikasnije poslovanje poslovanja i javnog sektora. Implementacija određenih alata za automatizaciju, po pravilu, podrazumeva izradu dokumentacije u različitim fazama, kao što su: razvoj zahteva za informacioni sistem; u fazi tehničkog projektovanja; faza izrade radne dokumentacije.

Istovremeno, postoje situacije kada programeri dokumentacije i kupac nemaju uvijek istu ideju o broju, strukturi i sadržaju dokumenata koji se razvijaju. To dovodi do činjenice da rezultati rada ne zadovoljavaju kupca, te se moraju potrošiti dodatna sredstva na finalizaciju dokumenata. Korištenje GOST zahtjeva pri izradi dokumentacije omogućava vam da izbjegnete takve situacije, jer Unatoč prevladavajućem mišljenju da standardi zaostaju za modernim tehnologijama, GOST pruža jasnu strukturu dokumentacije koja se razvija, ima svojstva potpunosti i konzistentnosti, a također uklanja kontroverzna pitanja između izvođača i kupca u vezi s rezultatima rada. Štoviše, u većini vladinih organizacija izrada dokumentacije u skladu s GOST-om je preduvjet. Zatim ćemo pokušati razumjeti zamršenosti razvoja dokumentacije prema zahtjevima GOST-a.

Prilikom razvoja automatizovanih sistema (AS) u skladu sa GOST 34 u IT projektima za vladine agencije, često se postavlja pitanje: koje GOST standarde treba da koristimo za izradu dokumentacije? GOST 34 ne sadrži eksplicitne instrukcije o tome koje standarde za izradu posebnih dokumenata razvijenih kao dio stvaranja AS, osim zahtjeva za pripremu tehničkih specifikacija. Pokušajmo saznati koji se GOST standardi koriste pri pripremi dokumenata u nedostatku preciznih uputa u vladinom ugovoru ili konkurentnoj tehničkoj specifikaciji (TOR). Ovaj materijal je prvenstveno namijenjen IT stručnjacima koji žele razumjeti kako se dokumenti sastavljaju u IT projektima u skladu sa zahtjevima GOST-a.

Definisanje standarda dokumentacije

Priprema dokumenata u GOST 34 zavisi od vrste dokumenta (dizajn ili softver) i faze kreiranja AS u kojoj se dokument priprema.

Spisak dokumenata razvijenih u različitim fazama stvaranja automatizovanih sistema dat je u GOST 34.201-89 „Vrste, kompletnost i oznaka dokumenata prilikom kreiranja automatizovanih sistema“. Sadrži sljedeće zahtjeve:

• U fazi "Tehničke specifikacije" razvijaju se tehničke specifikacije za stvaranje automatizovanog sistema u skladu sa GOST 34.602-89 "Tehničke specifikacije za stvaranje automatizovanog sistema";
• Vrste programskih dokumenata GOST 19.101-77“Jedinstveni sistem programske dokumentacije. Vrste programa i programska dokumenta.” To uključuje različite priručnike, kao što je korisnički priručnik.
• Vrste projektna dokumenta, razvijene u različitim fazama stvaranja AS određuju se GOST 2.102-2013“Jedinstveni sistem projektne dokumentacije. Vrste i kompletnost projektne dokumentacije." Na primjer, ovo uključuje izjave o idejnim i tehničkim projektima, izjave o kupljenim proizvodima, objašnjenja idejnih i tehničkih projekata.

Sada pogledajmo bliže kako odrediti standarde dizajna u različitim projektima.

Registracija tehničkih specifikacija

Sve je sasvim jasno sa tehničkim specifikacijama: GOST 34.602-89 daje standard za njegov dizajn: klauzula 3.2. navodi da su "Tehničke specifikacije za zvučnike sastavljene u skladu sa zahtjevima GOST 2.105 na A4 listovima u skladu sa GOST 2.301 bez okvira, glavnog natpisa i dodatnih stupaca."

Izrada programske dokumentacije

Uz programske dokumente razvijene kao dio IT projekta, postoji i jasna indikacija za korištenje serije GOST 19 u smislu dizajna: gornji GOST 19.101-77 dio je serije GOST 19 „Jedinstveni sistem programske dokumentacije“ (USPD) . ESPD je skup državnih standarda Ruske Federacije koji uspostavljaju međusobno povezana pravila za razvoj, izvođenje i promet programa i programske dokumentacije.

Dokumentacija u ESPD-u je sastavljena u skladu sa GOST 19.104-78 „Jedinstveni sistem programske dokumentacije. Osnovni natpisi", GOST 19.105-78 "Jedinstveni sistem programske dokumentacije. Opšti zahtjevi za programske dokumente“, GOST 19.106-78 „Jedinstveni sistem programske dokumentacije. Zahtjevi za štampane programske dokumente."

Izrada projektne dokumentacije

Pogledajmo sada GOST 2.102-2013. Ovaj standard je dio GOST serije 2 „Jedinstveni sistem projektne dokumentacije“ (ESKD). ESKD je međudržavni skup standarda koji uspostavljaju međusobno povezane norme i pravila za izradu, izvođenje i promet projektne dokumentacije koja se razvija i primjenjuje u svim fazama životnog ciklusa proizvoda (tokom projektovanja, proizvodnje, rada, popravke itd.)

Dokumentacija u ESKD-u je sastavljena prema nekoliko standarda. Najčešći od njih (u odnosu na IT sektor) su GOST 2.105-95 „Jedinstveni sistem projektne dokumentacije. Opšti zahtjevi za tekstualne dokumente" i GOST 2.106-96 "Jedinstveni sistem projektne dokumentacije. Tekstualni dokumenti."

Na prvi pogled, iz serije GOST 34 nije jasno kako sastaviti dokumentaciju za zvučnike. Često, u okviru IT projekta, posebno za vladine kupce, tehničke specifikacije sadrže zahtjeve za pripremu dokumentacije u skladu sa GOST 2.105-95 i GOST 2.106-96. Ali treba li dokumente sastavljati u skladu s ovim GOST-ovima ako ne postoje eksplicitni zahtjevi za registraciju?

Kako se pravilno prijaviti?

GOST 2. serija sadrži zahtjeve za svrhu svakog standarda i ukazuje na industriju njegove primjene: GOST 2.102-2013 - standard utvrđuje vrste i potpunost projektne dokumentacije za proizvode svih industrija.

Ako se GOST 2.102-2013 odnosi na proizvode iz svih industrija, uključujući IT sektor, hajde da shvatimo, šta je projektni dokument?

Prema GOST 2.001-2013 „Jedinstveni sistem projektne dokumentacije (ESKD). Opće odredbe":

A) „3.1.2 projektni dokument: Dokument koji, pojedinačno ili u kombinaciji s drugim dokumentima, definira dizajn proizvoda i ima sadržaj i potrebne dijelove, uključujući utvrđene potpise.”

B) „3.1.5 projektna dokumentacija: Skup projektne dokumentacije koja sadrži podatke potrebne za projektovanje (razvoj), proizvodnju, kontrolu, prijem, isporuku, rad, popravku, modernizaciju i odlaganje proizvoda.”

Ovdje bismo mogli stati, logično upoređujući zahtjeve za sastav dokumenata našeg IT projekta sa gore navedenim odredbama i utvrđivanjem da li svaki od dokumenata pripada projektnoj dokumentaciji ili ne i dovršavanjem dizajna prema standardima GOST 2. serije.

Glavni GOST-ovi 2. serije za IT projekat u smislu dizajna

Pogledajmo sada glavne GOST-ove 2. serije, koji se najčešće koriste za pripremu dokumenata u IT projektu. U pravilu, u pogledu dizajna koriste:

GOST 2.105-95 - standard utvrđuje opšte zahtjeve za izradu tekstualnih dokumenata za mašinstvo, izradu instrumenata i građevinske proizvode;

GOST 2.106-96 - standard utvrđuje obrasce i pravila za izradu projektne dokumentacije za mašinstvo i proizvode za izradu instrumenata.

Čitalac može imati pitanje: možemo li koristiti ove GOST-ove za zvučnike ako su namijenjeni za mašinstvo i proizvode za izradu instrumenata?

Prema definiciji Velike sovjetske enciklopedije, „Izrada instrumenata je grana mašinstva koja proizvodi sredstva za merenje, analizu, obradu i prezentaciju informacija, upravljačke uređaje, automatske i automatizovane sisteme upravljanja; oblast nauke i tehnologije koja razvija alate za automatizaciju i sisteme upravljanja“, odnosno sve što vam je potrebno na našu temu savremene informacione tehnologije.

Osim toga, ako pogledate GOST 34.003-90 „Automatski sistemi. Termini i definicije“, ovaj standard definira automatizirani sistem kao „sistem koji se sastoji od osoblja i skupa alata za automatizaciju za njihove aktivnosti, koji implementiraju informacionu tehnologiju za obavljanje uspostavljenih funkcija“.

Dakle, AU pripada industriji izrade instrumenata i stoga je projektna dokumentacija AU sastavljena u skladu sa GOST 2.105-95 i GOST 2.106-96.

Sada pogledajmo glavne točke pripreme projektne dokumentacije u skladu s GOST 2.105-95 i GOST 2.106-96.

Ključne tačke prilikom registracije prema GOST 2.105

Razmotrimo glavne parametre dizajna prema GOST 2. seriji.

Prema GOST 2.105-95, udaljenost od okvira obrasca do granica teksta na početku i kraju redova mora biti najmanje 3 mm. Udaljenost od gornjeg ili donjeg reda teksta do gornjeg ili donjeg okvira mora biti najmanje 10 mm. Paragrafi u tekstu počinju uvlačenjem jednakim pet poteza pisaće mašine (15 - 17 mm).

GOST 2.105-95 ne definiše parametre za formatiranje teksta u elektronskom obliku: naziv fonta, visinu fonta, prored. Stoga su parametri za obradu dokumenata u elektronskom obliku, po pravilu, predmet dogovora sa kupcem.

Na početku rada elektronskog formatiranja određuju se parametri formatiranja:

• Format pasusa teksta – korišteni font, visina fonta, prored;
• Format za svaki naslov po nivoima (1, 2, 3) – korišteni font, visina fonta, uvlačenje u cm, veličina proreda;

Tabela - korišteni font teksta, prored, debljina ivice tabele, širina tabele, uvlačenje ćelije, naslov postavljen iznad tabele. Naslov tabele je formatiran na isti način kao i glavni tekst dokumenta. Prema GOST 2.105-95, visina redova stola mora biti najmanje 8 mm. Visina fonta redova tabele takođe se može dogovoriti sa kupcem.

Ilustracije u dokumentu treba da budu centrirane. Naslov se nalazi direktno ispod ilustracije. Oblikovanje naslova je isto kao i tekst dokumenta.

Pravila dizajna stola

Tabela se, u zavisnosti od veličine, nalazi ispod teksta u kojem je prvi put dat link do nje, ili na sledećoj stranici, a po potrebi i u prilogu dokumenta.

Tabele su, sa izuzetkom tabela dodataka, numerisane arapskim brojevima i kontinuiranom numeracijom. Na primjer: "Tabela 1".

Tabele svake prijave označene su posebnom numeracijom arapskim brojevima uz dodatak oznake aplikacije ispred broja. Na primjer: “Tabela B.1”.

Dozvoljeno je numerisanje tabela unutar sekcije. U ovom slučaju, broj tabele se sastoji od broja sekcije i rednog broja tabele, odvojenih tačkom. Na primjer, u odjeljku 4 broj bi bio “Tabela 4.3”.

Naslov tabele treba da odražava njen sadržaj, da bude tačan i koncizan. Naziv se sastoji od riječi „Tabela“, broja tabele i teksta. GOST 2.105-95 ne definiše upotrebu crtice ili crtice u nazivu tabele. U praksi se može koristiti crtica, slično upotrebi crtice u naslovu slike. Na primjer, “Tabela 5 – Izvršeni radovi, sadržaj i rokovi.” Na kraju naslova nema tačke. Naslov se nalazi iznad tabele sa leve strane.

GOST 2.105-95 u tački 4.4.3 sadrži sljedeći zahtjev: „Sve tabele dokumenta moraju biti referencirane u tekstu dokumenta; kada se upućuje, treba napisati riječ „tabela“ koja označava njegov broj.“ U praksi se riječ „stol” u tekstu odbacuje prema pravilima ruskog jezika. Na primjer: „Kratak opis namjene i glavnih karakteristika IP IC podsistema druge faze predstavljen je u tabeli 1.“

Ako se vaša tabela prostire na više stranica, trebali biste prikazati njen naslov na početku svake stranice.

GOST 2.105-95 ima neobavezni zahtjev u klauzuli 4.4.7: „ako je tabela prekinuta na kraju stranice i njen nastavak će biti na sljedećoj stranici, u prvom dijelu tabele donja horizontalna linija ograničava tabelu ne može biti nacrtana.” U praksi se povlači donja horizontalna linija, jer njeno odsustvo narušava percepciju stola korisnika.

Pravila za oblikovanje ilustracija

Ilustracije uključuju grafičke slike (dijagrame, grafikone, fotografije, crteže).

Ilustracije, sa izuzetkom ilustracija aplikacija, numerisane su arapskim brojevima, a numeracija je kontinuirana. Na primjer: "Slika 3".

Ilustracije svake aplikacije označene su posebnom numeracijom arapskim brojevima uz dodatak oznake aplikacije ispred broja. Na primjer: "Slika B.6."

Dozvoljeno je numerisanje ilustracija unutar odeljka. U ovom slučaju, broj ilustracije se sastoji od broja sekcije i serijskog broja ilustracije, odvojenih tačkom. Na primjer, u odjeljku 5 broj će biti „Slika 5.2“.

Dozvoljeno je ne numerisati male ilustracije (male crteže) koje se nalaze direktno u tekstu i na koje u tekstu nema daljeg pozivanja.

Zahtjevi GOST 2.105-95 za lokaciju: „ilustracije se mogu nalaziti u cijelom tekstu dokumenta (moguće bliže relevantnim dijelovima teksta) i na njegovom kraju.”

GOST 2.105-95 u klauzuli 4.3.1 navodi sljedeće: „kada se pozivate na ilustracije, trebate napisati „... u skladu sa slikom 2” za kontinuirano numeriranje i „... u skladu sa slikom 1.2” za numeriranje unutar odjeljak "

Naziv je napisan ispod ilustracije u formatu „Slika 1 – Detalji uređaja“.

Zanimljiva činjenica: ako prikrijete grešku u papirnom dokumentu i napišete ispravku preko njega crnom tintom, to će biti u skladu sa GOST-om. GOST 2.105-95 dozvoljava ispravke dokumenata u papirnom obliku. Ovo stoji u klauzuli 3.7: „Greške u pisanju, administrativne greške i grafičke netačnosti otkrivene tokom izrade dokumenta mogu se ispraviti brisanjem ili farbanjem bijelom bojom i primjenom ispravljenog teksta (grafike) na istom mjestu kucanjem ili upotrebom crne boje mastilo, pasta ili mastilo u rukopisu. . Oštećenje listova tekstualnih dokumenata, mrlje i tragovi nepotpuno uklonjenog prethodnog teksta (grafika) nisu dozvoljeni.”

Odnosno, ako ste nešto ispisali i pronašli grešku, možete to ručno ispraviti koristeći gornju metodu.

Registracija prema GOST 2. 106-96

GOST 2.106-96 utvrđuje obrasce i pravila za izradu projektne dokumentacije. Za svaku vrstu dokumenta, GOST 2.106-96 daje predložak za dizajniranje okvira dokumenta.

GOST 2.106-96 određuje ne samo oblik okvira, već i glavni natpis u okviru. Primjer iz GOST 2.106-96: „PZ se sastavljaju na obrascima 9 i 9a Dodatka A, a potrebni dijagrami, tabele i crteži u papirnom obliku mogu se napraviti na listovima bilo kojeg formata utvrđenog GOST 2.301, dok je glavni natpis i dodatni stupci su napravljeni u skladu sa zahtjevima GOST 2.104 (obrazac 2a)."

Sažetak

Pored navedenog, možemo reći da prilikom razvoja AS u skladu sa GOST 34 u IT projektima za vladine agencije, u nedostatku preciznih uputstava u vladinom ugovoru ili konkurentnim tehničkim specifikacijama, softverska i projektna dokumentacija moraju biti izrađeni u skladu sa sa sljedećim GOST-ovima:

• Programski dokumenti razvijeni u različitim fazama stvaranja AS sastavljaju se u skladu sa GOST 19.104-78, GOST 19.105-78, GOST 19.106-78;
• Projektna dokumentacija razvijena u različitim fazama stvaranja NPP-a izrađuje se u skladu sa GOST 2.105-95 i GOST 2.106-96. U ovom slučaju, zahtjevi za sadržaj su regulisani RD 50.34-698-90.

Potrebno je provjeriti relevantnost GOST-ova i koristiti najnovije izdanje standarda, jer se oni, iako rijetko, još uvijek ažuriraju. Nadam se da će vam članak pomoći da se bolje snalazite u zahtjevima GOST-a, a ako je potrebno, uvijek možete