bahay - Windows
Pagpaparehistro ng dokumentasyon ng programa ayon sa espd, espd. Paghahanda ng dokumentasyon para sa programa ayon sa GOST para sa software

Sa pamamagitan ng Resolusyon ng State Committee of Standards ng Konseho ng mga Ministro ng USSR na may petsang Mayo 20, 1977 No. 1268, ang petsa ng pagpapakilala ay itinatag

mula 01/01/1980

Ang pamantayang ito ay nagtatatag ng mga uri ng mga programa at mga dokumento ng programa para sa mga computer, complex at system, anuman ang layunin at saklaw ng mga ito.

Ang pamantayan ay ganap na sumusunod sa ST SEV 1626-79.

1. MGA URI NG PROGRAMA

1.1. Ang programa (ayon sa GOST 19781-90) ay maaaring makilala at magamit nang nakapag-iisa at (o) bilang bahagi ng iba pang mga programa.

1.2. Ang mga programa ay nahahati sa mga uri na ipinapakita sa talahanayan. 1

Talahanayan 1

1.3. Ang dokumentasyong binuo para sa programa ay maaaring gamitin para sa pagpapatupad at paglilipat ng programa sa storage media, gayundin para sa paggawa ng isang produkto ng software.

1.2,1.3.

2. MGA URI NG MGA DOKUMENTO NG PROGRAM

2.1. Kasama sa mga dokumento ng software ang mga dokumentong naglalaman ng impormasyong kinakailangan para sa pagbuo, paggawa, pagpapanatili at pagpapatakbo ng mga programa.

2.2. Ang mga uri ng mga dokumento ng programa at ang mga nilalaman nito ay ibinibigay sa talahanayan. 2.

talahanayan 2

Uri ng dokumento ng programaMga nilalaman ng dokumento ng patakaran
Pagtutukoy Komposisyon ng programa at dokumentasyon nito
Listahan ng mga negosyo na nag-iimbak ng mga orihinal na dokumento ng programa
Teksto ng programa Pagre-record ng programa kasama ang mga kinakailangang komento
Paglalarawan ng programa Impormasyon tungkol sa lohikal na istraktura at pagpapatakbo ng programa
Mga kinakailangan upang ma-verify kapag sinusubukan ang programa, pati na rin ang pamamaraan at mga pamamaraan para sa kanilang kontrol
Teknikal na gawain Layunin at saklaw ng programa, teknikal, pagiging posible at mga espesyal na kinakailangan para sa programa, mga kinakailangang yugto at tuntunin ng pag-unlad, mga uri ng pagsubok
Paliwanag na tala Algorithm diagram, pangkalahatang paglalarawan ng algorithm at (o) pagpapatakbo ng programa, pati na rin ang pagbibigay-katwiran sa mga pinagtibay na teknikal at teknikal-ekonomikong desisyon
Mga dokumento sa pagpapatakbo Impormasyon upang matiyak ang paggana at pagpapatakbo ng programa

(Binagong edisyon, Susog Blg. 1).

2.3. Ang mga uri ng mga dokumento sa pagpapatakbo at ang mga nilalaman nito ay ibinibigay sa Talahanayan 3.

Talahanayan 3

Uri ng dokumento sa pagpapatakboMga nilalaman ng dokumento ng pagpapatakbo
Listahan ng mga dokumento sa pagpapatakbo para sa programa
Form Mga pangunahing katangian ng programa, pagkakumpleto at impormasyon tungkol sa pagpapatakbo ng programa
Paglalarawan ng aplikasyon Impormasyon tungkol sa layunin ng programa, saklaw ng aplikasyon, mga pamamaraan na ginamit, klase ng mga problemang malulutas, mga paghihigpit sa paggamit, pinakamababang pagsasaayos ng hardware
Impormasyon para sa pagsusuri, pagtiyak sa paggana at pagpapasadya ng programa para sa mga kondisyon ng isang partikular na aplikasyon
Gabay ng Programmer Impormasyon para sa paggamit ng programa
Talaalaman ng gagamit Impormasyon upang matiyak ang pamamaraan para sa komunikasyon sa pagitan ng operator at ng computer system sa panahon ng pagpapatupad ng programa
Paglalarawan ng wika Paglalarawan ng syntax at semantics ng wika
Impormasyon para sa paggamit ng mga programa sa pagsubok at diagnostic kapag nagseserbisyo ng mga teknikal na kagamitan

(Binagong edisyon, Susog Blg. 1).

2.4. Depende sa paraan ng pagpapatupad at likas na katangian ng aplikasyon, ang mga dokumento ng programa ay nahahati sa orihinal, duplicate at kopya (GOST 2.102-68), na nilayon para sa pagbuo, pagpapanatili at pagpapatakbo ng programa.

2.5. Ang mga uri ng mga dokumento ng programa na binuo sa iba't ibang yugto at ang kanilang mga code ay ibinibigay sa Talahanayan. 4.

Talahanayan 4

Code ng uri ng dokumentoUri ng dokumentoMga yugto ng pag-unlad
Paunang disenyoTeknikal na proyektoGumagana draft
sangkapkumplikado
- Pagtutukoy - -
05 Listahan ng mga orihinal na may hawak - - -
12 Teksto ng programa - -
13 Paglalarawan ng programa - -
20 Listahan ng mga dokumento sa pagpapatakbo - -
30 Form - -
31 Paglalarawan ng aplikasyon - -
32 Gabay ng Programmer ng System - -
33 Gabay ng Programmer - -
34 Talaalaman ng gagamit - -
35 Paglalarawan ng wika - -
46 Manwal sa Pagpapanatili - -
51 Programa at pamamaraan ng pagsubok - -
81 Paliwanag na tala - -
90-99 Iba pang mga dokumento

Alamat:
- ang dokumento ay sapilitan;
- ang dokumento ay sapilitan para sa mga bahagi na may independiyenteng paggamit;
- ang pangangailangan na gumuhit ng isang dokumento ay tinutukoy sa yugto ng pag-unlad at pag-apruba ng mga teknikal na pagtutukoy;
- - ang dokumento ay hindi iginuhit.

2.2-2.5. (Binagong edisyon, Susog Blg. 1).

2.6. Pinapayagan na pagsamahin ang ilang mga uri ng mga dokumento sa pagpapatakbo (maliban sa listahan ng mga dokumento sa pagpapatakbo at ang form). Ang pangangailangan na pagsamahin ang mga dokumentong ito ay ipinahiwatig sa mga teknikal na pagtutukoy. Ang pinagsamang dokumento ay itinalaga ang pangalan at pagtatalaga ng isa sa mga pinagsamang dokumento.

Dapat tukuyin ng mga pinagsamang dokumento ang impormasyong dapat isama sa bawat dokumentong pinagsasama.

2.7. Sa yugto ng pag-unlad at pag-apruba ng mga teknikal na pagtutukoy, ang pangangailangan na gumuhit ng mga teknikal na pagtutukoy na naglalaman ng mga kinakailangan para sa produksyon, kontrol at pagtanggap ng programa ay tinutukoy.

Ang mga teknikal na pagtutukoy ay binuo sa yugto ng "Detalyadong Disenyo".

2.8. Ang pangangailangan na gumuhit ng mga teknikal na pagtutukoy para sa mga bahagi na hindi inilaan para sa independiyenteng paggamit, at mga kumplikadong kasama sa iba pang mga complex, ay tinutukoy sa pamamagitan ng kasunduan sa customer.

(Ipinakilala bilang karagdagan, Susog Blg. 1).

Muling pag-isyu (Nobyembre 1987) na may Pagbabago No. 1, naaprubahan noong Hunyo 1981 (IUS 9-81)

Ang pangunahing layunin ng tekstong ito ay ipaliwanag kung ano ang Unified System of Program Documentation (USPD) at kung paano ilapat ang mga pamantayang ito sa pagsasanay. Magsisimula ako sa isang kuwento tungkol sa kung anong mga pamantayan ang mayroon, at magtatapos ako sa karanasan ng paglalapat ng bawat isa sa mga pamantayan ng ESPD nang hiwalay.

Sa isang pagkakataon, noong nagsisimula pa lang akong magtrabaho bilang isang programmer, madalas kong marinig ang "mangyaring magsulat ng dokumentasyon para sa iyong programa." Matapat kong inilarawan ang lahat, ibinigay ito sa aking amo, pagkatapos ay nagsimula ang black magic session. Pagkaraan ng ilang sandali, tinawag ako ng amo at nagsimulang bumulong ng hindi maipaliwanag na mga tunog, nilukot ang printout ng aking "pinakamahusay" na teksto sa kanyang mga kamay, na ipinikit ang kanyang mga mata. Ang pangkalahatang kahulugan ng kanyang mooing ay naging "mali," "mali," at "tingnan kung ano ang ginagawa ng iba." Dahil imposibleng makuha ang anumang iba pang sagot mula sa kanya, pumunta ako sa "iba" para sa mga halimbawa ng mga dokumento. Bilang isang patakaran, ang mga ito ay masasayang lalaki, ang kahulugan ng mga talumpati ay "narito ang mga halimbawa," "sa pangkalahatan, ayon sa GOST," at "walang nangangailangan ng lahat ng ito." Ito ay kung paano ko natutunan sa unang pagkakataon na ang isang programmer ay maaaring makipag-ugnayan sa mga kahila-hilakbot na pamantayan ng GOST.
Nakapagtataka na sa maraming dose-dosenang mga kasamahan ko, napakatalino na mga programmer, walang sinuman ang magtatrato sa mga GOST nang naiiba. Kahit na ang ilang mga tao na nakakakilala sa kanila at, tila, kahit na alam kung paano gumuhit ng mga dokumento, tinatrato sila nang may paghamak at pormalidad. Ang isang sitwasyon kung saan kahit na ang mga taong responsable para sa pamamahala ng pag-unlad ay hindi nauunawaan kung bakit kailangan ang mga GOST at kung paano ito ilalapat ay nangyayari sa maraming mga negosyo sa lahat ng oras. Oo, may mga kumpanyang nauunawaan kung paano naiiba ang "Paglalarawan ng Programa" sa "Paglalarawan ng Aplikasyon," ngunit mayroong isang malinaw na minorya sa kanila. Sa Internet, ang nangingibabaw na pananaw ay ang mga GOST para sa mga programmer ay isang malinaw na panimula, at kinakailangan lamang kung sila ay "yumuko" sa kanila. Ang draft na disenyo ay itinuturing na "isang medyo patas na paraan ng pagkuha ng labis na banknotes mula sa customer." Kinailangan kong bungkalin at unawain ito kamakailan - sa proseso ng pagbuo ng isang sistema ng pamamahala ng mga kinakailangan na iniayon sa mga lokal na detalye. Ang dokumentasyon na, siyempre, ay dapat mabuo "ayon sa GOST".

Dito nais kong tumuon sa isang paksa lamang na dapat harapin ng isang programmer sa mga domestic na negosyo, lalo na sa mga instituto ng pananaliksik - ang hanay ng mga pamantayan ng ESPD. Hindi ko itinuturing ang aking sarili na isang mahusay na dalubhasa sa ESPD - may mga taong nagtatrabaho dito sa loob ng mga dekada at tiyak na itatama ako. Ang artikulo sa halip ay sinusubukan na balangkasin ang mga balangkas ng isang "mapa ng daan" para sa mga taong papasok pa lamang sa ugoy ng mga bagay.

Mga pamantayan

Tingnan natin kung anong mga pamantayan ang mayroon (nakatuon sa lugar ng IT).
  1. internasyonal. Ang isang natatanging tampok ay na ito ay pinagtibay ng isang internasyonal na organisasyon. Ang isang halimbawa ng naturang organisasyon ay ISO (International Organization for Standardization). Isang halimbawa ng pamantayan nito: ISO 2382-12:1988 (Peripheral equipment). Ang mga pinagsamang pamantayan ng ISO at ang International Electrotechnical Commission (IEC, sa Russian - IEC) ay laganap: halimbawa, ISO/IEC 12207:2008 (software life cycle);
  2. rehiyonal. Isang natatanging tampok - pinagtibay ng komisyon ng rehiyon para sa standardisasyon. Halimbawa, maraming mga Sobyet na GOST ang mga pamantayang pangrehiyon na ngayon, dahil pinagtibay ng interstate council, na kinabibilangan ng ilang dating republika ng Sobyet. Ang konsehong ito ay nagpapatibay din ng mga bagong pamantayan - at natatanggap din nila ang pagtatalaga ng GOST. Halimbawa: GOST 12.4.240-2013;
  3. pamantayan ng mga pampublikong asosasyon; Halimbawa, ang parehong IEC: IEC 60255;
  4. pambansang pamantayan. Para sa Russia, ang simula ng naturang mga pamantayan ay "GOST R". Maaaring may tatlong uri:
    1. eksaktong mga kopya ng mga internasyonal o rehiyonal. Ang mga ito ay itinalaga nang walang pagkakaiba mula sa "self-written" (pambansa, independiyenteng isinulat);
    2. mga kopya ng internasyonal o rehiyonal na may mga karagdagan. Ang mga ito ay ipinahiwatig sa pamamagitan ng pagdaragdag sa cipher ng domestic standard ang internasyonal na cipher, na kinuha bilang batayan. Halimbawa: GOST R ISO/IEC 12207;
    3. actually, national standards. Halimbawa, GOST R 34.11-94.

Ang mga sistema ng notasyon sa bawat antas at sa bawat organisasyon ay magkakaiba; ang bawat kaso ay kailangang suriin nang hiwalay. Upang mabilis na maunawaan kung "kanino" ang pamantayan ay nasa harap ng iyong mga mata, maaari kang gumamit ng cheat sheet.

GOST

Kaya: ang mga pamantayan ay internasyonal, interstate (rehiyonal) at pambansa. Ang GOST, tulad ng nalaman namin, ay isang panrehiyong pamantayan. Ang mga GOST ay may medyo nakalilito, sa palagay ko, sistema ng notasyon. Ito ay ganap na itinakda sa GOST R 1.5-2004, ibibigay ko ang pinakamababa upang mag-navigate dito. Una, kinakailangan na makilala sa pagitan ng pagtatalaga ng GOST at pag-uuri nito. Ang isang pagtatalaga ay, halos nagsasalita, isang natatanging identifier para sa isang pamantayan. Ang classifier code ay isang auxiliary code na tumutulong upang mahanap ang isang pamantayan o matukoy kung saang lugar ng kaalaman ito kabilang. Maaaring magkaroon ng maraming mga classifier, higit sa lahat ay dalawa ang ginagamit: KGS (classifier ng mga pamantayan ng estado) at ang kahalili nitong OKS (all-Russian classifier ng mga pamantayan). Halimbawa: "GOST R 50628-2000" ang pagtatalaga ng pamantayan. Mula sa pagtatalaga ay malinaw lamang na ito ay pinagtibay noong 2000. Mayroon itong OKS code na "33.100;35.160": i.e. "33" - seksyong "Telekomunikasyon, audio, video", "100" - subsection na "electromagnetic compatibility". Gayunpaman, kasama rin ito sa 35.160 classifier branch. "35" - "Mga teknolohiya ng impormasyon. Mga makina ng opisina", "160" - "Mga microprocessor system...". At ayon sa KGS mayroon itong code na "E02", na nangangahulugang "E" - "Electronic technology, radio electronics at communications", "0" - "General rules and regulations for electronic technology, radio electronics and communications", atbp.

Kung alam mo ang pagtatalaga ng pamantayan, maaari mong makuha ang mga code nito para sa KGS at OKS, halimbawa, sa matalinong website na ito.
Kaya, bumalik tayo sa mga pagtatalaga ng GOST. Maaaring mayroong dalawang pagpipilian:

  1. ang pamantayan ay tumutukoy sa isang serye ng mga pamantayan. Sa kasong ito, pagkatapos ng karaniwang index ng kategorya (halimbawa, GOST, GOST R o GOST RV) mayroong isang serye ng code, isang tuldok at ang pagtatalaga ng pamantayan sa loob ng serye. Ang mga patakaran para sa pagtatalaga ng mga pamantayan sa loob ng isang serye ay itinatag ng mga tuntunin ng serye. Halimbawa: GOST RV 15.201-2000, GOST R 22.8.0-99, GOST 19.101-77;
  2. Ang pamantayan ay hindi kabilang sa isang serye ng mga pamantayan. Pagkatapos ng index ng kategorya ay mayroon lamang serial number ng pamantayan, isang gitling at ang taon ng pag-aampon. Halimbawa, GOST R 50628-2000.
Kaya, upang ilagay ito nang napakasimple, ang pagtatalaga ng GOST ay alinman sa simpleng serial number, isang gitling, isang taon, o isang numero ng serye, isang tuldok, at iba pa, depende sa serye. Sa katotohanan, ang lahat ay mas kumplikado (halimbawa, maaari kang makahanap ng isang bagay tulad ng GOST 11326.19-79, at hindi ito magiging serye ng 11326 - ngunit bihirang kailangan ito ng mga programmer. Para sa mga detalye, tingnan ang GOST R 1.5-2004).

ESPD

Ang ESPD ay isa sa mga serye ng GOST, numero 19. Iyon ay. lahat ng mga pamantayang nauugnay sa ESPD ay nagsisimula sa prefix na "19.": halimbawa, GOST 19.106-78. Ang ibig sabihin ay "Pinag-isang Sistema ng Dokumentasyon ng Programa". Mayroong iba pang mga serye:
  • GOST ESKD (pinag-isang sistema ng dokumentasyon ng disenyo, prefix "2.");
  • GOST ESTD (pinag-isang sistema ng teknolohikal na dokumentasyon, prefix "3.");
  • GOST R, Sistema para sa pagbuo at paggawa ng mga produkto, prefix na "15.";
  • GOST RV, Armament at kagamitang militar. Sistema para sa pagbuo at paglulunsad ng mga produkto sa produksyon, prefix na "15.";
  • GOST, Sistema ng teknikal na dokumentasyon para sa mga awtomatikong sistema ng kontrol, prefix na "24.";
  • GOST, Set ng mga pamantayan para sa mga awtomatikong system, prefix na "34.".
Kaya, ang ESPD ay naglalaman ng isang hanay ng mga pamantayan na ginagamit sa pagbuo ng software. Susunod, para sa bawat pamantayan mula sa ESPD, isang maikling paglalarawan at paliwanag para sa mga hindi halatang kaso ay ibinibigay.
19.001-77. Pangkalahatang probisyon
Inilalarawan ang mga panuntunan para sa pagtatalaga ng mga pagtatalaga sa mga pamantayan sa serye ng ESPD. Hindi kailangan sa praktikal na buhay.
19.102-80. Mga scheme ng mga algorithm at programa. Mga panuntunan sa pagpapatupad.
Inilalarawan ang mga panuntunan para sa pagbuo at pagdidisenyo ng mga algorithm. Gumagamit ng notasyon mula sa 19.103. Sa aking pagsasanay, ang tanging oras na kailangan ay kapag ang laboratoryo ng sertipikasyon ay iginiit sa isang pormal na batayan na ito ay ang algorithm diagram na kailangan. Mula sa aking pananaw, ang mga klasikong flowchart ay isang bagay ng nakaraan, at ang tanging lugar kung saan nananatili ang mga ito nang higit pa o hindi gaanong naaangkop ay kung, kapag nagtatanghal, nais ng may-akda na ituon ang pansin ng mambabasa sa algorithm.
19.003-80. Mga scheme ng mga algorithm at programa. Maginoo na mga graphic na simbolo
Ang mga graphic na pagtatalaga ng mga katanggap-tanggap na uri ng mga elemento ng block diagram ay ibinigay. Kinakailangan kung ang mga flowchart ay ginagamit.
19.004-80. Mga Tuntunin at Kahulugan.
Maliit na glossary. Ang pinaka-kagiliw-giliw na bagay ay naglalaman ito ng mga pormal na kahulugan ng programa at mga dokumento sa pagpapatakbo.
19.005-85. P-scheme ng mga algorithm at program
Halos nakalimutang wika. Sa isang pagkakataon, malawakang ginagamit ang mga P-scheme sa industriya ng rocket at espasyo, na naging de facto na pamantayan para sa pagsusulat ng mga programang kontrol sa paglulunsad at pagtulad sa mga paglulunsad. Gayunpaman, ngayon ang wikang ito ay ganap na nakalimutan. Sa aking trabaho, hindi pa ako nakatagpo ng mga P-scheme. Bagaman, kumpara sa mga block diagram, mayroon silang mga kapansin-pansing pakinabang: sila ay compact, na angkop para sa pag-visualize ng mga nonlinear na algorithm (halimbawa, mga klase sa C++) o mga istruktura ng data. Kasabay nito, halos walang impormasyon sa mga ito sa Internet: Nakita kong kapaki-pakinabang ito at ang site na ito. Sa anumang kaso, kung kailangan ko na ngayong magpasok ng algorithm diagram sa dokumentasyon ng software, pipiliin ko ang mga P-chart kaysa sa mga flowchart.
19.101-77. Mga uri ng mga programa at mga dokumento ng programa
Naglalaman ng isang talahanayan ng mga sulat sa pagitan ng isang uri ng dokumento at ang code nito, pati na rin ang isang dibisyon ng mga uri ng dokumento sa pagpapatakbo at programa. Ang konsepto ng kumplikado at bahagi ay ipinakilala. Walang ibang kapaki-pakinabang.
19.102-77. Mga yugto ng pag-unlad
Isang mahalaga at kinakailangang pamantayan na naglalarawan sa mga uri ng mga dokumento at nagbibigay ng mga code para sa mga uri ng mga dokumento ng programa. Ang pamantayang ito (kasama ang 19.103-77) ay isa sa mga susi sa "paglutas" ng mga pagtatalaga ng mga dokumento tulad ng ABVG.10473-01 32 01-1.
Ang pamantayan ay nagpapakilala sa konsepto ng isang kumplikado at isang bahagi (isang bilang ng mga negosyo ay nagdaragdag ng isang pangatlong uri - isang set, pagdating sa hindi nauugnay na mga elemento ng software), at isang dibisyon ay ibinigay: kung aling mga dokumento ang gumagana at kung alin ang hindi.
Dapat kang mag-ingat sa Talahanayan 4, na nagpapakita kung aling dokumento ang isinasagawa sa kung aling yugto ng pag-unlad. Ang mga yugto ng pag-unlad ay karaniwang kinokontrol sa mga pamantayan para sa pagpapatupad ng disenyo at gawaing pag-unlad, at ipinahiwatig din doon kung aling mga dokumento ang dapat iharap sa customer sa bawat yugto.
19.102-77. Mga yugto ng pag-unlad
Sa aking memorya, ang pamantayang ito ay hindi kailanman ginamit: sino ang gumagawa kung ano sa anong yugto at kung ano ang kanilang iniulat ay nakasulat sa mga teknikal na pagtutukoy o isang sanggunian ay ginawa sa GOST, kung saan ito ay mas malinaw na nakasaad (halimbawa, GOST RV 15.203 ). Kasabay nito, para sa isang baguhan, naglalaman ito ng isang medyo maikling balangkas ng trabaho sa mga pangunahing yugto ng OCD.
19.103-77. Mga pagtatalaga ng mga programa at mga dokumento ng programa
Ito ay kinakailangan pangunahin upang matutong basahin ang mga simbolo ng mga dokumento na katulad ng ibinigay sa itaas. Gayunpaman, ang pag-unawa sa scheme ng notasyon ay kapaki-pakinabang kapag kailangan mong lumampas sa karaniwang gawain: halimbawa, tandaan na ang mga dokumentong may mga code pagkatapos ng 90 ay tinukoy ng gumagamit, i.e. anuman. Sa aking pagsasanay, inilabas namin ang dokumento 93, na tinawag naming "Program Documentation Statement", dokumento 96 - "Mga Tagubilin sa Pagtitipon".
Ang karaniwang pariralang "pagpipilian sa pagpapatupad" ay wala sa ESPD at pinalitan ng "numero ng rebisyon". Sa isang banda, hindi ito ganap na tama: ang numero ng rebisyon ay inilaan upang subaybayan ang ebolusyon ng programa: una ang unang edisyon ay inilabas, pagkatapos, halimbawa, pagkatapos ng rebisyon, ang pangalawa. Ngunit sa pagsasagawa, kapag kailangan mong maglabas ng bersyon ng software para sa ilang mga operating system (cross-platform software), walang ibang pagpipilian. Mas tiyak, mayroon, ngunit ito ay hindi tama: italaga ang bersyon para sa bawat operating system ng sarili nitong pagtatalaga - at ilagay sa archive ang ilang mga disk na may mga source code (ayon sa bilang ng mga operating system), bumuo (sa katunayan, kopyahin) ang buong hanay ng dokumentasyon, atbp.... Iyon ay. puro katangahan at nakakalito na aktibidad. Ang solusyon sa anyo ng pagtatalaga ng numero ng bersyon sa bawat operating system ay ginagawang posible na gawing karaniwan ang ilang mga dokumento.
Ginagamit ng ESPD ang pagtatalaga ng source code ng programa at ang resulta ng pagpupulong bilang "mga dokumento," na nakalilito sa maraming programmer. Ang dokumentong "teksto ng programa", ayon sa 19.101-77, ay may pagtatalaga 12. Higit pang tinatanggap na ang source code ay itinalaga bilang 12 01 - i.e. 01 (ang unang) dokumento ng uri 12, at mga binary - tulad ng 12 02 - i.e. ang pangalawang dokumento ng uri 12. Sa ilang mga kaso, ang mga karagdagang tool ay kinakailangan upang bumuo ng isang programa - mga compiler, installer generators, atbp. Yung. mga programa na hindi kasama sa paghahatid, ngunit kailangan para sa pagpupulong. Ang isang solusyon ay maaaring italaga ang mga ito bilang 12 03 - i.e. ikatlong dokumento ng uri 12.
19.104-78. Mga pangunahing inskripsiyon
Inilalarawan ang dalawang sheet ng dokumento - ang approval sheet (AL) at ang pamagat na pahina. Ang sheet ng pag-apruba sa ESPD ay naglalaman ng mga pirma ng parehong mga awtoridad na nag-apruba sa dokumento at ng mga developer, normative inspector, mga kinatawan ng pagtanggap, atbp. Yung. naglalaman ito ng napakaraming sensitibong impormasyon para sa negosyo. Samakatuwid, ipinapalagay ng pamantayan na ang LU ay nananatili sa development enterprise at ipinadala lamang sa mga espesyal na tagubilin. Muli - ang LU ay hindi bahagi ng dokumento, ngunit, bilang ito ay, isang hiwalay na dokumento, at ito ay kasama sa detalye bilang isang hiwalay na linya.
Ang unang nakakalito na kakaiba sa paghihiwalay ng LU mula sa mismong dokumento ay may napakagandang dahilan:
  • gaya ng nabanggit na, kadalasan ang isang negosyo ay ayaw magbunyag ng impormasyon tungkol sa developer. Ang paghihiwalay sa LU at "pagipit" ay nagpapahintulot nito na magawa ito (hindi tulad ng ESKD, walang selyo sa mga sheet ng dokumento sa ESPD; lahat ng impormasyon ay naisalokal lamang sa LU);
  • Ang isang bilang ng mga negosyo ay gumagamit ng halo-halong daloy ng dokumento: ang mga orihinal na dokumento ay naka-imbak sa elektronikong paraan sa archive ng enterprise, at ang mga dokumento sa kanila (na may orihinal na mga lagda) ay naka-imbak sa papel na anyo;
Tulad ng para sa pagpaparehistro ng LU, kadalasan ang mga negosyo ay gumagamit ng isang halo - ang ilan sa mga inskripsiyon ng LU ay iginuhit ayon sa ESPD, ang ilan - ayon sa ESKD, at ang ilan - sa kanilang sariling paraan. Samakatuwid, pinakamainam, bago gumawa ng LU, maghanap ng enterprise standard (STO), o kumuha ng halimbawa mula sa lokal na kontrol sa regulasyon.
Dapat ding tandaan na ang LU ay hindi binibilang, at ang unang pahina ay ang pahina ng pamagat, at ang unang pahina kung saan nakalagay ang numero ay nasa tabi ng pahina ng pamagat. Ngunit kung mayroong higit sa isang LU (mangyayari ito kung ang lahat ng mga lagda ay hindi magkasya sa sheet), kung gayon ang mga LU ay binibilang nang hiwalay.
19.105-78. Pangkalahatang mga kinakailangan para sa mga dokumento ng programa
Ang pangkalahatang istraktura ng dokumento ay ipinakilala, anuman ang paraan ng pagpapatupad nito. Yung. Noong 1978, ito ay inilatag sa pamantayan na ang isang dokumento ay maaaring hindi nangangahulugang papel. Sa partikular, ang konsepto ng nilalaman ay ipinakilala para sa ganap na elektronikong mga dokumento. Para sa pagpapatupad ng papel, karaniwan sa oras na iyon, pinagtibay ang GOST 19.106-78.
Sa kasalukuyan, ang isa ay bihirang sumangguni sa pamantayang ito: maliban kung nakalimutan ng isa ang pagkakasunud-sunod ng mga pangunahing bahagi ng dokumento.
19.106-78. Pangkalahatang mga kinakailangan para sa mga naka-print na dokumento ng programa
Ang pinakakomprehensibong pamantayan mula sa ESPD, pangalawa lamang sa paglalarawan ng R-scheme. Ito ang pangunahing pamantayan sa pagtatrabaho kapag naghahanda ng dokumentasyon. Ipinapakilala ang mga panuntunan para sa pag-format ng text, mga elemento ng istruktura ng dokumento, mga larawan, mga formula, atbp. Gayunpaman, hindi katulad ng kaukulang 2.106 mula sa ESKD, ang 19.106 ay hindi gaanong detalyado, na humahantong sa maraming kawalan ng katiyakan.
Una, hindi aktwal na tinutukoy ng pamantayan ang spacing ng linya at ang dami ng patayong espasyo sa pagitan ng mga heading. Ipinakilala niya ang tatlong panuntunan para sa pagtukoy ng espasyo: para sa makinilya na teksto, machine at typographical.
Ang Typescript ay tekstong nai-type sa isang makinilya. Ang paglipat ng susunod na linya na nauugnay sa nauna ay awtomatikong isinagawa sa panahon ng tinatawag na "carriage return" - ang paglipat sa pag-print sa susunod na linya, na ginawa sa pamamagitan ng paglipat ng isang espesyal na pingga. Karaniwan, ang spacing ay maaaring manu-manong i-adjust sa pamamagitan ng pagpihit sa paper feed shaft, at mayroong "setting" na nagpapahintulot sa iyong itakda ang laki ng spacing - single o double.
Ang uri ng makina ay malamang na ang naka-print na teksto. Ngunit para sa kanya ay may indikasyon lamang na ang resulta ay dapat na angkop para sa microfilming. Ito ay isang implicit na sanggunian sa 13.1.002-2003, na, sa kasamaang-palad, ay nagtatakda ng line spacing (at, sa pamamagitan ng paraan, ang pinakamababang taas ng font) para lamang sa mga sulat-kamay na dokumento (clause 4.2.5).
Typographic - tekstong nai-type sa isang palimbagan. Isinasaalang-alang ang taon na pinagtibay ang pamantayan, malamang na pinag-uusapan natin
[letterpress printing, kung saan ang line spacing ay tinutukoy ng uri na ginamit. Hindi ako isang dalubhasa sa palalimbagan, at napakakaunting impormasyon tungkol sa mga pamamaraan ng pag-type sa ngayon.
Aling pagitan ang gagamitin sa dulo ay kadalasang tinutukoy ng mga lokal na regulasyon o istasyon ng serbisyo. Ang mga karaniwang halaga ay isa't kalahating puwang at laki ng font 14.
Ang paraan ng pagkakabalangkas ng isang dokumento ay kadalasang nagdudulot ng maraming katanungan. Isinasaalang-alang ng 19.106 na ang buong dokumento ay nahahati sa mga seksyon, mga subsection, mga talata at mga subparagraph. Lahat ng mga ito (maliban sa mga seksyon at subsection) ay maaaring may pamagat o wala. kung saan:
  • “Kabilang sa mga nilalaman ng dokumento ang bilang ng mga seksyon, mga subseksyon, mga sugnay at mga subseksyon na may pamagat” (sugnay 2.1.4). Ito ay isang direktang indikasyon na ang subclause ay maaaring may pamagat at kasama sa talaan ng mga nilalaman;
  • "Pinapayagan itong maglagay ng teksto sa pagitan ng mga heading ng seksyon at subsection, sa pagitan ng mga heading ng subsection at paragraph." Mahalagang tandaan na ang walang numerong teksto ay maaari lamang sa pagitan ng mga heading, at sa nangungunang 2 antas lamang.
Hindi tulad ng ESKD, ang ESPD ay gumagamit ng kakaibang paraan ng pag-format ng mga guhit: una ang pangalan ng drawing, pagkatapos ay ang drawing mismo, pagkatapos ay ang opsyonal na "under-figure text", at pagkatapos, sa isang bagong linya, "Fig. N".
Ang pamantayang ito ay may maraming "butas" at hindi pagkakapare-pareho. Halimbawa, sinasabing: “Ang mga ilustrasyon, kung mayroong higit sa isa sa mga ito sa isang ibinigay na dokumento, ay binibilang sa mga numerong Arabe sa buong dokumento. "Ngunit kung mayroon lamang isang ilustrasyon, kung gayon hindi ito binibilang, at kung gayon paano mo ito sasangguni? Ganoon din sa mga mesa. Para sa mga footnote, hindi ipinapahiwatig ng GOST ang paraan ng kanilang pagnunumero - sa loob ng buong dokumento o sa loob ng pahina.
Mga mesa. Ang dokumento mismo ay naglalaman ng isang sanggunian sa GOST 1.5.68. Sa paghusga sa unang yugto, madaling tapusin na ito ay isang pamantayan para sa pagbuo ng mga pamantayan. Hindi malinaw kung ano ang kinalaman niya dito. Sa kahulugan, ito ay tumutugma sa mga patakaran para sa pagdidisenyo ng mga talahanayan sa ESKD, na may maliliit na pagbubukod. Ang pamantayang ito ay kinansela at pinalitan, sa pamamagitan ng ilang mga pag-ulit, noong 1.5-2012, kung saan ang mga panuntunan sa disenyo ng talahanayan... basta na lang nawala. Noong 1.5-2002 nandoon sila, ngunit noong 1.5-2004 na sila nawala. Sa totoong buhay, gumuhit kami ng mga talahanayan ayon sa ESKD.
Mga aplikasyon. Ang pamantayan ay hindi nagsasaad kung ang mga numero, formula at talahanayan mula sa mga apendise ay kasama sa pangkalahatang listahan. Katulad nito, hindi sinasabi kung ang talaan ng mga nilalaman ay kailangang ibunyag ang istraktura ng aplikasyon kung naglalaman ito ng sarili nitong mga seksyon, mga talata, atbp. Sa aming pagsasanay, hindi namin ibinubunyag ang loob ng mga aplikasyon.
Sa wakas, may dapat sabihin tungkol sa indentation. Ang indent ng talata na may 5 character ay karaniwan para sa:
  • pulang linya;
  • indentation ng isang elemento ng istruktura ng dokumento pagkatapos ng isang seksyon (subsection, clause, subclause);
  • elemento ng enumeration.

    • Sa kasong ito, ang teksto na matatagpuan sa susunod na linya pagkatapos ng naka-indent na linya ay nakahanay sa kaliwang margin. Kadalasan mayroong mga error kapag tumalon ang indentation - ang pulang linya - isang halaga, ang numero ng item - sa amin na may ibang agwat, sa mga nested indentation sa mga listahan - ito ay karaniwang kinakailangan.

    Sa mga sumusunod na bahagi plano kong makarating sa dulo ng listahan ng mga pamantayan ng ESPD.

G O S U D A R S T V E N N Y S T A N D A R T S O Y W A S S R

Sistema ng teknikal na dokumentasyon para sa mga awtomatikong sistema ng kontrol

GOST 24.207-80

MGA KINAKAILANGAN PARA SA NILALAMAN NG SOFTWARE DOCUMENTS
Sistema ng teknikal na dokumentasyon para sa mga sistema ng kontrol sa computer. Mga kinakailangan para sa mga nilalaman ng mga dokumento sa software

Sa pamamagitan ng Decree ng USSR State Committee on Standards na may petsang Mayo 14, 1980 No. 2101, ang petsa ng pagpapakilala ay itinatag

mula 01/01/1981

Nalalapat ang pamantayang ito sa teknikal na dokumentasyon para sa mga automated control system (ACS) ng lahat ng uri, na binuo para sa lahat ng antas ng pamamahala (maliban sa mga pambansa), at nagtatatag ng mga kinakailangan para sa nilalaman ng mga dokumentong kasama alinsunod sa GOST 24.101-80 bilang bahagi ng dokumentasyon ng software sa mga proyekto ng ACS.

1. PANGKALAHATANG PROBISYON

1.1. Ang dokumentasyon ng software ay nilayon na:

  • upang ilarawan ang mga solusyon sa disenyo para sa software sa dokumentong "Paglalarawan ng ACS Software".
  • upang magtatag ng mga kinakailangan para sa isang programa (set ng mga programa) sa dokumentong "Mga Teknikal na Pagtutukoy";
  • upang ilarawan ang mga solusyon na nagbibigay ng pagpapanatili, paggawa at pagpapatakbo ng isang programa (set ng mga programa) sa mga dokumentong "Paliwanag na Tala", "Paglalarawan ng Aplikasyon", "Paglalarawan ng Programa", "Pagtutukoy", "Gabay ng Programmer", "Operator's Gabay", "Text ng Programa" , "Form", "Pamamaraan at mga pamamaraan ng pagsubok";
  • upang suriin ang pag-andar ng programa (set ng mga programa) sa dokumentong "Paglalarawan ng kaso ng pagsubok".

1.2. Kapag bumubuo ng mga dokumento para sa mga bahagi ng isang awtomatikong sistema ng kontrol, ang nilalaman ng mga seksyon ng bawat dokumento ay limitado sa balangkas ng kaukulang bahagi.

1.3. Depende sa layunin at tiyak na mga tampok ng nilikha na mga awtomatikong sistema ng kontrol, pinapayagan na isama ang mga karagdagang seksyon sa mga dokumento, ang mga kinakailangan sa nilalaman na hindi itinatag ng pamantayang ito. Ang kawalan ng mga solusyon sa disenyo para sa isang seksyon ng dokumento ay naitala sa naaangkop na seksyon na may mga kinakailangang paliwanag.

1.4. Ang mga kinakailangan para sa nilalaman ng mga dokumento na "Mga Teknikal na Pagtutukoy", "Paliwanag na Tala", "Paglalarawan ng Aplikasyon", "Pagtutukoy", "Manwal ng Operator", "Teksto ng Programa", "Form", "Pamamaraan at Pamamaraan ng Pagsubok" ay itinatag ng GOST 19.201-78, GOST 19.404-79, GOST 19.502-78, GOST 19.202-78, GOST 19.505-79, GOST 19.401-78, GOST 19.501-78 at GOST-19.301

(Binagong edisyon, Susog Blg. 1).

2. MGA KINAKAILANGAN PARA SA NILALAMAN NG MGA DOKUMENTO

2.1. Paglalarawan ng ACS software

2.1.1. Ang dokumento ay dapat maglaman ng panimulang bahagi at mga seksyon:

  • istraktura ng software;
  • ang mga pangunahing pag-andar ng mga bahagi ng software;
  • mga pamamaraan at tool sa pagbuo ng software;
  • operating system;
  • mga tool na nagpapalawak ng mga kakayahan ng operating system.

2.1.2. Ang panimulang bahagi ay dapat maglaman ng pangunahing impormasyon tungkol sa teknikal, impormasyon at iba pang mga uri ng suporta sa awtomatikong control system na kinakailangan para sa pagbuo ng software, o isang link sa mga nauugnay na dokumento ng proyekto ng automated control system.

2.1.3. Ang seksyong "Software Structure" ay dapat maglaman ng isang listahan ng mga bahagi ng software, na nagsasaad ng kanilang mga relasyon at ang katwiran para sa pagtukoy sa bawat isa sa kanila.

2.1.4. Ang seksyong "Mga pangunahing function ng mga bahagi ng software" ay dapat maglaman ng mga subsection kung saan, para sa bawat bahagi ng software, ang layunin at paglalarawan ng mga pangunahing function ay ibinibigay.

(Binagong edisyon, Susog Blg. 1).

2.1.5. Ang seksyon na "Mga pamamaraan at tool para sa pagbuo ng software" ay dapat maglaman ng isang listahan ng mga pamamaraan ng programming at mga tool para sa pagbuo ng automated control system software, na nagpapahiwatig ng mga bahagi ng software sa pagbuo ng kung saan ang mga naaangkop na pamamaraan at tool ay dapat gamitin.

2.1.6. Ang seksyong "Operating System" ay dapat maglaman ng:

  • pangalan, pagtatalaga at maikling paglalarawan ng napiling operating system at ang bersyon nito, kung saan isasagawa ang mga binuo na programa, na may katwiran para sa pagpili at indikasyon ng mga mapagkukunan kung saan ibinigay ang isang detalyadong paglalarawan ng napiling bersyon;
  • ang pangalan ng manu-manong alinsunod sa kung saan dapat mabuo ang napiling bersyon ng operating system;
  • mga kinakailangan para sa opsyon sa pagbuo ng napiling bersyon ng operating system.

2.1.7. Ang seksyong "Mga tool na nagpapalawak ng mga kakayahan ng operating system" ay dapat maglaman ng mga subsection kung saan para sa bawat tool na ginamit na nagpapalawak sa mga kakayahan ng operating system, dapat mong ipahiwatig ang:

  • pangalan, pagtatalaga at maikling paglalarawan ng produkto, na nagbibigay-katwiran sa pangangailangan para sa paggamit nito at nagpapahiwatig ng pinagmulan, na nagbibigay ng isang detalyadong paglalarawan ng napiling produkto;
  • ang pangalan ng manu-manong alinsunod sa kung saan ang produktong ginamit ay dapat i-configure para sa isang partikular na aplikasyon;
  • mga kinakailangan para sa pag-set up ng tool na ginamit.

2.2. Paglalarawan ng programa

2.2.2. Para sa isang program (set ng mga program) na nakuha sa pamamagitan ng paggamit ng dating binuong software, ang dokumentong "Deskripsyon ng Programa" ay dapat na dagdagan ng seksyong "Software Setup".

2.2.3. Ang seksyong "Software Configuration" ay dapat maglaman ng:

  • pangalan, pagtatalaga ng software na ginamit, paglalarawan ng mga pamamaraan na kinakailangan upang i-configure ang mga ito, o mga link sa dokumentasyon ng pagpapatakbo ng mga tool na ito;
  • isang listahan ng mga elemento ng ginamit na software na kinakailangan upang makuha ang program (set ng mga program);
  • paglalarawan ng mga setting sa wikang ibinigay sa dokumentasyon ng pagpapatakbo para sa software na ginamit.

2.3. Gabay ng Programmer

2.3.1. Ang dokumento sa komposisyon ng mga seksyon at ang kanilang nilalaman ay dapat sumunod sa GOST 19.504-79 at, bilang karagdagan, isama ang seksyong "Impormasyon sa anyo ng pagtatanghal ng programa (set ng mga programa)."

2.3.2. Ang seksyon na "Impormasyon tungkol sa anyo ng pagtatanghal ng programa (set ng mga programa)" ay dapat maglaman ng impormasyon tungkol sa medium kung saan naitala ang programa, tungkol sa nilalaman at sistema ng coding ng impormasyon na naitala sa medium, pati na rin ang impormasyong kinakailangan para sa pagbasa ng impormasyon mula sa midyum.

2.3.3. Para sa isang programa (set ng mga programa) na maaaring i-customize sa mga kundisyon ng isang partikular na aplikasyon, ang dokumentong "Gabay sa Programmer" ay may kasamang mga seksyon:

  • istraktura ng programa;
  • mga setting ng programa;
  • karagdagang mga tampok;
  • mga mensahe sa system programmer.

2.3.4. Pinapayagan para sa isang programa (set ng mga programa) na maaaring ipasadya sa mga kondisyon ng isang partikular na aplikasyon, sa halip na ang mga seksyon na nakalista sa sugnay 2.3.3, upang bumuo ng isang hiwalay na dokumento na "System Programmer's Guide" na nakakatugon sa mga kinakailangan ng GOST 19.503-79.

2.4. Paglalarawan ng test case

2.4.1. Ang dokumento ay dapat maglaman ng mga seksyon:

  • appointment;
  • paunang datos;
  • mga resulta ng pagkalkula;
  • pagsuri sa isang programa (set ng mga programa).

2.4.2. Ang seksyong "Layunin" ay dapat maglaman ng isang listahan ng mga parameter at isang maikling paglalarawan ng function na ipinatupad ng programa (set ng mga programa) na sinubok ng halimbawa ng pagsubok.

2.4.3. Ang seksyong "Initial data" ay dapat maglaman ng isang paglalarawan ng paunang data para sa pagsubok sa program (set ng mga program) kasama ang pagtatanghal ng paunang data. Pinapayagan na ipakita ang source data sa anyo ng isang printout mula sa ADCP.

2.4.4. Ang seksyong "Mga Resulta ng Pagkalkula" ay dapat maglaman ng mga resulta ng pagproseso ng paunang data ng isang programa (set ng mga programa), na nagpapahintulot sa isa na suriin ang tamang pagpapatupad ng mga function na sinusubok at ang halaga ng mga parameter na sinusuri. Pinapayagan na ipakita ang mga resulta ng pagkalkula sa anyo ng isang printout mula sa ADCP.

2.4.5. Ang seksyong "Pagsusuri sa programa (set ng mga programa)" ay dapat maglaman ng:

  • isang paglalarawan ng komposisyon ng mga teknikal na paraan na kinakailangan para sa pagpapatakbo ng programa (set ng mga programa), o isang link sa mga nauugnay na dokumento ng programa;
  • paglalarawan ng mga pamamaraan para sa pagbuo ng paunang data para sa pagsuri sa isang programa (set ng mga programa), pagtawag sa programa (set ng mga programa) na sinusuri at pagkuha ng mga resulta ng pagkalkula;
  • paglalarawan ng mga aksyon ng operator kapag naghahanda ng paunang data at sumusubok sa isang programa (set ng mga programa) gamit ang isang halimbawa ng pagsubok.
* Muling pag-isyu (Mayo 1986) na may Pagbabago No. 1, naaprubahan noong Agosto 1985 (IUS 11-85).

Ang Pinag-isang Sistema ng Dokumentasyon ng Mga Produkto ng Software - ESPD - ay kabilang sa GOST class 19 at nahahati sa 10 grupo:
1. Mga Pangunahing Pamantayan.
2. Mga panuntunan para sa pagpapatupad ng dokumentasyon ng pag-unlad.
3. Mga panuntunan para sa pagpapatupad ng dokumentasyon sa pagmamanupaktura.
4. Mga panuntunan para sa pagpapatupad ng dokumentasyon ng suporta.
5. Mga panuntunan para sa pagpapatupad ng dokumentasyon ng pagpapatakbo.
6. Mga panuntunan para sa sirkulasyon ng dokumentasyon ng software.

Ang karaniwang numero 0 ay naglalaman ng mga pangkalahatang probisyon, ang mga pamantayan 7 at 8 ay nakalaan, at ang numero 9 ay kinabibilangan ng iba pang mga pamantayan na hindi kasama sa unang 6.

Ito ay mga maikling paglalarawan ng GOST ng klase 19; para sa mas detalyadong impormasyon, mangyaring sumangguni sa mga sangguniang aklat.

  • GOST 19.001-77 - isang pinag-isang sistema ng dokumentasyon ng programa.
  • GOST 19.101-77 – mga uri ng mga programa at mga dokumento ng programa.
  • GOST 19.102-77 - mga yugto ng pag-unlad ng mga programa at dokumentasyon ng programa.
  • GOST 19.105-78 – mga kinakailangan para sa disenyo ng mga dokumento ng programa, mga complex at system, anuman ang kanilang layunin at saklaw. Ang GOST 19.105-78 ay naglalaman ng kumpletong listahan ng dokumentasyon na dapat kasama ng natapos na produkto ng software.

Listahan ng dokumentasyong ipinahayag ng GOST 19.105-78:

1. Mga dokumentong naglalaman ng impormasyong kinakailangan para sa pagbuo ng isang produkto ng software at paggawa nito.
1.1. Pagtutukoy – ang komposisyon ng programa at ang dokumentasyon nito.
1.2. Listahan ng mga orihinal na may hawak - isang listahan ng mga negosyo kung saan nakaimbak ang orihinal na dokumentasyon ng programa.
1.3. Teksto ng programa - itala ang teksto ng programa kasama ang mga kinakailangang komento.
1.4. Paglalarawan ng programa - impormasyon tungkol sa lohikal at functional na istraktura ng programa.
1.5. Programa at pamamaraan ng pagsubok - mga kinakailangan na ma-verify kapag sinusubukan ang programa, pamamaraan at mga pamamaraan para sa kanilang kontrol.
1.6. Mga tuntunin ng sanggunian - layunin at saklaw ng aplikasyon ng programa, teknikal at espesyal na mga kinakailangan, mga kinakailangang yugto at tuntunin ng pag-unlad, mga uri ng pagsubok.

1.7. Paliwanag na tala - algorithm diagram, pangkalahatang paglalarawan ng algorithm, pag-andar na isinagawa ng programa. Paliwanag ng mga teknikal na desisyon na kinuha.

2. Mga dokumentong ginagamit kapag nagpapatakbo ng produkto ng software.
Listahan ng mga dokumento sa pagpapatakbo – isang listahan ng mga dokumento sa pagpapatakbo para sa programa.
Form – mga pangunahing katangian ng programa, pagkakumpleto, pangkalahatang impormasyon tungkol sa pagpapatakbo ng programa.
Paglalarawan ng aplikasyon - impormasyon tungkol sa layunin ng programa, saklaw ng aplikasyon, klase ng mga gawaing dapat lutasin, mga paghihigpit sa paggamit, kinakailangang pagsasaayos ng hardware.
System Programmer's Guide - impormasyon para sa pagsuri at pagtiyak ng functionality, pagse-set up ng program.
Gabay ng Programmer - impormasyon para sa pagpapatakbo ng na-configure na programa.
Manual ng operator - impormasyon upang matiyak ang pamamaraan para sa komunikasyon sa pagitan ng operator at ng computer sa panahon ng pagpapatupad ng programa.
Deskripsyon ng wika – paglalarawan ng syntax at semantika ng wikang ginagamit sa programa.
Manwal sa Pagpapanatili - impormasyon para sa paggamit ng mga programa sa pagsubok kapag nagseserbisyo ng mga teknikal na kagamitan.

Iba pang mga GOST na klase 19:

  • GOST 19.201-78 – ang pamamaraan para sa pagbuo at paghahanda ng mga teknikal na pagtutukoy para sa pagbuo ng isang programa o produkto ng software.
  • GOST 19.202-78 – form at pamamaraan para sa pagguhit ng mga pagtutukoy para sa mga produktong software na tinukoy sa GOST 19.101-77.
  • GOST 19.301-79 – programa at pamamaraan para sa pagsubok ng mga produkto ng software.
  • GOST 19.401-78 – ang pamamaraan para sa pagbuo at pag-format ng teksto ng programa kapag bumubuo ng mga produkto ng software.
  • GOST 19.402-78 - paglalarawan ng programa.
  • GOST 19.403-79 - anyo ng pagkumpleto at nilalaman ng listahan ng mga orihinal na may hawak, na tinukoy sa GOST 19.105-78.
  • GOST 19.404-79 - anyo ng pagkumpleto at nilalaman ng paliwanag na tala, na tinukoy sa GOST 19.105-78.
  • GOST 19.501-78 – anyo ng pagpuno at mga nilalaman ng form para sa isang produkto ng software, na tinukoy sa GOST 19.105-78.
  • GOST 19.502-78 – anyo ng pagpuno at nilalaman ng paglalarawan ng aplikasyon na tinukoy sa GOST 19.105-78.
  • GOST 19.503-79 - anyo ng pagkumpleto at nilalaman ng manwal ng programmer ng system, na tinukoy sa GOST 19.105-78.
  • GOST 19.504-79 - anyo ng pagkumpleto at nilalaman ng manwal ng programmer, na tinukoy sa GOST 19.105-78.
  • GOST 19.505-79 - anyo ng pagkumpleto at nilalaman ng manwal ng operator, na tinukoy sa GOST 19.105-78.
  • GOST 19.506-79 - anyo ng pagkumpleto at nilalaman ng paglalarawan ng wika na tinukoy sa GOST 19.105-78.
  • GOST 19.507-79 - anyo ng pagkumpleto at nilalaman ng listahan ng mga dokumento sa pagpapatakbo, na tinukoy sa GOST 19.105-78.
  • GOST 19.508-79 - anyo ng pagkumpleto at nilalaman ng manwal ng pagpapanatili, na tinukoy sa GOST 19.105-78.
  • GOST 19.701-90 – mga diagram ng mga algorithm, programa, data at system.

KULTURA SA PAGBUBUO NG SOFTWARE

Anuman software, mula sa simple Website sa makapangyarihan mga sistema ng pamamahala ng database, ay isang high-tech na produkto at dapat matugunan ang mga sumusunod na pamantayan:

  • pagiging maaasahan;
  • sapat na paghawak ng mga sitwasyong pang-emergency;
  • madaling pag-upgrade.

Matutugunan lamang ng mga programa ang mga kinakailangang ito kung maingat nilang susundin ang lahat mga teknolohiya sa pagbuo ng software.

Ay karaniwan mga yugto ng pagbuo ng programa:

  • pagtukoy ng mga kinakailangan sa programa;
  • pagbuo ng mga teknikal na pagtutukoy;
  • pagbuo ng isang draft na programa;
  • coding ng programa;
  • pagpupulong ng programa;
  • pagsubok ng mga module ng software;
  • pagsubok na operasyon ng programa;
  • pagbuo ng software;
  • paglalagay ng programa sa permanenteng operasyon;
  • suporta sa programa;
  • pagtukoy ng mga kinakailangan para sa isang bagong bersyon ng programa;

Para sa pagtukoy ng mga kinakailangan sa programa Kailangang makakuha ng sagot ang developer sa tanong: "Gaano ka interesado ang customer sa pagbuo ng programa?"

Kung ang customer ay hindi handa na aktibong lumahok sa mga pagpupulong at kumperensya kasama ang developer o sinabi na may iba pang mga kandidato na gagawa ng trabaho, ang trabaho sa programa ay dapat makumpleto sa yugtong ito.

Kung seryoso ang intensyon ng customer, malamang na ang pagtukoy sa mga kinakailangan para sa programa ay higit sa isang pulong kung saan kinakailangan upang linawin at linawin ang mga isyu:

  • Ano ang (mga) layunin ng programa?
  • Ang hanay ng mga gumagamit ng programa.
  • Batayan sa regulasyon (legal, sanggunian) kung saan nakabatay ang mga prosesong na-algoritmo sa programa.
  • Ang posibilidad at pangangailangan para sa karagdagang pag-unlad ng programa.
  • Makipag-ugnayan sa taong awtorisado na lutasin ang lahat ng isyu sa ngalan ng customer.
  • Availability ng mga materyales na umiiral o ang customer ay nagplano upang maghanda para sa paggamit sa programa (!!! Ang puntong ito ay lalong mahalaga para sa pagbuo ng mga Web site).

Pag-unlad ng mga teknikal na pagtutukoy perpektong dapat isagawa ng customer. Sa pagsasagawa, madalas itong ginagawa ng developer dahil sa kakulangan ng customer ng mga kwalipikadong espesyalista na may kaalaman sa larangan ng software development. Ang mga tuntunin ng sanggunian, bilang panuntunan, ay binuo batay sa GOST 19.201-78 "ESPD. Teknikal na gawain. Mga kinakailangan para sa nilalaman at disenyo." Sa mga kaso ng pagbuo ng teknikal na software bilang bahagi ng mga awtomatikong system, GOST 34.602-89 "Teknolohiya ng impormasyon. Mga teknikal na pagtutukoy para sa paglikha ng isang awtomatikong sistema."

Ang mga teknikal na detalye ay sumasailalim sa isang pamamaraan ng pag-apruba sa pagitan ng customer at ng developer pagkatapos suriin ang kawastuhan ng pagpapatupad nito ng serbisyo sa pagkontrol sa regulasyon ng developer.

Batay sa naaprubahang teknikal na mga pagtutukoy ang dokumentasyon ng disenyo ay ginagawa (proyekto). Ang nilalaman ng proyekto ay nakasalalay sa uri ng software at mga tradisyon ng negosyo ng developer.

Ang mga ipinag-uutos na bahagi ng proyekto ay dapat na:

  • tala ng paliwanag (ayon sa GOST 19.404-79 "ESPD. Paliwanag na tala. Mga kinakailangan para sa nilalaman at disenyo").
  • paglalarawan ng programa (ayon sa GOST 19.402-78 "ESPD. Paglalarawan ng programa").
  • listahan ng mga terminong ginamit sa proyekto. Para sa mga website, kasama sa proyekto ang:
  • sketch ng disenyo ng website;
  • listahan ng mga materyales na ginamit bilang bahagi ng site;
  • istraktura ng database (kung mayroon man)

Para sa mga program na gumagana sa mga database, ang kanilang istraktura ay isang mandatoryong bahagi.

Ang proyekto ay ang dokumentong batayan kung saan binuo ang programa, at anumang pagbabago sa istruktura at mga function ng programa nang hindi gumagawa ng mga pagbabago sa proyekto ay hindi katanggap-tanggap. Ito ay ang proyekto na ang dokumento na batayan kung saan ang programa ay kasunod na nasuri at ang paglabas ng mga kasunod na bersyon ay inihanda.

Ipatupad coding ng programa Ang taga-disenyo ay nagbibigay ng mga gawain sa programmer para sa coding program modules. Tinutukoy ng gawain ang mga kinakailangan para sa istruktura ng data ng input at output ng module, ang mga pangalan ng mga variable na ginamit sa module, ang algorithm para sa pagproseso ng data ng module, at mga diskarte sa programming (kung kinakailangan). Ang code ng programa ay sinamahan ng isang detalyadong komentaryo, ang kalidad nito ay tumutukoy sa posibilidad na ilabas ang mga kasunod na bersyon ng programa.

Ang code ay dapat na maingat na ilarawan ang kahulugan ng input at output data ng bawat module, pati na rin ang kahulugan at mga function ng module mismo. Ito ay mahalaga sa tagumpay ng pagbuo ng programa.

Bawat yugto pagbuo ng programa Responsable ang project manager. Sa yugtong ito, ang programa ay nabuo bilang isang solong kabuuan. Dahil ang lahat ng mga bahagi ng programa ay nilikha ng iba't ibang mga programmer, ang yugtong ito ay lalong mahalaga para sa pag-aalis ng mga hindi pagkakapare-pareho at hindi pagkakatugma ng lahat ng nilikha na mga module.

Pagsubok sa programa ay ginagawa tulad ng sumusunod:

  1. Ang isang hanay ng mga kagamitan para sa pagsubok ay tinutukoy.
  2. Ang mga sitwasyon (mga kaso ng pagsubok) ay binuo para sa pagsubok.
  3. Batay sa mga sitwasyon, ang pagpapatakbo ng programa sa normal na mode ay nasuri (ang tamang pagpapatupad ng mga pag-andar na dapat gawin ng programa ay nasuri).
  4. Ang pagpapatakbo ng programa sa hindi normal na mga mode ay nasuri (ito ay sinusuri kung ang programa ay gumagana nang matatag sa mga mode na maaari lamang lumitaw kapag ang mga gumagamit ay lumalabag sa mga patakaran para sa pagpapatakbo ng programa, halimbawa, pagpasok ng mga titik sa isang numeric field).
  5. Isinasagawa ang pagsubok para sa kadalian ng pamamahala ng programa at kalidad ng interface.
  6. Ang data ng pagsubok at ang mga resulta nito ay pinoproseso at naidokumento alinsunod sa GOST 34.603-92 "Teknolohiya ng impormasyon. Mga uri ng pagsubok ng mga automated system."
  7. Habang natukoy ang mga pagkakamali, itinatama ang mga ito at inuulit ang pagsubok.
  8. Matapos ang lahat ng mga error ay naitama, ang programa ay ililipat sa pagsubok na operasyon.

Sa customer sa entablado pagsubok na operasyon ang programa ay ipinadala at kinakailangang pakete ng dokumentasyon:

  • listahan ng mga dokumento sa pagpapatakbo (ayon sa GOST 19.507-79 "ESPD. Listahan ng mga dokumento sa pagpapatakbo")
  • form (ayon sa GOST 19.501-78 "ESPD. Form. Mga kinakailangan para sa nilalaman at disenyo")
  • paglalarawan ng application (ayon sa GOST 19.502-78 "ESPD. Paglalarawan ng application. Mga kinakailangan para sa nilalaman at disenyo")
  • manwal ng programmer ng system (ayon sa GOST 19.503-79 "ESPD. Manwal ng programmer ng system. Mga kinakailangan para sa nilalaman at disenyo")
  • manwal ng operator (ayon sa GOST 19.505-79 "ESPD. Manual ng operator. Mga kinakailangan para sa nilalaman at disenyo").

Depende sa uri ng gawain, ang mga sumusunod ay maaaring mailipat din:

  • manwal ng programmer (ayon sa GOST 19.504-79 "ESPD. Manwal ng programmer. Mga kinakailangan para sa nilalaman at disenyo")
  • teknikal na manual (ayon sa GOST 19.508-79 "ESPD. Maintenance manual. Mga kinakailangan para sa nilalaman at disenyo").

Sa entablado pagsubok na operasyon Itinatala ng programa ang mga komento ng customer at natukoy na mga error.

Batay dito, ito ay ginawa pagbuo ng software, iyon ay, ang pag-aalis ng mga komento at mga error, at ang programa ay ililipat sa customer sa patuloy na operasyon.

Suporta sa programa depende sa pagiging kumplikado nito, ito ay isinasagawa ng customer o ng developer. Ang suporta ay binubuo ng pagsasagawa ng mga sumusunod na uri ng trabaho:

  • mga konsultasyon;
  • pagpapanatili ng hardware kung saan ginagamit ang programa;
  • pagsuri at pagsusuri ng mga database;
  • pagpapatunay ng kawastuhan ng mga teknolohiya sa pagproseso ng data;
  • pagdodokumento at pagsusuri ng mga bagong kinakailangan sa programa.

Ang huling punto ay ang batayan para sa pagsisimula pagbuo ng isang bagong bersyon ng programa.

Tanging isang karampatang proseso ng pagbuo ng programa ang nagsisiguro ng kanilang mataas na kalidad at mahabang buhay!!!
 

Basahin:



Naka-type na programming language Uri, o format specifier, o conversion character, o control character

Naka-type na programming language Uri, o format specifier, o conversion character, o control character

C++ programming language Huling na-update: 08/28/2017 Ang C++ programming language ay isang high-level na pinagsama-samang wika...

Iskedyul ng trabaho sa Russian Post sa mga pista opisyal ng Bagong Taon Trabaho sa post sa mga pista opisyal ng Bagong Taon

Iskedyul ng trabaho sa Russian Post sa mga pista opisyal ng Bagong Taon Trabaho sa post sa mga pista opisyal ng Bagong Taon

Ang Russian Post sa ika-21 siglo ay naging isang unibersal na institusyon na tumutulong hindi lamang upang makatanggap ng mga liham at parsela. Mga pagbabayad sa utility, pensiyon,...

Tass: abbreviation decoding

Tass: abbreviation decoding

Ang terminong ito ay nagmula sa Italian abbreviatura at ang Latin brevis - maikli. Sa mga sinaunang aklat at manuskrito ito ang pangalan para sa pinaikling...

Ang mga template ng sertipiko ay blangko na i-download ang template ng Certificate of Honor para sa pag-print

Ang mga template ng sertipiko ay blangko na i-download ang template ng Certificate of Honor para sa pag-print

Pagbati, mahal na mambabasa! Ngayon sasabihin ko sa iyo kung paano gumawa ng isang liham sa Word. Sa aking trabaho kailangan kong magsulat ng isang malaking bilang ng...
feed-image RSS