Programmide dokumentatsiooni ühtne süsteem(ESPD) - riiklike standardite kogum , programmide ja programmidokumentatsiooni väljatöötamise, kujundamise ja levitamise omavahel seotud reeglite kehtestamine. ESPD standardid kehtestavad programmide väljatöötamist, hooldust, tootmist ja käitamist reguleerivad nõuded, mis tagavad võimaluse:
Tarkvaratoodete ühendamine programmide vastastikuseks vahetamiseks ja varem väljatöötatud programmide kasutamine uusarendustes;
Tööjõumahukuse vähendamine ja tarkvaratoodete arendamise, hoolduse, tootmise ja käitamise efektiivsuse tõstmine;
Programmi dokumentatsiooni tootmise ja säilitamise automatiseerimine.
Programmi hooldus hõlmab programmi toimimise, arendamise ja täiustamise analüüsi, samuti selles muudatuste tegemist vigade kõrvaldamiseks.
Kaasaegsete tarkvarapakettide keerukuse ja mahu kiire kasv koos täidetavate funktsioonide vastutuse suurenemisega on järsult tõstnud klientide ja kasutajate nõudmisi nende kvaliteedile ja kasutusohutusele.
Tõestatud vahend programmide ja tarkvarasüsteemide kõrge efektiivsuse ja töökvaliteedi tagamiseks on rahvusvahelised standardid, mis on välja töötatud valdkonna juhtivate ettevõtete esindajate osalusel.
Infosüsteemide kasutamise ja keerukuse kasvades võivad vead või programmide ebapiisav kvaliteet põhjustada kahju, mis ületab oluliselt nende kasutamise positiivset mõju.
GOST 28195-89 kehtestab üldsätted algoritmide ja programmide fondide (FAP) kaudu tarnitava arvutitehnoloogia tarkvara (PS) kvaliteedi, tarkvara kvaliteedinäitajate nomenklatuuri ja kohaldatavuse hindamiseks. Kvaliteedi kontroll PS on toimingute kogum, mis hõlmab hinnatud PS-i kvaliteedinäitajate vahemiku valimist, nende näitajate väärtuste määramist ja nende võrdlemist põhiväärtustega.
Vastavalt standardile GOST 28195-89 viiakse kvaliteedi hindamine läbi alajaama elutsükli kõigil etappidel:
PS kvaliteedinäitajate planeerimine;
Kvaliteedikontroll arenduse üksikutel etappidel (tehnilised kirjeldused, tehniline projekt, tööprojekt);
Kvaliteedikontroll PS tootmisprotsessi ajal;
PS-i modifitseerimise tõhususe kontrollimine hooldusetapis.
Kvaliteedi hindamist viivad läbi organisatsioonide spetsialistid: arendaja - tarkvara arendamise etappides; fondi omanik - tarkvara fondi vastuvõtmise etappides; testimiskeskused ja PS-i sertifitseerimiskeskused - testimise ja rakendamise etapis; tootja - PS-i replikatsiooni etappides; kasutaja – tarkvara juurutamise, hoolduse ja käitamise etappides.
Peamised ülesanded, mida tarkvara kvaliteedi hindamisel lahendada:
Kvaliteeditaseme planeerimine;
Kvaliteedinäitajate väärtuste jälgimine arenduse ja testimise käigus;
Etteantud kvaliteeditaseme operatiivkontroll;
Põhinäidiste valik alaklasside ja rühmade kaupa;
Metoodiline juhendamine kvaliteedi hindamise normatiiv- ja tehniliste dokumentide väljatöötamisel.
PS kvaliteedinäitajate määramise meetodid on erinevad:
PS-i kohta teabe hankimise meetodite abil - mõõtmine, registreerimine, organoleptiline, arvutamine;
Vastavalt teabeallikatele - traditsiooniline, ekspert, sotsioloogiline.
Mõõtmine Meetod põhineb tööriistade abil teabe hankimisel PS omaduste ja omaduste kohta. Näiteks seda meetodit kasutades määratakse programmi maht - programmide lähteteksti ridade arv ja kommentaaride ridade arv, operaatorite ja operandide arv, täidetavate lausete arv, harude arv programmis. programm, sisenemis- (väljumis-) punktide arv, programmiharu täitmise aeg, reaktsiooniaeg ja muud näitajad.
Registreerimine Meetod põhineb teabe hankimisel alajaama testimise või töötamise ajal, kui teatud sündmused salvestatakse ja loendatakse, näiteks rikete ja rikete aeg ja arv, juhtimise üleandmise aeg teistele moodulitele, algus- ja lõpuaeg. tööst.
Organoleptiline meetod põhineb meelte (nägemine, kuulmine) tajumise analüüsi tulemusena saadud teabe kasutamisel ja seda kasutatakse selliste näitajate määramiseks nagu kasutusmugavus, tõhusus jne.
Arvutatud Meetod põhineb teoreetiliste ja empiiriliste sõltuvuste (arengu algfaasis), alajaama testimise, töötamise ja hoolduse käigus kogutud statistiliste andmete kasutamisel. Arvutusmeetodi abil määratakse arvutuste kestus ja täpsus, reaktsiooniaeg ja vajalikud ressursid.
PS-i kvaliteedinäitajate väärtuste määramise ekspertmeetodi abil teostab selle probleemi lahendamiseks pädevate spetsialistide rühm, tuginedes oma kogemustele ja intuitsioonile.
Ekspertmeetodit kasutatakse juhtudel, kui probleemi ei ole võimalik ühegi muu olemasoleva meetodiga lahendada või on muud meetodid palju töömahukamad. Ekspertmeetodit soovitatakse kasutada programmi dokumentatsiooni selguse, täielikkuse ja ligipääsetavuse, õppimise lihtsuse ja struktuuri näitajate määramisel.
Sotsioloogilised meetodid põhinevad spetsiaalsete küsimustike töötlemisel. Siseriiklik standard GOST 28195-89 määratleb tarkvara kvaliteedikontseptsioonide hierarhilise struktuuri, nomenklatuuri ja sisu. Tipptasemel eristatakse kuut omadust: töökindlus, korrektsus, kasutusmugavus, tõhusus, mitmekülgsus ja hooldatavus, mis on detailselt teisel tasemel 19 kompleksse näitajaga. Kolmandal tasemel sisaldab täiendavaid üksikasju rohkem kui 200 hindamiselementi. Kasutatavate indikaatorite koosseis on soovitatav valida sõltuvalt tarkvara elutsükli eesmärgist, funktsioonidest ja etappidest. Siiski puuduvad näitajate hindamise meetodid.
Rahvusvaheline standard ISO / IEC 14598-1-6:1998-2001 on pühendatud valmis PCBde kvaliteediomaduste hindamise metoodikale elutsükli erinevatel etappidel. Alates GOST 28195-89 jõustumisest on ühiskonnaelu paljudes aspektides toimunud olulisi muutusi, sealhulgas olulisi muudatusi majandus- ja õigussuhetes tarkvara arendamise ja kasutamise valdkonnas. Näiteks kommertstarkvaratoodete valdkonnas on fondiomanik kadunud ning arendaja ja tootja on enamasti sama juriidiline isik. Turutingimustes on arendaja huvitatud oma toodete kvaliteedi tagamisest kogu nende elutsükli jooksul. Lisaks on muutunud toodete sertifitseerimise kord.
Võõrandumineõigusi arvutiprogrammile teostatakse lepingu alusel. Võõrandatava programmi ainuõiguse võõrandamise lepingu osapoolt (arendajat), kes annab üle või kohustub võõrandama talle kuuluva ainuõiguse, nimetatakse autoriõiguse omajaks. Omandajaks nimetatakse poolt, kes nõustub võõrandatava programmi ainuõiguse võõrandamise lepingu alusel.
Ainuõiguse võõrandamise lepingu alusel annab autoriõiguse valdaja talle kuuluva ainuõiguse üle või kohustub selle täielikult omandajale üle andma (Vene Föderatsiooni tsiviilseadustiku artikli 1234 punkt 1 ja artikkel 1285).
Ainuõiguse võõrandamise leping ei nõua juriidiliselt perioodi ja territooriumi märkimist, kuna arvutiprogrammi ainuõiguse täielik üleandmine tähendab ainuõiguse üleminekut kogu kehtivusaja jooksul, ilma et see piiraks ainuõiguse kehtivusaega. territooriumil.
Ainuõiguse võõrandamise lepinguga kohustub omandaja maksma õiguse valdajale lepingus ettenähtud tasu, kui lepingus ei ole sätestatud teisiti.
Kuna registreeritud arvutiprogrammi ainuõiguse võõrandamise kokkulepe kuulub riiklikule registreerimisele, läheb Vene Föderatsiooni tsiviilseadustiku artikli 1234 lõike 4 kohaselt ainuõigus sellistele tulemustele üle autoriõiguse omanikul. omandajale käesoleva lepingu riikliku registreerimise ajal.
Litsentsilepingu alusel annab üks pool - autor või muu autoriõiguse valdaja (litsentsiandja) või kohustub andma teisele poolele (litsentsiaadile) õiguse kasutada seda teost lepinguga kehtestatud piirides (mitte täies mahus). Arvutiprogrammi kasutusõigust andev litsentsileping ei kuulu kohustuslikule registreerimisele. Programmi arendaja lepingus võib lubada teisel poolel programmi teatud tingimustel (tingimused, territoorium, rent jne) kasutada. Sel juhul jääb programm oma autorist võõrandamatuks.
Kõige levinumad küsimused, mis tarkvara arendamise protsessis esile kerkivad, on järgmised:
Läbipaistvuse puudumine. Igal ajahetkel on raske öelda, millises seisus projekt on ja kui suur on selle valmidusprotsent. See probleem tekib siis, kui tulevase tarkvaratoote struktuur (või arhitektuur) ei ole piisavalt planeeritud, mis on enamasti tingitud projekti piisava rahastuse puudumisest: programmi on vaja, kui kaua arendamine aega võtab, mis on etapid, kas mõnda etappi saab kõrvaldada või salvestada - selle protsessi tagajärg on projekteerimisfaasi lühenemine.
Kontrolli puudumine. Ilma arendusprotsessi täpse hinnanguta rikutakse töögraafikuid ja ületatakse kehtestatud eelarveid. Tehtud ja allesjäänud tööde mahtu on raske hinnata. See probleem tekib staadiumis, mil projekti, millest enam kui pool on lõpetatud, jätkatakse pärast lisarahastamist, ilma projekti valmidusastet hindamata.
Jälgimise puudumine.
Järelevalve puudumine. Suutmatus projekti kulgu jälgida ei võimalda arenduse kulgu reaalajas jälgida. Tööriistade abil teevad projektijuhid otsuseid reaalajas andmete põhjal. See probleem tekib tingimustes, kus tööriistade omandamiseks vajaliku koolitusjuhtimise kulud on võrreldavad programmi enda arendamise kuludega.
Kontrollimatud muutused. Tarbijatel tuleb pidevalt välja uusi ideid arendatava tarkvara kohta. Muudatuste mõju võib projekti edule olla märkimisväärne, seetõttu on oluline hinnata kavandatud muudatusi ja rakendada ainult neid, mis on heaks kiidetud, kontrollides seda protsessi tarkvaratööriistade abil. See probleem tekib lõpptarbija vastumeelsuse tõttu teatud tarkvarakeskkondi kasutada. Näiteks klient-server süsteemi loomisel ei esita tarbija nõudmisi mitte ainult klientarvutite operatsioonisüsteemile, vaid ka serverarvutile.
Ebapiisav usaldusväärsus. Kõige keerulisem protsess on arvutiprogrammides vigade leidmine ja parandamine. Kuna programmide vigade arv on ette teadmata, siis ei ole ette teada ka programmide silumise kestus ning puudub garantii, et programmides vigu ei teki. Tuleb märkida, et tõenduspõhise lähenemise kasutamine tarkvara kujundamisel võimaldab avastada programmis vigu enne selle käivitamist. See probleem ilmneb siis, kui valite valed arendustööriistad. Näiteks kui proovite luua programmi, mis nõuab madala taseme tööriistu kasutades kõrgetasemelisi tööriistu. Näiteks kui proovite luua automatiseerimistööriistu koos DBMS-iga assembleris. Selle tulemusena osutub programmi lähtekood liiga keeruliseks ja raskesti struktureeritavaks.
Programmide kvaliteedi ja töökindluse garantiide puudumine, kuna puudub garantii, et programmides ei esine vigu kuni programmide formaalse üleandmiseni klientidele. See probleem ei ole ainult tarkvaraarenduse probleem. Kvaliteedi tagamine on toote (mitte toote) tarnija valimise probleem.
Tarkvara loomise õiguslikud, majanduslikud ja muud küsimused Tarkvara reguleeriv raamistik peab sisaldama õigusnorme, mis reguleerivad:
Omandiõigus tarkvarale ja selles salvestatud teabele;
Meetodid teabe hankimiseks vastavate andmebaaside täitmiseks;
Juriidiliste ja üksikisikute õigused teabele;
Riigi ja teabetarbija õiguste kaitse viisid;
Õigussuhted (õigused, kohustused ja vastutus) tarkvara haldavate isikute vahel;
Tarkvara töös kasutatava teabekandja ja dokumentide teabe juriidiline jõud.
Peamised sätted, mis määravad tarkvara loomise majandusliku aluse, on järgmised:
Tarkvara loomise ja toimimise tagamise tööde rahastamine avalikule haldusele eraldatud föderaaleelarvelistest vahenditest, osakondade (organisatsioonide, asutuste) - potentsiaalsete teabekasutajate ja Venemaa Riigivaraministeeriumiga koostööd teinud osakondade (organisatsioonide, asutuste) eelarvevahenditest. riigi tarkvara (GS) loomiseks, samuti eelarveväliste rahaliste vahendite konto jaoks;
Tarkvara loomiseks ja arendamiseks eraldatud eelarvevahendite kasutamise jälgimine;
Infotoetuse pakkumine riigivara haldamisega tegelevatele organisatsioonidele, samuti tarkvarainvestoritele;
Venemaa Riigivaraministeeriumile konkreetsete infotoodete ja -teenuste hindade määramise õiguse andmine;
Riikliku kontrolli teostamine hindade üle teatud perioodi või teatud tüüpi teabetoote puhul;
Riigipoolne hindade kehtestamine riigi tellimusel ja eelarvevahendite arvel osutatavatele infotoodetele (teenustele).
Samal ajal lahendatakse organisatsioonilised küsimused, mis reguleerivad töötajate suhtlemist tehniliste vahenditega ja omavahelist tarkvara arendamise ja käitamise protsessis.
Mõistet “intellektuaalomand” kasutasid aeg-ajalt teoreetikud – juristid ja majandusteadlased 18. ja 19. sajandil, kuid laialdaselt kasutusele võeti see alles 20. sajandi teisel poolel seoses Maailma Intellektuaalse Omandi Organisatsiooni (WIPO) loomisega. ) Genfis 1967. aastal. WIPO asutamisdokumentide kohaselt hõlmab "intellektuaalomand" õigusi, mis on seotud:
Kirjandus-, kunsti- ja teadusteosed:
Artistide tegevused, helisalvestised, raadio- ja telesaated:
Leiutised kõigis inimtegevuse valdkondades:
Teaduslikud avastused;
Tööstusdisainilahendused;
Kaubamärgid, teenusemärgid, kaubanimed ja kaubanimed;
Kaitse kõlvatu konkurentsi eest;
Nagu ka kõik muud õigused, mis on seotud intellektuaalse tegevusega tööstus-, teadus-, kirjandus- ja kunstivaldkonnas.
Hiljem hõlmas WIPO tegevusvaldkonda geograafiliste tähiste, uute taimesortide ja loomatõugude, integraallülituste, raadiosignaalide, andmebaaside ja domeeninimedega seotud ainuõigusi.
Igal intellektuaalomandi objektil on individuaalsuse omadus, kuna selle loomisel kasutati inimese intelligentsuse saavutusi, mõtlemise ja taju individuaalseid omadusi. Intellektuaalomandi objekt on alati tihedas vastasmõjus asjaõiguse objektidega ja kehastub alati materiaalsetes objektides, kuid eksisteerib eraldi, mis võimaldab kasutada intellektuaalse omandi objekti sõltumata selle materiaalsest kandjast. Eraldi õigusliku regulatsiooni objekt on erilised sotsiaalsed suhted, mis tekivad seoses intellektuaalomandi objektiga.
Riigi suhtumise järkjärgulisest muutumisest intellektuaalse tegevuse tulemustesse, mis omandavad üha enam turul toimimiseks loodud toote tunnuseid, annab tunnistust ka arvutiprogrammide õiguskaitse kehtestamine.
Tarkvara on seadusega kaitstud intellektuaalomandi objektina. Seda tüüpi objektide suhtes kehtib 20. oktoobril 1992 jõustunud seadusega "Elektrooniliste arvutite programmide ja andmebaaside õiguskaitse seadus" kehtestatud õiguslik eriregulatsioon.
Enesetesti küsimused
1. Millised kvaliteedinäitajad määravad programmid?
2. Mis on tarkvaratoode?
3. Mida mõeldakse tarkvara elutsükli all?
4. Mis eesmärgil on tarkvara spetsifikatsioonid määratletud?
5. Millised on tarkvaraarenduse etapid?
7. Mida mõeldakse tarkvaratoote verifitseerimise ja sertifitseerimise all?
8. Mis on tarkvara modulaarse struktuuri olemus?
9. Mis vahe on eraldiseisval ja integreeritud tarkvarasilumisel?
10. Mis on programmi kaasaskantavus?
11. Millised omadused on avatud süsteemidel?
12. Mida mõeldakse programmidokumentatsiooni ühtse süsteemi all?
13. Kuidas vormistatakse võõrandunud programm?
14. Milline seadus kaitseb arvutiprogrammide intellektuaalomandit?
Kirjandus
- Ivanova G.S. Programmeerimistehnoloogia. - M.: KnoRus, 2011. - 333 lk.
- Kamaev V.A. Programmeerimistehnoloogiad. - M.: Kõrgkool, 2006. - 454 lk.
- Orlov S.A. Tarkvara arendamise tehnoloogia. - Peterburi: Peeter, 2004. 526 lk.
- Rudakov A.V. Tarkvara arendamise tehnoloogia. - M.: Akadeemia, 2010. 207 lk.
- http://sp.cmc.msu.ru/info/37techprog.htm - programmeerimistehnoloogia.
- http://www.twirpx.com/file/27591/ - programmeerimistehnoloogia, loengud.
- http://www.intuit.ru/department/se/introprogteach/1/3.html - programmi elutsükkel.
- http://www.pervviurok.ru/Info/Internet Development/gl11/gl11.html - silumismoodulid.
- http://citforum.ru/database/articles/art 19.shtml - avatud süsteemid.
- http://www.mini-soft.ru/book/tech prog/ - programmeerimistehnoloogia.
- http://www.labfor.ru/?act=metod&target=metod leso1 1 - programmeerimiskeskkond.
Programmide dokumentatsiooni ühtne süsteem. Algoritmide ja programmide skeemid. Täitmise reeglid.
Programmide dokumentatsiooni ühtne süsteem. Algoritmide ja programmide skeemid. Tavapärased graafilised sümbolid
Programmide dokumentatsiooni ühtne süsteem. Tingimused ja määratlused.
Programmide dokumentatsiooni ühtne süsteem. Algoritmide ja programmide P-skeemid.
Programmide dokumentatsiooni ühtne süsteem. Programmide tüübid ja programmidokumendid.
Programmide dokumentatsiooni ühtne süsteem. Arengu etapid.
Programmide dokumentatsiooni ühtne süsteem. Programmide ja programmidokumentide tähistused.
Programmide dokumentatsiooni ühtne süsteem. Põhilised pealdised.
Programmide dokumentatsiooni ühtne süsteem. Üldnõuded programmidokumentidele.
Programmide dokumentatsiooni ühtne süsteem. Nõuded trükitud programmidokumentidele.
Programmide dokumentatsiooni ühtne süsteem. Tehniline ülesanne. Nõuded sisule ja kujundusele.
Programmide dokumentatsiooni ühtne süsteem. Spetsifikatsioon. Nõuded sisule ja kujundusele.
Programmide dokumentatsiooni ühtne süsteem. Testi programm ja metoodika. Nõuded sisule ja kujundusele.
Programmide dokumentatsiooni ühtne süsteem. Programmi tekst. Nõuded sisule ja kujundusele.
Programmide dokumentatsiooni ühtne süsteem. Programmi kirjeldus.
Programmide dokumentatsiooni ühtne süsteem. Originaalhoidjate nimekiri.
Programmide dokumentatsiooni ühtne süsteem. Selgitav märkus. Nõuded sisule ja kujundusele.
Programmide dokumentatsiooni ühtne süsteem. Vorm. Nõuded sisule ja kujundusele.
Programmide dokumentatsiooni ühtne süsteem. Üldkirjeldus. Nõuded loomingule ja disainile.
Programmide dokumentatsiooni ühtne süsteem. Süsteemi programmeerija juhend. Nõuded sisule ja kujundusele.
Programmide dokumentatsiooni ühtne süsteem. Programmeerija juhend. Nõuded sisule ja kujundusele.
Programmide dokumentatsiooni ühtne süsteem. Kasutusjuhend. Nõuded sisule ja kujundusele.
Programmide dokumentatsiooni ühtne süsteem. Keele kirjeldus. Nõuded sisule ja kujundusele.
Programmide dokumentatsiooni ühtne süsteem. Tegevusdokumentide loetelu.
Programmide dokumentatsiooni ühtne süsteem. Hooldusjuhend. Nõuded sisule ja kujundusele.
Programmide dokumentatsiooni ühtne süsteem. Üldreeglid dubleerimiseks, arvestuseks ja säilitamiseks.
Programmide dokumentatsiooni ühtne süsteem. Trükitud programmidokumentide paljundamise, arvestuse ja säilitamise reeglid.
Programmide dokumentatsiooni ühtne süsteem. Üldised reeglid muudatuste tegemiseks.
Programmide dokumentatsiooni ühtne süsteem. Reeglid trükis tehtud programmidokumentides muudatuste tegemiseks.
GOST 19.001-77 Üldsätted
GOST 19781-90 Mõisted ja määratlused.
GOST 19.101-77 Programmide ja programmidokumentide tüübid
GOST 19.102-77 Arengu etapid
GOST 19.103-77 Programmide ja programmidokumentide nimetused
GOST 19.104-78 Põhilised pealdised
GOST 19.105-78 Üldnõuded programmidokumentidele
GOST 19.106-78 Nõuded trükitud programmidokumentidele
GOST 19.201-78 Tehnilised kirjeldused, nõuded sisule ja kujundusele
GOST 19.202-78 spetsifikatsioon. Nõuded sisule ja kujundusele
GOST 19.301-79 Testimise programm ja metoodika. Nõuded sisule ja kujundusele
GOST 19.401-78 Programmi tekst. Nõuded sisule ja kujundusele
GOST 19.402-78 Programmi kirjeldus
GOST 19.403-79 Originaalhoidjate loend
GOST 19.404-79 Selgitav märkus. Nõuded sisule ja kujundusele
Vorm GOST 19.501-78. Nõuded sisule ja kujundusele
GOST 19.502-78 Rakenduse kirjeldus. Nõuded sisule ja kujundusele
GOST 19.503-79 Süsteemi programmeerija juhend. Nõuded sisule ja kujundusele
Programmeerija juhend GOST 19.504-79. Nõuded GOST 19.505-79 kasutusjuhendi sisule ja kujundusele. Nõuded sisule ja kujundusele
GOST 19.506-79 Keele kirjeldus. Nõuded sisule ja kujundusele
GOST 19.507-79 Tegevusdokumentide loetelu
GOST 19.508-79 Hooldusjuhend. Nõuded sisule ja kujundusele
GOST 19.601-78 Üldreeglid dubleerimiseks, raamatupidamiseks ja ladustamiseks
GOST 19.602-78 Trüki teel valmistatud programmidokumentide paljundamise, arvestuse ja säilitamise reeglid. tee
GOST 19.603-78 Muudatuste tegemise üldreeglid
GOST 19.604-78 Reeglid trükis tehtud programmidokumentides muudatuste tegemiseks
TEHNILINE ÜLESANNE.
NÕUDED SISU JA KUJANDUSELE
GOST 19.201-78
alates 01.01. 1980. aasta
Käesolev standard kehtestab arvutite, komplekside ja süsteemide programmi või tarkvaratoote arendamiseks mõeldud tehniliste kirjelduste koostamise ja koostamise korra, sõltumata nende eesmärgist ja ulatusest.
Standard vastab täielikult ST SEV 1627-79-le.
1. ÜLDSÄTTED
1.1. Lähteülesanne koostatakse vastavalt standardile GOST 19.106-78 vormingutega 11 ja 12 lehtedel vastavalt standardile GOST 2.301-68, reeglina lehe välju täitmata. Lehtede (lehekülgede) numbrid asetatakse lehe ülaossa teksti kohale.
1.2. Kinnitusleht ja tiitelleht koostatakse vastavalt standardile GOST 19.104-78.
Teabeosa (märkus ja sisu), muudatuste registreerimislehte ei tohi dokumendile lisada.
1.3. Tehnilistes spetsifikatsioonides muudatuste või täienduste tegemiseks programmi või tarkvaratoote arendamise järgmistes etappides avaldatakse sellele täiendus. Tehniliste kirjelduste täienduste kooskõlastamine ja kooskõlastamine toimub samamoodi nagu tehniliste kirjelduste jaoks.
1.4. Lähteülesanne peab sisaldama järgmisi jaotisi:
sissejuhatus;
· arengualused;
· arendamise eesmärk;
· nõuded programmile või tarkvaratootele;
· nõuded tarkvara dokumentatsioonile;
· tehnilised ja majanduslikud näitajad;
· arenguetapid ja -faasid;
· kontrolli ja vastuvõtmise kord;
· Rakendused võivad sisalduda tehnilistes kirjeldustes.
Olenevalt programmi või tarkvaratoote omadustest on võimalik täpsustada osade sisu, tuua sisse uusi jaotisi või kombineerida üksikuid.
2.1. Jaotises "Sissejuhatus" märkige programmi või tarkvaratoote nimi, rakendusala lühikirjeldus ja objekt, milles programmi või tarkvaratoodet kasutatakse.
(Muudetud väljaanne, muudatus nr 1)
2.2. Jaotises "Arenduse alused" tuleks märkida:
· dokument(id), mille alusel arendust teostatakse;
· selle dokumendi kinnitanud organisatsioon ja selle kinnitamise kuupäev;
· arendusteema nimetus ja (või) sümbol.
(Muudetud väljaanne, muudatus nr 1)
2.3. Jaotises “Arenduseesmärk” tuleb näidata programmi või tarkvaratoote funktsionaalne ja tööeesmärk.
2.4. Jaotis „Nõuded programmile või tarkvaratootele” peaks sisaldama järgmisi alajaotisi.
· nõuded funktsionaalsetele omadustele;
· Töökindlusnõuded;
· kasutustingimused;
· nõuded tehniliste vahendite koostisele ja parameetritele;
· nõuded teabe ja tarkvara ühilduvusele;
· märgistamise ja pakendamise nõuded;
· nõuded transpordile ja ladustamisele;
· erinõuded.
(Muudetud väljaanne, muudatus nr 1)
2.4.1. Alajaotises “Nõuded funktsionaalsetele omadustele” tuleb näidata nõuded täidetavate funktsioonide koosseisule, sisend- ja väljundandmete korraldusele, ajastuskarakteristikutele jne.
2.4.2. Alajaotises „Töökindlusnõuded“ tuleb ära näidata nõuded töökindluse tagamiseks (stabiilse töö tagamine, sisend- ja väljundinfo jälgimine, rikkejärgne taastumisaeg jne).
2.4.3. Alajaotises „Kasutustingimused“ tuleb näidata töötingimused (valitud tüüpi andmekandjate puhul ümbritseva õhu temperatuur, suhteline õhuniiskus jne), mille puhul tuleb tagada ettenähtud omadused, samuti teenuse liik, nõutav arv ja kvalifikatsioon. personal.
2.4.4. Alajaotises “Nõuded tehniliste vahendite koostisele ja parameetritele” on märgitud tehniliste vahendite nõutav koostis, näidates ära nende peamised tehnilised omadused.
2.4.5. Alajaotises “Nõuded teabe ja tarkvara ühilduvusele” tuleb ära näidata nõuded infostruktuuridele sisend- ja väljund- ning lahendusmeetodite, lähtekoodide, programmeerimiskeelte ja programmi poolt kasutatava tarkvara kohta.
Vajadusel tuleb tagada teabe ja programmide kaitse.
(Muudetud väljaanne, muudatus nr 1)
2.4.6. Alajaotises “Nõuded märgistamisele ja pakendamisele” on üldiselt ära toodud tarkvaratoote märgistamise nõuded, pakendamise võimalused ja viisid.
2.4.7. Alajaotises “Transpordi ja ladustamise nõuded” tuleb näidata tarkvaratoote transporditingimused, hoiukohad, hoiutingimused, hoiutingimused, hoiuperioodid erinevates tingimustes.
2.5a. Jaotises “Nõuded programmi dokumentatsioonile” tuleks näidata programmidokumentatsiooni esialgne koosseis ja vajadusel erinõuded sellele.
(lisatud täiendavalt, muudatus nr 1).
2.5. Jaotises “Tehnilised ja majanduslikud näitajad” tuleks märkida: hinnanguline majanduslik efektiivsus, hinnanguline aastane nõudlus, arenduse majanduslikud eelised võrreldes parimate kodumaiste ja välismaiste näidiste või analoogidega.
2.6. Jaotises “Arenduse etapid ja faasid” kehtestatakse vajalikud väljatöötamise etapid, etapid ja töö sisu (väljatöötatavate, kokku leppitavate ja kinnitatavate programmidokumentide loetelu), samuti reeglina väljatöötamise ajakava ja täitjad määratakse.
2.7. Jaotises “Kontrollimise ja vastuvõtmise kord” tuleks näidata katsete liigid ja tööde vastuvõtmise üldnõuded.
2.8. Tehniliste kirjelduste lisades esitatakse vajadusel:
väljatöötamist õigustavate uurimistööde ja muude tööde loetelu;
algoritmide diagrammid, tabelid, kirjeldused, põhjendused, arvutused ja muud dokumendid, mida saab arenduse käigus kasutada;
muud arendusallikad.
NÕUDED TARKVARADOKUMENTIDELE,
TRÜKITUD
GOST 19.106-78
1.5. Programmi dokumendid koostavad:
A4 formaadis lehtedel (GOST 2.301-68) - dokumendi koostamisel masinakirja või käsitsi kirjutamise teel (vorm 1). Lubatud on kujundus A3 lehtedele (vorm 2);
A4- ja A3-vormingus lehtedel, mis on ette nähtud andmeväljundseadmete väljundomadustega - dokumendi valmistamisel masinaga. Lubatud on kõrvalekalded A4 ja A3 formaadile vastavate lehtede suurustes, mis on määratud kasutatavate tehniliste vahendite võimalustega;
tüpograafiliste vormingute lehtedel - dokumendi koostamisel tüpograafilisel meetodil.
Programmdokumendi materjalid on järjestatud järgmises järjekorras:
pealkirja osa:
§ kooskõlastusleht (ei sisaldu dokumendi lehtede koguarvus);
§ tiitelleht (dokumendi esimene leht);
§ teabe osa:
§ annotatsioon;
§ põhiosa:
§ dokumendi tekst (koos piltide, tabelitega jne);
§ avaldused;
§ mõistete loetelu;
§ lühendite loetelu;
§ jooniste loetelu;
§ tabelite loetelu;
§ aineregister;
§ viitedokumentide loetelu;
§ tähiste ja arvuliste koefitsientide loetelu;
§ Muuda registreerimisosa:
§ muutmise registreerimisleht.
Vajadusel viiakse läbi lisad, terminite loetelud, lühendid, joonised ja tabelid, aineregister, teatmeteoste loetelud, tähised ja numbrilised koefitsiendid.
(Muudetud väljaanne, muudatus nr 1)
1.7. Tähestikulises järjekorras tuleks koostada terminite ja lühendite loendid, teemaregister, sümbolite ja numbriliste koefitsientide loend.
Ülejäänud loendid koostatakse kasvavas numbrite järjekorras.
(lisatud täiendavalt, muudatus nr 1)
2. NÕUDED ENAMIKALT PIDEVTEKSTI SISALDAVATEL TARKVARADOKUMENTIDELE.
2.1. Dokumendi ülesehitus.
2.1.1. Vajadusel on lubatud dokument osadeks jagada. Osadeks jagamine toimub tasemel, mis ei ole madalam kui sektsioon. Iga osa tarnitakse eraldi. Kõikidele osadele on määratud dokumenditähis vastavalt standardile GOST 19.103-77.
Osad on koostatud vastavalt selle standardi nõuetele ja esimese osa sisu lõpus tuleks loetleda ülejäänud osade nimetused.
Dokumendis on lubatud lisada programmi teksti osi, mis on vormindatud vastavalt programmi teksti kirjutamise keele reeglitele.
Dokumendi lehekülgede nummerdamine, samuti jaotiste, jooniste ja tabelite nummerdamine toimub iga osa sees. Iga osa algab tiitellehega.
Dokumendi lehekülgede eraldi nummerdamine jaotises ja alajaos ei ole lubatud.
Kogu dokumendi kohta väljastatakse kinnitusleht, mis näitab esimest osa.
2.1.2. Programmdokumendi teave ja põhiosad esitatakse vormil 1 või 2, kus:
väli 1 - lehe seerianumber;
väli 2 - dokumendi tähistus;
väli 3 - dokumendi tekst;
väli 4 - muuda rida; täidetud vastavalt GOST 19.604-78 nõuetele.
Dokumendi lehevormingu raami (ääriseid) ei pruugita rakendada.
2.1.3. Referaat paigutatakse eraldi (nummerdatud) lehele pealkirjaga “KONTROLL” ja seda ei nummerdata jaotisena.
Annotatsioon näitab programmi väljaannet ning kirjeldab lühidalt dokumendi eesmärki ja sisu. Kui dokument koosneb mitmest osast, näidatakse annotatsioonis osade koguarv.
Sisu kuuluvad nimed kirjutatakse väiketähtedega. Suurtähed ja lühendid tuleb trükkida suurtähtedega.
2.1.3, 2.1.4. (Muudetud väljaanne, muudatus nr 1).
2.1.5. Iga dokumendi tekst jaotatakse vajadusel lõigeteks ja lõiked alapunktideks, olenemata sellest, kas dokument on jagatud osadeks, osadeks ja alajaotisteks või mitte.
2.1.6. Dokumenditeksti struktuurielementideks on lõigud, alajaotised, lõigud, lõigud ja loendid.
Jaotis - jaotuse esimene etapp, mis on tähistatud numbriga ja varustatud pealkirjaga.
Alamjaotis - osa jaotisest, mis on tähistatud numbriga ja millel on pealkiri.
Üksus - osa jaotisest või alajaotusest, mis on tähistatud numbriga. Võib olla pealkiri.
Alamartikkel – numbriga tähistatud üksuse osal võib olla pealkiri.
Lõige on loogiliselt eraldatud tekstiosa, millel ei ole numbrit.
Kui dokumendi tekstis puuduvad jaotised, on selle esimene struktuurielement lõik.
Teksti on lubatud paigutada jaotise ja alajaotuse pealkirjade vahele, alajaotuse ja lõigu pealkirjade vahele.
Alajaotiste, lõikude ja lõikude sees võib anda loetelusid, mida on soovitav tähistada araabia numbritega sulgudes: 1), 2) jne. Loetelu on lubatud esile tõsta, asetades teksti ette sidekriipsu.
Iga struktuurielement algab lõigu taandega.
(Muudetud väljaanne, muudatus nr 1).
2.1.7. Jaotiste pealkirjad kirjutatakse suurtähtedega ja asetatakse sümmeetriliselt teksti parema ja vasaku serva suhtes.
Alajaotuste pealkirjad kirjutatakse lõigust alates väiketähtedega (v.a esimene suurtäht).
Dokumendi masinaga printimisel on lubatud kirjutada alajaotiste ja lõikude pealkirjad trükiseadmes olevas kirjatüübis.
Sõnade sidekriipsud pealkirjades ei ole lubatud. Pealkirja lõpus pole punkti.
Kui pealkiri koosneb kahest lausest, eraldatakse need punktiga.
(Muudetud väljaanne, muudatus nr 1).
2.1.8. Vahemaa pealkirja ja järgmise teksti, samuti jaotise ja alajaotuse pealkirjade vahel peaks olema võrdne:
dokumendi täitmisel kirjutusmasinaga - kaks intervalli;
kui see on tehtud käsitsi kirjutatud - 10 mm;
masinaga tehes – vähemalt kolm fondi kõrgust.
Jaotiste ja alajaotiste puhul, mille tekst on kirjutatud samale lehele eelmise jaotise tekstiga, peaks teksti viimase rea ja järgneva pealkirja vaheline kaugus olema võrdne:
dokumendi täitmisel masinakirja meetodil - kolm masinakirja intervalli;
käsitsi kirjutatuna - vähemalt 15 mm;
masinaga tehes – vähemalt neli fondikõrgust.
Pealkirja ridade aluste vaheline kaugus on sama, mis tekstis.
Trükimeetodil dokumentide avaldamisel vormistatakse määratud vahemaad vastavalt trükiste trükkimise reeglitele.
2.1.9. Jaod, alajaotised, lõigud ja lõigud tuleb nummerdada araabia numbritega koos punktiga.
Jaotistel peab olema järjenumber (1, 2 jne).
Jaotises peab olema kõigi selles jaotises sisalduvate alajaotiste, lõigete ja lõikude pidev nummerdamine.
Alajagude numeratsioon sisaldab punktiga eraldatuna selles jaotises sisalduva jaotise numbrit ja järjekorranumbrit (2.1; 3.1 jne).
Jaotiste ja alajaotiste olemasolul lisatakse alajao numbrile pärast punkti punkti ja alapunkti (3.1.1, 3.1.1.1 jne) järjekorranumber.
Programmdokumendi teksti ülesehituse ja selle osade, alajagude, lõikude ja lõikude numeratsiooni näide on toodud viites 2. lisas.
(Muudetud väljaanne, muudatus nr 1).
2.1.10. (Kustutatud, muudatus nr 1)
2.2. Dokumendi tekst.
2.2.1. Dokumendi tekst peaks olema lühike, selge, välistades valesti tõlgendamise.
Terminid ja määratlused peavad olema ühtsed ja vastama kehtestatud standarditele, nende puudumisel - teadus- ja tehnikakirjanduses üldtunnustatud ning olema toodud terminite loetelus.
2.2.2. Sõnade lühendid tekstis ja pealdised illustratsioonide all on lubatud vastavalt standardile GOST 2.316-68. Dokumendis vastu võetud täiendavad lühendid, mida GOST 2.316-68 ei sisalda, tuleks esitada aktsepteeritud lühendite loendis.
2.2.3. Üksikute mõistete esiletõstmiseks on lubatud muuta sõnade vahekaugust, samuti printida üksikuid sõnu või tekstiosi põhitekstist erinevas kirjas, näiteks:
UNCATLG – näitab, et lähteandmete kogumiga seotud kataloogikirje tuleks välja jätta.TO = seade = loend – näitab andmekandjat, millele...ABC3-91 SÜNTAKSIVEA PÕHJUS. Täpsustatud teates...SÜSTEEMI TEGEVUS. Ülesannet ei täideta...PROGRAMMEERIJA TEGEVUSED. On vaja pakkuda...
2.2.4. Vajalikud selgitused dokumendi teksti kohta võib esitada joonealuste märkustena.
Joonealust märkust tähistab fondi ülaserva tasemele paigutatud sulg, näiteks: “prindiseade2)...” või “paber5)”.
Kui joonealune märkus viitab üksikule sõnale, siis asetatakse joonealuse märk otse selle sõna kõrvale, kui aga viitab lausele tervikuna, siis lause lõppu. Joonealuse märkuse tekst asetatakse lehe lõppu ja eraldatakse põhitekstist 3 cm pikkuse joonega, mis on tõmmatud lehe vasakusse serva.
2.3. Illustratsioonid.
2.3.1. Illustratsioonid võivad asuda dokumendi tekstis ja (või) lisades.
Illustratsioonid, kui neid on antud dokumendis rohkem kui üks, nummerdatakse kogu dokumendi ulatuses araabia numbritega.
Lisades on illustratsioonid nummerdatud iga lisa sees dokumendi põhiteksti jaoks kehtestatud järjekorras.
Illustratsioonidel võib olla temaatiline pealkiri ja tiitritekst, mis selgitab illustratsiooni sisu.
Illustratsiooni kohale asetatakse temaatiline pealkiri (nimi), selle alla pildiallkirja tekst. Illustratsiooni number on paigutatud selgitavate andmete alla.
(Muudetud väljaanne, muudatus nr 1).
2.4. Valemid.
2.4.1. Dokumendi valemid, kui neid on rohkem kui üks, nummerdatakse araabia numbritega lehe paremas servas, valemi tasemel sulgudes.
Kogu dokumendi või selle osade piires, kui dokument on jagatud osadeks, on valemid pideva nummerdamisega.
Dokumendi osadeks jagamisel asetatakse osa number valemi järjekorranumbri ette ja eraldatakse viimasest punktist, näiteks: "valemis (1.4)."
2.4.2. Valemis sisalduvate sümbolite ja arvuliste koefitsientide tähendus tuleb esitada vahetult valemi all. Iga märgi tähendus trükitakse uuele reale selles järjekorras, nagu need valemis on antud. Ärakirja esimene rida peaks algama sõnaga “kus”, ilma koolonita.
Kui programmidokument sisaldab nende sümbolite ja arvuliste koefitsientide loetelu, ei pruugita valemi all olevaid väärtusi esitada.
(Muudetud väljaanne, muudatus nr 1).
2.4.3. Sama parameetri mõõde ühes dokumendis peab olema konstantne.
2.5.1. Programmidokumentides on lubatud viited standarditele (v.a ettevõtete standardid), tehnilistele kirjeldustele ja muudele dokumentidele (näiteks riikliku järelevalve organite dokumendid, NSVL Riikliku Ehituskomitee eeskirjad ja määrused). Standarditele ja tehnilistele spetsifikatsioonidele viidates on märgitud nende tähistus.
Viidata tuleks dokumendile tervikuna või selle osadele (märkida dokumendi nimetus ja nimetus, jaotise või lisa number ja nimetus). Jaotisele või rakendusele viitamist korrates märgitakse ainult number.
Lubatud on märkida ainult dokumendi ja (või) jaotiste tähistus ilma nende nimesid märkimata. Viited mõne muu dokumendi üksikutele alajaotistele, lõikudele ja illustratsioonidele ei ole lubatud. Dokumendisisesed lingid lõikudele, illustratsioonidele ja üksikutele alajaotistele on lubatud.
(Muudetud väljaanne, muudatus nr 1).
2.6. Tabelid
2.6.1. Näitajate parema nähtavuse ja võrreldavuse saavutamiseks tuleks digitaalne materjal esitada tavaliselt tabeli kujul.
2.6.2. Tabelid tuleb koostada vastavalt GOST 1.5-68 nõuetele.
Tabelil võib olla pealkiri, mis peaks olema väiketähtedega. Suurtähed ja lühendid tuleb trükkida suurtähtedega.
(Muudetud väljaanne, muudatus nr 1).
2.6.3. Tabelite joonealused märkused asuvad vahetult tabeli all. Näiteks:
Printimiseks kasutatavad andmekogumid
Eesmärk
Standardne nimi
Kasutatud seade
Teabe väljatrükk
SSSSSSS1) Prindiseade2)
Programmi täitmise ajal printimiseks
RRRRRRRR Prindiseade2)
1) Operatsioonisüsteemi seadistamisel tuleb määrata nimi SSSSSSS.
2) I/O-toimingutest tingitud protsessori seisakuaja vähendamiseks võib kasutada magnetlinti.
2.7. Märkmed.
2.7.1. Märkused teksti ja tabelite juurde näitavad ainult viite- ja selgitavaid andmeid.
Üks sedel ei ole nummerdatud. Pärast sõna "Märkus" pange punkt.
Mitmed noodid tuleks nummerdada araabia numbritega koos punktiga. Pärast sõna "Märkus" pange koolon.
Näiteks:
Märge.
Märkused: 1. 2.
2.7.2. Märkmete teksti võib trükkida ainult ühe intervalliga.
2.8. Lühendid.
2.8.1. Sõnade lühendid tekstis ja pealdised illustratsioonide all ei ole lubatud, välja arvatud:
lühendid, mis on kehtestatud standardis GOST 2.316-68 ja vene keeles üldtunnustatud;
lühendid, mida kasutatakse programmide, nende osade ja töörežiimide tähistamiseks ülesannete juhtimiskeeltes, programmi konfiguratsioonitööriistades jne, sealhulgas need, mis on tähistatud ladina tähestiku tähtedega.
Kui dokument kasutab sõnade või nimede jaoks spetsiaalset lühendite süsteemi, peab see sisaldama aktsepteeritud lühendite loendit.
(Muudetud väljaanne, muudatus nr 1).
2.9. Rakendused
2.9.1. Illustreeritud materjali, tabeleid või abiteksti võib esitada lisadena.
Taotlused koostatakse selle dokumendi jätkuna järgmistel lehekülgedel või väljastatakse eraldi dokumendina.
2.9.2. Iga taotlus peab algama uuelt lehelt, mille paremas ülanurgas on märgitud sõna “LISA” ning sellel peab olema temaatiline pealkiri, mis kirjutatakse teksti suhtes sümmeetriliselt suurtähtedega.
Kui dokumendis on rohkem kui üks lisa, nummerdatakse kõik lisad araabia numbritega (ilma nr-märgita), näiteks LISA 1, LISA 2 jne.
Taotluse eraldi dokumendina väljastamisel tuleks tiitellehele dokumendi nimetuse alla märkida sõna “LISA” ning mitme avalduse korral märkida ka nende järjekorranumbrid.
Eraldi dokumendina väljastatud lisad on märgitud dokumendi osaks. Vajadusel võib selline taotlus sisaldada "Sisu".
Programmdokumendi eraldi osaks on võimalik ühendada mitu rakendust.
(Muudetud väljaanne, muudatus nr 1).
2.9.4. Dokumendi ja dokumendis sisalduvate lisade lehekülgede nummerdamine peab olema pidev, välja arvatud juhul, kui lisad on tehtud eraldi dokumendina.
Lisades olevad illustratsioonid ja tabelid on igas lisas nummerdatud.
(Muudetud väljaanne, muudatus nr 1).
Kõik manused peavad olema sisulehel loetletud.
3. NÕUDED GRAAFILISTEKS JAOTATUD TEKSTI SISALDAVAD TARKVARADOKUMENTID.
3.1. Graafikuteks jaotatud teksti sisaldavad programmidokumendid jagatakse vajadusel osadeks ja alajaotisteks, mis ei ole nummerdatud. Lubatud on mitte tõmmata jooni ja veerge piiritlevaid jooni.
3.2. Jaotiste ja alajaotiste nimed kirjutatakse pealkirjadena väiketähtedega (v.a esimene suurtäht) ja alla joonitud.
Pealkirja ja järgneva teksti, teksti ja järgneva pealkirja ning pealkirjade vaheline kaugus peab vastama punktis 2.1.8 määratletule.
3.3. Märkused dokumendis vormistatakse punktis 2.7 toodud järjekorras.
3.4. Ridadega tabelites ja vormides paigutatakse kõik kirjed igale reale ühte ritta.
Kirjed ei tohiks sulanduda ridu ja veerge eraldavate joontega.
Peate jätma vabad read jaotiste ja alajaotiste vahele ning suurtes dokumentides ka jaotiste ja alajaotiste sisse.
Kui dokumendi veergu on kirjutatud mitu rida teksti, algavad järgmiste veergude kirjed esimese rea tasemelt. Kirje on lubatud paigutada viimase rea tasemele, kui see hõivab ühe rea.
(Muudetud väljaanne, muudatus nr 1).
LISA 1
Teave
TEAVEANDMED GOST 19.106-78 VASTAVUSE KOHTA
ST SEV 2088-80
Sec. 1 GOST 19.106-78 vastab jaotisele. 1 ja sek. 4 (p 4.1) ST SEV 2088-80.
Sec. 2 GOST 19.106-78 vastab jaotisele. 4 (punktid 4.4-4.9) ST SEV 2088-80.
(lisatud täiendavalt, muudatus nr 1).
LISA 2
Teave
PROGRAMMI DOKUMENDI TEKSTI STRUKTUUR
PÕHIJUHISED
Programmide dokumenteerimise ühtne süsteem.
NSVL Riikliku Standardikomitee määrusega 18. detsembrist 1978 nr 3351 kehtestati kasutuselevõtu kuupäev.
alates 01.01.1980
See standard kehtestab ESPD standarditega ette nähtud programmidokumentides kinnituslehe ja tiitellehe põhikirjade vormid, suurused, asukoha ja täitmise korra, olenemata nende rakendamise meetoditest.
Standard vastab tüübikinnituslehe ja tiitellehe kujunduse osas standardile ST SEV 2088-80 (vt viide Lisa 1).
1. PÕHISÄTTED
1.1. Kinnituslehe ja tiitellehe peamised pealdised programmidokumentides sisaldavad järgmisi struktuuriandmeid:
ministeeriumi (osakonna) nimi;
Dokumendi pealkiri;
dokumendi tähistus;
teave andmekandja kohta, millel originaal esitatakse;
kooskõlastuslehtede koguarv, dokumendi maht;
teave arendaja kohta;
reguleeriva inspektori viisa;
registreerimise ja säilitamise dokument;
teave muudatuse kohta.
2. TÜÜBIKINNITUSLEHE PÕHIJUHISED (LA)
2.1. Iga programmidokumendi kohta väljastatakse A4 paberilehtedel (GOST 2.301-68) sõltumata dokumendi tüübist kinnitusleht, mida saab täita mis tahes andmekandjal.
2.2. Kinnituslehe tähistus koosneb selle dokumendi tähistusest, mille kohta kinnitusleht on seotud, ja eraldatuna sidekriipsuga – LU koodist.
Kinnitusleht ei kuulu dokumendi lehtede koguarvu hulka.
2.3. Heakskiitmisleht võib sisaldada mitut lehte, sel juhul on iga leht nummerdatud. Esimesel lehel on näidatud kinnituslehel sisalduvate lehtede koguarv.
Teine ja järgnevad kinnituslehed koostatakse vastavalt punktile. 1 GOST 19.106-78, samas kui väljale "Dokumendi tekst" on märgitud nende isikute ametikohad ja allkirjad, kes ei mahu kinnituslehe esimesele lehele.
2.4. Heakskiitmisleht lisatakse spetsifikaadile pärast kinnitatud dokumenti ja seda säilitatakse ettevõttes, kus originaaldokument on olemas.
Sellele spetsifikatsioonile on lisatud ka spetsifikatsiooni kinnitusleht.
Kooskõlastuslehe koopiad saadetakse kliendile ja emaettevõttele.
Kliendi eriloal võib kooskõlastuslehe saata teistele organisatsioonidele.
2.5. Kinnitusleht täidetakse vastavalt joonisel näidatud vormile:
väli 1 - ministeeriumi või osakonna nimi, mille süsteemi kuulub käesoleva dokumendi välja töötanud organisatsioon.
Täidetakse kliendi soovil.
Välja 1 kohale, üleval paremas nurgas, kantakse vajadusel spetsiaalne märge (saladustempel, märge “Ettevõttest mitte eemaldada” jne);
väli 2 - välja vasakul pool - kliendi organisatsioonist dokumendi kinnitanud isikute ametikohad ja allkirjad, vajadusel välja paremal pool - dokumendi kinnitanud isikute ametikohad ja allkirjad alates arendaja organisatsioon.
Koordineerivaid ja kinnitavaid organisatsioone ning ametnike konkreetseid allkirju reguleerivad ministeeriumid ja osakonnad;
Dokumendi pealkirja võib ära jätta või kombineerida programmi pealkirjaga;
Andmekandja tüüp näidatakse ainult juhul, kui dokument on vormistatud andmekandjal;
väli 5 - kinnituslehtede koguarv, näiteks "Lehed 3". Ühe lehe puhul väli 5 ei ole täidetud;
väli 6 - välja paremal küljel - dokumendi väljastanud organisatsiooni juhi, dokumendi välja töötanud osakonnajuhataja, arendusjuhi (arendaja), dokumendi väljatöötajate ja dokumendi väljatöötajate ametikohad ja allkirjad. normatiivinspektor.
Igast allkirjast paremal on dokumendile alla kirjutanud isiku initsiaalid ja perekonnanimi ning allkirja all allkirjastamise kuupäev.
Kui sobivaid allkirju on palju, asetatakse need kas 2. välja vasakusse või 6. välja vasakusse serva.
Teiste ametnike viisad, kui need on dokumendil nõutud, kantakse LÜ esitamise väljale;
väli 9 - muudatuste rida vastavalt standardile GOST 19.604-78;
väli 10 - dokumendi kiri.
LU täitmise näide on toodud viitelisas 2. Allkirjade arv lisas on antud tingimuslikult.
3. TIITELLEHE PÕHIJUHISED
3.1. Tiitelleht täidetakse vastavalt LÜ-le kehtestatud vormile ja reeglitele, kusjuures:
väli 1 - täidetud kliendi soovil;
väli 2 – ära täida;
väli 3 - programmi või tarkvaratoote täisnimi (suurtähtedega), dokumendi nimi ja liik.
Dokumendi pealkirja võib ära jätta või kombineerida toote nimetusega. Lubatud on näidata programmi või tarkvaratoote lühendatud nimetust;
väli 4 - dokumendi tähistus ja andmekandja tüübi märge.
Andmekandja tüüp näidatakse ainult juhul, kui programmidokument täidetakse andmekandjal;
väli 5 - märkige dokumendi maht;
väli 6 - ära täida;
väli 7 - dokumendi avaldamise (kinnitamise) aasta (ilma sõna “aasta” või “y” märkimata);
väli 8 - märge raamatupidamise ja ladustamise kohta vastavalt standardile GOST 19.601-78;
väli 9 - muudatuste rida vastavalt standardile GOST 19604-78;
väli 10 - dokumendi kiri.
3.2. Tiitellehel vasakus ülanurgas peaks olema järgmine kiri:
Kinnitatud--------------------- tähistus LU
Tiitellehe täitmise näide on toodud viites Lisa 3.
4. PÕHIKIRJELDUSED DOKUMENDI TEKSTIS.
LISA 1
Teave
TEAVEANDMED GOST 19.104-78 VASTAVUSE KOHTA
ST SEV 2088-80
Sec. 1 ja 2 GOST 19.104-78 vastavad jaotisele. 2 ST SEV 2088-80
Sec. 3 GOST 19.104-78 vastab jaotisele. 3 ST SEV 2088-80
LISA 2
Teave
KINNITUSLEHE TÄITMISE NÄIDE
NÕUSTUD
Kliinilise Keskhaigla juhataja
(allkiri) A. A. Petrov
MA KINNITASIN
Osakonnajuhataja
(allkiri) N. N. Sizov
MASINA KASUTUSSÜSTEEM
Laadija
Programmeerija juhend
KINNITUSLEHT
A.V.00001-01 33 01-1-LU
(salvestusmeediumi tüüp)
NÕUSTUD
KK juhataja
(allkiri) I. I. Pavlov
Tehase peainsener
(allkiri) A. A. Ivanov
esindajad
arendajafirma
Peainsener
NIIavtomatika
(allkiri) A. V. Basov
Osakonnajuhataja 12
(allkiri) G. F. Sizov
Arendusjuht
(allkiri) L. A. Sokolov
Täitja
(allkiri) A. M. Pašin
Standardne kontroller
(allkiri) G. V. Gromova
LISA 3
Teave
TIITELLEHE TÄITMISE NÄIDE
KINNITUD
A.V.00001-01 33 01-1-LU
ÜHENDATUD ELEKTROONILINE ARVUTUSÜSTEEM
MASINA KASUTUSSÜSTEEM
Laadija
Programmeerija juhend
A.V.00001-01 33 01-1
(salvestusmeediumi tüüp)
| | | järgmine loeng ==> ESPD – viitab üldiste tehniliste standardite keerukatele süsteemidele ESPD on Vene Föderatsiooni territooriumil töötav SRÜ riikide riikidevaheliste standardite süsteem, mis põhineb riikidevahelisel standardimislepingul. ESPD standardid hõlmavad seda osa dokumentatsioonist, mis luuakse tarkvara arendamise käigus ja mis on enamasti seotud tarkvara funktsionaalsete omaduste dokumenteerimisega. ESPD standardid on oma olemuselt soovituslikud ESPD on riiklike standardite kogum, mis kehtestab omavahel seotud reeglid programmide ja programmidokumentatsiooni arendamiseks, täitmiseks ja levitamiseks ESPD standardid kehtestavad programmide väljatöötamist, toetamist, tootmist ja toimimist reguleerivad nõuded, mis tagavad võimaluse: 1. Tarkvaratoodete ühtlustamine programmide vastastikuseks vahetamiseks ja varem väljatöötatud programmide kasutamine uusarendustes 2. Tööjõumahukuse vähendamine ning tarkvaratoodete arendamise, hoolduse, tootmise ja käitamise efektiivsuse tõstmine 3. Programmi dokumentatsiooni automatiseerimine, tootmine ja säilitamine Programmi hooldus hõlmab programmi toimimise, arendamise ja täiustamise analüüsi ning selles muudatuste tegemist vigade kõrvaldamiseks ESPD standardites kehtestatud reeglid ja eeskirjad kehtivad lahutavate masinate, komplekside ja süsteemide programmide ja tarkvaradokumentatsiooni suhtes, olenemata nende eesmärgist ja rakendusalast. ESPD sisaldab: 1. Põhilised ning organisatsioonilised ja metoodilised standardid 2. Andmetöötluses kasutatavate programmidokumentide vormid ja sisu määratlevad standardid 3. Standardid, mis tagavad programmidokumentide väljatöötamise automatiseerimise Organisatsioonilise ja metoodilise dokumentatsiooni väljatöötamine, mis määratleb ja reguleerib programmide väljatöötamise, hooldamise ja toimimise organisatsioonide tegevust, tuleks läbi viia ESPD standardite alusel. ESPD standardid on jagatud klassifikatsioonirühmadesse ESPD standardid on tähistatud järgmiselt: GOST 19.001-77 19 – ESPD kuuluvad standardid 0 – Üldsätted 77 – kinnitamise aasta GOST 19.503-79- süsteemi programmeerija juhend. Nõuded sisule ja kujundusele. Abstraktne ja sisu on nõutavad. Süsteemi programmeerija käsiraamat peaks sisaldama järgmisi jaotisi: 1. Üldinfo programmi kohta Programmi eesmärk ja funktsioonid ning teave riist- ja tarkvara kohta, mis tagab selle programmi täitmise 2. Programmi struktuur Teave programmi ülesehituse, selle komponentide, komponentidevaheliste seoste ja seoste kohta teiste programmidega 3. Programmi seadistamine Programmi konkreetse rakenduse jaoks seadistamise sammude kirjeldus (riistvara koostise kohandamine, funktsioonide valik jne) 4. Programmi kontrollimine Testimismeetodite kirjeldus, mis võimaldavad teha üldisi järeldusi programmi toimimise kohta (testi näited, töömeetodid, tulemused) 5. Lisafunktsioonid Lisajaotiste kirjeldus, programmi funktsionaalsus ja meetodid nende valimiseks 6. Teade süsteemi programmeerijale Programmi täitmisel väljastatud teadete tekstid, nende sisu kirjeldus ja toimingud, mida nende sõnumitega teha tuleb 7. Dokumentide loetelu Olenevalt dokumendi spetsiifikast on võimalik üksikuid jaotisi kombineerida ja uusi sisse tuua. Põhjendatud juhtudel on lubatud mitte lisada jaotist "lisafunktsioonid" ja jaotiste nimedesse - sõna programm välja jätta või asendada see programmi nimega. Süsteemi programmeerija käsiraamatu lisa võib sisaldada lisamaterjale (näited, illustratsioonid, tabelid, graafikud...) GOST 19.504-79- programmeerija juhend. Nõuded sisule ja kujundusele. Abstraktne ja sisu on nõutavad. Programmeerija käsiraamat peaks sisaldama järgmisi jaotisi: 1. Kasutusotstarve ja -tingimused Eesmärk ja funktsioonid, juurutamiseks vajalikud tingimused (RAM maht, nõuded välisseadmete koostisele ja parameetritele, tarkvara nõuded) 2. Programmi omadused Programmi põhiomaduste ja funktsioonide kirjeldus (ajakarakteristikud, töörežiim, programmi korrektse täitmise ja iseparanemise jälgimise vahendid) 3. Juurdepääs programmile Programmi väljakutsumise protseduuride kirjeldus (juhtimise ja andmeparameetrite edastamise meetodid) 4. I/O andmed I/O teabe korralduse ja vajadusel selle kodeerimise kirjeldus 5. Sõnum Programmeerijale või operaatorile programmi täitmise ajal väljastatud teadete tekstid, nende sisu kirjeldus ja toimingud, mida nende sõnumitega tuleb teha 6. Dokumentide loetelu Olenevalt dokumendi spetsiifikast on võimalik üksikuid jaotisi kombineerida ja uusi sisse tuua. Programmeerija käsiraamatu lisa võib sisaldada lisamaterjale (näited, illustratsioonid, tabelid, graafikud...) GOST 19.505-79- kasutusjuhend. Nõuded sisule ja kujundusele. Abstraktne ja sisu on nõutavad. Kasutusjuhend peaks sisaldama järgmisi jaotisi: 1. Programmi eesmärk Teave eesmärgi kohta ja piisav teave programmi funktsioonide ja selle toimimise mõistmiseks 2. Programmi täitmise tingimused Programmi täitmiseks vajalikud tingimused (minimaalne ja (või) maksimaalne riist- ja tarkvara 3. Programmi täitmine Operaatori toimingute jada, mis tagab programmi laadimise, käivitamise ja lõpetamise (käskude funktsioonide, vormingu ja võimalike valikute kirjeldus, millega operaator programmi laadib ja täitmist juhib, samuti programmi vastused neile käskudele pakkuda 4. Sõnum operaatorile Programmi täitmisel väljastatud teadete tekstid, nende sisu kirjeldus ja vastavad operaatori tegevused (operaatori toimingud tõrke korral, programmi taaskäivitamise võimalus...) 5. Dokumentide loetelu Olenevalt dokumendi spetsiifikast on võimalik üksikuid jaotisi kombineerida ja uusi sisse tuua. Sektsioonide sisu on lubatud illustreerida selgitavate näidete, tabelite, diagrammide ja graafikutega. Kasutusjuhendi lisasse on lubatud lisada erinevaid materjale, mida ei sobi juhendi osadesse lisada Selle teksti põhieesmärk on selgitada, mis on ühtne programmidokumentatsiooni süsteem (USPD) ja kuidas neid standardeid praktikas rakendada. Alustan looga selle kohta, millised standardid on olemas, ja lõpetan iga ESPD standardi eraldi rakendamise kogemusega.Kunagi, kui ma alles alustasin programmeerijana töötamist, kuulsin sageli: "Palun kirjutage oma programmi dokumentatsioon". Kirjeldasin kõike ausalt, andsin ülemusele, misjärel algas musta maagia seanss. Mõne aja pärast helistas mulle ülemus ja hakkas pomisema artikuleerimatuid helisid, kortsutas käte vahel minu “parima” teksti väljatrükki, pilgutades silmi. Tema mölisemise üldine tähendus oli see, et see osutus "valeks", "valeks" ja "vaadake, mida teised teevad". Kuna temalt muud vastust polnud võimalik saada, läksin dokumentide näiteid otsima “teised”. Reeglina olid need rõõmsad poisid, kelle kõnede tähendus oli see, et "siin on näited", "GOST-i järgi üldiselt" ja "seda pole kellelgi vaja". Nii sain esimest korda teada, et programmeerija võib kokku puutuda kohutavate GOST-i standarditega. On hämmastav, et paljude kümnete minu kolleegide, väga intelligentsete programmeerijate seas polnud kedagi, kes kohtleks GOST-e erinevalt. Isegi vähesed inimesed, kes neid tundsid ja näis, isegi dokumente vormistada oskasid, suhtusid neisse põlguse ja formaalsusega. Olukord, kus isegi arendusjuhtimise eest vastutavad inimesed ei saa aru, miks GOST-e vaja on ja kuidas neid rakendatakse, tuleb paljudes ettevõtetes ette pidevalt. Jah, oli ettevõtteid, kes mõistsid, kuidas programmi kirjeldus erineb rakenduse kirjeldusest, kuid neid oli selge vähemus. Internetis on valdav seisukoht, et programmeerijate jaoks mõeldud GOST-id on ilmselge alge ja neid on vaja ainult siis, kui need "painduvad" nende poole. Kavandi kavandit peetakse "suhteliselt õiglaseks viisiks üleliigsete pangatähtede eemaldamiseks kliendilt". Pidin sellesse süvenema ja sellest aru saama suhteliselt hiljuti – kodumaisele eripärale kohandatud nõuete haldussüsteemi väljatöötamise käigus. Dokumentatsioon, mis loomulikult tuleb genereerida “vastavalt GOST-ile”. Siin tahan keskenduda ainult ühele teemale, millega kodumaiste ettevõtete, eriti uurimisinstituutide programmeerija peab tegelema - ESPD standardite komplekt. Ma ei pea end ESPD suureks eksperdiks – on inimesi, kes on selle kallal aastakümneid töötanud ja kindlasti parandavad mind. Artiklis püütakse pigem visandada “teekaardi” piirjooned neile, kes on alles asjade hoos. StandardidVaatame põgusalt, millised standardid on olemas (keskendudes IT-valdkonnale).
Märgistussüsteemid igal tasandil ja igas organisatsioonis on erinevad, tuleb iga juhtumit eraldi analüüsida. Et kiiresti aru saada, “kelle” standard on teie silme ees, võite kasutada petulehte. GOSTNiisiis: standardid on rahvusvahelised, riikidevahelised (piirkondlikud) ja riiklikud. GOST, nagu saime teada, on piirkondlik standard. GOST-idel on minu arvates üsna segane tähistussüsteem. See on täielikult sätestatud GOST R 1.5-2004-s, annan selles navigeerimiseks miinimumi. Esiteks on vaja eristada GOST-i tähistust ja selle klassifikatsiooni. Nimetus on jämedalt öeldes standardi kordumatu tunnus. Klassifikaatori kood on abikood, mis aitab leida standardit või määrata, millisesse teadmiste valdkonda see kuulub. Klassifikaatoreid võib olla palju, peamiselt kasutatakse kahte: KGS (riigistandardite klassifikaator) ja selle järglane OKS (ülevenemaaline standardite klassifikaator). Näiteks: "GOST R 50628-2000" on standardi tähis. Nimetusest on selge, et see võeti vastu 2000. aastal. Sellel on OKS-kood “33.100;35.160”: st. "33" - jaotis "Telekommunikatsioon, heli, video", "100" - alajaotis "Elektromagnetiline ühilduvus". Samas kuulub see ka 35.160 klassifikaatori harusse. “35” – “Infotehnoloogiad. Kontorimasinad”, “160” - “Mikroprotsessorsüsteemid...”. Ja KGS-i järgi on sellel kood “E02”, mis tähendab “E” - “elektroonikatehnoloogia, raadioelektroonika ja side”, “0” - “elektroonika, raadioelektroonika ja side üldeeskirjad ja eeskirjad” jne.Kui teate standardi tähistust, saate sellelt nutikalt veebisaidilt hankida selle koodid näiteks KGS-i ja OKS-i jaoks.
ESPDESPD on üks neist GOST-i seeriatest, number 19. See tähendab. kõik ESPD-ga seotud standardid algavad eesliitega “19.”: näiteks GOST 19.106-78. Tähistab ühtset programmidokumentatsiooni süsteemi. On ka teisi sarju:
19.001-77. ÜldsättedKirjeldab ESPD seeria standarditele tähistuste määramise reegleid. Praktilises elus pole seda vaja.19.102-80. Algoritmide ja programmide skeemid. Täitmise reeglid.Kirjeldab algoritmide koostamise ja kujundamise reegleid. Kasutab tähistust alates 19.103. Minu praktikas oli seda vaja ainult siis, kui sertifitseerimislabor nõudis formaalselt, et vaja on algoritmi diagrammi. Minu vaatevinklist on klassikalised vooskeemid minevik ja ainus koht, kus need enam-vähem sobivaks jäävad, on see, kui autor soovib esitlemisel lugeja tähelepanu algoritmile koondada.19.003-80. Algoritmide ja programmide skeemid. Tavapärased graafilised sümbolidToodud on vastuvõetavate plokkskeemi elementide tüüpide graafilised tähised. Nõutav, kui kasutatakse plokkskeeme.19.004-80. Tingimused ja määratlused.Napp sõnastik. Kõige huvitavam on see, et see sisaldab programmi ja tegevusdokumentide formaalseid määratlusi.19.005-85. Algoritmide ja programmide P-skeemidPeaaegu unustatud keel. Omal ajal kasutati P-skeeme laialdaselt raketi- ja kosmosetööstuses, saades de facto standardiks stardijuhtimisprogrammide kirjutamisel ja startide simuleerimisel. Nüüd on see keel aga sootuks unustatud. Oma töös pole ma kunagi P-skeemidega kokku puutunud. Kuigi vooskeemidega võrreldes on neil märgatavaid eeliseid: need on kompaktsed, sobivad mittelineaarsete algoritmide (näiteks klassid C++ keeles) või andmestruktuuride visualiseerimiseks. Samal ajal pole Internetis nende kohta praktiliselt mingit teavet: leidsin, et see ja see sait olid kasulikud. Igal juhul, kui ma peaksin nüüd tarkvara dokumentatsiooni sisestama algoritmi diagrammi, valiksin ma pigem P-diagrammid kui vooskeemid.19.101-77. Programmide tüübid ja programmidokumendidSisaldab dokumenditüübi ja selle koodi vastavustabelit, samuti dokumenditüüpide jaotust operatiiv- ja programmiliseks. Tutvustatakse kompleksi ja komponendi mõistet. Muud kasulikku pole.19.102-77. Arengu etapidOluline ja vajalik standard, mis kirjeldab dokumenditüüpe ja annab koodid programmidokumentide tüüpidele. See standard (koos standardiga 19.103-77) on üks võtmeid selliste dokumentide tähistuste lahtiharutamiseks nagu ABVG.10473-01 32 01-1.Standard tutvustab kompleksi ja komponendi mõistet (mitmed ettevõtted lisavad kolmanda tüübi - komplekti, kui tegemist on mitteseotud tarkvaraelementidega) ning antakse jaotus: millised dokumendid töötavad ja millised mitte. Ettevaatlik tasub olla tabeliga 4, mis näitab, millist dokumenti millises arendusetapis täidetakse. Väljatöötamise etapid on tavaliselt reguleeritud projekteerimis- ja arendustööde teostamise standardites ning seal on ka märgitud, millised dokumendid tuleb igal etapil tellijale esitada. 19.102-77. Arengu etapidMinu mäletamist mööda pole seda standardit kunagi kasutatud: kes mida millises etapis teeb ja mille kohta aru annab, see on kirjas tehnilistes kirjeldustes või viidatakse GOST-idele, kus see on selgemalt kirjas (näiteks GOST RV 15.203). ). Samal ajal sisaldab see algaja jaoks üsna lakoonilist ülevaadet OCD peamistest etappidest.19.103-77. Programmide ja programmidokumentide tähistusedSeda on vaja peamiselt selleks, et õppida lugema ülaltoodud dokumentide sümboleid. Märgistusskeemi mõistmine tuleb aga kasuks siis, kui tuleb tavatööst kaugemale minna: näiteks pea meeles, et dokumendid, mille koodid on pärast 90, on kasutaja määratud, s.t. ükskõik milline. Minu praktikas avaldasime dokumendi 93, mida nimetasime "Programmi dokumentatsiooni avalduseks" ja dokumendi 96 "Assamblee juhised".Üldine fraas „täitmisvõimalus” ESPD-st puudub ja see asendatakse sõnaga „revisjoni number”. Ühest küljest pole see päris õige: versiooninumbri eesmärk oli jälgida programmi arengut: esmalt ilmub esimene väljaanne, seejärel näiteks pärast läbivaatamist teine. Kuid praktikas, kui teil on vaja välja anda tarkvara versioon mitme operatsioonisüsteemi jaoks (platvormideülene tarkvara), pole muud valikut. Täpsemalt on olemas, kuid see on vale: määrake iga operatsioonisüsteemi versioonile oma nimetus - ja pange arhiivi mitu lähtekoodiga ketast (vastavalt operatsioonisüsteemide arvule), arendage (tegelikult kopeerige) kogu dokumentatsiooni komplekt jne... See on. puhas rumal ja segane tegevus. Lahendus igale operatsioonisüsteemile versiooninumbri määramise näol võimaldab muuta mõned dokumendid ühiseks. ESPD kasutab programmi lähtekoodi ja montaaži tulemuse tähistust "dokumentidena", mis ajab paljud programmeerijad segadusse. Dokumendil “programmi tekst” vastavalt punktidele 19.101-77 on tähis 12. Lisaks aktsepteeritakse, et lähtekoodiks on märgitud 12 01 – s.o. 01 (esimene) 12. tüüpi dokument ja kahendkoodid - nagu 12 02 - st. teine dokument tüüp 12. Mõnel juhul on programmi koostamiseks vaja täiendavaid tööriistu - kompilaatorid, installeri generaatorid jne. Need. programmid, mis ei kuulu tarnekomplekti, kuid on vajalikud kokkupanekuks. Lahenduseks võiks olla nende tähistamine 12 03 - s.o. kolmas 12. tüüpi dokument. 19.104-78. Põhilised pealdisedKirjeldab kahte dokumendi lehte – kinnituslehte (AL) ja tiitellehte. ESPD-s oleval kooskõlastuslehel on nii dokumendi kooskõlastanud ametiasutuste kui ka väljatöötajate, normatiivinspektorite, vastuvõtuesindajate jne allkirjad. Need. see sisaldab ettevõtte jaoks üsna palju tundlikku teavet. Seetõttu eeldab standard, et LU jääb arendusettevõttesse ja saadetakse ainult erijuhiste alusel. Veelkord - LU ei ole osa dokumendist, vaid on justkui eraldi dokument ja see on spetsifikatsioonis eraldi reana.Algselt segadust tekitaval veidrusel LU eraldamisel dokumendist endast on väga mõjuvad põhjused:
Samuti tuleb meeles pidada, et LU ei ole nummerdatud ja esimene leht on tiitelleht ja esimene leht, millele number asetatakse, on tiitellehe kõrval. Aga kui LU-sid on rohkem kui üks (see juhtub siis, kui kõik allkirjad lehele ei mahu), siis nummerdatakse LU-d eraldi. 19.105-78. Üldnõuded programmidokumentideleTutvustatakse dokumendi üldist ülesehitust, olenemata selle täitmise viisist. Need. Veel 1978. aastal oli standardis sätestatud, et dokument ei pruugi olla paberkandjal. Eelkõige võetakse täielikult elektrooniliste dokumentide puhul kasutusele sisu mõiste. Sel ajal levinud paberkujundamiseks võeti vastu GOST 19.106-78.Praegu tuleb sellele standardile väga harva viidata: kui just ei unustata ära dokumendi põhiosade järjekord. 19.106-78. Üldnõuded trükitud programmidokumentideleKõige põhjalikum standard ESPD-st, teine pärast R-skeemide kirjeldust. See on peamine tööstandard dokumentatsiooni koostamisel. Tutvustatakse reegleid teksti, dokumendi struktuuri elementide, piltide, valemite jms vormindamiseks. Erinevalt ESKD vastavast 2.106-st on 19.106 aga oluliselt vähem detailne, mis toob kaasa palju ebakindlust.Esiteks ei määratle standard tegelikult reavahet ega pealkirjade vahelise vertikaalruumi suurust. Ta tutvustab kolme vahekauguse määramise reeglit: masinakirja teksti, masin- ja tüpograafilise teksti puhul. Masinakiri on kirjutusmasinal trükitud tekst. Järgmise rea nihutamine eelmise suhtes viidi läbi automaatselt nn "käru tagasituleku" ajal - üleminek järgmisele rea trükkimisele, mis saadakse spetsiaalse hoova liigutamisega. Tavaliselt sai vahekaugust käsitsi reguleerida, keerates paberi etteandevõlli, ja sellel oli "seadistus", mis võimaldas teil määrata vahekauguse - ühe või kahe. Masina tüüp on tõenäoliselt trükitud tekst. Kuid tema jaoks on ainult viide, et tulemus peab olema mikrofilmimiseks sobiv. See on kaudne viide 13.1.002-2003, mis paraku seab reavahe (ja muide ka minimaalse fondi kõrguse) ainult käsitsi kirjutatud dokumentidele (punkt 4.2.5). Tüpograafiline - trükikojas trükitud tekst. Arvestades standardi vastuvõtmise aastat, räägime tõenäoliselt sellest [kõrgtrükk, kus reavahe määrati kasutatava tüübi järgi. Ma ei ole tüpograafia ekspert ja ladumismeetodite kohta on praegu väga vähe teavet. Millist intervalli lõpuks kasutada, määravad sageli kohalikud eeskirjad või teenindusjaamad. Tüüpilised väärtused on poolteist vahekaugust ja fondi suurus 14. Dokumendi ülesehitus tekitab sageli palju küsimusi. 19.106 leiab, et kogu dokument on jagatud osadeks, alajagudeks, lõigeteks ja lõikudeks. Kõigil neil (välja arvatud jaotised ja alajaotised) võib olla pealkiri, aga võib ka mitte. Kus:
Sellel standardil on mitmeid "auke" ja ebakõlasid. Näiteks öeldakse: „illustratsioonid, kui neid on antud dokumendis rohkem kui üks, nummerdatakse kogu dokumendi ulatuses araabia numbritega. “Aga kui on ainult üks illustratsioon, siis see ei ole nummerdatud ja kuidas siis sellele viidata? Sama kehtib ka laudade kohta. Joonealuste märkuste puhul ei näita GOST nende nummerdamismeetodit - kogu dokumendi või lehe sees. Tabelid. Dokument ise sisaldab viidet GOST 1.5.68-le. Esimese episoodi järgi otsustades on lihtne järeldada, et see on standardite väljatöötamise standard. Mis tal sellega pistmist on, on ebaselge. Tähenduselt vastab see väikeste eranditega ESKD tabelite kujundamise reeglitele. See standard tühistati ja asendati mitme iteratsiooni kaudu 1.5-2012, milles tabeli kujundamise reeglid... lihtsalt kadusid. Veel 1.5-2002 olid nad seal, aga juba 1.5-2004 kadusid. Reaalses elus koostame tabeleid ESKD järgi. Rakendused. Standardis ei ole märgitud, kas lisade joonised, valemid ja tabelid sisalduvad üldnimekirjas. Samuti ei öelda, kas sisukorras on vaja avaldada rakenduse struktuur, kui see sisaldab oma jaotisi, lõike jne. Oma praktikas me rakenduste sisemust ei avalda. Lõpetuseks tuleks midagi öelda taande kohta. Viiest tähemärgist koosnev lõigu taane on tavaline:
Sel juhul joondatakse järgmisel real pärast taandrida asuv tekst vasaku veerisega. Sageli esineb tõrkeid taande hüppamisel - punane joon - üks väärtus, kauba number - meid erineva intervalliga, loendites pesastatud taandes - see on üldiselt vajalik. Järgmistes osades plaanin jõuda ESPD standardite loetelu lõppu. |