PSRS Valsts standartu komitejas 1978. gada 18. decembra dekrēts Nr. 3350 noteica ieviešanas termiņu.

Nr. 01.01.1980

Šis standarts nosaka vispārīgas prasības datoru, kompleksu un sistēmu programmu dokumentu izstrādei nettkarīgi no to mērķa un apjoma un ko paredz Vienotās sistēmas standarti. programmas dokumentācija(ESPD) jebkurai dokumentu noformēšanas metodei dažādos datu nesējos.

Standards atbilst ST SEV 2088-80 vispārīgajām prasībām informācijas daļas projektēšanai (skatīt atsauces pielikumu).

Wien. VISPĀRĪGĀS PRASĪBAS

3 . INFORMĀCIJAS DAĻA

3.1 . Informatīvajai daļai jāsastāv no anotācijas un satura.

3.2 Nepieciešamību iekļaut informācijas daļu dažāda veida programmas dokumentos nosaka attiecīgie ESPD standarti šiem dokumentiem.

3.3 . Anotācija sniedz informāciju par dokumenta mērķi un tā galvenās daļas kopsavilkumu.

3.4 . Saturā ir iekļauts ierakstu saraksts par dokumenta galvenās daļas strukturālajiem elementiem, no kuriem katrs ietver:

konstrukcijas elementa apzīmējums (nodaļas, apakšnodaļas u.c. numurs);

konstrukcijas elementa nosaukums;

strukturālā elementa adrese datu nesējā (piemēram, lapas numurs, lietas numurs u.c.);

Noteikumus dokumenta galvenās daļas strukturālo elementu apzīmēšanai un to adresēšanai nosaka ESPD standarti dokumentu apstrādes noteikumiem attiecīgajos datu nesējos.

Šī teksta galvenais mērķis ir izskaidrot, kas ir Wiener System programmas dokumentācija (ESPD) un kā šie standarti tiek piemēroti praksē. Sākšu ar stāstu par to, kas ir standarti, un beigšu ar katra ESPD standarta piemērošanas pieredzi atsevišķi.

Savulaik, kad es tikko sāku strādāt par programmētāju, es bieži dzirdēju "lūdzu, uzrakstiet dokumentāciju savai programmai". Godīgi visu aprakstīju, iedevu priekšniekam, pēc kā sākās melnās maģijas seanss. Pēc brīža man piezvanīja priekšnieks un sāka muldēt neizteiksmīgas skaņas, burzīdams rokās mana „labākā“ teksta izdruku, skraidīdams ar acīm. Viņa pazemojuma vispārējā nozīme bija tāda, ka tas izrādījās „nepareizi“, „nepareizi“ un „paskaties, kā citi dara“. Tā kā citu atbildi no viņa nebija iespējams iegūt, devos meklēt dokumentu piemērus pie „citiem“. Parasti tie bija jautri puiši, kuru runu nozīme bija tāda, ka „šeit ir piemēri“, „faktiski saskaņā ar GOST“ un „tas viss nevienam nav vajadzīgs“. Tāpēc es pirmo reizi uzzināju, ka programmētājs var saskarties ar briesmīgiem valsts standartiem.
Apbrīnojami, ka starp daudziem desmitiem manu kolēģu, ļoti inteliģentu programmētāju, nebija neviena, kas pret GOST izturētos savādāk. Pat tie daži cilvēki, kas viņus pazina un, šķiet, pat prata noformēt dokumentus, izturējās pret viņiem nicinoši-formāli. Situācija, kad pat par attīstības vadību atbildīgie cilvēki nesaprot, kāpēc GOST ir nepieciešami un kā tie tiks piemēroti, daudzos uzņēmumos pastāv visu laiku. Jā, bija uzņēmumi, kas saprata, ar ko „Programmas apraksts“ atšķiras no „Pieteikuma apraksta“, taču tie bija izteikti mazākumā. Internetā parasti dominē viedoklis, ka GOST programmētājiem ir acīmredzams rudiments, un tie ir nepieciešami tikai tad, ja tie „noliecas“ zem tiem. Projekta projekts tiek uzskatīts par "salīdzinoši godīgu veidu, kā no klienta paņemt papildu banknotes". Man tajā nācās iedziļināties un izdomāt salīdzinoši nesen - pašmāju specifikai pielāgotas prasību vadības sistēmas izstrādes procesā. Dokumentācija, kurai, protams, jāģenerē „saskaņā ar GOST“.

Šeit es vēlos koncentrēties tikai uz vienu tēmu, kas programmētājam ir jārisina pašmāju uzņēmumos, it īpaši pētniecības institūtos - uz ESPD standartu kopumu. Es neuzskatu sevi par lielu ESPD ekspertu - ir cilvēki, kas pie tā strādā gadu desmitiem, un viņi mani noteikti izlabos. Rakstā drīzāk mēģināts ieskicēt „ceļa kartes“ aprises tiem, kas tikai sāk.

standardi

Īsi apsvērsim, kas ir standarti (koncentrējoties uz IT jomu).

starptautiskā. pazīšanas zīme- pieņēmusi starptautiska organizācija. Šādas organizācijas piemērs ir ISO ( Starptautiska-Organisation standartizācija). Tā standarta piemērs ir ISO 2382-12:1988 (Perifērijas aprīkojums). ISO un Starptautiskās elektrotehniskās komisijas (IEC, krievu valodā - IEC) kopīgie standarti ir izplatīti: piemēram, ISO / IEC 12207:2008 (programmatūras dzīves cikls);
regionalā. Atšķirīga iezīme - pieņēmusi reģionālā standartizācijas komisija. Piemēram, daudzi padomju GOST tagad ir reģionālais standarts, jo pieņēmusi starpvalstu padome, kurā ietilpst dažas bijušās padomju republikas. Šī padome arī pieņem jaunus standartus - un tie arī saņem GOST apzīmējumu. Piemers: GOST 12.4.240-2013;
standartiem sabiedriskās asociācijas; Piemēram, tas pats IEC: IEC 60255;
valst standartiem. Krievijai šādu standartu sākumā - „GOST R“. Var Hintern tris veidi:
1. precīzas starptautisko vai reģionālo dokumentu kopijas. Tie ir apzīmēti nettšķirami no „pašrakstītiem“ (valsts, rakstīti nettkarīgi);
2. starptautiskās vai reģionālās kopijas ar papildinājumiem. Tie tiek norādīti, vietējā standarta šifram pievienojot starptautisko šifru, kas tika ņemts par pamatu. Piemer: GOST R ISO/IEC 12207;
3. faktiski valsts standarti. Piemēram, GOST R 34.11-94.

Apzīmējumu sistēmas katrā līmenī un katrā organizācijā ir atšķirīgas, katram gadījumam tas būs jāsaprot atsevišķi. Lai ātri saprastu, „kura“ standarts ir jūsu acu priekšā, varat izmantot apkrāptu lapu.

GOST

Tatad: standarti ir starptautiski, starpvalstu (reģionālie) un nacionālie. GOST, kā mēs noskaidrojām, ir reģionālais standarts. GOST ir diezgan mulsinoša, manuprāt, apzīmējumu sistēma. Tas ir pilnībā izklāstīts GOST R 1.5-2004, es došu minimumu, lai tajā varētu orientēties. Pirmkārt, ir jānošķir GOST apzīmējums un tā klasifikācija. Apzīmējums, rupji runājot, ir unikāls standarta identifikators. Klasifikatora kods ir palīgkods, kas palīdz atrast standartu vai notikt, kurai zināšanu jomai tas pieder. Klasifikatoru var būt daudz, galvenokārt tiek izmantoti divi: KGS (valsts standartu klasifikators) un tā pēctecis OKS ( Viskrievijas klasifikators standardi). Piemēram: "GOST R 50628-2000" ir standarta apzīmējums. No apzīmējuma ir skaidrs tikai tas, ka tas pieņemts 2000. gadā. Tam ir OKS kods „33.100;35.160“: t.i. "33" - sadaļa "Telekomunikācijas, audio, video", "100" - apakšsadaļa "Elektromagnētiskā saderība". Tomēr tas ir iekļauts arī klasifikatora filiālē 35.160. „35“ – „Informācijas tehnoloģijas. Biroja tehnika“, „160“ - „Mikroprocesoru sistēmas...“. Un saskaņā ar KGS tam ir kods „E02“, kas nozīmē „E“ - „Elektronika, radioelektronika un sakari“, „0“ - „ Vispargi noteikumi un elektroniskās inženierijas, radioelektronikas un sakaru normas” utt.

Ja standarta apzīmējums ir zināms, tad šajā saprātīgajā vietnē varat iegūt tā kodus, piemēram, KGS un OKS.
Tatad, atpakaļ pie GOST apzīmējumiem. Var būt divas iespējas:

standarts attiecas uz standartu sēriju. Šajā gadījumā aiz standarta kategorijas indeksa (piemēram, GOST, GOST R vai GOST RV) nāk sērijas kods, Perioden un standarta apzīmējums sērijā. Noteikumus standartu noteikšanai sērijā nosaka sērijas noteikumi. Piemēram: GOST RV 15.201-2000, GOST R 22.8.0-99, GOST 19.101-77;
standarts nepieder pie standartu sērijas. Pēc kategoriju indeksa ir vienkārši standarta sērijas numurs, domuzīme un pieņemšanas gads. Piemēram, GOST R 50628-2000.

Tātad, ja tas ir pavisam vienkārši, tad GOST apzīmējums ir vai nu tikai sērijas numurs, domuzīme, gads vai sērijas numurs, punkts un tālāk, atkarībā no sērijas. Patiesībā viss ir sarežģītāk (piemēram, jūs varat atrast kaut ko līdzīgu gost 11326.19-79, unt visspār nebūs 11326 sērija - Wette programmētājiem tas ir vajadzīgs ļoti reti sīkāku informāciju skatiet gost r 1.5-2004.).

ESPD

ESPD ir viena no šādām GOST sērijām ar numuru 19. Ti. visi ar ESPD saistītie standarti sākas ar prefiksu „19.“: piemēram, GOST 19.106-78. Tas nozīmē "Vienotā programmu dokumentācijas sistēma". Ir ari citas serijas:

GOST ESKD (vienota projektēšanas dokumentācijas sistēma, prefikss „2.“);
GOST ESTD (vienota tehnoloģiskās dokumentācijas sistēma, prefikss „3.“);
GOST R, Produktu izstrādes un ražošanas sistēma, prefikss „15.“;
GOST RV, Bruņojums un militārais aprīkojums. Produktu izstrādes un nodošanas ražošanā sistēma, prefikss „15.“;
GOST, System technisko dokumentāciju uz ACS prefikss „24.“;
GOST, automatizēto sistēmu standartu kopums, prefikss “34.”.

Tātad ESPD satur standartu kopumu, ko izmanto izstrādē Programmatur. Turklāt katram ESPD standartam ir sniegts īss apraksts un skaidrojums neskaidriem gadījumiem.

19.001-77. Vispargi noteikumi

Aprakstīti noteikumi apzīmējumu piešķiršanai ESPD sērijas standartiem. Praksē nav vajadzīgs.

19.102-80. Algoritmu un programmu shemas. Izpildes notikumi.

Apraksta algoritmu konstruēšanas un projektēšanas noteikumus. Izmanto apzīmējumu Nr. 19.103. Manā praksē vienīgā reize bija vajadzīga, kad sertifikācijas laboratorija formāli balstījās uz to, ka ir vajadzīga algoritmu shēma. Manā skatījumā klasiskās blokshēmas ar divām kājām ir pagātnē, un vienīgā vieta, kur tās palika vairāk vai mazāk aktuālas, ir, ja autors vēlas prezentācijā koncentrēt lasītāja uzmanību uz algoritmu.

19.003-80. Algoritmu un programmu shemas. Nosacīti grafiskie simboli

Ir doti pieļaujamo blokshēmas elementu veidu grafiskie apzīmējumi. Nepieciešams, ja tiek izmantotas blokshēmas.

19.004-80. Termini un definedcijas.

Slikta glossarijs. No interesantākajiem - satur formālas programmas un darbības dokumentu definīcijas.

19.005-85. Algoritmu un programmu P-shēmas

Gandrīz aizmirsta valoda. Savulaik P-diagrammas tika plaši izmantotas raķešu un kosmosa industrijā, kļūstot par de facto standartu palaišanas kontroles programmu rakstīšanai un palaišanas simulācijai. Tomēr tagad šī valoda ir pilnībā aizmirsta. Savā darbā es nekad neesmu saskāries ar R shēmām. Lai gan, salīdzinot ar blokshēmām, tām ir manāmas priekšrocības: tās ir kompaktas, piemērotas nelineāru algoritmu (piemēram, klases C++) vai datu struktūru vizualizēšanai. Tajā pašā laikā internetā par tiem praktiski nav informācijas: šī un šī vietne man šķita noderīga. Jebkurā gadījumā, ja man tagad programmatūras dokumentācijā būtu jāievieto algoritma diagramma, es izvēlētos P-diagrammas, nevis blokshēmas.

19.101-77. Programmu veidi un programmas dokumenti

Tajā ir atrodama dokumenta veida un tā koda atbilstības tabula, kā arī dokumenta veidu iedalījums operatīvajos un programmās. Tiek ieviests kompleksa un komponenta jēdziens. Nav neka noderigaka.

19.102-77. Attīstības stadijas

Svarīgs un nepieciešams standarts, kas apraksta dokumentu veidus un nodrošina programmas dokumentu veidu kodus. Šis standarts (kopā ar 19.103-77) ir viens no atslēgām, lai „atšķetinātu“ tādu dokumentu apzīmējumus kā ABVG.10473-01 32 01-1.
Standards ievieš kompleksa un komponenta jēdzienu (vairāki uzņēmumi pievieno trešo veidu - komplektu, ja runa ir par nesaistītiem programmatūras elementiem), tiek dots sadalījums: kuri dokumenti darbojas, kuri ne.
Rūpīgi jāizturas pret 4. tabulu, kurā redzams, kurš dokuments kurā izstrādes stadijā tiek noformēts. Izstrādes posmi parasti tiek reglamentēti P&A standartos, kā arī norādīts, kādi dokumenti katrā posmā jāuzrāda pasūtītājam.

19.102-77. Attīstības stadijas

Manā atmiņā šis standarts nekad nav ticis piemērots: kurš, kurā posmā ko dara un kā viņš ziņo, ir notikts TTZ vai ir sniegta atsauce uz GOST, kur tas ir skaidri norādīts (piemēram, GOST RV 15.203). Tajā pašā laikā iesācējam tajā ir apkopojums par darbu galvenajos pētniecības un izstrādes posmos, kas savā lakonismā nav slikts.

19.103-77. Programmu un programmu dokumentu apzīmējumi

Tas ir nepieciešams galvenokārt, lai iemācītos lasīt tādu dokumentu apzīmējumus kā iepriekš. Tomēr apzīmēšanas shēmas izpratne ir noderīga, ja jums ir jaiet ārpus tipiskā darba: piemēram, atcerieties, ka dokumenti, kuru kodi ir pēc 90, ir lietotāja definēti, t.i. jebkura. Manā praksē mēs izdevām 93.dokumentu, ko saucām par „Programmas dokumentācijas lapu“, 96.dokumentu – „Montāžas instrukcijas“.
ESPD nav izplatītas frāzes „izpildes versija“, un tā ir aizstāta ar „pārskatīšanas numuru“. No vienas puses, tas nav pilnīgi pareizi: pārskatīšanas numurs tika izveidots, lai izsekotu programmas attīstībai: vispirms tiek izlaists pirmais izdevums, pēc tam, piemēram, pēc pārskatīšanas, otrais. Bet praksē, kad ir jāizlaiž programmatūras versija vairākām operētājsistēmām (starpplatformu programmatūra), citas izejas nav. Precīzāk, ir, bet tas ir nepareizi: katrai operētājsistēmai piešķiriet versiju savam apzīmējumam - un arhivējiet vairākus diskus ar pirmkodiem (atbilstoši operētājsistēmu skajiitam), izstrādskiējietam dokumentāciju utt. ... Ti tīrs ūdens stulba un mulsinoša darbība. Lēmums par katras operētājsistēmas versijas piešķiršanu ar savu pārskatīšanas numuru ļauj dažus dokumentus padarīt kopīgus.
ESPD tiek izmantots programmas avota tekstu un montāžas rezultāta apzīmējums kā „dokumenti“, kas mulsina daudzus programmētājus. „Programmas teksta“ dokumentam saskaņā ar 19.101-77 ir apzīmējums 12. Tālāk tiek pieņemts, ka pirmkodi ir apzīmēti kā 12 01 - t.i. 01 (pirmais) 12. tipa documents un binārie faili - piemēram, 12 02 - t.i. veidlapas otrais Dokumente 12. Atsevišķos gadījumos, lai izveidotu programmu, papildus Instrumente- kompilatori, uzstādītāju ģeneratori utt. Binden. programmas, kas nav iekļautas piegādē, bet ir nepieciešamas montāžai. Risinājums var būt to apzīmēšana ar 12 03 – t.i. trešais 12. tipa-dokumente.

19.104-78. pamata uzraksti

Apraksta divas dokumenta lapas - apstiprinājuma lapu (AL) un titullapu. ESPD saskaņošanas lapā ir gan dokumentu apstiprinājušo iestāžu paraksti, gan izstrādātāju, normatīvo kontrolieru, pieņemšanas pārstāvju u.c. Binden. tajā ir diezgan daudz uzņēmumam sensitīvas informācijas. Tāpēc standartā ir pieņemts, ka LU paliek jaunattīstības uzņēmumā un tiek nosūtīta tikai pēc īpašiem norādījumiem. Kārtējo reizi LU neietilpst dokumentā, bet it kā ir atsevišķs dokuments, un tas ir iekļauts specifikācijā kā atsevišķa rinda.
Sākotnēji apkaunojošajai dīvainībai, atdalot LL no paša dokumenta, ir ļoti labi iemesli:

kā jau minēts, bieži vien uzņēmums nevēlas izpaust informāciju par izstrādātāju. LU atdalīšana un tās „spīlēšana“ ļauj to izdarīt (uz dokumenta lapām ESPD nav zīmoga, visa informācija ir lokalizēta tikai LU);
vairāki uzņēmumi izmanto jauktu darbplūsmu: oriģinālie dokumenti tiek glabāti elektroniskā formatā uzņēmuma arhīvā, un uz tiem LU (ar oriģināliem parakstiem) - papīra formātā;

Runājot par LU reģistrāciju, diezgan bieži uzņēmumos tiek izmantots maisījums - daļa LU uzrakstu tiek izsniegti pēc ESPD, daļa - pēc ESKD, bet daļa - savā veidā. Tāpēc vislabāk, pirms pašam taisīt LU, pameklēt uzņēmuma standartu (STO) vai ņemt piemēru no vietējās normatīvās kontroles.
Jāatceras arī, ka LU nav numurēts, un pirmā lapa ir titullapa, un pirmā lapa, kurā ievietots numurs, ir tā, kas atrodas aiz titullapas. Bet gadījumā, ja LU ir vairāk par vienu (tas notiek, ja visi paraksti neder uz lapas), tad LU numurē atsevišķi.

19.105-78. Visparigas prasības politikas dokumentiem

Evasts vispārēja struktūra dokumentu nettkarīgi no tā, kā tas tiek izpildīts. Binden. 1978 Jo īpaši satura jēdziens ir ieviests pilnībā elektronische Dokumente. Papīra versijai, kas tajā laikā bija izplatīta, tika pieņemts GOST 19.106-78.
Pašlaik šim standartam ir jāpiekļūst ļoti reti, izņemot to, ka tiek aizmirsta dokumenta galveno daļu secība.

19.106-78. Vispārīgās prasības drukātajiem programmas dokumentiem

Apjomīgākais ESPD standarts, kas ir zemāks tikai par R-shēmu aprakstu. Tas ir galvenais darba standarts dokumentācijas sagatavošanā. Ievieš formatēšanas noteikumus tekstam, dokumentu struktūras elementiem, attēliem, formulām utt. Tomēr atšķirībā no atbilstošās 2.106 no ESKD, 19.106 ir ievērojami mazāk detalizēts, kas rada daudzas neskaidrības.
Pirmkārt, standarts faktiski nenosaka rindstarpu un vertikālo polsterējumu starp virsrakstiem. Tas ievieš trīs noteikumus atstarpju noteikšanai: mašīnrakstītam tekstam, mašīnrakstītajam tekstam un tipogrāfiskajam tekstam.
Rakstāmmašīnas teksts ir teksts, kas rakstīts ar rakstāmmašīnu. Nakamās rindas nobīde attiecībā pret iepriekšējo tika veikta automātiski ar tā saukto "ratu atgriešanos" - pāreju uz nākamās rindas drukāšanu, kas tika veikta, pārvietojot īpašu sviru. Parasti atstarpi varēja manuāli pielāgot, pagriežot papīra padeves rullīti, un tam bija "iestatījums", lai iestatītu atstarpi uz vienu vai dubultu.
Mašīna - tas, visticamāk, ir drukātais teksts. Bet viņam ir tikai norāde, ka rezultātam jābūt piemērotam mikrofilmēšanai. Tā ir netieša atsauce uz 13.1.002-2003, kas diemžēl nosaka rindstarpu (un, starp citu, minimālo fonta augstumu) tikai ar roku rakstītiem dokumentiem (4.2.5. punkts).
Tipogrāfija - teksts, kas ierakstīts tipogrāfija. Ņemot vērā gadu, kad standarts tika pieņemts, visticamāk, mēs runājam par
[augstspiede, kur rindstarpas tika noteiktas pēc izmantotajām rakstzīmēm. Es neesmu tipogrāfijas eksperts, un šobrīd ir ļoti maz informācijas par salikšanas metodēm.
Kuru intervālu beigās izmantot, bieži nosaka vietējās regulatīvās kontroles vai degvielas uzpildes stacijas. Tipiskās vērtības ir 1.5 atstarpes un 14 fontu lielums.
Dokumenta struktūra bieži rada daudz jautājumu. 19.106 uzskata, ka viss documents ir sadalīts sadaļās, apakšsadaļās, punktos un apakšpunktos. Visiem (izņemot sadaļu un apakšsadaļu) var būt vai nebūt virsraksts. Kura:

„dokumenta saturs ietver to sadaļu, apakšsadaļu, rindkopu un apakšpunktu skaitu, kuriem ir virsraksts“ (2.1.4. punkts). Tā ir tieša norāde, ka apakšpozīcijai var būt virsraksts un to var iekļaut satura rādītājā;
"Tekstu ir atļauts ievietot starp sadaļas un apakšsadaļas virsrakstiem, starp apakšsadaļas un rindkopas virsrakstiem." Ir svarīgi ņemt vērā, ka nenumurētais teksts var atrasties tikai starp virsrakstiem un tikai divos augšējos līmeņos.

Atšķirībā no ESKD, ESPD ir dīvains rasējumu noformēšanas veids: vispirms parādās zīmējuma nosaukums, pēc tam pats zīmējums, pēc tam izvēles „figūras teksts“ un pēc tam jaunā „rindiņ. N".
Šim standartam ir vairāki „caurumi“, ordentlichbilstības. Piemēram, ir teikts: „ilustrācijas, ja tās ir also dokumentu vairāk nekā viens, numurēts ar arābu cipariem visā dokumentā. „Bet, ja ir tikai viena ilustrācija, tad tā nav numurēta, un kā tad uz to atsaukties? Tas pats attiecas uz galdiem. Zemsvītras piezīmēm GOST nenorāda, kā tās ir numurētas - visā dokumentā vai lapā.
Tabellen. Pašā dokumentā ir atsauce uz GOST 1.5.68. Spriežot pēc pirmās sērijas, ir viegli secināt, ka šis ir standartu izstrādes standarts. Un šeit viņš ir, nav skaidrs. Pēc nozīmes tas atbilst ESKD tabulu noformēšanas noteikumiem, ar dažiem izņēmumiem. Šis standarts tika atcelts, tā vietā ieviests pēc vairākām iterācijām, 1.5-2012, kurā tabulas formatēšanas noteikumi ... vienkārši pazuda. Vēl 1.5-2002.gadā tie bija, un jau 1.5-2004.gadā pazuda. IN Ista dzive sastādām tabulas pēc ESKD.
Lietojumprogramme. Standards nenorāda, vai skaitļi, formulas un tabulas no pieteikumiem ietilpst vispārīgajā sarakstā. Tāpat nav teikts, vai satura rādītājā ir jāatklāj lietojumprogrammas struktūra, ja tajā ir savas sadaļas, rindkopas utt. Mūsu praksē mēs nettklājam lietojumprogrammu iekšējos elementus.
Visbeidzot, jāsaka par ievilkumiem. 5 rakstzīmju rindkopas atkāpe ir izplatīta:

sarkanā līnija;
dokumenta struktūras elementa atkāpe aiz sadaļas (apakšnodaļas, rindkopas, apakšpunkta);
Enum-Elemente.

Nākamajās daļās plānoju nonākt līdz ESPD standartu saraksta beigām.

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

Vienota programmu dokumentācijas sistēma	GOST 19.105-78* (ST SEV 2088-80)

VISPĀRĪGĀS PRASĪBAS PROGRAMMU DOKUMENTIEM

Vienota programmu dokumentācijas sistēma. Vispārējās prasības programmas dokumentiem.

PSRS Valsts standartu komitejas 1978. gada 18. decembra dekrēts Nr. 3350 noteica ieviešanas termiņu.

Nr. 01.01.1980

Šis standarts nosaka vispārīgas prasības datoru, kompleksu un sistēmu programmu dokumentu izpildei nettkarīgi no to mērķa un apjoma un ko paredz Vienotās programu dokumentācijas sistēmas (ESPD) standarti jebkurai dokumentu izpildes metodei dažādos.

Standards atbilst ST SEV 2088-80 vispārīgajām prasībām informācijas daļas projektēšanai

1. VISPĀRĪGĀS PRASĪBAS

1.1. Politikas dokumentu var noformēt uz dažāda veida datu nesējiem.

1.2. Programmas dokuments sastāv no šādām nosacītajām daļām:

Titel;

informativ;

Papata;

izmaiņu reģistrācija.

1.3. Dokumenta un tā daļu noformēšanas noteikumus uz katra datu nesēja nosaka ESPD standarti dokumentu noformēšanas noteikumiem uz attiecīgajiem datu nesējiem.

2. NOSAUKUMA DAĻA

2.1. Virsraksta daļa sastāv no apstiprinājuma lapas un titullapa. Apstiprinājuma lapas un titullapas noformēšanas noteikumi ir noteikti saskaņā ar GOST 19.104-78.

3. INFORMĀCIJAS DAĻA

3.1. Informatīvajai daļai jāsastāv no anotācijas un satura.

3.2. Nepieciešamību iekļaut informācijas daļu dažāda veida programmas dokumentos nosaka attiecīgie ESPD standarti šiem dokumentiem.

3.3. Anotācija sniedz informāciju par dokumenta mērķi un tā galvenās daļas kopsavilkumu.

konstrukcijas elementa apzīmējums (nodaļas, apakšnodaļas u.c. numurs);

konstrukcijas elementa nosaukums;

strukturālā elementa adrese datu nesējā (piem., lapas numurs, faila numurs utt.).

Noteikumus dokumenta galvenās daļas strukturālo elementu apzīmēšanai un to adresēšanai nosaka ESPD standarti dokumentu apstrādes noteikumiem attiecīgajos datu nesējos.

4. GALVENĀ DAĻA

4.1. Programmas dokumenta galvenās daļas sastāvu un struktūru nosaka ESPD standarti attiecīgajiem dokumentiem.

5. IZMAIŅU REĢISTRACIJAS DAĻA

5.1. Katras izmaiņas programmas dokumentā šajā daļā tiek reģistrētas saskaņā ar GOST 19.603-78 prasībām.

PIELIKUMS Atsauce

INFORMĀCIJAS DATI PAR ATBILSTĪBU GOST 19.105-78 ST SEV 2088-80

Sek. 3 GOST 19.105-78 atbilst Sec. 4 (4.2., 4.3. Punkte) ST SEV 2088-80.

(Eviests papildus. Grozījums Nr. 1)

* Atkārtota izdošana (1987. gada novembris) ar grozījumu Nr. 1, kas apstiprināts 1981. gada septembrī (IUS 11-81)

Savā ziņojumā es paļaujos uz:

raksts "Standartizācija programmatūras jomā" V.V. Vasyutkovich - nodaļas vadītājs un S.S. VNII-Standard GOSSTANDARD RF;
EZ Zinder raksts "Sistēmu dzīves ciklu organizēšanas standartu korelācija un izmantošana";
GOST un citu standartu teksti.

1. Galvenie jautājumi programmatūras izstrādē

Kad programmētājs-izstrādātājs vienā vai otrā veidā saņem programmēšanas uzdevumu, viņam, projekta vadītājam un visai projekta komandai rodas jautājumi:

kas būtu jādara, izņemot pašu programmu?
kas un kā jādokumentē?
ko nodot lietotājiem un ko? eskorta pakalpojums?
kā vadīt visu šo procesu?
Kas jāiekļauj pašā programmēšanas uzdevumā?

Papildus iepriekš minētajiem jautājumiem ir arī citi.

Uz šiem un daudziem citiem jautājumiem savulaik atbildēja valsts standarti programmu dokumentācijai? GOST ESPD 19. sērijas standartu kopums. Bet tad programmētājiem bija daudz sūdzību par šiem standartiem. Kaut ko daudzkārt vajadzēja dublēt dokumentācijā (kā likās - nepamatoti), un daudz kas netika sniegts, piemēram, atspoguļojot ar integrēto datu bāzi strādājošo programmu dokumentēšanas specifiku.

Šobrīd aktuāls joprojām ir jautājums par programmatūras iekārtu (PS) dokumentācijas regulēšanas sistēmas esamību.

2. Valsts vispārīgais raksturojums

Vietējā normatīvā regulējuma pamats PS dokumentācijas jomā ir Vienotās programmu dokumentācijas sistēmas (ESPD) standartu kopums. ESPD kompleksa galvenā un lielākā daļa tika izstrādāta 70. un 80. gados. Tagad šis komplekss ir NVS valstu starpvalstu standartu sistēma (GOST), kas darbojas teritorijā Krievijas Federacija pamatojoties uz starpvalstu vienošanos par standartizāciju.

ESPD standarti galvenokārt aptver to dokumentācijas daļu, kas tiek izveidota PS izstrādes laikā, un lielākoties ir saistīta ar PS funkcionālo īpašību dokumentēšanu. Jāatzīmē, ka ESPD standartiem (GOST 19) ir ieteikuma raksturs. Tomēr tas attiecas arī uz visiem citiem PS standartiem (GOST 34, ISO/IEC starptautiskais standarts utt.). Fakts ir tāds, ka saskaņā ar Krievijas Federācijas likumu "Par standartizāciju" šie standarti kļūst obligāti uz līguma pamata - tas ir, ja tie ir minēti līgumā par PS izstrādi (piegādi).

Runājot par ESPD stāvokli kopumā, var konstatēt, ka lielākā daļa ESPD standartu ir novecojuši.

Starp galvenajiem trūkumiem ESPD var attiecinat:

koncentrēties uz vienotu PS dzīves cikla (LC) „kaskādes“ modeli;
skaidru ieteikumu trūkums par PS kvalitātes raksturlielumu dokumentēšanu;
sistēmiskas saiknes trūkums ar citām pastāvošām vietējām dzīves cikla un produktu dokumentācijas standartu sistēmām kopumā, piemēram, ESKD;
neskaidra pieeja PS kā tirgojama produkta dokumentēšanai;
ieteikumu trūkums PS pašdokumentēšanai, piemēram, ekrāna izvēlņu un tiešsaistes lietotāja palīdzības rīku veidā („palīdzība“);
ieteikumu trūkums par PS perspektīvo dokumentu sastāvu, saturu un izpildi, kas atbilst starptautisko un reģionālo standartu ieteikumiem.

Tātad ESPD ir pilnībā jāpārskata, pamatojoties uz ISO / IEC 12207-95 standartu PS dzīves cikla procesiem, šis standarts tiks apspriests sīkāk vēlāk).

Jāsaka, ka līdz ar ESPD kompleksu ierēdnis normative bāze Krievijas Federācija PS dokumentācijas jomā un ar to saistītajās jomās ietver vairākus daudzsološus standartus (iekšzemes, starpvalstu un starptautiskā līmenī).

starptautiskais Standards ISO/IEC 12207: 1995-08-01 par programmatūras produktu dzīves cikla organizēšanu (SW) - tas šķistu ļoti neskaidrs, bet pilnīgi jauns un daļēji "modīgs" standarts.

Sarežģīti standarti GEOST 34 radīšanai un attīstībai automatizētas sistēmas(AS) - vispārināts, bet uztverts kā ļoti stingrs dzīves cikla struktūras un projekta dokumentācijas ziņā. Taču daudzi uzskata, ka šie standarti ir birokrātiski līdz pat kaitīgiem un konservatīviem līdz novecojušiem. Cik lielā mērā tas tā ir un cik lielā mērā GOST 34 joprojām darbojas ar labumu, ir lietderīgi to noskaidrot.

Savā rakstā E.Z. Zinders detalizēti aplūko metodiku Oracle CDM(Custom Development Method), lai izstrādātu lietišķo Informationssystem sistēmas saskaņā ar pasūtījumu - konkrēts materiāls, detalizēts līdz projektēšanas dokumentu sagataves līmenim, paredzēts tiešai lietošanai AES projektos, pamatojoties uz Oracle rīkiem.

2.1. Īss ievads ESPD standartos

Tomēr, kamēr viss komplekss nav pārskatīts, daudzus ESPD standartus var lietderīgi pielietot PS dokumentēšanas praksē. Šīs pozīcijas pamatā ir:

ESPD standarti ievieš racionalizācijas elementu PS dokumentēšanas procesā;
ESPD standartos paredzētais programmu dokumentu sastāvs nemaz nav tik „stingrs“, kā dažiem šķiet: standarti ļauj PS dokumentācijas komplektu papildināt ar papildu veidiem.
ESPD standarti turklāt ļauj mobilajā režīmā mainīt noteikto PD veidu struktūru un saturu, pamatojoties uz klienta un lietotāja prasībām.

Tajā pašā laikā standartu piemērošanas stils var atbilst mūsdienu vispārējam standartam pielāgošanas standartam projekta specifikai: pasūtītājs un projekta vadītājs izvēlas projektā v atbilstošu standartu un Āto apildina kopuiz, papildina kopuiz, papildina kopuiz PD ar nepieciešamajām sadaļām un izslēdzot nevajadzīgās, sasaistīt šo dokumentu veidošanu ar projektā izmantoto LC shēmu.

ESPD standarti (tāpat kā citi GOST) ir sadalīti grupās, kas norādītas tabulā:

ESPD standarda apzīmējums ir veidots saskaņā ar klasifikācijas pazīmi:

ESPD standarta apzīmējumam jāsastāv no:

numurs 19 (piešķirts ESPD standartu klasei);
viens cipars (aiz punkta), kas norāda tabulā norādītās standartu klasifikācijas grupas kodu;
divciparu skaitlis (aiz domuzīmes), kas norāda standarta reģistrācijas gadu.

ESPD dokumentu Saraksts

GOST 19.001-77 ESPD. Vispargi noteikumi.
GOST 19.101-77 ESPD. Programmu veidi un programmas dokumenti.
GOST 19.102-77 ESPD. Attīstības stadijas.
GOST 19.103-77 ESPD. Programmu un programmu dokumentu apzīmēšana.
GOST 19.104-78 ESPD. Pamata uzraksti.
GOST 19.105-78 ESPD. Vispārīgās prasības programmas dokumentiem.
GOST 19.106-78 ESPD. Prasības programmas dokumentiem, kas izgatavoti drukātā veidā.
GOST 19.201-78 ESPD. Tehniskais uzdevums. Prasibas saturam und dizainam.
GOST 19.202-78 ESPD. Spezifikacija. Prasibas saturam und dizainam.
GOST 19.301-79 ESPD. Pārbaudes procedūra un metodes.
GOST 19.401-78 ESPD. Programmtexte. Prasibas saturam und dizainam.
GOST 19.402-78 ESPD. Programme apraksts.
GOST 19.404-79 ESPD. Paskaidrojuma Piezime. Prasibas saturam und dizainam.
GOST 19.501-78 ESPD. Veidlapa. Prasibas saturam und dizainam.
GOST 19.502-78 ESPD. Lietojumprogrammas apraksts. Prasibas saturam und dizainam.
GOST 19.503-79 ESPD. Sistēmas programmētāja rokasgrāmata. Prasibas saturam und dizainam.
GOST 19.504-79 ESPD. Programmētāja rokasgrāmata.
GOST 19.505-79 ESPD. Operatora rokasgrāmata.
GOST 19.506-79 ESPD. Valodas apraksts.
GOST 19.508-79 ESPD. Vadit apkope. Prasibas saturam und dizainam.
GOST 19.604-78 ESPD. Noteikumi izmaiņu veikšanai programmas dokumentos, kas tiek drukāti.
GOST 19.701-90 ESPD. Algoritmu, programmu, datu un sistēmu shēmas. Konvencijas un izpildes notikumi.
GOST 19.781-90. Informācijas apstrādes sistēmu programmatūras nodrošināšana.

Termini undefined

No visiem ESPD standartiem koncentrēsimies tikai uz tiem, kurus praksē var izmantot biežāk.

Pirmkārt, mēs norādām standartu, ko var izmantot programmēšanas uzdevumu veidošanā.

GOST (ST SEV) 19.201-78 (1626-79). ESPD. Tehniskais uzdevums. Prasibas saturam und dizainam. (Atkārtoti izdots 1987. gada novembrī ar 1. redakciju).

Darba uzdevums (TOR) satur prasību kopumu PS, un to var izmantot kā kritēriju izstrādātās programmas pārbaudei un akceptēšanai. Tāpēc diezgan pilnībā sastādīts (ņemot vērā iespēju ieviest papildu sadaļas) un pasūtītāja un izstrādātāja akceptēts TOR ir viens no PS projekta pamatdokumentiem.

Darba uzdevumā jāiekļauj šādas sadaļas:

ievads;
attīstības pamatojums;
attīstības mērķis;
prasības programmai vai programmatūras produktam;
programmatūras dokumentācijas prasības;
tehniskie un ekonomiskie rādītāji;
attīstības stadijas un stadijas;
kontroles un pieņemšanas kārtība;
darba uzdevumā atļauts iekļaut pieteikumus.

Atkarībā no programmas vai programmatūras produkta īpašībām ir atļauts precizēt sadaļu saturu, ieviest jaunas sadaļas vai apvienot dažas no tām.

Nakamais-Standards
GOST (ST SEV) 19.101-77 (1626-79). ESPD. Programmu veidi un programmas dokumenti (Atkārtoti izdots 1987. gada novembrī ar 1. red.).
Izveido programmu veidus un programmu dokumentus datoriem, kompleksiem un sistēmām nettkarīgi no to mērķa un apjoma.

Programmu veidi

Politikas dokumentu veidi

Politikas dokumenta veids
Spezifikacija	Programmas sastāvs un tā dokumentācija
	Uzņēmumu saraksts, kas glabā programmu dokumentu oriģinālus
Programmtexte	Programme ierakstīšana ar nepieciešamajiem komentāriem
Programme apraksts	Informācija par programmas loģisko uzbūvi un darbību
	Programmes testēšanas laikā pārbaudāmās prasības, kā arī to kontroles kārtība un metodes
Tehniskais uzdevums	Programme mērķis un apjoms, tehniskās, tehniskās, ekonomiskās un īpašās prasības programmai, nepieciešamie izstrādes posmi un termiņi, testu veidi
Paskaidrojuma Piezime	Algoritma shēma, vispārīgs algoritma un (vai) programmas darbības apraksts, kā arī pieņemto tehnisko un tehnisko un ekonomisko risinājumu pamatojums.
Darbibas dokumenti	Informācija programmas funkcionēšanas un darbības nodrošināšanai

Betreiben Sie documentu veidi

Operativa dokumenta veids
	Programme darbibas dokumentu saraksts
veidlapa	Programmas galvenās īpašības, pilnīgums un informācija par programmas darbību
Lietojumprogrammas apraksts	Informācija par programmas mērķi, apjomu, izmantotajām metodēm, risināmo uzdevumu klasi, lietošanas ierobežojumiem, tehnisko līdzekļu minimālo konfigurāciju
	Informācija testēšanai, programmas darbības nodrošināšanai un noskaņošanai konkrētas aplikācijas apstākļiem
Programmētāja rokasgrāmata	Informācija par programmas lietošanu
Operatora rokasgrāmata	Informācija, lai nodrošinātu saziņas kārtību starp operatoru un datoristēmu programmas izpildes laikā
Valodas apraksts	Valodas sintakses un semantikas apraksts
	Informācija pārbaudes un diagnostikas programmu izmantošanai tehnisko līdzekļu apkopē

Atkarībā no īstenošanas metodes un pieteikuma rakstura programmas dokumenti tiek sadalīti oriģinālā, dublikātā un kopijā (GOST 2.102-68), kas paredzēti programmas izstrādei, uzturēšanai un darbībai.

Dažādos posmos izstrādāto programmu dokumentu veidi un to kodi

Documenta Veida-Codes	Dokumentieren Sie Veiden	Attīstības stadijas
		Sakotnējais dizains	Tehniskais-Projekte	darba-Projekte
		Sakotnējais dizains	Tehniskais-Projekte	Komponenten	Komplex
-	Spezifikacija	-	-	!	+
05	Oriģinālo turētāju Saraksten	-	-	-	?
12	Programmtexte	-	-	+	?
13	Programme apraksts	-	-	?	?
20	Operativo dokumentu izzina	-	-	?	?
30	veidlapa	-	-	?	?
31	Lietojumprogrammas apraksts	-	-	?	?
32	Sistēmas programmētāja rokasgrāmata	-	-	?	?
33	Programmētāja rokasgrāmata	-	-	?	?
34	Operatora rokasgrāmata	-	-	?	?
35	Valodas apraksts	-	-	?	?
46	Servisa rokasgrāmata	-	-	?	?
51	Parbaudes programma un methododika	-	-	?	?
81	Paskaidrojuma Piezime	?	?	-	-
90-99	Citi documenti	?	?	?	?

Ir atļauts kombinēt notikti veidi operatīvie dokumenti (izņemot operatīvo dokumentu izziņu un veidlapu). Nepieciešamība apvienot šos dokumentus ir norādīta darba uzdevumā. Apvienotajam dokumentam tiek piešķirts viena no apvienotajiem dokumentiem nosaukums un apzīmējums. Apvienotajos dokumentos ir jābūt informācijai, kas jāiekļauj katrā apvienotajā dokumentā.

GOST 19.102-77. ESPD. Attīstības stadijas.

Nosaka datoru, kompleksu un sistēmu programmu un programmatūras dokumentācijas izstrādes posmus nettkarīgi no to mērķa un apjoma

Attīstības stadijas, posmi un darba saturs

Attīstības stadijas	Darba posmi
Tehniskais uzdevums	Programmas izstrādes nepieciešamības pamatojums	Probleme formulēšana. Izejmaterialu vākšana. Izstrādātās programmas efektivitātes un kvalitātes kritēriju izvēle un pamatojums. Pētnieciskā darba nepieciešamības pamatojums.
	Petnieciskais darbs	Ievades un izvaddatu strukturas noteikšana. Problēmu risināšanas metožu iepriekšēja izvēle. Iepriekš izstrādāto programmu izmantošanas lietderības pamatojums. Prasību noteikšana tehniskajiem līdzekļiem. Problēmas risināšanas pamatiespējas pamatojums.
	Darba uzdevuma izstrade un apstiprināšana	Prasību notikšana programmai. Priekšizpētes izstrāde programmas izstrādei. Programme izstrādes posmu, posmu un termiņu definīcija un dokumentācija par to. Programmēšanas valodu izvēle. Pētnieciskā darba nepieciešamības noteikšana turpmākajos posmos. Darba uzdevuma saskaņošana un apstiprināšana.
Sakotnējais dizains	Projekta projekta izstrade	Ievades un izvaddatu struktūras sākotnējā izstrāde. Problēmas risināšanas metožu pilnveidošana. Problēmas risināšanas algoritma vispārīga apraksta izstrāde. Priekšizpetes izstrade.
Sakotnējais dizains	Koncepcijas projekta apstiprinašana	Projekta projekta saskanosana un apstiprināšana
Tehniskais-Projekte	Tehniskā projekta izstrade	Ievades un izvaddatu struktūras pilnveidošana. Algoritma izstrade problēmas risināšanai. Ievades un izejas datu attēlojuma formas noteikšana. Valodas semantikas un sintakses definicija. Programmas strukturas izstrade. Aparatūras konfigurācijas galīgā definīcija.
Tehniskais-Projekte	Tehniskā projekta apstiprināšana	Rīcības plāna izstrāde programmu izstrādei un īstenošanai. Paskaidrojuma raksta izstrade. Tehniskā projekta saskaņošana un apstiprināšana.
darba-Projekte	Programme izstrade	Programmes programmēšana un atkļūdošana
	Programmas dokumentācijas izstrade	Programmas dokumentu izstrāde saskaņā ar GOST 19.101-77 prasībām.
	Programme izmēģinājumi	Programme un pārbaudes metožu izstrāde, saskaņošana un apstiprināšana. Iepriekšējo stāvokļa, starpresoru, pieņemšanas un cita veida testu veikšana. Programme un programmas dokumentācijas korekcija, pamatojoties uz testa rezultātiem.
Īstenošana	Programmas sagatavošana un pārraide	Programme un programmas dokumentācijas sagatavošana un nodošana apkopei un (vai) ražošanai. Akta par programmas nodošanu apkopei un (vai) ražošanai reģistrācija un apstiprināšana. Programmas nodošana algoritmu un programmu fondā.

Piezime:

Ir atļauts izslēgt otro attīstības posmu, bet tehniski pamatotos gadījumos - otro un trešo posmu. Šo posmu nepieciešamība ir norādīta darba uzdevumā.
Atļauts apvienot, izslēgt darba posmus un (vai) to saturu, kā arī ieviest citus darba posmus pēc vienošanās ar pasūtītāju.

GOST 19.103-77 ESPD. Programmu un programmu dokumentu apzīmēšana

Valsts izstrādātāja kods un organizācijas izstrādātāja kods tiek piešķirts noteiktajā kārtībā.

Katrai attīstības organizācijai reģistrācijas numurs tiek piešķirts augošā secībā, sākot no 00001 līdz 99999.
Programme izdevuma numurs vai versijas numurs. šī veida dokumenta numuru, dokumenta daļas numuru piešķir augošā secībā no 01 līdz 99.
Programme darbības dokumentu specifikācijas un izraksta redakcijas numuram jāsakrīt ar tās pašas programmas izdevuma numuru.

GOST 19.105-78 ESPD. Vispārīgās prasības programmas dokumentiem

Programmas dokuments var tikt prezentēts uz dažāda veida datu nesējiem un sastāv no šādām nosacītajām daļām:
Titel;
informativ;
Papata.

Dokumenta un tā daļu noformēšanas noteikumus uz katra datu nesēja nosaka ESPD standarti dokumentu noformēšanas noteikumiem uz attiecīgajiem datu nesējiem.

GOST 19.106-78 ESPD. Prasības programmas dokumentiem, kas izgatavoti drukātā veidā

Programmas dokumenti tiek sastādīti:

uz A4 format lapām (GOST 2.301-68), sagatavojot dokumentu mašīnrakstā vai rokrakstā;
atļauta reģistrācija uz A3 formata lapām;
ar mašīnu noformēšanas metodi pieļaujamas novirzes A4 un A3 formatātam atbilstošos lapu izmēros, ko nosaka izmantoto tehnisko līdzekļu iespējas; uz A4 un A3 formatāta loksnēm, ko paredz datu izvadierīču izvades raksturlielumi, veidojot dokumentu ar mašīnu;
uz tipogrāfisko formātu lapām, veidojot dokumentu tipogrāfiskā veidā.

Programmas dokumenta materiālu izvietošana tiek veikta šādā secībā:

Nosaukuma-Dala:

apstiprinājuma lapa (nav iekļauta kopējā dokumentu lapu skaitā);
titullapa (dokumenta pirma lapa);

informācijas daļa:

anotacija;
satura lapa;

galvenā dala:

dokumenta teksts (ar attēliem, tabulām utt.)
terminu saraksts un zu definicijas;
saīsinājumu Saraksten;
pieteikumi;
priekšmetu radītājs;
izziņas dokumentu Saraksten;

mezizstrades daļa:

mainīt reģistrācijas lapu.

Ja nepieciešams, tiek sastādīts terminu un to definīciju saraksts, saīsinājumu saraksts, pielikumi, priekšmetu rādītājs, uzziņu dokumentu saraksts.

Šis standarts ir vērsts uz iegūtā izstrādes produkta dokumentēšanu:

GOST 19.402-78 ESPD. Programme apraksts

Documentation "Programmas apraksts" sastāvu tā saturā var papildināt ar sadaļām un rindkopām, kas ņemtas no citu aprakstošo dokumentu un vadlīniju standartiem: GOST 19.404-79 ESPD. Paskaidrojuma piezīme, GOST 19.502-78 ESPD. Pielietojuma apraksts, GOST 19.503-79 ESPD. Sistēmas programmētāja rokasgrāmata, GOST 19.504-79 ESPD. Programmētāja rokasgrāmata, GOST 19.505-79 ESPD. Operatora rokasgrāmata.

Ir arī standartu grupa, kas nosaka prasības visa programmu kopuma un PD fiksēšanai, kas tiek izsniegtas PS nodošanai. Tie ģenerē kodolīgus grāmatvedības dokumentus un var būt noderīgi, lai racionalizētu visu programmu un PD ekonomiku (galu galā ļoti bieži jums vienkārši ir jāsakārto lietas!). Ir arī standarti, kas nosaka dokumentu uzturēšanas noteikumus PS "ekonomikā".

Mütter arī jāizceļ

GOST 19.301-79 ESPD. Testa programma un metodika, ar kuras palīdzību (pielāgotā veidā) var izstrādāt plānošanas dokumentus un veikt pārbaudes darbus, lai novērtētu PS gatavību un kvalitāti.

Visbeidzot, pēdējais standarta pieņemšanas gads.

GOST 19.701-90 ESPD. Algoritmu, programmu, datu un sistēmu shēmas. Nosacīti grafiskie apzīmējumi un izpildes noteikumi.

Tas nosaka noteikumus diagrammu izpildei, ko izmanto, lai attēlotu dažāda veida datu apstrādes uzdevumus, un to risināšanas līdzekļus, un tas pilnībā atbilst ISO 5807:1985.

Kopā ar ESPD starpvalstu līmenī ir vēl divi standarti, kas ir saistīti arī ar PS dokumentāciju un pieņemti ne tik sen, tāpat kā lielākā daļa GOST ESPD.

GOST 19781-90 Informācijas apstrādes sistēmu programmatūras nodrošināšana. Termini un definedcijas. Izstrādāts, lai aizstātu GOST 19,781-83 un GOST 19,004-80 un nosaka terminus un jēdzienu definīcijas datu apstrādes sistēmu (DPS) programmatūras (programmatūras) jomā, ko izmanto visu veidu dokumentacija un LITERATURA, Kas iekļauta standartizācijas darba tvērumā Vai izmantojot šo darbu rezultātus.

GOST 28388-89 Informācijas apstrādes sistēmas. Dokumenti uz magnētiskajiem datu nesējiem. Izpildes un apstrādes kārtība. Tas attiecas ne tikai uz programmatūru, bet arī uz dizaina, tehnoloģiskajiem un citiem projektēšanas dokumentiem, kas tiek izpildīti uz magnētiskajiem datu nesējiem.

2.2. GOST 34 kompleksie standarti

GOST 34 tika iecerēts 80. gadu beigās kā visaptverošs savstarpēji saistītu starpnozaru dokumentu kopums. Motīvi un iegūtie rezultāti ir aprakstīti zemāk GOST 34 "Iezīmes". Standartizācijas objekti ir dažādu (jebkuru!) veidu AS un visu veidu to sastāvdaļas, nevis tikai programmatūra un datu bāzes.

Komplekss ir paredzēts mijiedarbībai starp klientu un izstrādātāju. Līdzīgi kā ISO12207 ir paredzēts, ka klients pats var izstrādāt AS (ja izveido tam specializētu nodaļu). Tomēr GOST 34 formulējums nav vērsts uz tik skaidru un zināmā mērā simetrisku abu pušu darbību atspoguļojumu kā ISO12207. Tā kā GOST 34 galvenokārt koncentrējas uz projekta dokumentu saturu, darbību sadale starp pusēm parasti tiek veikta, pamatojoties uz šo saturu.

No visām esošajām un neieviestajām dokumentu grupām balstīsimies tikai uz 0.grupu "Vispārīgie noteikumi" un 6.grupu "AS izveide, darbība un attīstība". Par populārākajiem standartiem var uzskatīt GOST 34.601-90 (AU izveides posmi), GOST 34.602-89 (TOR AU izveidei) un vadlīnijas RD 50-34.698-90 (Prasības dokumentu saturam). Standarti paredz AS izveides posmus un darba posmus, bet nepārprotami neparedz procesus no gala līdz galam.

Vispārējam AES attīstības gadījumam GOST 34 posmi un posmi ir parādīti tabulā:

1. FT - ĀS prasību veidošana.	1.1. Objekta apskate un ĀS izveides nepieciešamības pamatojums; 1.2. Lietotāju prasību veidošana ĀS; 1.3. Atskaites par paveikto darbu reģistrācija un iesniegums ĀS izstrādei (taktiskās un tehniskās specifikācijas);
2. RK - ĀS koncepcijas izstrade.	2.1. Objekta izpēte; 2.2. Nepieciešamo pētniecisko darbu veikšana; 2.3. Lietotāja prasībām atbilstošu AU koncepcijasvarianteu izstrāde 2.4. Atskaites sagatavošana par paveikto darbu
3. TK - ĀS tehniskā izveide.	3.1. Darba uzdevuma nolikuma izstrade un apstiprināšana.
4. EP - Projekta-Projekte.	4.1. Sistēmas un tās daļu priekšprojekta risinājumu izstrāde; 4.2. Dokumentācijas izstrāde ĀS un tās daļām.
5. TP - Tehniskais-Projekte.	5.1. Sistēmas un tās daļu dizaina risinājumu izstrāde; 5.2. AES un tās daļu dokumentācijas izstrāde; 5.3. Produktu piegādes dokumentācijas izstrāde un noformēšana atomelektrostaciju iegādei un/vai tehniskajam prasibam(tehniskās specifikācijas) zu izstrādei; 5.4. Projektēšanas uzdevumu izstrāde blakus esošajās automatizācijas objekta projekta daļās.
6. RD - Darba dokumentācija.	6.1. Attistība darba dokumentācija par sistēmu un tās daļām; 6.2. Programmu izstrāde vai adaptācija.
7. VD - Nodošana ekspluatācijā.	7.1. Automatizācijas objekta sagatavošana AU nodošanai ekspluatācijā; 7.2. Personala apmacība; 7.3. Pilns skaļruņu komplekts ar piegādātajiem produktiem (programmatūra un tehniskajiem līdzekļiem, programmatūras un aparatūras sistēmas, informācijas produkti); 7.4. Celtniecības un uzstādīšanas darbi; 7.5. Nodošanas darbi; 7.6. Iepriekšējo pārbaužu veikšana; 7.7. Izmēģinājuma operāciju veikšana; 7.8. Pieņemšanas testu veikšana.
8. Sp - Skaļruņu pavadīšana.	8.1. Darbu veikšana saskaņā ar garantijas saistībām; 8.2. Pēcgarantijas serviss.

Ir aprakstīts katrā posmā izstrādāto dokumentu saturs. Tas nosaka iespēju satura līmenī nodalīt paralēli vai secīgi veiktu darbu no gala līdz galam (tas ir, faktiski - procesus), un tos veidojošos uzdevumus. Šādu paņēmienu var izmantot, veidojot projekta dzīves cikla standartu profilu, kas ietver saskaņotas GOST 34 and ISO12207 standartu apakškopas.

Galvenais Motive: atrisināt "Bābeles torņa" problēmu.

80. gados izveidojās situācija, kurā dažādās nozarēs un darbības jomās tika izmantota vāji saskaņota vai nekonsekventa zinātniski tehniskā dokumentācija - "normatīvā un tehniskā dokumentācija". Tas apgrūtināja sistēmu integrāciju un to efektīvas kopīgās darbības nodrošināšanu. Bija dažādi standartu kompleksi un sistēmas, kas noteica prasības dazadi veidi ALS.

Standartu piemērošanas prakse ir parādījusi, ka tajos būtībā (bet ne saskaņā ar stingrām definīcijām) tiek izmantota vienota jēdzienu sistēma, ir daudz koplietošanas telpas standartizāciju, tomēr standartu prasības nav savstarpēji saskaņotas, ir atšķirības darba sastāvā un saturā, atšķirības dokumentu apzīmējumā, sastāvā, saturā un izpildījumā u.c.

Protams, šī situācija daļēji atspoguļoja AS attīstības apstākļu dabisko daudzveidību, izstrādātāju mērķus, izmantotās pieejas un metodes.

Šādos apstākļos bija iespējams analizēt šādu šķirni un pēc tam turpināt, piemēram, vienā no diviem lielā mērā pretējiem veidiem:

Izstrādāt vienu vispārinātu konceptuālo un terminoloģisko sistēmu, vispārīgu izstrādes shēmu, vienotu dokumentu kopumu ar to saturu un definēt tos kā obligātus visām AU;
Tāpat definēt vienu vienotu konceptuālo un terminoloģisko sistēmu, vispārinātu sistēmas prasību kopumu, kvalitātes kritēriju kopumu, bet nodrošināt maksimālu brīvību izstrādes shēmas, dokumentu sastāva un citu aspektu izvēlē, uzliekot tikai minimālas obligātās prasības, kas ļautu:
- notikt rezultāta kvalitātes līmeni;
- izvēlēties tās specifiskās metodes (ar to dzīves cikla modeļiem, dokumentu kopumu u.c.), kas ir vispiemērotākās izstrādes apstākļiem un atbilst izmantotajām Informācijas tehnoloģijām;
- darbu, tātad ar minimāliem ierobežojumiem AES projektētāja efektīvai rīcībai.

Standartu kopas 34 izstrādātāji ir izvēlējušies metodi, kas ir tuvu pirmajai no iepriekšminētajām, tas ir, viņi ir izvēlējušies ceļu, kas ir tuvāks konkrētu metožu kēmāmāmie1 standarttām27 Tomēr konceptuālās bāzes kopības dēļ standarti joprojām ir piemērojami ļoti plašā gadījumu lokā.

Pielāgošanās pakāpi formāli nosaka iespējas:

izlaist priekšprojektēšanas posmu un apvienot posmus „Tehniskais projekts“ un „Detalizēta dokumentācija“;
izlaist soļus, sapludināt un izlaist lielāko daļu dokumentu un to sadaļu;
ievadiät papildu dokumenti, dokumentu un darbu sadaļas;
dinamiski veidojot quer CHTZ - privatie uzdevumi - tas ir diezgan elastīgs, lai veidotu AS dzīves ciklu; parasti šis paņēmiens tiek izmantots lielu vienību (apakšsistēmu, kompleksu) līmenī, kuru dēļ tiek uzskatīts par pamatotu izveidot CTZ, taču nav būtiska pamata nopietni ierobežot šo dzīves cikla pātrodival. .

Posmi un posmi, ko veic organizācijas - ĀS izveides dalībnieki, ir noteikti līgumos un darba uzdevumos, kas ir tuva ISO pieejai.

Noteikti noderīga ir vienotas, pietiekami kvalitatīvi definētas terminoloģijas ieviešana, pietiekami pamatotas darbu klasifikācijas, dokumentu, atbalsta veidu u.c. GOST 34 veicina patiešām dažādu sistēmu pilnīgāku un kvalitatīvāku dokošanu, kas ir īpaši svarīgi apstākļos, kad tiek izstrādātas arvien sarežģītākas integrētās AS, piemēram, CAD-CAM ievatīsīs kas tipa. , automatizēta vadības sistēma, CAD projektētājs, CAD tehnologs, ASNI un citas sistēmas.

Ir definēti vairāki svarīgi noteikumi, kas atspoguļo AS kā standartizācijas objekta iezīmes, Piemēram: "vispārējā gadījumā AS sastāv keine programmatūras un aparatūras (PTC), programmatūras un metodoloģiskajiem (PMC) kompleksiem un atsevišķiem komponentiem organizatoriskais, Tehniskais, programmatūras un informācijas atbalsts .."

PTK un AS jēdzienu nodalīšana nostiprināja principu, saskaņā ar kuru AS nav „IS ar datu bāzi“, bet gan:

"Organizatoriskā un tehniskā sistēma, Kas nodrošina uz informācijas procesu automatizāciju dažādās darbības jomas (vadībā, projektēšanā, ražošana U.C.) Vai kombinācijās balstītu risinājumu izstrādi" (Saskaņā ar RD 50-680-88), Kas ir īpaši svarīgi biznesa pārveidošanas ziņā;
"sistēma, kas sastāv no personāla un līdzekļu kopuma tā darbību automatizēšanai, informācijas tehnoloģiju ieviešanai noteikto funkciju veikšanai" (saskaņā ar GOST 34.003-90).

Šīs definīcijas norāda, ka ĀS, pirmkārt, ir personal.ls, kas pieņem lēmumus un veic citas kontroles darbības ar organizatoriskiem un tehniskiem līdzekļiem.

Pflichtabsolventen:

nav iepriekšēja pilna pienākuma, GOST34 materiāli būtībā ir kļuvuši par metodisko atbalstu, un biežāk klientiem, kuriem standartā ir notikts prasību kopums attiecībā uz tehnisko specifikāciju saturu un AU testēšanu. Tajā pašā laikā GOST34 priekšrocības var palielināties vairākas reizes, ja tās ir elastīgākas maiņstrāvas dzīves cikla profila veidošanā.

Galvenais pušu mijiedarbības dokuments ir TOR - AS izveides darba uzdevums. TOR ir galvenais avota dokuments AS izveidei un tā pieņemšanai, TOR nosaka svarīgākos mijiedarbības punktus starp klientu un izstrādātāju. Tajā pašā laikā TOR izstrādā izstrādātāja organizācija (saskaņā ar GOST 34.602-89), bet klients formāli izsniedz TOR izstrādātājam (saskaņā ar RD 50-680-88).

2.3. Krievijas Federācijas valsts standarti (GOST R)

Krievijas Federācijā ir vairāki standarti attiecībā uz PS dokumentāciju, kas izstrādāti, pamatojoties uz starptautisko ISO standartu tiešu piemērošanu. Schwester? "svaigākie" standarti līdz pieņemšanas brīdim. Daži no tiem ir tieši adresēti projektu vadītājiem vai informācijas dienestu direktoriem. Taču profesionāļu vidū tie ir nepamatoti maz zināmi. Seit ir viņu prezentācija.

GOST R ISO/IEC 9294-93 Informaciju tehnoloģijas. Programmatūras dokumentācijas pārvaldības rokasgrāmata. Standards pilnībā atbilst starptautiskajam standartam ISO/IEC TO 9294:1990 un nosaka ieteikumus efektīvai PS dokumentācijas parvaldībai vadītājiem, kas ir atbildīgi par to izveidi. Standarta mērķis ir palīdzēt definēt OS dokumentēšanas stratēģiju; dokumentācijas standartu izvēle; dokumentācijas procedūru izvēle; nepieciešamo resursu noteikšana; dokumentācijas planu sastādīšana.

GOST R ISO/IEC 9126-93 Informaciju tehnoloģijas. Programmatūras produktu novērtēšana. Kvalitates raksturojums un to lietošanas vadlīnijas. Standards pilnībā atbilst starptautiskajam standartam ISO/IEC 9126:1991. Savā kontekstā kvalitātes raksturlielums tiek saprasts kā "programmatūras produkta īpašību (atribūtu) kopums, saskaņā ar kuru tiek aprakstīta un novērtēta tā kvalitāte". Standarts nosaka sešus sarežģītus raksturlielumus, kas raksturo PS (programmatūra, programmatūras produkti) kvalitāti ar minimālu dublēšanos: funkcionalitāte; uzticamiba; Praktika; Wirkung; kopjamība; mobilisieren. Šie raksturlielumi veido pamatu turpmākai PS kvalitātes uzlabošanai un aprakstam.

GOST R ISO 9127-94 Informācijas apstrādes sistēmas. Lietotāja dokumentācija un informācija par patērētāju programmatūras pakotnēm. Standards pilnībā atbilst starptautiskajam standartam ISO 9127:1989. Šī starptautiskā standarta kontekstā patērētāju programmatūras pakotne (SP) ir definēta kā "programmatūras produkts, kas izstrādāts un pārdots noteiktu funkciju veikšanai; programma un ar to saistītā dokumentācija, kas iepakoība kārdoša". Lietotāja dokumentācija tiek saprasta kā dokumentācija, kas sniedz gala lietotājam informāciju par programmatūras instalēšanu un lietošanu. Informācija uz iepakojuma tiek saprasta kā informācija, kas atveidota uz PP ārējā iepakojuma. Tās mērķis ir sniegt potenciālajiem pircējiem primāro informāciju par PP.

GOST R ISO/IEC 8631-94 Informaciju tehnoloģijas. Programmatūras konstrukcijas un simboli to attēlošanai. Apraksta procesuālo algoritmu attēlojumu.

2.4. Starptautiskais-Standards ISO/IEC 12207: 1995-08-01

ISO12207 pirmo izdevumu 1995. gadā sagatavoja ISO/IEC Apvienotā tehniskā komiteja JTC1

Pēc definīcijas ISO12207 ir programmatūras dzīves cikla procesu pamatstandarts, kas orientēts uz dažāda veida (jebkuriem!) programmatūras veidiem un AS projektu veidiem, kur programmatūra ir iekļauta kā sastāvdaļa. Standards nosaka stratēģiju un vispārējā kārtība programmatūras izveidē un darbībā tas aptver programmatūras dzīves ciklu no ideju konceptualizācijas līdz dzīves cikla pabeigšanai.

ĻOTI SVARĪGAS STANDARTA PIEZĪMES:

Programmatūras dzīves cikla laikā izmantotajiem procesiem jābūt saderīgiem ar AS dzīves cikla laikā izmantotajiem procesiem. (Tādējādi AS un programmatūras standartu kopīgas izmantošanas lietderība ir skaidra.)
Par unikālu vai īpašu procesu, darbību un uzdevumu pievienošanu pusēm jāvienojas līgumā. Līgums tiek saprasts plašā nozīmē: no juridiska līguma līdz neoformālai vienošanās, vienošanos var definēt viena puse kā sev izvirzītu uzdevumu.
Standards būtībā nesatur konkrētas darbības metodes, īpaši - risinājumu vai dokumentācijas sagatavošanu. Tajā ir aprakstīta programmatūras dzīves cikla procesu arhitektūra, bet nav detalizēti norādīts, kā ieviest vai veikt procesos iekļautos pakalpojumus un uzdevumus, un tas nav paredzēts, lai noteiktu iegūtās noskumentās dokuumentā Šāda veida lēmumi tiek pieņemti, izmantojot standartu.

DEFINITIONSSTANDARDS:

Sistēma ir viena vai vairāku procesu, aparatūras, programmatūras, aprīkojuma un cilvēku apvienība, kasļauj sasniegt noteiktas vajadzības vai mērķus.
Dzives cikla modelis- struktūra, kas satur procesus, darbības un uzdevumus, kas tiek veikti programmatūras produkta izstrādes, darbības un uzturēšanas laikā visā sistēmas darbības laikā, no prasību noteikšanas līdz tā lietošanas pabeigšanai.
Daudzi procesi un uzdevumi ir izstrādāti tā, lai tos varētu pielāgot programmatūras projektiem. Pielāgošanas process ir process, kurā tiek novērsti procesi, darbības un uzdevumi, kas nav piemērojami konkrētam projektam. Pielāgošanās spējas pakāpe: maksimālā
Kvalifikācijas prasība- kritēriju vai nosacījumu kopums (kvalifikācijas prasības), kas jāizpilda, lai programmatūras produktu kvalificētu kā atbilstošu (atbilstošu) tā specifikācijām un gatavu lietošanai mērķa vidē.

Standarts nenosaka konkrētu dzīves cikla modeli vai programmatūras izstrādes metodi, bet nosaka, ka standarta lietošanas puses ir atbildīgas par programmatūras projekta dzīves cikla modeļa izvēli, par standarta procesu un uzdevumu pielāgošam šim standartanu. modelis, programmatūras izstrādes metožu izvēlei un pielietošanai, programmatūras projektam atbilstošu darbību un uzdevumu veikšanai.

ISO12207-Standards ir vienlīdz vērsts uz abu pušu – piegādātāja (izstrādātāja) un pircēja (lietotāja) – darbību organizēšanu; var vienlīdz piemērot, ja abas puses ir no vienas organizācijas.

Katrs dzīves cikla process ir sadalīts darbību komplektā, katra darbība ir sadalīta uzdevumu komplektā. Ļoti būtiska atšķirība starp ISO: katru procesu, darbību vai uzdevumu pēc vajadzības ierosina un izpilda cits process, un nav iepriekš noteiktu secību (protams, saglabājot saišu loģiku saskaņā ar fona informācija uzdevumi utt.).

ISO12207-Standard-Apraksta:

5 Galvenie programmatūras dzīves cikla procesi:
- Iegūšanas-Prozess. Definē pirkšanas uzņēmuma darbības, kas iegādājas AS, programmatūras produktu vai programmatūras pakalpojumu.
- Piegades-Prozess. Definē piegādātāja uzņēmuma darbības, kas piegādā klientam sistēmu, programmatūras produktu vai programmatūras pakalpojumu.
- Attistības-Prozess. Definē uzņēmuma izstrādātāja darbības, kas izstrādā programmatūras produkta un programmatūras produkta konstruēšanas principu.
- Darbibas-Prozess. Definē operatora uzņēmuma darbības, kas nodrošina sistēmas (ne tikai programmatūras) apkopi tās darbības laikā lietotāju interesēs. Atšķirībā no darbībām, ko izstrādātājs nosaka lietošanas instrukcija pats un uzņemas atbilstošos pienākumus, ir noteikti.
- Pēcpārbaudes-Prozess. Nosaka apkopes personāla darbības, kas nodrošina programmatūras produkta apkopi, kas ir programmatūras produkta modifikāciju vadība, saglabājot tā pašreizējo stāvokli un funkcionālo piemērotību, ietver programmatūras produkta uzstādīšanu un noņemšanu dators
8 palīgprocesi, kas atbalsta cita procesa ieviešanu, esot ordentlichņemama sastāvdaļa visa programmatūras produkta dzīves cikla garumā un nodrošināt pareizu programmatūras projekta kvalitāti:
- Probleme risinājums;
- documentacija;
- konfigurācijas vadība;
- kvalitātes nodrošināšana, kurā tiek izmantoti kvalitātes nodrošināšanas komandas atlikušo procesu rezultāti, kas ietver:
  - Parbaudes-Prozess;
  - Attestācijas-Prozess;
  - Kopīgs novērtēšanas-Prozess;
  - Prüfungsprozess.
4 Organisationsprozesse:
- Vadības-Prozess;
- Infrastrukturas izveides-Prozess;
- Uzlabosanas-Prozess;
- Mācibu-Prozess.

Tam seko īpašs Pielāgošanas-Prozess, kas nosaka galvenos soļus, kas nepieciešami, lai standartu pielāgotu konkrēta projekta apstākļiem.

Ar pilnveides procesu šeit saprot nevis AS vai programmatūras pilnveidošanu, bet gan reāli organizācijā veikto iegādes, izstrādes, kvalitātes nodrošināšanas u.c. processu uzlabosanu.

Nav posmu, fāžu, posmu, kas dod tālāk aprakstīto pielāgošanās pakāpi.

Standarta "dinamisko" raksturu nosaka process un uzdevumu secība, kad viens process pēc vajadzības izsauc citu vai tā daļu.

Iegūšanas procesa izpilde sistēmas vai programmatūras prasību analīzes un fiksēšanas ziņā var izraisīt atbilstošo Izstrādes procesa uzdevumu izpildi;
Piegādes procesā piegādātājs pārvalda apakšuzņēmējus atbilstoši Iegādes procesam un veic pārbaudi un kvalifikāciju atbilstoši attiecīgajiem procesiem;
apkopei var būt nepieciešama sistēmas un programmatūras izstrāde, kas tiek veikta Izstrādes procesa ietvaros.

Šis raksturs ļauj īstenot jebkuru dzīves cikla modeli.

Veicot programmatūras prasību analīzi, tiek nodrošinātas 11 kvalitātes raksturlielumu klases, kuras vēlāk tiek izmantotas kvalitātes nodrošināšanā.

To darot, izstrādātājam ir jānosaka un jādokumentē programmatūras prasības:

Funkcionālās un iespējamās specifikācijas, tostarp veiktspēja, fiziskās īpašības un vides apstākļi, kādos programmatūra ir jāizpilda;
Ārējās saites (saskarnes) ar programmatūras vienību;
kvalifikācijas prasības;
Uzticamības specifikācijas, tostarp specifikācijas, kas saistītas ar darbības un apkopes metodēm, ietekmi vid un personāla ievainojumu iespējamība;
drošības specifikacijas,
Cilvēka faktoru specifikācijas inženierpsiholoģijā (Ergonomika), Tostarp Tas, kas saistītas ar manuālu darbību, cilvēka un aprīkojuma mijiedarbību, personala ierobežojumiem un jomam, Kuraś nepieciešama koncentrēta cilvēka uzmanība un kuras ir jutīgas Prät cilvēka kļūdām un mācīšanos;
Datu un datu bāzes prasību definēšana;
Piegādātā programmatūras produkta uzstādīšanas un pieņemšanas prasības ekspluatācijas un apkopes (ekspluatācijas) vietās;
Lietotāja dokumentācija;
Lietotāja darba un izpildes prasības;
Lietotāju apkalpošanas prasības.

(Interesanti un svarīgi, ka šie un līdzīgi raksturlielumi labi atbilst ĀS īpašībām, kas paredzētas GOST 34 pēc sistēmas atbalsta veida.)

Standartā irļoti maz aprakstu, kas paredzēti datu bāzes projektēšanai. To var uzskatīt par pamatotu, jo dažādas sistēmas un dažādi lietojumprogrammatūras kompleksi var ne tikai izmantot ļoti specifiskus datu bāzes veidus, bet arī neizmantot

Rezumējot, ISO12207 ir processu, darbību un uzdevumu kopums, kas aptver visplašāko iespējamo situāciju loku ar maksimālu pielāgošanās spēju.

Tas parāda piemēru, kā jāizveido labi organizēts standarts, kas satur minimālus ierobežojumus (Prinzip „nav divu vienādu projektu“). Tajā pašā laikā ir ieteicams iekļaut detalizētas procesu definīcijas, dokumentu formas utt. dažādos funkcionālajos standartos, apartamentos. notikumi vai patentētas metodes, kuras var vai nevar izmantot konkrētā projektā.

Šī iemesla dēļ ir lietderīgi uzskatīt ISO12207 par centrālo standartu, kura nosacījumi tiek uzskatīti par sākotnējo noteikumu „pamatkopu“ LC standarta profila veidošanas procesā konkrētam projektam. Šis „kodols“ var definēt programmatūras un AS dzīves cikla modeli, kvalitātes nodrošināšanas koncepciju, projektu vadības modeli

Praktiķi izmanto citu veidu: viņi paši tulko un savos projektos izmanto mūsdienīgus PS dzīves cikla organizācijas standartus un to dokumentāciju. Taču šis ceļš cieš vismaz no tā trūkuma, ka dažādi dažādu izstrādātāju un klientu veiktie standartu tulkojumi un adaptācijas daudzās detaļās atšķirsies. Šīs atšķirības neizbēgami attiecas ne tikai uz nosaukumiem, bet arī uz to jēgpilnajām definīcijām, kas ieviestas un izmantotas standartos. Tādējādi šajā ceļā neizbēgama ir nemitīga neskaidrība, un tas ir tieši pretējs ne tikai standartu, bet arī jebkuru kompetentu metodisko dokumentu mērķiem.

Pašlaik Viskrievijas Standartu pētniecības institūts ir sagatavojis priekšlikumus PS dokumentēšanas standartu kopuma uzlabošanai un izstrādei.

atsauces informācija

Lai iegādātos standartus dokumentācijas jomā, iesakām sazināties ar šādām organizācijām:

IPK "Standartu izdevnieciba", NTD teritoriālās izplatīšanas nodaļa ("Standards" veikals), 17961, Maskava, st. Donskaja, 8. dz., talr. 236-50-34, 237-00-02, fakss/talr. 236-34-48 (attiecībā uz GOST und GOST R).

Standartu kopums automatizētām sistēmām (KSAS)

Vienotā programmu dokumentācijas sistēma (ESPD) ir vietējais programmu dokumentācijas standartu kopums. Profesionālajā valodā to sauc arī par "deviņpadsmito viesi", kas nav pilnīgi pareizi, jo mēs runājam nevis par vienu, bet par 30 dažādiem normatīvajiem un tehniskajiem dokumentiem.

Pamatā ESPD standarti satur prasības programmu aprakstošo dokumentu sastāvam, saturam un izpildei dažādos tās dzīves cikla posmos. Turklāt vairāki dokumenti ir veltīti dokumentācijas glabāšanas un atjaunināšanas procedūrai.

ESPD standartos praktiski nav metodoloģiskās sastāvdaļas. Tie neizskaidro izstrādātājam, kā rakstīt dokumentāciju, lai tā būtu noderīga, saprotama, informatīva, ērta utt. Tie nodrošina tikai dokumentu tipu sarakstu un katrai no tām pirmā līmeņa sadaļu sarakstu. Tiesa, katrā sadaļā ir norādīts, kāda informācija tajā ir jāuzrāda.

ESPD standarti tika pieņemti 70. gadu beigās un ir nonākuši līdz mums oriģinālam tuvā formā. Krawatte atspoguļo departureamentu skaitļošanas centru darba praksi, kur tika darbināti lieli datori. Cilvēka mijiedarbība ar datoristēmu toreiz tika veidota pavisam citādāk nekā tagad un tika veikta ar apjomīgām pultīm, perfokartēm un izdrukām, un „vienkāršiem mirstīgajiem“ risinot liemastišķas problīvaldmas, patīpaldmas Vai ir ilgi jāskaidro, cik šie standarti jau ir novecojuši? Pietiek pateikt, ka viņi nezina par mūsdienās plaši izplatītiem dokumentiem, piemēram, Lietotāja rokasgrāmatu un Administratora rokasgrāmatu.

Un tomēr tos turpina aktivi izmantot. Formāli "deviņpadsmitais" ir moderna alternatīva. Daži ISO / IEC standarti sistēmu un programmatūras inženierijas jomā ir tulkoti krievu valodā un pieņemti Krievijā kā nacionālie standarti. Taču lielie, tostarp valdības klienti, nesteidzas uz tiem pāriet. Zu var izskaidrot ar viņu inerci (vai lojalitāti tradīcijām, kā vēlaties), bet tikai daļēji.

Fakts ir tāds, ka katrs ESPD standarts ar nelielu (maksimums trīs lappušu) apjomu ir diezgan formāls un tāpēc viegli parbaudams prasības dokumentam vai dokumentācijas kopumam. Stingri sakot, tas neliedz dokumentācijas izstrādātājam rakstīt labi izveidotas muļķības. Bet, tā kā ESPD ir skaidri definēts, no kā jāsastāv rezultātam un kā tam jāizskatās, mēs varam vismaz uzreiz noraidīt papīra kaudzi, kas neietilpst šajos rāmjos. Tas ievērojami vienkāršo dokumentācijas piegādes un pieņemšanas uzdevumu gan pasūtītājam, gan darbuzņēmējam.

No otras puses, ISO/IEC standardi satur daudz saprātīgu būtisku noteikumu, taču ir grūti iedomāties procedūru to formālai pārbaudei. Taču neviens neapgrūtina abus standartu kopumus vienlaikus piemērot, par laimi, tie attiecas uz dažādiem dokumentācijas aspektiem un praktiski nav pretrunā viens otram.

Normatīvo un tehnisko dokumentu sastādīšana

Apzīmējums	Vārds
GOST 19.001-77	Vispargi noteikumi
GOST 19.002-80	Vienota programmu dokumentācijas sistēma. Algoritmu un programmu shemas. Izpildes notikumi
GOST 19.004-80	Vienota programmu dokumentācijas sistēma. Termini undefined
GOST 19.005-85	Vienota programmu dokumentācijas sistēma. Algoritmu un programmu P-shēmas. Nosacīti grafiskie apzīmējumi un izpildes noteikumi
GOST 19.101-77	Vienota programmu dokumentācijas sistēma. Programmu veidi un programmas dokumenti
GOST 19.102-77	Vienota programmu dokumentācijas sistēma. Attīstības stadijas
GOST 19.103-77	Vienota programmu dokumentācijas sistēma. Programmu un programmu dokumentu apzīmēšana
GOST 19.104-78	Vienota programmu dokumentācijas sistēma. pamata uzraksti
GOST 19 105-78	Vienota programmu dokumentācijas sistēma. Vispārīgās prasības programmas dokumentiem
GOST 19.106-78	Vienota programmu dokumentācijas sistēma. Prasības programmas dokumentiem, kas izgatavoti drukātā veidā
GOST 19.201-78	Vienota programmu dokumentācijas sistēma. Tehniskais uzdevums
GOST 19.202-78	Vienota programmu dokumentācijas sistēma. Spezifikacija. Prasības saturam un dizainam
GOST 19.301-79	Vienota programmu dokumentācijas sistēma. Programma un testa-Verfahren. Prasības saturam un dizainam
GOST 19.401-78	Vienota programmu dokumentācijas sistēma. Programmtexte. Prasības saturam un dizainam
GOST 19.402-78	Vienota programmu dokumentācijas sistēma. Programme apraksts
GOST 19 403-79	Vienota programmu dokumentācijas sistēma. Oriģinālo turētāju Saraksten
GOST 19.404-79	Vienota programmu dokumentācijas sistēma. Paskaidrojuma Piezime. Prasības saturam un dizainam
GOST 19.501-78	Vienota programmu dokumentācijas sistēma. Veidlapa. Prasības saturam un dizainam
GOST 19.502-78	Vienota programmu dokumentācijas sistēma. Pielietojuma apraksts. Prasības saturam un dizainam
GOST 19.503-79	Vienota programmu dokumentācijas sistēma. Sistēmu programmētāja rokasgrāmata. Prasības saturam un dizainam
GOST 19.504-79	Vienota programmu dokumentācijas sistēma. Programmētāja rokasgrāmata
GOST 19.505-79	Vienota programmu dokumentācijas sistēma. Operatora rokasgrāmata. Prasības saturam un dizainam
GOST 19.506-79	Vienota programmu dokumentācijas sistēma. Valodas apraksts. Prasības saturam un dizainam
GOST 19.507-79	Vienota programmu dokumentācijas sistēma. Operativo dokumentu izzina
GOST 19.508-79	Vienota programmu dokumentācijas sistēma. Apkopes rokasgrāmata. Prasības saturam un dizainam
GOST 19.601-78	Vienota programmu dokumentācijas sistēma. Vispārīgi noteikumi dublēšanai, uzskaitei un uzglabāšanai
GOST 19.602-78	Vienota programmu dokumentācijas sistēma. Drukātā veidā izgatavotu programmas dokumentu pavairošanas, uzskaites un uzglabāšanas noteikumi
GOST 19.603-78	Vienota programmu dokumentācijas sistēma. Vispārīgi noteikumi izmaiņu veikšanai
GOST 19.604-78	Vienota programmu dokumentācijas sistēma. Noteikumi izmaiņu veikšanai programmas dokumentos, kas izgatavoti drukātā veidā