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.
Zbirka izvornih materijala.
Izbor i opravdanost kriterijuma za efektivnost i kvalitet izrađenog programa.
Opravdanost potrebe za istraživačkim radom.

Istraživački rad

Određivanje strukture ulaznih i izlaznih podataka.
Preliminarni izbor metoda rješavanja problema.
Obrazloženje svrsishodnosti korištenja prethodno razvijenih programa.
Utvrđivanje uslova za tehnička sredstva.
Opravdanje osnovne mogućnosti rješavanja problema.

Izrada i odobrenje projektnog zadatka

Određivanje uslova za program.
Izrada studije izvodljivosti za razvoj programa.
Definisanje faza, faza i rokova izrade programa i dokumentacije o njemu.
Izbor programskih jezika.
Utvrđivanje potrebe za istraživačkim radom u narednim fazama.
Koordinacija i odobravanje projektnog zadatka.

Idejni projekat

Izrada nacrta dizajna

Preliminarni razvoj strukture ulaznih i izlaznih podataka.
Rafiniranje metoda za rješavanje problema.
Izrada opšteg opisa algoritma za rešavanje problema.
Izrada studije izvodljivosti.

Odobrenje idejnog projekta


Koordinacija i odobravanje nacrta projekta

Tehnički projekat

Izrada tehničkog projekta

Rafiniranje strukture ulaznih i izlaznih podataka.
Razvoj algoritma za rješavanje problema.
Određivanje oblika reprezentacije ulaznih i izlaznih podataka.
Definicija semantike i sintakse jezika.
Razvoj programske strukture.
Konačna definicija hardverske konfiguracije.

Odobrenje tehničkog projekta

Izrada akcionog plana za razvoj i implementaciju programa.
Izrada objašnjenja.
Koordinacija i odobravanje tehničkog projekta.

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.
Izvođenje preliminarnih državnih, međuresorskih, prijemnih i drugih vrsta ispitivanja.
Korekcija programa i programske dokumentacije na osnovu rezultata ispitivanja.

Implementacija

Priprema i prijenos programa

Priprema i prenos programske i programske dokumentacije za održavanje i (ili) proizvodnju.
Registracija i odobravanje akta o prenosu programa na održavanje i (ili) proizvodnju.
Prenos programa u fond algoritama i programa.

napomene:

  1. 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.
  2. 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:

    1. Program je pokrenut...
    2. Odabrano…
    3. Pritisnuto...
    4. 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-80

Umjesto toga

GOST 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.
Indeksiranje programa i programskih dokumenata.

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-XX
Opš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-X
Opć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



Nastavak teme:
Windows

Natalya Komarova , 28.05.2009. (25.03.2018.) Kada čitate forum ili blog, sjećate se autora postova po nadimku i ... po slici korisnika, tzv avataru ....