Označavanje dokumenata prema GOST-u 19. Dizajn programa prema GOST-u (kako). Vježba kompjuterske pismenosti
V.E. Karpov
Ovaj dokument sadrži kratak opis ESPD standarda čije je poznavanje neophodno studentima za izradu seminarskih radova i projekata vezanih za kreiranje softverskih sistema. Osim toga, može biti korisno u smislu poboljšanja kvaliteta programske dokumentacije općenito.
ZADATAK (GOST 19.201-78)
1. Opšte odredbe
FAZE RAZVOJA (GOST 19.102-77)
OPIS PROGRAMA (GOST 19.402-78)
TEKST PROGRAMA (GOST 19.401-78)
PROGRAM I METODE ISPITIVANJA (GOST 19.301-79)
ZAHTJEVI ZA PROGRAMSKA DOKUMENTA IZRAĐENA METODOM ŠTAMPE (GOST 19.106-78)
Standardizacija u oblasti softverske dokumentacije
Kako dalje
Priprema dokumentacije za softverske alate (PS) u skladu sa postojećim GOST-ovima
2. Opšte karakteristike države
2.3. Državni standardi Ruske Federacije (GOST R)
2.4. Međunarodni standard ISO/IEC 12207: 1995-08-01
Možda najneugodnija i najteža faza programiranja je izrada programske dokumentacije. Nažalost, to se obično ili uopće ne uči, ili, u najboljem slučaju, ne obraćaju dužnu pažnju na kvalitet primljenih dokumenata. Međutim, ovladavanje ovom vještinom često je jedan od najvažnijih faktora u određivanju kvaliteta programera.
Prvo, sposobnost kreiranja programske dokumentacije određuje profesionalni nivo programera. Kupac se neće upuštati u suptilnosti i značajke čak ni najdivnijeg programa. Kupac će prvo pročitati dokumentaciju. Psihološki faktor takođe igra važnu ulogu u tome. Konkretno, bivša sovjetska škola programiranja bila je cijenjena (i cijenjena je sada) u cijelom svijetu. Savremeni domaći programeri su prestali da se citiraju. Klasa nije ista. Danas se programi više ne pišu, već kompajliraju (a to su "dve velike razlike"). Dakle, paket softverske dokumentacije (u daljem tekstu PD) kreiran u "klasičnom" stilu ostaviće najpovoljniji utisak na vašeg kupca ili poslodavca. Pogotovo ako će autor PD-a izbjegavati fraze poput "klikni na traku za pomicanje...", "šraf" itd. Nažalost, takvo žargonsko brbljanje obično skriva ili oskudicu u mislima ili potpunu prazninu (autora je neizbrisivo dojmila priča jednog od njegovih poznanika o određenom „gejmeru“ koji je ili „ćaskao“ sa nekim tamo, ili se bavio „umerenošću“. “ Ili tako nešto.). Jezik PD je neka vrsta birokratskog, vrlo konzervativnog jezika. Ima svoj poseban šarm. Slažete se da termini hard disk, floppy disk drive, ručni manipulator poput "miš" (ili "kolobok", kako je to bilo u jednom od starih PD paketa) zvuče potpuno drugačije od odgovarajućih "šraf", "flop" i samo "miš". Inače, stvari su već stigle dotle da se, kažu, pojavila čak i posebna specijalnost - tehnički pisac, tj. osoba koja može kreirati softversku dokumentaciju.
Drugo, dobro sastavljen (tačnije kreiran) PD paket će vas spasiti od mnogih nevolja. Konkretno, možete se riješiti dosadnih pitanja i neosnovanih tvrdnji jednostavnim upućivanjem korisnika na dokumentaciju. To se prije svega tiče najvažnijeg dokumenta – Projektnog zadatka. O tome ćemo govoriti u nastavku, a sada se možemo prisjetiti višemilionske tužbe protiv IBM-a. Tužbu je podnijela velika izdavačka kuća, nezadovoljna kvalitetom BT-a i softvera. IBM je dobio slučaj. A pobijedila je samo zahvaljujući činjenici da je predstavila Projektni zadatak koji su potpisale obje strane. Bilo je to davno, davne 70-te, ali to ne mijenja suštinu stvari.
Još jedna stvar. Važno je kreirati prvi PD paket. Ovo će biti dovoljno za izgradnju svih narednih na njegovoj osnovi, koristeći ga kao model ili predložak. Ali to mora biti urađeno veoma dobro. Leisurely. Vrlo temeljno.
Prvo se morate naoružati GOST-ovima. GOST definiše sve. Konkretno, uključuje i Jedinstveni sistem programske dokumentacije (ESPD) koji nas zanima. Možda je najteže nabaviti sam GOST. GOST treba da bude samo u štampanom originalnom obliku. Prodaju se (barem je tako bilo) u specijaliziranim radnjama. Konkretno, za sticanje standarda u oblasti dokumentacije možete se obratiti sljedećim organizacijama:
- IPK "Izdavačka kuća Standardi", Teritorijalno odeljenje za distribuciju naučno-tehničke dokumentacije (prodavnica "Standardi"), 17961, Moskva, ul. Donskaya, d. 8, tel. 236-50-34, 237-00-02, fax/tel. 236-34-48 (u vezi GOST i GOST R).
- VNIIKI Državnog standarda Rusije (čitaonica), 103001, Moskva, Granatny per. 4, tel. 290-50-94 (u smislu međunarodnih, stranih standarda i drugih naučnih i tehničkih dokumenata).
I bez citata i sekundarnih izvora. GOST je zakon. I još više, nema interneta (zamislite da sud donese kaznu, koristeći ispis Krivičnog zakonika, preuzet sa nekog sajta). Ne vjerujte nikome osim originalu. Međutim, dalje će autor morati pribjeći citiranju ESPD-a, a sam sebe oslobađa svake odgovornosti.
Počnimo s općim odredbama o Jedinstvenom sistemu programske dokumentacije (koje su također definirane u odgovarajućem standardu GOST 19.001-77).
Jedinstveni sistem programske dokumentacije je skup državnih standarda koji uspostavljaju međusobno povezana pravila za izradu, izradu i promet programa i programske dokumentacije.
ESPD standardi definišu opšte odredbe i osnovne standarde, pravila za implementaciju razvojne dokumentacije, pravila za implementaciju proizvodne dokumentacije, pravila za implementaciju dokumentacije za održavanje, pravila za implementaciju operativne dokumentacije, pravila za rukovanje programskom dokumentacijom i drugim standardima. ESPD uključuje:
- temeljne i organizacione i metodološke standarde;
- standardi koji definišu forme i sadržaj programskih dokumenata koji se koriste u obradi podataka;
- standardi koji obezbeđuju automatizaciju izrade programskih dokumenata.
Općenito, lista ESPD dokumenata je veoma opsežna. Konkretno, uključuje sljedeće GOST-ove:
- GOST 19.001-77 ESPD. Opće odredbe.
- GOST 19.101-77 ESPD. Vrste programa i programski dokumenti (ponovno izdati u novembru 1987. sa izmjenama).
- GOST 19.102-77 ESPD. Faze razvoja.
- GOST 19.103-77 ESPD. Označavanje programa i programskih dokumenata.
- GOST 19.104-78 ESPD. Osnovni natpisi.
- GOST 19.105-78 ESPD. Opšti zahtjevi za programske dokumente.
- GOST 19.106-78 ESPD. Zahtjevi za programske dokumente izrađene u štampanom obliku.
- GOST 19.201-78 ESPD. Tehnički zadatak. Zahtjevi za sadržaj i dizajn.
- GOST 19.202-78 ESPD. Specifikacija. Zahtjevi za sadržaj i dizajn.
- GOST 19.301-79 ESPD. Program i postupak testiranja.
- GOST 19.401-78 ESPD. Tekst programa. Zahtjevi za sadržaj i dizajn.
- GOST 19.402-78 ESPD. Opis programa.
- GOST 19.404-79 ESPD. Objašnjenje. Zahtjevi za sadržaj i dizajn.
- GOST 19.501-78 ESPD. Forma. Zahtjevi za sadržaj i dizajn.
- GOST 19.502-78 ESPD. Opis aplikacije. Zahtjevi za sadržaj i dizajn.
- GOST 19.503-79 ESPD. Vodič za sistemskog programera. Zahtjevi za sadržaj i dizajn.
- GOST 19.504-79 ESPD. Programer's Guide.
- GOST 19.505-79 ESPD. Uputstvo za upotrebu.
- GOST 19.506-79 ESPD. Opis jezika.
- GOST 19.508-79 ESPD. Priručnik za održavanje. Zahtjevi za sadržaj i dizajn.
- GOST 19.604-78 ESPD. Pravila za izmjene programskih dokumenata koji se štampaju.
- GOST 19.701-90 ESPD. Šeme algoritama, programa, podataka i sistema. Konvencije i pravila izvršenja.
- GOST 19.781-90. Pružanje softvera za sisteme za obradu informacija.
Kao što vidite, glavni dio ESPD kompleksa razvijen je 70-ih i 80-ih godina. Ti standardi su jednim dijelom zastarjeli, a osim toga, nisu bez nekih nedostataka. Prvo, ne odražavaju neke moderne trendove u dizajnu programa i programske dokumentacije, a drugo, ovi standardi sadrže višestruko umnožavanje fragmenata programske dokumentacije. Međutim, zbog nedostatka boljeg načina, čovjek se mora fokusirati na njih.
Dakle, ESPD standardi pojednostavljuju proces dokumentovanja softverskih sistema. Međutim, prvo, sastav programskih dokumenata predviđen ESPD standardima uopće nije tako „rigidan“ kao što se može činiti: standardi dozvoljavaju uključivanje dodatnih tipova u skup dokumentacije softverskog sistema (PS), i, drugo, na osnovu zahtjeva kupaca, određene promjene kako u strukturi tako iu sadržaju uspostavljenih tipova PD. Štaviše, može se primijetiti da su ESPD standardi (a to vrijedi i za sve ostale standarde iz oblasti PS - GOST 34, Međunarodni standard ISO/IEC, itd.) savjetodavne prirode. Činjenica je da u skladu sa Zakonom Ruske Federacije "O standardizaciji" ovi standardi postaju obavezni na osnovu ugovora - tj. kada se na njih poziva u ugovoru za razvoj (nabavku) PS.
Prije nego što pređemo na razmatranje pravila za sastavljanje programske dokumentacije, potrebno je dati sljedeću napomenu. Svakom dokumentu poželjno je prethoditi nekim uvodom. Uvod je opšti. O relevantnosti, neophodnosti itd. Svrha Izvođača je da pokaže značaj i neophodnost obavljanja ovog posla. Početak je obično standardan: "Brojni sistemi koji trenutno postoje ... ... otvaraju stvarne izglede u ...", itd. Ovdje se obično ubacuju citati iz govora raznih ličnosti (ovo je čisto psihološki aspekt): "...kao što je rečeno na prošlom plenumu, kongresu, konferenciji itd.). Možete početi i od toga da ". .. Danas, u eri autohtonih društveno-ekonomskih transformacija... itd.“ Generalno, ovdje je glavna stvar ne pretjerati.
I dalje. Opisujući svoj proizvod, programer često brka koncepte komponente i kompleksa. To su različite vrste programa. Komponenta je definirana kao "program koji se razmatra kao cjelina, koji obavlja potpunu funkciju i koristi se samostalno ili kao dio kompleksa", a kompleks je "program koji se sastoji od dvije ili više komponenti i (ili) kompleksa koji obavljaju međusobno povezane funkcije , i koriste se samostalno ili unutar drugog kompleksa.
Prema GOST-u, ovaj standard (ponovno izdat u novembru 1987.) uspostavlja proceduru za izradu i izvršenje tehničkih specifikacija za razvoj programa ili softverskog proizvoda za računare, komplekse i sisteme, bez obzira na njihovu namjenu i opseg.
Moramo biti izuzetno pažljivi i pažljivi kada ga kreiramo, jer. često vješto (i kompetentno) sastavljen TOR određuje uspjeh cjelokupnog posla. To je TOR koji je dogovoren sa Kupcem, koji obično nastoji da postavi što više konfliktnih i preteranih zahteva. Zadatak Izvršitelja je, naprotiv, da sebi olakša život. Ali nakon što se stave potpisi sa obe strane, prekasno je da se bilo šta reproducira.
Projektni zadatak se sastavlja na listovima formata A4 i/ili A3, u pravilu, bez popunjavanja polja na listu. Brojevi listova (stranica) se stavljaju na vrh lista iznad teksta.
Za izmjene i dopune tehničke pozadine u narednim fazama razvoja programa ili softverskog proizvoda, izdaje se dodatak tome. Koordinacija i odobravanje dopuna projektnog zadatka vrši se na isti način kao što je utvrđeno za projektni zadatak.
Projektni zadatak treba da sadrži sljedeće dijelove:
- naziv i obim;
- osnova za razvoj;
- svrha razvoja;
- tehnički zahtjevi za program ili softverski proizvod;
- faze i faze razvoja;
- postupak kontrole i prihvatanja;
- aplikacije.
U zavisnosti od karakteristika programa ili softverskog proizvoda, dozvoljeno je razjasniti sadržaj sekcija, uvesti nove sekcije ili kombinovati neke od njih.
U poglavlju Naziv i opseg navesti naziv, kratak opis opsega programa ili softverskog proizvoda i objekt u kojem se program ili softverski proizvod koristi.
U poglavlju Osnova za razvoj mora biti navedeno:
- dokument (dokumenta) na osnovu kojeg se vrši razvoj;
- organizacija koja je odobrila ovaj dokument i datum njegovog odobrenja;
- naziv i (ili) simbol razvojne teme.
S obzirom na specifičnosti obrazovnog procesa, kao osnova može poslužiti zadatak za izradu predmeta, naredba za institut od __.__. za N ___., ugovor __.__. za N___. , i tako dalje.
U poglavlju Svrha razvoja mora biti naznačena funkcionalna i operativna svrha programa ili softverskog proizvoda. Ovdje se možete ograničiti na jednu ili dvije fraze. Glavna stvar je jasno definirati čemu služi ovaj program.
Na primjer: Program je jezgro automatizirane radne stanice (AWS) programera kontinuiranih linearnih automatskih upravljačkih sistema (ACS), koji omogućava korisniku rješavanje problema analize jednostavnih modela.
Poglavlje Tehnički zahtjevi za program ili softverski proizvod treba da sadrži sljedeće pododjeljke:
- zahtjevi za performanse;
- zahtjevi za pouzdanost;
- pravila korištenja;
- zahtjeve za sastav i parametre tehničkih sredstava;
- zahtjevi za kompatibilnost informacija i softvera;
- zahtjevi za etiketiranje i pakovanje;
- zahtjevi za transport i skladištenje;
- posebne zahtjeve.
Drugim riječima, ovdje počinju specifičnosti. Opisuje šta bi program trebao raditi i kako bi trebao izgledati.
zahtjevi performansi. Ovdje treba navesti zahtjeve za sastav izvršenih funkcija, organizaciju ulaznih i izlaznih podataka, vremenske karakteristike itd.
Na primjer: Program mora omogućiti ... izračunavanje ... izgradnju ... stvaranje ...
Početni podaci: tekstualni fajl sa datim ...
Izlazni podaci: grafičke i tekstualne informacije - rezultati analize sistema...; tekstualne datoteke - izvještaji o ... dijagnosticiranju stanja sistema i prijavljivanju svih grešaka koje su se dogodile.
zahtjevi za pouzdanost. Treba specificirati zahtjeve za osiguranje pouzdanog rada (osiguranje stabilnog rada, kontrola ulaznih i izlaznih informacija, vrijeme oporavka nakon kvara, itd.).
Teško je tu nešto "pogoditi". U najboljem slučaju može proći varijanta u kojoj vaš program radi samo sa apsolutno tačnim podacima. Obično Kupac ne pristaje na ovo, ali možete pokušati.
Na primjer: Program mora raditi sa datom proširenom matricom incidencije grafa koji se proučava u skladu s algoritmom funkcioniranja, izdavati poruke o grešci ako su početni podaci pogrešno navedeni, podržavati interaktivni način rada u okviru mogućnosti koje se pružaju korisniku .
Pravila korištenja. Moraju biti specificirani uslovi rada (temperatura ambijentalnog vazduha, relativna vlažnost itd. za odabrane tipove nosača podataka), pod kojima se moraju obezbediti navedene karakteristike, kao i vrsta usluge, potreban broj i kvalifikacije osoblja.
Sa ovom tačkom poteškoće obično ne nastaju. Nažalost, poentu o profesionalnosti korisnika nužno implicira Kupac. Ovo je, naravno, još jedan razlog da pronađete grešku u svom programu. Međutim, ovdje se možete ograničiti na fraze poput "Uvjeti rada programa poklapaju se sa radnim uvjetima IBM PC-a i kompatibilnih PC-a", "Program bi trebao biti dizajniran za neprofesionalnog korisnika." i tako dalje.
Zahtjevi za sastav i parametre tehničkih sredstava. Navesti potreban sastav tehničkih sredstava sa naznakom njihovih tehničkih karakteristika.
Ovdje je najvažnije ništa ne zaboraviti i predvidjeti sve, s jedne strane (inače će im skliznuti neki IBM PC/XT sa monohromatskim displejom i bez miša), as druge strane, ne pretjerivati sa povećanim zahtjevima, u suprotnom će Kupac pronaći ugodnijeg Izvođača.
Na primjer: Potreban vam je IBM PC kompatibilan PC s EGA (VGA) grafičkim adapterom. Potreban prostor na disku je najmanje 600 Kb, količina slobodnog RAM-a je najmanje 400 Kb. Poželjno je imati EMS drajver i miš.
Zahtjevi za informacije i kompatibilnost softvera. Karakteristike su iste kao u prethodnom paragrafu. Ovdje treba navesti zahtjeve za informacijske strukture na ulazu i izlazu i metode rješenja, izvorne kodove, programske jezike. Gdje je potrebno, informacije i programi trebaju biti zaštićeni.
Na primjer: Program mora raditi autonomno pod MS DOS verzijom 3.3 ili novijom. Osnovni programski jezik je Turbo Pascal 6.0.
Zahtjevi za etiketiranje i pakovanje i zahtjevi za transport i skladištenje su prilično egzotični. U opštem slučaju, ovde su naznačeni zahtevi za označavanje softverskog proizvoda, opcije i načini pakovanja. A u zahtevima za transport i skladištenje, za softverski proizvod treba navesti uslove za transport, mesta skladištenja, uslove skladištenja, uslove skladištenja, periode skladištenja u različitim uslovima.
Posebni zahtjevi su vrlo odgovorna stvar. Najbolje ih je izbjegavati što je više moguće. I objavite to odmah.
Na primjer: Ne postoje posebni zahtjevi za vremenske karakteristike programa. Ne postoje posebni zahtjevi za kapacitivne karakteristike programa.
Tehnički i ekonomski pokazatelji. Ova najteža stavka za programera nije uvijek tu. Potreban je prvenstveno kada vam je cilj da opravdate ogromnu efektivnost i značaj obavljenog posla. Ova stavka obično radi veoma dobro za Kupca. Barem, ovo je najbolje opravdanje za vrijeme i cijenu razvoja.
U ovom dijelu treba navesti: procijenjenu ekonomsku efikasnost, procijenjenu godišnju potrebu (na primjer: procijenjeni broj poziva u kompleks u cjelini godišnje je 365 radnih sesija), ekonomske prednosti razvoja u odnosu na najbolje domaće i strane uzorke ili analozi.
Pored toga, poželjno je dati definiciju i procijenjenih troškova razvoja programa i definiciju složenosti programiranja.
Faze i faze razvoja(o tome više u nastavku) utvrditi potrebne faze razvoja, faze i sadržaj rada (spisak programskih dokumenata koji se moraju izraditi, usaglasiti i odobriti), kao i, po pravilu, vremenski okvir izrade i odrediti izvršioce.
Ovdje su opisani standardni koraci. Glavna stvar je pravilno odrediti vrijeme. Ako je moguće, pokušajte ravnomjerno rasporediti faze prema vremenu (i količini). Zapamtite da svi projekti ne dođu do posljednje faze. I izvještaji bi trebali biti na svakoj fazi. Imajte na umu da će radni projekat oduzeti najviše vremena. Ukoliko nemate vremena da na vrijeme kompletirate dokumentaciju, tada Kupac ima pravo da se uopće ne prihvati posla sa svim posljedicama koje proizilaze.
Glavne i nezaobilazne faze i faze su sam projektni zadatak, nacrt, tehnički i radni projekti.
- Idejni projekat. U ovoj fazi detaljno se razvijaju strukture ulaznih i izlaznih podataka, određuje se oblik njihovog prikaza. U toku je razvoj opšteg opisa algoritma, samog algoritma i strukture programa. U toku je izrada akcionog plana za razvoj i implementaciju programa.
- Tehnički projekat. Sadrži razvijeni algoritam za rješavanje problema, kao i metode za kontrolu početnih informacija. Takođe razvija alate za obradu grešaka i izdavanje dijagnostičkih poruka, utvrđuje oblike prezentacije početnih podataka i konfiguraciju tehničkih sredstava.
- Radni projekat. U ovoj fazi se vrši programiranje i otklanjanje grešaka u programu, razvoj programskih dokumenata, programa i metoda ispitivanja. U pripremi su primjeri testiranja i otklanjanja grešaka. Dokumentacija i grafički materijal su finalizirani. Obično se navodi da tokom izrade programa treba pripremiti sljedeću dokumentaciju:
- tekst programa;
- opis programa;
- program i metodologija testiranja;
- opis aplikacije;
- korisnički vodič.
Ovo su standardni zahtjevi. Ako se Kupac slaže da se ne može dostaviti sva ova lista, to znači da njegove namjere u vezi s vama i vašim proizvodom nisu ozbiljne.
Grafika može ili ne mora biti dostupna. Pogotovo kada nećete izvještavati o rezultatima svog rada. Ali za ozbiljne projekte, ova stavka je neophodna.
Na primjer: Tokom izrade programa potrebno je pripremiti sljedeći grafički materijal:
- tehnički i ekonomski pokazatelji;
- struktura programa;
- format za predstavljanje ulaznih podataka programa;
- opšta šema algoritma (2 lista);
- osnovni računski algoritmi;
- primjer programa.
U poglavlju Procedura kontrole i prihvatanja treba navesti vrste ispitivanja i opšte uslove za prijem radova. Ako je moguće, u ovom paragrafu naznačite da se „kontrola i prihvatanje razvoja vrše na opremi koju je obezbedio Kupac“, u suprotnom se može tražiti da opremu ponesete sa sobom.
Na primjer: Kontrola i prihvatanje razvoja vrše se na osnovu testova kontrole i primjera za otklanjanje grešaka. Time se provjerava izvršenje svih programskih funkcija.
IN Prijave do projektnog zadatka, ako je potrebno, dovesti:
- spisak istraživačkih i drugih radova koji potkrepljuju razvoj;
- algoritamske šeme, tabele, opisi, opravdanja, proračuni i drugi dokumenti koji se mogu koristiti u razvoju;
- drugi izvori razvoja.
Ovaj standard utvrđuje faze razvoja programa, programske dokumentacije, kao i faze i sadržaj rada:
Faze razvoja |
Faze rada |
|
Tehnički zadatak |
Obrazloženje potrebe za razvojem programa |
Formulacija problema. |
Istraživački rad |
Određivanje strukture ulaznih i izlaznih podataka. |
|
Izrada i odobrenje projektnog zadatka |
Određivanje uslova za program. |
|
Idejni projekat |
Izrada nacrta dizajna |
Preliminarni razvoj strukture ulaznih i izlaznih podataka. |
Odobrenje idejnog projekta |
|
|
Tehnički projekat |
Izrada tehničkog projekta |
Rafiniranje strukture ulaznih i izlaznih podataka. |
Odobrenje tehničkog projekta |
Izrada akcionog plana za razvoj i implementaciju programa. |
|
radni nacrt |
Razvoj programa |
Programiranje i otklanjanje grešaka u programu |
Izrada programske dokumentacije |
Izrada programskih dokumenata u skladu sa zahtjevima GOST 19.101-77. |
|
Probe programa |
Razvoj, koordinacija i odobravanje programa i metoda ispitivanja. |
|
Implementacija |
Priprema i prijenos programa |
Priprema i prenos programske i programske dokumentacije za održavanje i (ili) proizvodnju. |
napomene:
- Dozvoljeno je isključiti drugu fazu razvoja, au tehnički opravdanim slučajevima - drugu i treću fazu. Potreba za ovim fazama je naznačena u projektnom zadatku.
- Dozvoljeno je kombinovanje, isključivanje faza rada i (ili) njihovog sadržaja, kao i uvođenje drugih faza rada po dogovoru sa kupcem.
Ovaj standard se fokusira na dokumentovanje rezultirajućeg razvojnog proizvoda.
Strogo govoreći, postoje dva različita dokumenta koja, međutim, imaju mnogo zajedničkog. To su OPŠTI OPIS (GOST 19.502-78) i OPIS PROGRAMA (GOST 19.402-78). Međutim, s obzirom na to da je vrlo teško kvalitetno kreirati i jedno i drugo, a da se ne pribjegne gotovo potpunom umnožavanju, otkidanju komada, bilo bi dovoljno implementirati jedan, opštiji, "hibridni" dokument. Nazovimo ga "Opis programa".
Zapravo, "Opis programa" u svom sadržaju može biti dopunjen odjeljcima i paragrafima preuzetim iz standarda za druge opisne dokumente i priručnike: GOST 19.404-79 ESPD. Objašnjenje, GOST 19.503-79 ESPD. Priručnik sistemskog programera, GOST 19.504-79 ESPD. Priručnik za programera, GOST 19.505-79 ESPD. Uputstvo za upotrebu itd. Konkretno, iz Objašnjenja se može uzeti šema algoritma, opšti opis algoritma i (ili) funkcionisanja programa, kao i obrazloženje usvojenih tehničko-tehničkih i ekonomskih rešenja.
Opis programa mora obavezno sadržavati informativni dio - napomenu i sadržaj.
Glavni dio dokumenta treba da se sastoji od uvodnog dijela i sljedećih dijelova:
- funkcionalna namjena;
- opis logike.
- uslovi korišćenja;
- sastav i funkcije.
U zavisnosti od karakteristika programa, dozvoljeno je uvođenje dodatnih sekcija.
IN Uvodni dio dokument daje općenite informacije o programu - puni naziv, oznaku, njegove moguće primjene itd.
Na primjer: Program "Automatsko radno mjesto programera ACS-a" namijenjen je ... implementiranom na .... Program podržava...
U poglavlju Svrha navesti svrhu programa i dati opšti opis funkcionisanja programa, njegove glavne karakteristike, informacije o ograničenjima nametnutim obima programa, a takođe navesti vrste elektronskih računara i uređaja koji se koriste u radu .
Na primjer: Program je dizajniran za rješavanje problema... Program je srž automatiziranog radnog mjesta...
Korisnik ima mogućnost da ..., implementira ..., pokreće ..., analizira ..., dobije rezultate analize i obrade ..., gradi ... itd.
u poglavlju " Opis logike" ukazati:
- opis strukture programa i njegovih glavnih dijelova
(na primjer: Program uključuje sljedeće:
- korisnički interfejs,
- modul za određivanje putanja u grafu,
- modul za proračun prijenosne funkcije,
- modul za konstruisanje amplitudnih i fazno-frekventnih karakteristika,
- modul za konstruisanje odgovora na polinomsku akciju,
- uređivač teksta).
- opis funkcija sastavnih dijelova i odnosa među njima;
Na primjer: Program se sastoji od šest modula: modul interfejsa; modul definicije ...; proračunski modul ...; modul…itd..
Modul interfejsa je izgrađen na dva tipa dijaloga: dijalog "pitanje - odgovor" i dijalog tipa "meni". Interfejs modul upravlja...
Definicijski modul... To je...
Kalkulacijski modul...itd.
- informacije o programskom jeziku;
Na primjer: Program je napisan na jeziku ... pomoću kompajlera ...
- opis ulaznih i izlaznih podataka za svaku od komponenti;
Na primjer: ULAZNI PODACI. Ulazni podaci za program je tekstualna datoteka koja opisuje proširenu matricu incidencije grafa sistema koji se proučava.
IZLAZ. Izlaz je:
- grafičke i tekstualne informacije prikazane na ekranu (rezultati analize sistema);
- datoteke u jednom od grafičkih formata - kopije slike konstruisanih karakteristika (frekventni odziv, fazni odziv itd.);
- tekstualne datoteke - istraživački izvještaji;
- dijagnosticiranje stanja sistema i prijavljivanje svih grešaka koje su se dogodile.
- opis logike sastavnih dijelova (ako je potrebno, treba sastaviti opis programskih šema).
Prilikom opisivanja programske logike potrebno je povezati se sa tekstom programa.
U poglavlju Sastav i funkcije navesti opis sastava i funkcija programa, primijenjene metode za rješavanje problema.
U poglavlju Uslovi primjene naznačeni su uslovi neophodni za realizaciju programa (zahtjevi za tehničkim sredstvima potrebnim za ovaj program, i druge programe, opšte karakteristike ulaznih i izlaznih informacija, kao i zahtjevi i uslovi organizacione, tehničke i tehnološke prirode i dr. .).
Na primjer: Programom se upravlja na osobnom računalu (PC) kao što je IBM PC/AT. Za rad u interaktivnom režimu koriste se ekran, tastatura i miš. EGA (VGA) adapter je neophodan za podršku grafičkog režima. Ulazni podaci se pohranjuju na flopi i/ili hard diskove. Program radi na OS...
Referentni materijali (ilustracije, tabele, grafikoni, primjeri, itd.) mogu biti uključeni u dodatak opisu.
I ne zaboravite uključiti naziv modula za pokretanje kao i opis cijele procedure.
Sistem poziva i pokretanja
Zahtjevi za dizajn teksta programa prilično su jednostavni i prirodni za kompetentnog programera. Glavna stvar kojom se treba voditi pri kreiranju ovog dokumenta je da tekst programa bude čitljiv.
I dalje je obavezno izraditi informativni dio – napomene i sadržaj.
Glavni dio dokumenta treba da se sastoji od tekstova jednog ili više odjeljaka koji imaju naslove.
Tekst svake programske datoteke počinje "zaglavljem", što označava:
- naziv programa,
- autor,
- datum kreiranja programa,
- broj verzije
- datum posljednje izmjene.
Komentari su obavezni, kao i striktno poštovanje pravila uvlačenja. Zapamtite, čak i nemogućnost pisanja programske dokumentacije može biti opravdana. A ružan tekst programa - nikad. Pozivanje na činjenicu da je ovaj tekst jasan i samom autoru ne shvataju se ozbiljno. Programski tekstovi ne treba da se stide da ih čitaju drugi ljudi.
Ispod je primjer ovako dobro pročitanog programskog teksta (preuzeto sa web stranice Nikolaja Gechta, e-mail: [email protected], http://users.omskreg.ru/~geht)
/* Windows izvori"98
Izvorni kod za Windows 98 */ #include "win31.h" #include "win95.h" #include "evenmore.h" #include "oldstuff.h" #include "billrulz.h" #include "monopoly.h" # define INSTALL = HARD char make_prog_look_big; void main() ( while(!CRASHED) ( display_copyright_message(); display_bill_rules_message(); do_nothing_loop(); if(first_time_installation) ( make_50_megabyte_swapfile(); do_nothing_loop(); totally_screw_fil_up_HP_System(the_screw_fil_up_HPstroy); disable_RealPlayer(); disable_Corel_Products(); hang_system(); ) write_something(anything); display_copyright_message(); do_nothing_loop(); do_some_stuff(); if(i dalje_not_crashed) (display_copyright_message(); do_nothing_nothing_ru_;do_nothing_loop(1_nothing_loop); (); do_nothing_loop(); ) ) if(detect_cache()) disable_cache(); if(fast_cpu()) (set_wait_states(lots); set_mouse(brzina, vrlo_spor); set_mouse(akcija, skakanje); set_mouse(reakcija, ponekad ); ) /* printf("Dobrodošli u Windows 3.11"); */ /* printf("Dobrodošli u Windows 95"); */ printf("Dobrodošli u Windows 98"); if(system_ok()) crash(to_dos_prompt ) else system_memory = open("a:\swp0001.swp", O_CREATE); while(nešto) ( sleep(5); get_user_input(); spavanje(5); act_on_user_input(); spavanje(5); ) create_general_protection_fault();
Ovaj dokument sadrži opis onoga što treba učiniti i kako osigurati (i uvjeriti Kupca) da program radi ispravno. U stvari, ovaj dokument je odlučujući za testove prihvatanja. Dobro osmišljen program i metodologija testiranja je ključ za potpisivanje potvrde o prihvatanju, tj. onaj za koji ste potrošili toliko vremena i truda.
Formalno, ovaj GOST se koristi za izradu planskih dokumenata i provođenje testnih radova za procjenu spremnosti i kvaliteta softverskog sistema. Dokument sadrži opis predmeta i svrhe testiranja, zahteve za programsku i softversku dokumentaciju, način i postupak testiranja, kao i opis test slučajeva.
Komponente ovog dokumenta je lakše i jasnije odmah opisati u obliku primjera.
Testni objekat
Primjer: Testni objekt je program ... dizajniran za ...
Svrha testiranja
Primjer: Provjera pouzdanosti programa.
Programski zahtjevi
Primjer: Rad programa ne smije dovesti do kvara (fatalnog prekida rada sistema). Organizacija dijaloga treba da obezbedi zaštitu od unošenja netačnih podataka. Program bi trebao izdati dijagnostiku stanja sistema i poruke o svim greškama koje su se dogodile... i tako dalje.
Zahtjevi za softversku dokumentaciju
Primjer: Sastav programske dokumentacije predstavljene na testiranje:
- opis programa (GOST 19.402-78);
- program i metodologija ispitivanja (GOST 19.301-79);
- tekst programa (GOST 19.401-78).
Sredstva i postupak ispitivanja
Primjer: Program radi u skladu sa radnim uvjetima MS DOS-a (verzija 3.0 ili novija) na PC-u kao što je IBM PC/AT, kao i kompatibilan s njim. Za rad je također potreban EGA (VGA) adapter.
Procedura testiranja:
- Program je pokrenut...
- Odabrano…
- Pritisnuto...
- Selektivno odabrano...
Test Cases
Primjer: Za testiranje su ponuđeni ... čiji je opis sadržan u datotekama ... Sadržaj testnih datoteka i rezultati programa dati su u Dodatku 1.
I na kraju, razmotrite najnoviji ESPD standard, koji se zove
Ovim standardom utvrđuju se pravila za implementaciju programskih dokumenata za računare, komplekse i sisteme, bez obzira na njihovu namjenu i obim i predviđena ESPD standardima.
Opšti zahtjevi. U programske dokumente izrađene kucanim, mašinskim i rukopisnim načinom potrebno je uneti pojedinačne riječi, formule, simbole (ručno u crtežnom fontu), slova latinskog i grčkog alfabeta, kao i popuniti dijagrame i crteže crnom tintom ili mastilo.
Greške i grafičke netačnosti uočene prilikom izvođenja mogu se ispraviti brisanjem loše izvedenog dijela teksta (crtež) i nanošenjem ispravljenog teksta (grafika) na isti list kucanjem ili crnom tintom, ovisno o načinu izrade dokumenta.
Oštećenje listova dokumenata, mrlje i tragovi nepotpuno izbrisanog teksta (grafika) nisu dozvoljeni.
Programski dokumenti se sastavljaju na listovima A4 formata. Osim toga:
- prihvatljiv je dizajn na listovima A3 formata;
- kod mašinskog načina izrade dokumenata dozvoljena su odstupanja u veličini listova koji odgovaraju formatima A4 i A3, a određena su mogućnostima korišćenih tehničkih sredstava; na listovima formata A4 i A3, predviđenim izlaznim karakteristikama uređaja za izlaz podataka, pri mašinskoj izradi dokumenta;
- pri izradi dokumenta na tipografski način moguće je koristiti listove tipografskih formata.
Lokacija materijala programskog dokumenta vrši se u sljedećem redoslijedu:
- naslovni dio:
- list odobrenja (nije uključen u ukupan broj listova dokumenata);
- naslovna stranica (prva stranica dokumenta);
- informativni dio:
- anotacija;
- list sadržaja;
- glavni dio:
- tekst dokumenta (sa slikama, tabelama itd.);
- lista pojmova i njihovih definicija;
- lista skraćenica;
- aplikacije;
- predmetni indeks;
- spisak referentnih dokumenata;
- dio evidencije:
- promijeniti registarski list.
Izrada dokumenta. Ako je potrebno, dokument se može podijeliti na dijelove. Podjela na dijelove vrši se na nivou koji nije niži od presjeka. Svaki dio se popunjava posebno, dok na kraju sadržaja prvog dijela treba navesti nazive preostalih dijelova.
Dozvoljeno je u dokument uključiti dijelove programskog teksta, koji su sastavljeni u skladu s pravilima jezika na kojem je programski tekst napisan.
Sažetak se nalazi na posebnoj stranici (stranicama), sa naslovom "SAŽETAK", numerisan i uključen u sadržaj dokumenta.
Tekst svakog dokumenta, po potrebi, dijeli se na paragrafe, a pasuse na podstavke, bez obzira na to da li je dokument podijeljen na dijelove, odjeljke i pododjeljke ili ne.
Naslovi sekcija pišu se velikim slovima i postavljaju simetrično u odnosu na desnu i lijevu ivicu teksta. Podnaslovi se iz pasusa pišu malim slovima (osim prvog velikog). Prevođenje riječi u naslovima nije dozvoljeno. Ne stavljajte tačku na kraj naslova. Preporučuje se da svaki odjeljak počne na novom listu.
Odjeljci, pododjeljci, stavovi i podstavovi trebaju biti numerisani arapskim brojevima sa tačkom. Sekcije moraju imati serijski broj (1, 2, itd.)
Tekst dokumenta. Tekst dokumenta treba da bude kratak, jasan, isključujući mogućnost pogrešnog tumačenja. Termini i definicije moraju biti jednoobrazni i usklađeni sa utvrđenim standardima, a u njihovom odsustvu - opšteprihvaćenim u naučnoj i tehničkoj literaturi, i dati u spisku pojmova.
Potrebna objašnjenja teksta dokumenta mogu se sagledati fusnotama. Fusnota je označena brojem sa zagradom postavljenom na nivou gornje ivice fonta.
Ako se fusnota odnosi na jednu riječ, znak fusnote se stavlja neposredno uz ovu riječ, a ako se odnosi na cijelu rečenicu, onda na kraju rečenice. Tekst fusnote se nalazi na kraju stranice i odvojen od glavnog teksta linijom dužine 3 cm povučenom na lijevoj strani stranice.
Ilustracije. Ilustracije se mogu nalaziti u tekstu dokumenta i (ili) u aplikacijama. Ilustracije, ako ih ima više u ovom dokumentu, numerisane su arapskim brojevima unutar cijelog dokumenta.
U prilozima su ilustracije numerisane unutar svakog dodatka redosledom utvrđenim za glavni tekst dokumenta. Reference na ilustracije date su po tipu: "Sl. 12" ili "(Sl. 12)". Ilustracije mogu imati tematski naslov i slikovni tekst koji objašnjava sadržaj ilustracije.
Formule. Formule u dokumentu, ako ih ima više, numerišu se arapskim brojevima, broj se stavlja na desnu stranu stranice, u zagradama na nivou formule. Unutar cijelog dokumenta ili njegovih dijelova, u slučaju podjele dokumenta na dijelove, formule imaju kontinuiranu numeraciju.
Reference u tekstu na redni broj formule date su u zagradama, na primjer: "u formuli (3)". Prilikom podjele dokumenta na dijelove, broj dijela se stavlja ispred rednog broja formule i odvaja od posljednje točke, na primjer: "u formuli (1.4)".
Značenje simbola uključenih u formulu mora biti navedeno direktno ispod formule. Vrijednost svakog znaka ispisuje se u novom redu redoslijedom kojim su dati u formuli. Prvi red za dešifriranje mora početi riječju "gdje", bez dvotočke iza nje.
Linkovi. Reference na standarde i druge dokumente su dozvoljene u dokumentima politike. Treba se pozvati na dokument u cjelini ili na njegove dijelove (navodeći naziv i naziv dokumenta, broj i naziv odjeljka ili dodatka).
Dozvoljeno je navesti samo oznaku dokumenta i (ili) odjeljaka bez navođenja njihovih naziva. Veze ka pojedinačnim pododeljcima, paragrafima i ilustracijama drugog dokumenta nisu dozvoljene. Reference unutar dokumenta na paragrafe, ilustracije i pojedinačne pododjeljke su dozvoljene.
Bilješke. Napomene uz tekst i tabele navode samo referentne i pojašnjene podatke. Jedna napomena nije numerisana. Nakon riječi "Napomena" stavite tačku. Nekoliko napomena treba uzastopno numerisati arapskim brojevima sa tačkom. Nakon riječi "Napomena" slijedi dvotočka. Tekst napomena je dozvoljeno štampati samo sa jednim proredom.
Skraćenice. Skraćenice riječi u tekstu i natpisi ispod ilustracija nisu dozvoljene, osim:
- skraćenice utvrđene u GOST 2.316-68 i općenito prihvaćene na ruskom jeziku;
- Skraćenice koje se koriste za označavanje programa, njihovih dijelova i načina rada, u jezicima za upravljanje poslovima, u alatima za podešavanje programa, itd., označene slovima latinice.
Prijave. Ilustrovani materijal, tabele ili tekstovi pomoćne prirode mogu se sastaviti u obliku prijava. Aneksi su raspoređeni kao nastavak ovog dokumenta na narednim stranicama ili se izdaju kao poseban dokument.
Svaka prijava mora početi na novoj stranici s riječju "Prijava" u gornjem desnom kutu i imati tematski naslov. Ako u dokumentu postoji više od jedne aplikacije, sve aplikacije su numerisane arapskim brojevima (bez znaka broja), na primjer:
Dodatak 1, Dodatak 2, itd.
Kada se prijava izdaje kao poseban dokument, na naslovnoj strani ispod naziva dokumenta treba navesti riječ "Prijava", a ako je prijava više, navesti i njegov serijski broj.
G O S U D A R S T V E N N Y S T A N D A R T S O YU Z A S S R
Jedinstveni sistem programske dokumentacije |
GOST 19.003-80Umjesto togaGOST 19428-74 |
ŠEME ALGORITAMA I PROGRAMA OZNAČAVANJE USLOVA GRAFIKA |
|
Jedinstveni sistem programske dokumentacije. Simboli grafičkog dijagrama toka. |
Uredbom Državnog komiteta SSSR-a o standardima od 24. aprila 1980. br. 1867, rok za uvođenje
od 01.07.1981
Ovaj standard se primenjuje na konvencionalne grafičke simbole (simbole) u šemama algoritama i programa koji prikazuju glavne operacije procesa obrade podataka i programiranja za softverske sisteme računara, kompleksa i sistema, bez obzira na njihovu namenu i opseg.
Standard se ne primjenjuje na unose i oznake smještene unutar simbola ili pored njega, a koje služe za pojašnjenje funkcija koje on obavlja.
Standard uspostavlja listu, naziv, oblik, veličinu simbola i funkcije koje se prikazuju simbolima.
Standard je usklađen sa MS ISO 1028-73 u pogledu simbola
1. LISTA, NAZIV, OZNAKA SIMBOLA I FUNKCIJA KOJE IH PRIKAZU
1.1. Lista, naziv, oznaka i veličine obaveznih simbola i funkcija koje oni prikazuju u algoritmu i programu za obradu podataka moraju odgovarati onima navedenim u tabeli. 1.
Tabela 1.
Ime |
Oznaka i dimenzije u mm |
Funkcija |
1. Proces |
|
Izvođenje operacija ili grupe operacija koje mijenjaju vrijednost, oblik predstavljanja ili lokaciju podataka |
2. Rješenje |
|
Odabir smjera izvršavanja algoritma ili programa ovisno o nekim varijabilnim uvjetima |
3. Modifikacija |
|
Izvođenje operacija koje mijenjaju naredbe ili grupe naredbi koje mijenjaju program |
4. Unaprijed definirani proces | Upotreba prethodno kreiranih i posebno opisanih algoritama ili programa | |
5. Ručni rad |
|
Autonomni proces, koji se izvodi ručno ili neautomatskim sredstvima |
6. Pomoćni rad | Samostalni proces koji izvršava uređaj koji nije direktno kontroliran od strane procesora | |
7. Spajanje | Kombinovanje dva ili više setova u jedan set | |
8. Istaknite |
|
Uklanjanje jednog ili više skupova iz jednog skupa |
9. Grupisanje |
|
Unija dva ili više skupova sa izborom nekoliko drugih setova |
10. Sortiraj |
|
Naručivanje seta prema zadatim kriterijumima |
11. Ručni unos |
|
Ručni unos podataka pomoću on-line uređaja sa tastaturom, kompletom prekidača, dugmadi |
12. Ulaz-izlaz |
|
Pretvaranje podataka u oblik pogodan za obradu (ulaz) ili prikaz rezultata obrade (izlaz) |
13. On-line memorija |
|
Ulazno-izlazni podaci u slučaju korištenja uređaja za pohranu koji kontrolira direktno procesor |
14. Offline memorija | Unos/izlaz podataka u slučaju korištenja uređaja za pohranu koji nije kontroliran direktno od strane procesora | |
15. Dokument |
|
Unos-izlaz podataka čiji je nosilac papir |
16. Bušene kartice |
|
Ulaz-izlaz podataka čiji je nosilac bušena kartica |
17. Špil bušenih karata |
|
Prikaz kompleta bušenih kartica |
18. Fajl |
|
Predstavljanje podataka organizovano na osnovu zajedničkih karakteristika, koje u zbiru karakterišu neki objekat obrade podataka. Simbol se koristi u kombinaciji sa simbolima specifičnih nosača podataka koji obavljaju I/O funkcije. |
19. Perforirana traka |
|
Ulaz-izlaz podataka, čiji je nosilac bušene trake |
20. Magnetna traka | Ulaz-izlaz podataka, čiji je nosilac magnetna traka | |
21. Magnetski bubanj |
|
Ulaz-izlaz podataka, čiji je nosilac magnetni bubanj |
22. Magnetni disk |
|
Ulaz-izlaz podataka, čiji je nosilac magnetni disk |
23. RAM |
|
Ulaz-izlaz podataka čiji je nosilac magnetno jezgro |
24. Displej | Unos-izlaz podataka, ako uređaj koji je direktno povezan s procesom reproducira podatke i omogućava operateru računala da izvrši promjene tokom njihove obrade | |
25. Komunikacijski kanal |
|
Prijenos podataka komunikacijskim kanalima |
26. Protočni vod |
|
Određivanje redosleda između znakova |
27. Paralelne radnje |
|
Početak ili kraj dvije ili više istovremenih operacija |
28. Konektor |
|
Označavanje veze između prekinutih vodova protoka, povezujući simboli |
29. Start - stop |
|
Početak, završetak, prekid obrade podataka ili izvršavanja programa |
30. Komentar |
|
Odnos između shematskog elementa i objašnjenja |
1.2. Lista, naziv, oznaka i veličine preporučenih simbola i funkcija koje oni prikazuju u algoritmu i programu za obradu podataka moraju odgovarati onima navedenim u tabeli. 2.
tabela 2
Ime |
Oznaka i dimenzije u mm |
Funkcija |
1. Konektor van stranice | Indikacija odnosa između nepovezanih dijelova dijagrama algoritama i programa koji se nalaze na različitim listovima | |
2. Magnetna kartica |
|
Ulaz-izlaz podataka, čiji je nosilac magnetna kartica |
3. Ručni dokument |
|
Formiranje dokumenta kao rezultat ručnih operacija |
4. Arhiva |
|
Pohranjivanje skupa organiziranih medija za pohranu za ponovnu upotrebu |
5. Vanmrežna obrada | Transformacija izvornih podataka kao rezultat vanmrežnih operacija | |
6. Dešifriranje |
|
Čitanje s medija za pohranu, transkodiranje i ispis na istom ili drugom mediju za pohranu kao rezultat vanmrežne operacije |
7. Kodiranje |
|
Primjena kodiranih informacija na medije kao rezultat vanmrežne operacije |
8. Kopiraj |
G O S U D A R S T V E N N Y S T A N D A R T S O YU Z A S S R
Jedinstveni sistem programske dokumentacije |
GOST 19.103-77 |
DESIGNIRANJE PROGRAMA I PROGRAMSKIH DOKUMENTA |
|
Jedinstveni sistem programske dokumentacije. |
Datum uvođenja od 01.01.80
1. Ovaj standard utvrđuje strukturu označavanja programa i softverskih dokumenata za računare, komplekse i sisteme, bez obzira na njihovu namenu i obim.
2. Označavanje programa i dokumenata treba da se sastoji od grupa znakova razdvojenih tačkama (nakon koda zemlje i koda razvojne organizacije), razmaka (nakon broja revizije dokumenta i koda vrste dokumenta), crtica (iza registracijskog broja i broj dokumenta ove vrste).
3. Uspostavlja se sistem registracije za imenovanje programa i programskih dokumenata.
Struktura oznake programa i njegovog programskog dokumenta - specifikacije:
A.B.XXXXX-XXOpšti dio oznake / Pozivni broj države | | | |
programi i softver | Organizacijski kod programera | | |
dokumenta o tome Registarski broj | |
Broj izdanja (za program) |
Broj revizije (za dokument) |
4. Struktura oznake drugih dokumenata politike:
A.B.XXXXX-XX XX XX-XOpći dio programske oznake | | | | |
i programski dokumenti na njemu | | | | |
Broj revizije dokumenta | | | |
Šifra vrste dokumenta | | |
Broj dokumenta ove vrste | |
Broj dijela dokumenta |
5. Šifra zemlje-programera i šifra organizacije (preduzeća)-programera dodjeljuje se na propisan način.
Registarski broj se dodjeljuje u skladu sa Svesaveznim klasifikatorom programa, odobrenim od strane Državnog standarda u skladu sa utvrđenom procedurom.
Prije odobrenja Svesaveznog klasifikatora programa, dozvoljeno je dodijeliti registarski broj uzlaznim redoslijedom, počevši od 00001 do 99999, za svaku organizaciju (preduzeće)-programer.
Broj izdanja programa ili broj revizije dokumenta dodjeljuje se rastućim redoslijedom od 01 do 99.
6. Šifra vrste dokumenta se dodeljuje u skladu sa zahtevima GOST 19.101-77.
7. Broj dokumenta ove vrste dodjeljuje se rastućim redoslijedom od 01 do 99.
8. Broj dijela istog dokumenta dodjeljuje se rastućim redoslijedom od 1 do 9.
Bilješka. Ako se dokument sastoji od jednog dijela, onda se crtica i serijski broj dijela ne navode.
9. Broj izdanja specifikacije i izjave operativnih dokumenata za program mora odgovarati broju izdanja istog programa.
Ponovno izdanje. novembra 1987