4.1. Kërkesat për sistemin në tërësi.

4.1.1. Kërkesat për strukturën dhe funksionimin e sistemit.
4.1.2. Kërkesat për numrin dhe kualifikimet e personelit të sistemit dhe mënyrën e funksionimit të tyre.
4.1.3. Kërkesat e besueshmërisë.
4.1.4. Kërkesat e sigurisë.
4.1.5. Kërkesat për ergonomi dhe estetikë teknike.
4.1.6. Kërkesat e funksionimit dhe mirëmbajtjes.
4.1.7. Kërkesat për mbrojtjen e informacionit nga aksesi i paautorizuar;
4.1.8. Kërkesat për sigurinë e informacionit në rast aksidentesh.
4.1.9. Kërkesat për mbrojtje nga ndikimet e ndikimeve të jashtme.
4.1.10. Kërkesat për lejimin e patentës.
4.1.11. Çdo kërkesë shtesë.

4.2. Kërkesat për funksionet (detyrat) që kryen sistemi.

(lista e funksioneve (detyrave) që do të automatizohen; plani kohor për zbatimin e secilit funksion (detyrë); kërkesat për cilësinë e zbatimit të secilit funksion (detyrë), për formën e paraqitjes së informacionit dalës, për saktësinë dhe kohën të ekzekutimit, për besueshmërinë e rezultateve, listën dhe kriteret e dështimeve për çdo funksion (detyrë) për të cilën janë përcaktuar kërkesat e besueshmërisë)

4.3. Kërkesat për llojet e kolateralit.

4.3.1. Kërkesat për mbështetjen matematikore të sistemit.

(kërkesat për përbërjen, shtrirjen dhe metodat e përdorimit të metodave dhe modeleve matematikore në sistem, algoritme dhe algoritme tipike që do të zhvillohen)

4.3.2. Kërkesat për mbështetjen e informacionit të sistemit.

për mbrojtjen e të dhënave nga shkatërrimi gjatë aksidenteve dhe ndërprerjeve të rrymës së sistemit; për kontrollin, ruajtjen, përditësimin dhe rikuperimin e të dhënave)

4.3.3. Kërkesat për mbështetjen gjuhësore të sistemit.

(kërkesat për përdorimin e gjuhëve të programimit të nivelit të lartë në sistem, gjuhët për ndërveprimin midis përdoruesve dhe mjeteve teknike të sistemit, si dhe kërkesat për kodimin dhe dekodimin e të dhënave, për gjuhët hyrëse-dalëse, gjuhët e manipulimit të të dhënave , mjete për përshkrimin e fushës së temës (modelimi i informacionit), për metodat e organizimit të dialogut me përdoruesin, etj.)

4.3.4. Kërkesat e softuerit të sistemit.

(lista e produkteve softuerike të licencuara, prania e të cilave është e nevojshme që sistemi të funksionojë në gjendje normale)

4.3.5. Kërkesat për mbështetje teknike.

(kërkesat për llojet e komplekseve të harduerit, softuerit dhe harduerit dhe komponentëve të tjerë që mund të përdoren në sistem; për karakteristikat funksionale, projektuese dhe operacionale të harduerit të sistemit)

4.3.6. Kërkesat për mbështetje organizative.

(kërkesat për strukturën dhe funksionet e departamenteve të përfshira në funksionimin e sistemit ose sigurimin e funksionimit; për organizimin e funksionimit të sistemit dhe rendin e ndërveprimit të personelit të objektit të automatizimit; për mbrojtjen nga veprimet e gabuara të personelit të sistemit)

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 Z A S S R

Data e prezantimit 01.01.90

Ky standard zbatohet për sistemet e automatizuara (AS) të përdorura në fusha të ndryshme të veprimtarisë (kontroll, kërkim, dizajn, etj.), duke përfshirë kombinimin e tyre, dhe përcakton llojet, emrin, plotësinë dhe përcaktimin e dokumenteve të zhvilluara në fazat e krijimit të një AU. , themeluar GOST 24.601.

Një shpjegim i termave të përdorur në këtë standard jepet në Shtojcën 1.

1. LLOJET DHE EMRITI I DOKUMENTEVE

1.1. Përbërja e llojeve të dokumenteve të zhvilluara në fazën "Kërkimi dhe vërtetimi i krijimit të AU" përcaktohet në përputhje me Sec. 3 GOST 24.601, bazuar në rezultatet e kërkuara të kësaj faze.

1.2. Në fazën "Termat e Referencës", Kushtet e Referencës (TOR) zhvillohen për krijimin e një sistemi të automatizuar në përputhje me kërkesat e GOST 34.602.

Lejohet të zhvillohet TK private për sisteme individuale (nënsisteme, komplekse detyrash, komplekse softuerësh dhe harduerësh, komponentë harduerësh dhe softuerësh, etj.)

1.3. Llojet e dokumenteve të zhvilluara në fazat "Draft projektimi", "Projektimi teknik", "Dokumentacioni i punës" janë dhënë në tabelë. një.

Tabela 1

1.3.1. Emrat e dokumenteve specifike të zhvilluara gjatë projektimit të sistemit në tërësi ose pjesë të tij janë dhënë në tabelë. 2.

tabela 2

(Botim i modifikuar, Amendamenti nr. 1)

Shënime:

• 1. Tabela përdor emërtimet e mëposhtme:
  • EP - dizajn paraprak;
  • TP - dizajn teknik;
  • RD - dokumentacioni i punës;
  • OSE - zgjidhje në të gjithë sistemin;
  • OO - vendime për mbështetjen organizative;
  • TO - zgjidhje për mbështetje teknike;
  • IO - zgjidhje për mbështetje informacioni;
  • Software - zgjidhje softuerike;
  • MO - zgjidhje softuerike.
• 2. Shenja X - përcakton që i përkasin vlerësimeve të projektimit ose dokumentacionit operacional.
• 3. Nomenklatura e dokumenteve me një emër përcaktohet në varësi të vendimeve të projektimit të miratuara gjatë krijimit të sistemit

1.3.2. Llojet e dokumenteve për softuerin e përdorur në krijimin e AU (pjesët e tij) - në përputhje me GOST 19.101.77.

1.3.3. Llojet e dokumenteve për mjetet teknike të përdorura në krijimin e AU (pjesët e tij) - sipas GOST 2.102 dhe sipas GOST 2.601 për sa i përket dokumenteve operacionale.

1.3.4. Në varësi të metodave të projektimit të përdorura dhe specifikave të altoparlantëve të krijuar, lejohet:

• 1) zhvilloni dokumente grupore dhe bazë në përputhje me seksionin. 1, 3, 4, 6 GOST 2.113;
• 2) lëshon dokumente në pjesë të veçanta të pavarura që korrespondojnë me seksionet e dokumentit kryesor;
• 3) zgjeroni gamën e dokumenteve të përcaktuara nga ky standard.

1.4. Në fazat "Prodhimi i komponentëve jo serialë të ASK-së" dhe "Komisionimi", zhvillohen dokumentet e mëposhtme organizative dhe administrative:

• 1) akti i përfundimit të punës;
• 2) akti i pranimit për punë provuese;
• 3) akti i pranimit në veprimtari industriale;
• 4) orari i punës;
• 5) urdhër për përbërjen e komisionit pranues;
• 6) urdhër për kryerjen e punës;
• 7) programi i punës;
• 8) raporti i testit;
• 9) protokolli i marrëveshjes.

2. PLOTËSIA E DOKUMENTACIONIT

2.1. Lista e emrave të dokumenteve që zhvillohen dhe plotësia e tyre për sistemin dhe pjesët e tij duhet të përcaktohet në termat e referencës për krijimin e një sistemi (nënsistemi) të automatizuar.

Shënim. Plotësia e dokumenteve të projektimit dhe vlerësimit përcaktohet në përputhje me rregullat e përcaktuara nga sistemi i dokumentacionit të projektimit për ndërtim (SPDS).

2.2. Për çdo grup duhet të hartohet një listë dokumentesh.

2.3. Plotësia e dokumentacionit për zhvillimin, prodhimin, pranimin dhe instalimin e pajisjeve teknike është në përputhje me GOST 2.102. Plotësia e dokumentacionit operacional për këto fonde është në përputhje me GOST 2.601.

2.4. Plotësia e dokumentacionit për softuerin kompjuterik është në përputhje me GOST 19.101.77.

2.5. Në rast të vetë-zhvillimit të një pjese të sistemit, dokumentet për të plotësohen në përputhje me kërkesat e këtij standardi.

3. IDENTIFIKIMI I DOKUMENTEVE

3.1. Çdo dokumenti të zhvilluar duhet t'i caktohet një përcaktim i pavarur. Një dokument i ekzekutuar në bartës të ndryshëm të të dhënave duhet të ketë një emërtim. Shkronja "M" i shtohet përcaktimit të dokumenteve të bëra në median e makinës.

Dokumentet e huazuara ruajnë përcaktimet e caktuara më parë.

3.2. Këto rregulla nuk zbatohen për dokumentet, rregullat e përcaktimit të të cilave rregullohen nga standardet shtetërore të sistemeve të tjera të dokumentacionit.

3.3. Emërtimi i dokumentit ka strukturën e mëposhtme:

Para> ___________
|___________|. XX. XX. X- X. M
Emërtimi i sistemit | | | | | |
(pjesë të sistemit) | | | | | |
Kodi i dokumentit | | | | |
Numri serial i një dokumenti | | | |
emrat | | | |
Numri i rishikimit të dokumentit | | |
Numri i pjesës së dokumentit | |
Shenja e dokumentit të ekzekutuar në makinë |
transportuesit |

3.3.1. Rregullat e përcaktimit për sistemin (pjesë e sistemit) janë dhënë në shtojcën 2.

3.3.2. Kodi i dokumentit përbëhet nga dy karaktere alfanumerike. Kodi për dokumentet e përcaktuara nga ky standard vendoset në përputhje me kolonën 3 të tabelës. 2. Kodi i dokumenteve shtesë formohet si më poshtë: karakteri i parë është një shkronjë që tregon llojin e dokumentit sipas tabelës. 1, karakteri i dytë është një numër ose shkronjë që tregon numrin serial të një dokumenti të këtij lloji.

Kodi i dokumentit ndahet nga përcaktimi i mëparshëm me një pikë.

3.3.3. Numrat serialë të dokumenteve me të njëjtin emër (2 karaktere) janë caktuar, duke filluar nga i dyti dhe ndahen nga përcaktimi i mëparshëm me një pikë.

3.3.4. Numri i rishikimit të dokumentit caktohet, duke filluar nga i dyti në rend rritës nga 2 në 9, dhe ndahet nga vlera e mëparshme me një pikë. Numri tjetër i rishikimit caktohet në rastet e ruajtjes (jo anulimit) të botimit të mëparshëm.

3.3.5. Numri i pjesës së dokumentit ndahet nga përcaktimi i mëparshëm me vizë. Nëse dokumenti përbëhet nga një pjesë, atëherë viza nuk vendoset dhe numri i pjesës së dokumentit nuk caktohet.

3.3.6. Atributi i një dokumenti të bërë në median e makinës futet nëse është e nevojshme. Shkronja "M" ndahet nga përcaktimi i mëparshëm me një pikë.

ANEKSI 1
Referenca

SHPJEGIMI I KUSHTEVE TË PËRDORUR NË KËTË STANDARD

Dokumentacioni për sistemin e automatizuar- një grup dokumentesh të ndërlidhura, i cili përshkruan plotësisht të gjitha vendimet për krijimin dhe funksionimin e sistemit, si dhe dokumentet që konfirmojnë përputhshmërinë e sistemit me kërkesat e specifikimeve teknike dhe gatishmërinë e tij për funksionim (funksionim).

Dokumentacioni i projektimit dhe vlerësimit për NPP-në- pjesë e dokumentacionit për TEC-in, i zhvilluar për kryerjen e punimeve ndërtimore dhe montuese lidhur me krijimin e TEC-it.

Dokumentacioni i punës për folësin- pjesë e dokumentacionit të NPP-së që kërkohet për prodhimin, ndërtimin, instalimin dhe rregullimin e sistemit të automatizuar në tërësi, si dhe të përfshira në sistemin e softuerit dhe harduerit, softuerëve dhe komplekseve metodologjike dhe përbërësve të mbështetjes teknike, softuerike dhe informacionit.

RREGULLAT PËR PËRCAKTIMIN E SISTEMEVE DHE PJESËVE TË TYRE

1. Struktura e përcaktimit të një sistemi të automatizuar ose pjesës së tij është si më poshtë:

2. Kodi i organizatës zhvilluese caktohet në përputhje me Klasifikuesin Gjithë Bashkimi të Ndërmarrjeve, Institucioneve dhe Organizatave (OKPO) ose sipas rregullave të përcaktuara nga dokumentacioni shkencor dhe teknik i industrisë.

3. Kodi i karakteristikës së klasifikimit të sistemit ose pjesës së tij (nënsistemi, kompleksi, përbërësi) caktohet në përputhje me rregullat e vendosura në industri në bazë të nënklasës 425 të klasifikuesit të gjithë Bashkimit të produkteve dhe/ose klasifikuesi gjithë-Bashkimi i nënsistemeve dhe komplekseve të detyrave të ACS - 1 84 154.

4. Numri serial i regjistrimit të sistemit (pjesë e sistemit) caktohet nga shërbimi i organizatës së zhvilluesit, e cila është përgjegjëse për ruajtjen e indeksit të kartës dhe llogaritjen e emërtimeve. Numrat e regjistrimit caktohen nga 001 në 999 për çdo kod karakteristik të regjistrimit.

TË DHËNAT E INFORMACIONIT

1. ZHVILLUAR DHE PARAQITET
Komiteti Shtetëror i BRSS për Standardet
Ministria e Instrumentimit, Automatizimit dhe Sistemeve të Kontrollit të BRSS

KONTRAKTORËT
I.P. Vakhlakov; Ya.G. Vilenchik; N.M. Vitsyn, Cand. teknologjisë. shkencat; F.R. Otter, Cand. teknologjisë. shkencat; S.V. Garshina; B.A. Dyukov; L.M. Seidenberg, Cand. teknologjisë. shkencat; A.P. Igoshin, Cand. teknologjisë. shkencat; Yu.B. Irz, Cand. teknologjisë. Shkencat (udhëheqës i temës); V.Yu. Korolev; I.A. Koroteeva; E.S. Krankov, Cand. teknologjisë. shkencat; NË DHE. Makhnach, Dr. shkencat; I.S. Mityaev; JAM. Mustafina; E.I. Nekrylov, Cand. teknologjisë. shkencat; V.F. Popov; P.sh. Savina; N.V. Stepanchikova; QV. Chistov, Cand. teknologjisë. shkencat; P.A. Shalaev, Cand. teknologjisë. shkencat

2. MIRATUAR DHE HYUR NË FUQI me Dekretin e Komitetit Shtetëror të BRSS sipas standardeve të datës 24.03.89 nr.664.

3. Periudha e verifikimit - 1999; Frekuenca e inspektimit - 10 vjet

4. ZËVENDËso GOST 24,101-80, GOST 24,102-80, RD 50-617-86

5. DOKUMENTA RREGULLATIVE DHE TEKNIKE REFERENCA

U bënë ndryshime ¹ 1, (Miratuar dhe vënë në fuqi me Dekretin e Komitetit Shtetëror të BRSS për Menaxhimin e Cilësisë së Produkteve dhe Standardet e datës 29 dhjetor 1990 Nr. 3468, datë e prezantimit 07/01/1991).

GOST 19.101-77

Grupi T55

STANDARD NDËRSHTETOR

Sistemi i unifikuar i dokumentacionit të programit

LLOJET E PROGRAMEVE DHE DOKUMENTEVE Softuerike

Sistemi i unifikuar për dokumentacionin e programit. Llojet e programeve dhe dokumentet e programit

ISS 35.080

Data e prezantimit 1980-01-01

Me dekret të Komitetit Shtetëror të Standardeve të Këshillit të Ministrave të BRSS të 20 majit 1977 N 1268, data e prezantimit u vendos 01.01.80

EDICIONI (Janar 2010) me Amendamentin Nr. 1, miratuar në qershor 1981 (IUS 9-81).


Ky standard përcakton llojet e programeve dhe dokumenteve programore për kompjuterë, komplekse dhe sisteme, pavarësisht nga qëllimi dhe qëllimi i tyre.

Standardi është plotësisht në përputhje me ST SEV 1626-79.

(Botim i modifikuar, Amendamenti N 1).

1. LLOJET E PROGRAMEVE

1. LLOJET E PROGRAMEVE

1.1. Programi (sipas GOST 19781-90) lejohet të identifikohet dhe përdoret në mënyrë të pavarur dhe (ose) si pjesë e programeve të tjera.

1.2. Programet ndahen në lloje të paraqitura në tabelën 1.

Tabela 1

1.3. Dokumentacioni i zhvilluar për programin mund të përdoret për zbatimin dhe transmetimin e programit në bartësit e të dhënave, si dhe për prodhimin e një produkti softuer.

1.2, 1.3. (Botim i modifikuar, Amendamenti N 1).

2. LLOJET E DOKUMENTEVE Softuerike

2.1. Dokumentet e softuerit përfshijnë dokumente që përmbajnë informacione të nevojshme për zhvillimin, prodhimin, mirëmbajtjen dhe funksionimin e programeve.

2.2. Llojet e dokumenteve të programit dhe përmbajtja e tyre janë paraqitur në tabelën 2.

tabela 2

2.3. Llojet e dokumenteve operacionale dhe përmbajtja e tyre janë paraqitur në tabelën 3.

Tabela 3

2.4. Në varësi të metodës së zbatimit dhe natyrës së aplikacionit, dokumentet e programit ndahen në origjinal, dublikatë dhe kopje (GOST 2.102-68), të destinuara për zhvillimin, mirëmbajtjen dhe funksionimin e programit.

2.5. Llojet e dokumenteve softuerike të zhvilluara në faza të ndryshme dhe kodet e tyre janë paraqitur në tabelën 4.

Tabela 4

Legjenda:

- dokumenti është i detyrueshëm;

- dokumenti është i detyrueshëm për komponentët që kanë aplikim të pavarur;

- nevoja për të hartuar një dokument përcaktohet në fazën e zhvillimit dhe miratimit të termave të referencës;

- - dokumenti nuk është hartuar.

2.2-2.5. (Botim i modifikuar, Amendamenti N 1).

2.6. Lejohet të kombinohen disa lloje të dokumenteve operative (me përjashtim të listës së dokumenteve operative dhe formularit). Nevoja për të kombinuar këto dokumente tregohet në termat e referencës. Dokumentit të bashkuar i jepet emri dhe përcaktimi i njërit prej dokumenteve të bashkuar.

Dokumentet e kombinuara duhet të përmbajnë informacion që duhet të përfshihet në çdo dokument të kombinuar.

2.7. Në fazën e zhvillimit dhe miratimit të specifikimeve teknike, përcaktohet nevoja për të hartuar specifikimet teknike që përmbajnë kërkesat për prodhimin, kontrollin dhe pranimin e programit.

Specifikimet teknike zhvillohen në fazën e "Projektimit të punës".

2.8. Nevoja për të hartuar specifikimet teknike për komponentët që nuk janë të destinuar për përdorim të pavarur, dhe komplekset e përfshira në komplekse të tjera, përcaktohet me marrëveshje me klientin.

(E prezantuar më tej, Rev. N 1).



Teksti elektronik i dokumentit
përgatitur nga SH.A. "Kodeks" dhe verifikuar nga:
publikim zyrtar
Sistemi i unifikuar i softuerit
dokumentacioni: Sht. GOST. -
M .: Standartinform, 2010

PËRDORIMI I KËRKESAVE TË SERIAVE GOST 19 dhe 34 KUR REGJISTRIMI I DOKUMENTACIONIT NË PROJEKTET TI PËR STRUKTURA SHTETËRORE

Prezantimi

Bota moderne nuk mund të imagjinohet pa mjete automatizimi, të cilat po futen me shpejtësi kudo në strukturat tregtare dhe qeveritare, gjë që siguron funksionim më efikas të biznesit dhe sektorit publik. Futja e mjeteve të caktuara të automatizimit zakonisht përfshin zhvillimin e dokumentacionit në faza të ndryshme, si p.sh.: formimi i kërkesave për sistemin e informacionit; në fazën e një projektimi teknik; fazat e zhvillimit të dokumentacionit të punës.

Në të njëjtën kohë, ka situata kur zhvilluesit e dokumentacionit dhe klienti nuk kanë gjithmonë të njëjtën ide për numrin, strukturën dhe përmbajtjen e dokumenteve që zhvillohen. Kjo çon në faktin se rezultatet e punës nuk i përshtaten klientit; burime shtesë duhet të shpenzohen për finalizimin e dokumenteve. Përdorimi i kërkesave GOST në zhvillimin e dokumentacionit ju lejon të shmangni situata të tilla, pasi Megjithë mendimin mbizotërues se standardet mbeten prapa teknologjive moderne, GOST siguron një strukturë të qartë të dokumentacionit të zhvilluar, ka vetitë e plotësisë dhe konsistencës, dhe gjithashtu heq çështjet e diskutueshme midis kontraktorit dhe klientit në lidhje me rezultatet e punës. Për më tepër, në shumicën e organizatave shtetërore, zhvillimi i dokumentacionit në përputhje me GOST është një parakusht. Tjetra, ne do të përpiqemi të kuptojmë ndërlikimet e zhvillimit të dokumentacionit për kërkesat e GOST.

Kur zhvilloni sisteme të automatizuara (AS) në përputhje me GOST 34 në projektet e TI-së për agjencitë qeveritare, shpesh lind pyetja: sipas cilit GOST duhet të hartojnë dokumentacionin? Në GOST 34, nuk ka udhëzime të qarta se cilat standarde duhet të hartohen dokumente specifike të zhvilluara si pjesë e krijimit të një AU, përveç kërkesave për hartimin e specifikimeve teknike. Le të përpiqemi të zbulojmë se cilat GOST përdoren në ekzekutimin e dokumenteve në mungesë të udhëzimeve të sakta në kontratën shtetërore ose detyrën teknike konkurruese (TOR). Ky material është menduar kryesisht për specialistët e IT-së që duan të kuptojnë se si hartohen dokumentet në projektet e TI-së në përputhje me kërkesat e GOST.

Përcaktimi i standardeve të dokumentacionit

Ekzekutimi i dokumenteve në GOST 34 varet nga lloji i dokumentit (dizajni ose softueri) dhe faza e krijimit të AU, në të cilën përgatitet dokumenti.

Lista e dokumenteve të zhvilluara në faza të ndryshme të krijimit të një AU është dhënë në GOST 34.201-89 "Llojet, plotësia dhe përcaktimi i dokumenteve gjatë krijimit të sistemeve të automatizuara". Ai rendit kërkesat e mëposhtme:

• Në fazën "Termat e Referencës", ata zhvillojnë specifikimet teknike për krijimin e një AU në përputhje me GOST 34.602 -89 "Kushtet e referencës për krijimin e një sistemi të automatizuar";
• Llojet dokumentet e politikave GOST 19.101-77“Sistemi i unifikuar i dokumentacionit programor. Llojet e programeve dhe dokumentet e programit ". Këto përfshijnë manuale të ndryshme si p.sh. manuali i përdoruesit.
• Llojet dokumentet e projektimit të zhvilluara në faza të ndryshme të krijimit të AU përcaktohen nga GOST 2.102-2013“Sistemi i unifikuar për dokumentacionin projektues. Llojet dhe plotësia e dokumenteve të projektimit ". Për shembull, këto përfshijnë deklarata të një drafti dhe dizajni teknik, një listë të produkteve të blera, shënime shpjeguese për draftin, dizajne teknike.

Tani le të hedhim një vështrim më të afërt se si të përcaktojmë standardet e projektimit në projekte të ndryshme.

Regjistrimi i TK

Me TK, gjithçka është mjaft e qartë: në GOST 34.602-89, jepet standardi për hartimin e tij: klauzola 3.2. thotë se "TK për NPP-të është hartuar në përputhje me kërkesat e GOST 2.105 në fletët A4 në përputhje me GOST 2.301 pa kornizë, mbishkrimin kryesor dhe kolonat shtesë për të."

Regjistrimi i dokumentacionit të softuerit

Me dokumentet e programit të zhvilluara në kuadrin e një projekti IT, ekziston gjithashtu një udhëzim i qartë për përdorimin e serive GOST 19 për sa i përket dizajnit: GOST 19.101-77 e mësipërm është përfshirë në serinë e serisë GOST 19 "Sistemi i Unifikuar i Dokumentimit të Programit" ( ESPD). ESPD është një grup standardesh shtetërore të Federatës Ruse që vendosin rregulla të ndërlidhura për zhvillimin, hartimin dhe qarkullimin e programeve dhe dokumentacionit të programit.

Dokumentacioni në ESPD është hartuar në përputhje me GOST 19.104-78 "Sistemi i unifikuar i dokumentacionit të programit. Mbishkrimet bazë ", GOST 19.105-78" Sistemi i unifikuar i dokumentacionit të programit. Kërkesat e përgjithshme për dokumentet e programit ", GOST 19.106-78" Sistemi i unifikuar i dokumentacionit të programit. Kërkesat për dokumentet e programit të printuar”.

Regjistrimi i dokumentacionit të projektimit

Tani le të shqyrtojmë GOST 2.102-2013. Ky standard përfshihet në një seri GOST të serisë së dytë "Sistemi i unifikuar për dokumentacionin e projektimit" (ESKD). ESKD është një grup standardesh ndërshtetërore që vendosin norma dhe rregulla të ndërlidhura për zhvillimin, ekzekutimin dhe qarkullimin e dokumentacionit të projektimit të zhvilluar dhe zbatuar në të gjitha fazat e ciklit të jetës së produktit (gjatë projektimit, prodhimit, funksionimit, riparimit, etj.)

Dokumentacioni në ESKD hartohet sipas disa standardeve. Më të përdorurat prej tyre (në lidhje me sferën e TI-së) janë GOST 2.105-95 "Sistemi i unifikuar për dokumentacionin e projektimit. Kërkesat e përgjithshme për dokumentet e tekstit "dhe GOST 2.106-96" Sistemi i unifikuar për dokumentacionin e projektimit. Dokumentet e tekstit ".

Në shikim të parë, nuk është e qartë nga seria GOST 34 se si të hartoni dokumentacionin për AU. Shpesh, në kuadrin e një projekti IT, veçanërisht për klientët e qeverisë, TK përmban kërkesa për ekzekutimin e dokumentacionit në përputhje me GOST 2.105-95 dhe GOST 2.106-96. Por a duhet të hartohen dokumentet në përputhje me këto GOST nëse nuk ka kërkesa të qarta për regjistrim?

Si të rregulloni saktë?

Seria e 2-të GOST rendit kërkesat për qëllimin e secilit standard dhe tregon degën e aplikimit të tij: GOST 2.102-2013 - standardi përcakton llojet dhe plotësinë e dokumenteve të projektimit për produktet e të gjitha industrive.

Nëse GOST 2.102-2013 zbatohet për produktet e të gjitha industrive, përfshirë sektorin e IT, le ta kuptojmë, çfarë është një dokument projektimi?

Sipas GOST 2.001-2013 "Sistemi i unifikuar për dokumentacionin e projektimit (ESKD). Dispozitat e përgjithshme ":

A) "3.1.2 dokumenti i projektimit: Një dokument që, individualisht ose në kombinim me dokumente të tjera, përcakton dizajnin e produktit dhe ka pjesë thelbësore dhe të nevojshme, duke përfshirë nënshkrimet e vendosura "

B) “3.1.5 dokumentacioni i projektimit: Një grup dokumentesh projektimi që përmbajnë të dhënat e nevojshme për projektimin (zhvillimin), prodhimin, kontrollin, pranimin, dorëzimin, funksionimin, riparimin, modernizimin, asgjësimin e produktit "

Ne mund të ndalemi në këtë, duke krahasuar logjikisht kërkesat për përbërjen e dokumenteve të projektit tonë të IT me dispozitat e dhëna më sipër, dhe duke përcaktuar nëse secili prej dokumenteve i referohet dokumenteve të projektimit apo jo, dhe duke përfunduar dizajnin sipas standardeve të GOST 2 seri.

GOST-të kryesore të serisë së 2-të për një projekt IT për sa i përket dizajnit

Tani le të shohim GOST-të kryesore të serisë së 2-të, të cilat përdoren më shpesh për dokumente në një projekt IT. Si rregull, për sa i përket dizajnit ata përdorin:

GOST 2.105-95 - standardi përcakton kërkesat e përgjithshme për zbatimin e dokumenteve të tekstit për inxhinierinë mekanike, prodhimin e instrumenteve dhe produktet e ndërtimit;

GOST 2.106-96 - standardi përcakton format dhe rregullat për zbatimin e dokumenteve të projektimit për inxhinierinë mekanike dhe produktet e prodhimit të instrumenteve.

Lexuesi mund të ketë një pyetje, a mund t'i zbatojmë këto GOST për AU, nëse ato janë të destinuara për inxhinieri mekanike dhe instrumente?

Sipas përkufizimit të "Enciklopedisë së Madhe Sovjetike", "Instrumentbërja është një degë e inxhinierisë mekanike, që prodhon mjete matëse, analizë, përpunim dhe paraqitje informacioni, pajisje kontrolli, sisteme kontrolli automatike dhe të automatizuara; fusha e shkencës dhe teknologjisë, zhvillimi i mjeteve të automatizimit dhe sistemeve të kontrollit ", domethënë gjithçka që nevojitet në temën tonë të teknologjive moderne të informacionit.

Për më tepër, nëse shikoni GOST 34.003-90 "Sistemet e automatizuara. Termat dhe përkufizimet ", ky standard e përcakton AU si" një sistem i përbërë nga personeli dhe një grup mjetesh automatizimi për aktivitetet e tij, i cili zbaton teknologjinë e informacionit për kryerjen e funksioneve të vendosura".

Kështu, AU i përket industrisë së instrumenteve dhe, për rrjedhojë, dokumentet e projektimit të AU janë hartuar në përputhje me GOST 2.105-95 dhe GOST 2.106-96.

Tani le të shohim pikat kryesore të dokumentacionit të projektimit në përputhje me GOST 2.105-95 dhe GOST 2.106-96.

Pikat kryesore gjatë projektimit në përputhje me GOST 2.15

Konsideroni parametrat kryesorë të projektimit në përputhje me serinë 2-të GOST.

Sipas GOST 2.105-95, distanca nga korniza e formularit deri në kufijtë e tekstit në fillim dhe në fund të rreshtave duhet të jetë së paku 3 mm. Distanca nga rreshti i sipërm ose i poshtëm i tekstit në kornizën e sipërme ose të poshtme duhet të jetë së paku 10 mm. Paragrafët në tekst fillojnë me një pikë të barabartë me pesë goditje të makinës së shkrimit (15 - 17 mm).

GOST 2.105-95 nuk përcakton parametrat për formatimin e tekstit në formë elektronike: emrin e shkronjave, lartësinë e shkronjave, ndarjen e rreshtave. Prandaj, parametrat për përpunimin e dokumenteve në formë elektronike janë, si rregull, objekt i marrëveshjes me klientin.

Në fillim të punës për formatimin elektronik, përcaktohen parametrat për formatimin:

• Formati i paragrafëve të tekstit - fonti i përdorur, lartësia e shkronjave, hapësira e rreshtave;
• Formati për secilin titull sipas niveleve (1, 2, 3) - fonti i përdorur, lartësia e shkronjave, dhëmbëzimi në cm, hapësira midis rreshtave;

Tabela - fonti i përdorur i tekstit, hapësira e rreshtave, trashësia e kufijve të tabelës, gjerësia e tabelës, dhëmbëzimi i qelizës, titulli vendoset sipër tabelës. Formatimi i titullit të tabelës kryhet në të njëjtën mënyrë si për tekstin kryesor të dokumentit. Sipas GOST 2.105-95, lartësia e rreshtave të tabelës duhet të jetë së paku 8 mm. Lartësia e shkronjave të rreshtave të tabelës gjithashtu mund të bihet dakord me klientin.

Ilustrimet në dokument duhet të jenë të përqendruara. Titulli është vendosur direkt nën ilustrim. Formatimi i titullit është i njëjtë me tekstin e dokumentit.

Rregullat e formatimit të tabelës

Tabela, në varësi të madhësisë së saj, vendoset nën tekstin në të cilin është dhënë fillimisht lidhja me të, ose në faqen tjetër dhe, nëse është e nevojshme, në shtojcën e dokumentit.

Tabelat, me përjashtim të tabelave aneks, numërohen me numra arabë. Për shembull: "Tabela 1".

Tabelat e çdo shtojce përcaktohen me numërim të veçantë me numra arabë me shtimin e përcaktimit të aplikacionit përpara numrit. Për shembull: "Tabela B.1".

Lejohet numërimi i tabelave brenda një seksioni. Në këtë rast, numri i tabelës përbëhet nga numri i seksionit dhe numri i sekuencës së tabelës, të ndarë me një pikë. Për shembull, në seksionin 4 numri do të jetë "Tabela 4.3".

Emri i tabelës duhet të pasqyrojë përmbajtjen e saj, të jetë i saktë dhe konciz. Emri përbëhet nga fjala "Tabela", numri i tabelës dhe teksti. GOST 2.105-95 nuk specifikon përdorimin e vizës ose vizës në emrin e tabelës. Në praktikë, mund të përdoret një vizë, e ngjashme me përdorimin e një vize në emër të një fotografie. Për shembull, "Tabela 5 - Puna që do të kryhet, përmbajtja dhe termat". Nuk ka pikë në fund të emrit. Emri vendoset sipër tabelës në të majtë.

Në GOST 2.105-95, në pikën 4.4.3, jepet kërkesa e mëposhtme: "Të gjitha tabelat e dokumentit duhet të referohen në tekstin e dokumentit, kur lidhni, shkruani fjalën" tabelën "duke treguar numrin e tij". Në praktikë, fjala "tavolinë" refuzohet në tekst sipas rregullave të gjuhës ruse. Për shembull: "Një përshkrim i shkurtër i qëllimit dhe karakteristikave kryesore të nënsistemeve të fazës së dytë IS është paraqitur në Tabelën 1".

Nëse tabela shtrihet në shumë faqe, shfaqni titullin e saj në fillim të secilës faqe.

Në GOST 2.105-95 ekziston një kërkesë opsionale në pikën 4.4.7: "nëse në fund të faqes tabela ndërpritet dhe vazhdimi i saj do të jetë në faqen tjetër, lejohet të mos vizatoni vijën e poshtme horizontale që kufizon tabela në pjesën e parë të tabelës." Në praktikë vizatohet vija e poshtme horizontale, pasi mungesa e saj dëmton perceptimin e tabelës nga përdoruesi.

Rregullat e projektimit të ilustrimit

Ilustrimet përfshijnë imazhe grafike (diagrame, grafikë, fotografi, vizatime).

Ilustrimet, me përjashtim të ilustrimeve në shtojca, numërohen me numra arabë, me numërim të vazhdueshëm. Për shembull: "Figura 3".

Ilustrimet e çdo aplikacioni shënohen me numërim të veçantë me numra arabë me shtimin e përcaktimit të aplikacionit përpara numrit. Për shembull: "Figura B.6".

Lejohet numërimi i ilustrimeve brenda seksionit. Në këtë rast, numri i ilustrimit përbëhet nga numri i seksionit dhe numri vijues i ilustrimit, të ndarë me një pikë. Për shembull, në seksionin 5 numri do të jetë "Figura 5.2".

Lejohet të mos numërohen ilustrime të vogla (figura të vogla) të vendosura drejtpërdrejt në tekst dhe për të cilat nuk ka referenca të mëtejshme në tekst.

Kërkesat e GOST 2.105-95 për vendndodhjen: "ilustrimet mund të vendosen si në tekstin e dokumentit (sa më afër pjesëve përkatëse të tekstit), ashtu edhe në fund të tij."

Në GOST 2.105-95 në pikën 4.3.1 tregohet si më poshtë: "kur i referoheni ilustrimeve, duhet të shkruani" ... në përputhje me figurën 2 "me numërim të vazhdueshëm dhe" ... në përputhje me figurën 1.2 "me numërim brenda seksionit ".

Emri është shkruar nën ilustrim në formatin "Figura 1 - Detajet e instrumentit".

Një fakt interesant: nëse mbuloni një gabim në një dokument letre dhe shkruani një korrigjim sipër me bojë të zezë, ai do të jetë në përputhje me GOST. GOST 2.105-95 lejon korrigjimet e dokumenteve në formë letre. Kjo thuhet në pikën 3.7: “Gabimet, gabimet dhe pasaktësitë grafike të gjetura gjatë ekzekutimit të dokumentit mund të korrigjohen duke fshirë ose lyer me bojë të bardhë dhe duke aplikuar tekstin (grafikën) të korrigjuar në të njëjtin vend me metodën e shkrimit të makinës ose me bojë të zezë. , paste ose bojë me dorë. ... Dëmtimi i fletëve të dokumenteve të tekstit, njollave dhe gjurmëve të tekstit të mëparshëm të fshirë jo plotësisht (grafika) nuk lejohen."

Kjo do të thotë, nëse keni shtypur diçka dhe keni gjetur një gabim, atëherë mund ta korrigjoni manualisht duke përdorur metodën e mësipërme.

Dizajni sipas GOST 2. 106-96

GOST 2.106-96 përcakton format dhe rregullat për zbatimin e dokumenteve të projektimit. Për çdo lloj dokumenti, GOST 2.106-96 ofron një shabllon për hartimin e kornizave të dokumenteve.

GOST 2.106-96 përcakton jo vetëm formën e kornizave, por edhe mbishkrimin kryesor në kornizë. Një shembull nga GOST 2.106-96: "PZ është hartuar në formularët 9 dhe 9a të Shtojcës A, dhe diagramet, tabelat dhe vizatimet e nevojshme në formë letre mund të kryhen në fletë të çdo formati të përcaktuar nga GOST 2.301, ndërsa mbishkrimi kryesor dhe kolonat shtesë për të kryhen në përputhje me kërkesat e GOST 2.104 (formulari 2a) ".

Përmbledhje

Përveç sa më sipër, mund të thuhet se kur zhvillohet një AU në përputhje me GOST 34 në projektet e IT për agjencitë qeveritare, në mungesë të udhëzimeve të sakta në një kontratë shtetërore ose TK konkurruese, duhet të hartohet programi dhe dokumentacioni i projektimit. në përputhje me GOST-et e mëposhtme:

• Dokumentet e programit të zhvilluara në faza të ndryshme të krijimit të AU janë hartuar në përputhje me GOST 19.104-78, GOST 19.105-78, GOST 19.106-78;
• Dokumentet e projektimit të zhvilluara në faza të ndryshme të krijimit të një AU janë hartuar në përputhje me GOST 2.105-95 dhe GOST 2.106-96. Në të njëjtën kohë, kërkesat për përmbajtjen rregullohen me RD 50.34-698-90.

Është e nevojshme të kontrolloni GOST-et për rëndësinë dhe të përdorni rishikimin më të fundit të standardeve, pasi, megjithëse rrallë, ato janë ende të përditësuara. Shpresoj se ky artikull do t'ju ndihmojë të lundroni më mirë në kërkesat e GOST, dhe nëse është e nevojshme, mundeni gjithmonë