• hjem
  •  > 
  • Nyttig
  •  > 
  • Riktig betegnelse for et programdokument er en beskrivelse av programmet. Erfaring med bruk av ESP

Riktig betegnelse for et programdokument er en beskrivelse av programmet. Erfaring med bruk av ESP

Dato for introduksjon fra 01.01.80

Denne standarden etablerer typer programmer og programdokumenter for datamaskiner, komplekser og systemer, uavhengig av deres formål og omfang.

Standarden samsvarer fullt ut med ST SEV 1626-79.

1. TYPER PROGRAMMER

1.1. Programmet (i henhold til GOST 19781-90) kan identifiseres og brukes uavhengig og (eller) som en del av andre programmer.

1.2. Programmer er delt inn i typer vist i tabellen. 1

Tabell 1

1.3. Dokumentasjonen utviklet for programmet kan brukes til implementering og overføring av programmet på lagringsmedier, samt til produksjon av et programvareprodukt.

1.2,1.3.

2. TYPER PROGRAMDOKUMENT

2.1. Programvaredokumenter omfatter dokumenter som inneholder informasjon som er nødvendig for utvikling, produksjon, vedlikehold og drift av programmer.

2.2. Typer programdokumenter og deres innhold er gitt i tabell. 2.

tabell 2

Type programdokumentInnhold i policydokumentet
Spesifikasjon Sammensetning av programmet og dets dokumentasjon
Liste over virksomheter som lagrer originale programdokumenter
Programtekst Opptak av programmet med nødvendige kommentarer
Programbeskrivelse Informasjon om den logiske strukturen og driften av programmet
Krav som skal verifiseres ved testing av programmet, samt prosedyre og metoder for deres kontroll
Teknisk oppgave Formål og omfang av programmet, tekniske, gjennomførbarhet og spesielle krav til programmet, nødvendige stadier og vilkår for utvikling, typer tester
Forklarende merknad Algoritmediagram, generell beskrivelse av algoritmen og (eller) driften av programmet, samt begrunnelse for vedtatte tekniske og teknisk-økonomiske beslutninger
Driftsdokumenter Informasjon for å sikre funksjon og drift av programmet

(Endret utgave, endringsforslag nr. 1).

2.3. Typer driftsdokumenter og deres innhold er gitt i tabell 3.

Tabell 3

Type driftsdokumentInnhold i driftsdokumentet
Liste over driftsdokumenter for programmet
Skjema Hovedkarakteristika for programmet, fullstendighet og informasjon om driften av programmet
Beskrivelse av søknad Informasjon om formålet med programmet, anvendelsesomfang, metoder som brukes, klasse av problemer som skal løses, restriksjoner for bruk, minimumskonfigurasjon av maskinvare
Informasjon for kontroll, sikring av funksjon og tilpasning av programmet til betingelsene for en spesifikk applikasjon
Programmeringsveiledning Informasjon for bruk av programmet
Brukerhåndbok Informasjon for å sikre prosedyren for kommunikasjon mellom operatør og datasystem under programkjøring
Språkbeskrivelse Beskrivelse av språkets syntaks og semantikk
Informasjon for bruk av test- og diagnoseprogrammer ved service på teknisk utstyr

(Endret utgave, endringsforslag nr. 1).

2.4. Avhengig av implementeringsmetoden og applikasjonens art, er programdokumenter delt inn i original, duplikat og kopi (GOST 2.102-68), beregnet for utvikling, vedlikehold og drift av programmet.

2.5. Typer programdokumenter utviklet på ulike stadier og deres koder er gitt i klikktabellen. 4.

Tabell 4

DokumenttypekodeDokumenttypeUtviklingsstadier
Foreløpige designTeknisk prosjektArbeidsutkast
komponentkompleks
- Spesifikasjon - -
05 Liste over originale holdere - - -
12 Programtekst - -
13 Programbeskrivelse - -
20 Liste over driftsdokumenter - -
30 Skjema - -
31 Beskrivelse av søknad - -
32 Systemprogrammeringsveiledning - -
33 Programmeringsveiledning - -
34 Brukerhåndbok - -
35 Språkbeskrivelse - -
46 Vedlikeholdsmanual - -
51 Testprogram og metodikk - -
81 Forklarende merknad - -
90-99 Andre dokumenter

Legende:
- dokumentet er obligatorisk;
- dokumentet er obligatorisk for komponenter som har uavhengig bruk;
- behovet for å utarbeide et dokument bestemmes på utviklingsstadiet og godkjenningen av de tekniske spesifikasjonene;
- - dokumentet er ikke utarbeidet.

2.2-2.5. (Endret utgave, endringsforslag nr. 1).

2.6. Det er tillatt å kombinere visse typer driftsdokumenter (med unntak av listen over driftsdokumenter og skjemaet). Behovet for å kombinere disse dokumentene er angitt i de tekniske spesifikasjonene. Det sammenslåtte dokumentet tildeles navn og betegnelse på ett av de sammenslåtte dokumentene.

Sammenslåtte dokumenter skal spesifisere informasjonen som skal inkluderes i hvert dokument som slås sammen.

2.7. På utviklingsstadiet og godkjenningen av de tekniske spesifikasjonene bestemmes behovet for å utarbeide tekniske spesifikasjoner som inneholder krav til produksjon, kontroll og aksept av programmet.

Tekniske spesifikasjoner utvikles på "Detaljert design"-stadiet.

2.8. Behovet for å utarbeide tekniske spesifikasjoner for komponenter som ikke er beregnet for selvstendig bruk, og komplekser som inngår i andre komplekser, avgjøres etter avtale med kunden.

(Innført i tillegg, endringsforslag nr. 1).

Nyutgivelse (november 1987) med endring nr. 1, godkjent i juni 1981 (IUS 9-81)

I rapporten min stoler jeg på:

  • artikkel "Standardisering innen programvare" av V.V Vasyutkovich - leder av avdelingen og S.S. Samotokhin - seniorforsker. All-Russian Research Institute of Standards of the State Standard of the Russian Federation;
  • artikkel "Korrelasjon og bruk av standarder for organisering av livssykluser av systemer" av E.Z.
  • tekster av GOST og andre standarder.

1. Grunnleggende problemstillinger innen programvareutvikling

Når en programmerer-utvikler mottar en programmeringsoppgave i en eller annen form, står han, prosjektlederen og hele prosjektteamet overfor følgende spørsmål:

  • hva bør gjøres i tillegg til selve programmet?
  • hva og hvordan skal dokumenteres?
  • hva skal man formidle til brukerne, og hva? eskortetjeneste?
  • hvordan håndtere hele denne prosessen?
  • Hva bør inkluderes i selve programmeringsoppgaven?

I tillegg til de nevnte problemene, er det andre.

Svarte statlige standarder for programvaredokumentasjon en gang på disse og en rekke andre spørsmål? sett med standarder for den 19. serien av GOST ESPD. Men selv da hadde programmerere mange klager på disse standardene. Noe måtte dupliseres i dokumentasjonen mange ganger (som det virket - uberettiget), og mye ble ikke sørget for, som for eksempel å gjenspeile detaljene ved å dokumentere programmer som arbeider med en integrert database.

Foreløpig er spørsmålet om å ha et system som regulerer dokumentasjonen av programvare fortsatt relevant.

2. Generelle kjennetegn ved tilstanden

Grunnlaget for det nasjonale regelverket innen programvaredokumentasjon er et sett med standarder for Unified System of Program Documentation (USPD). Den største og største delen av ESPD-komplekset ble utviklet på 70- og 80-tallet. Nå er dette komplekset et system med mellomstatlige standarder for CIS-landene (GOST), som opererer på den russiske føderasjonens territorium på grunnlag av en mellomstatlig avtale om standardisering.

ESPD-standarder dekker hovedsakelig den delen av dokumentasjonen som lages i prosessen med programvareutvikling, og er for det meste assosiert med å dokumentere programvarens funksjonelle egenskaper. Det skal bemerkes at ESPD-standardene (GOST 19) er av rådgivende natur. Dette gjelder imidlertid også alle andre standarder innen PS (GOST 34, International Standard ISO/IEC, etc.). Faktum er at, i samsvar med loven til den russiske føderasjonen "Om standardisering", blir disse standardene obligatoriske på kontraktsbasis - det vil si når de er referert til i kontrakten for utvikling (leveranse) av programvaren.

Når vi snakker om tilstanden til ESPD som helhet, kan det sies at de fleste av ESPD-standardene er moralsk utdaterte.

Blant de viktigste ulempene ESPD kan tilskrives:

  • orientering mot en enkelt "kaskade" modell av livssyklusen (LC) til en transformatorstasjon;
  • mangel på klare anbefalinger for å dokumentere kvalitetsegenskapene til programvaren;
  • mangel på systemisk kobling med andre eksisterende innenlandske standardsystemer for livssyklus- og produktdokumentasjon generelt, for eksempel ESKD;
  • uklar tilnærming til å dokumentere PS som et salgbart produkt;
  • mangel på anbefalinger for egendokumentasjon av programvaren, for eksempel i form av skjermmenyer og midler for operasjonell assistanse til brukeren ("hjelp");
  • mangel på anbefalinger om sammensetning, innhold og utforming av potensielle dokumenter på PS, i samsvar med anbefalingene fra internasjonale og regionale standarder.

Så ESPD trenger en fullstendig revisjon basert på ISO/IEC 12207-95-standarden for programvarelivssyklusprosesser (denne standarden vil bli diskutert mer detaljert senere).

Det må sies at, sammen med ESPD-komplekset, inkluderer det offisielle regelverket til Den russiske føderasjonen innen dokumentasjon av PS og relaterte områder en rekke lovende standarder (nasjonale, mellomstatlige og internasjonale nivåer).

Internasjonal standard ISO/IEC 12207: 1995-08-01 for å organisere livssyklusen til programvareprodukter - en tilsynelatende veldig vag, men ganske ny og noe "moteriktig" standard.

Komplekse standarder GOST 34 for opprettelse og utvikling av automatiserte systemer (AS) - generalisert, men oppfattet som svært streng i strukturen av livssyklusen og designdokumentasjonen. Men disse standardene anses av mange for å være byråkratiske til det skadelige og konservative til det punktet at de er utdaterte. I hvilken grad dette er sant, og i hvilken grad GOST 34 forblir nyttig, er nyttig å forstå.

I sin artikkel dveler E.Z Zinder i detalj ved metodikken Oracle CDM(Custom Development Method) for utvikling av skreddersydde - spesifikt materiale, detaljert til nivået av designdokumentblank, designet for direkte bruk i AS-prosjekter basert på Oracle-verktøy.

2.1. Kort introduksjon til ESPD-standarder

Men før du reviderer hele komplekset, kan mange ESPD-standarder med fordel brukes i praksisen med å dokumentere programvare. Denne stillingen er basert på følgende:

  • ESPD-standarder introduserer et element av bestilling i prosessen med å dokumentere programvaren;
  • Sammensetningen av programdokumenter gitt av ESPD-standardene er ikke i det hele tatt så "stiv" som noen kanskje tror: standardene tillater flere typer å legges til settet med dokumentasjon for programvaren
  • ESPD-standarder gjør det også mulig å fleksibelt endre struktur og innhold i etablerte typer PD basert på kunde- og brukerkrav.

Samtidig kan stilen for anvendelse av standarder samsvare med den moderne generelle stilen for å tilpasse standarder til prosjektets spesifikasjoner: kunden og prosjektlederen velger et undersett av standarder og PD som er passende for prosjektet, supplerer valgt PD med de nødvendige seksjonene og ekskluder unødvendige, knytte opprettelsen av disse dokumentene til livssyklusordningen som brukes i prosjektet.

ESPD-standarder (som andre GOST-er) er delt inn i grupper vist i tabellen:

Utpekingen av ESPD-standarden er basert på klassifiseringskriteriene:

Betegnelsen på ESPD-standarden må bestå av:

  • nummer 19 (tildelt klassen av ESPD-standarder);
  • ett siffer (etter prikken) som indikerer koden til klassifiseringsgruppen av standarder spesifisert i tabellen;
  • et tosifret tall (etter en bindestrek) som indikerer registreringsåret for standarden.

Liste over ESPD-dokumenter

  1. GOST 19.001-77 ESPD. Generelle bestemmelser.
  2. GOST 19.101-77 ESPD. Typer programmer og programdokumenter.
  3. GOST 19.102-77 ESPD. Utviklingsstadier.
  4. GOST 19.103-77 ESPD. Utpeking av programmer og programdokumenter.
  5. GOST 19.104-78 ESPD. Grunnleggende inskripsjoner.
  6. GOST 19.105-78 ESPD. Generelle krav til programdokumenter.
  7. GOST 19.106-78 ESPD. Krav til trykte programdokumenter.
  8. GOST 19.201-78 ESPD. Teknisk oppgave. Krav til innhold og design.
  9. GOST 19.202-78 ESPD. Spesifikasjon. Krav til innhold og design.
  10. GOST 19.301-79 ESPD. Testprosedyre og metodikk.
  11. GOST 19.401-78 ESPD. Programtekst. Krav til innhold og design.
  12. GOST 19.402-78 ESPD. Programbeskrivelse.
  13. GOST 19.404-79 ESPD. Forklarende merknad. Krav til innhold og design.
  14. GOST 19.501-78 ESPD. Skjema. Krav til innhold og design.
  15. GOST 19.502-78 ESPD. Beskrivelse av søknad. Krav til innhold og design.
  16. GOST 19.503-79 ESPD. Systemprogrammeringsveiledning. Krav til innhold og design.
  17. GOST 19.504-79 ESPD. Programmeringsveiledning.
  18. GOST 19.505-79 ESPD. Brukerhåndbok.
  19. GOST 19.506-79 ESPD. Beskrivelse av språket.
  20. GOST 19.508-79 ESPD. Vedlikeholdsmanual. Krav til innhold og design.
  21. GOST 19.604-78 ESPD. Regler for å gjøre endringer i programdokumenter utført på trykk.
  22. GOST 19.701-90 ESPD. Ordninger av algoritmer, programmer, data og systemer. Konvensjoner og utførelsesregler.
  23. GOST 19.781-90. Programvare for informasjonsbehandlingssystemer.

Begreper og definisjoner

Av alle ESPD-standardene vil vi kun fokusere på de som kan brukes oftere i praksis.

Først vil vi indikere en standard som kan brukes når du oppretter programmeringsoppgaver.

GOST (ST SEV) 19.201-78 (1626-79). ESPD. Teknisk oppgave. Krav til innhold og design. (Gjenutgitt i november 1987 med revisjon 1).

Den tekniske spesifikasjonen (TOR) inneholder et sett med krav til programvaren og kan brukes som et kriterium for å sjekke og akseptere det utviklede programmet. Derfor, ganske fullstendig kompilert (med tanke på muligheten for å introdusere flere seksjoner) og akseptert av kunden og utvikleren, er den tekniske spesifikasjonen et av de grunnleggende dokumentene i PS-prosjektet.

Referansen må inneholde følgende avsnitt:

  • introduksjon;
  • årsaker til utvikling;
  • formålet med utvikling;
  • krav til et program eller programvareprodukt;
  • krav til programvaredokumentasjon;
  • tekniske og økonomiske indikatorer;
  • stadier og stadier av utvikling;
  • kontroll og aksept prosedyre;
  • Applikasjoner kan inkluderes i de tekniske spesifikasjonene.

Avhengig av egenskapene til programmet eller programvareproduktet, er det mulig å avklare innholdet i seksjoner, introdusere nye seksjoner eller kombinere individuelle.

Neste standard
GOST (ST SEV) 19.101-77 (1626-79). ESPD. Programtyper og programdokumenter (Gjenutgitt i november 1987 med endring 1).
Etablerer typer programmer og programdokumenter for datamaskiner, komplekser og systemer, uavhengig av formål og omfang.

Typer programmer

Typer programdokumenter

Type programdokument
Spesifikasjon Sammensetning av programmet og dets dokumentasjon
Liste over virksomheter som lagrer originale programdokumenter
Programtekst Opptak av programmet med nødvendige kommentarer
Programbeskrivelse Informasjon om den logiske strukturen og driften av programmet
Krav som skal verifiseres ved testing av programmet, samt prosedyre og metoder for deres kontroll
Teknisk oppgave Formål og omfang av programmet, tekniske, gjennomførbarhet og spesielle krav til programmet, nødvendige stadier og vilkår for utvikling, typer tester
Forklarende merknad Algoritmediagram, generell beskrivelse av algoritmen og (eller) driften av programmet, samt begrunnelse for vedtatte tekniske og teknisk-økonomiske beslutninger
Driftsdokumenter Informasjon for å sikre funksjon og drift av programmet

Typer driftsdokumenter

Type driftsdokument
Liste over driftsdokumenter for programmet
Skjema Hovedkarakteristika for programmet, fullstendighet og informasjon om driften av programmet
Beskrivelse av søknad Informasjon om formålet med programmet, anvendelsesomfang, metoder som brukes, klasse av problemer som skal løses, restriksjoner for bruk, minimumskonfigurasjon av maskinvare
Informasjon for kontroll, sikring av funksjon og tilpasning av programmet til betingelsene for en spesifikk applikasjon
Programmeringsveiledning Informasjon for bruk av programmet
Brukerhåndbok Informasjon for å sikre prosedyren for kommunikasjon mellom operatør og datasystem under programkjøring
Språkbeskrivelse Beskrivelse av språkets syntaks og semantikk
Informasjon for bruk av test- og diagnoseprogrammer ved service på teknisk utstyr

Avhengig av implementeringsmetoden og applikasjonens art, er programdokumenter delt inn i original, duplikat og kopi (GOST 2.102-68), beregnet på utvikling, vedlikehold og drift av programmet.

Typer programdokumenter utviklet på ulike stadier og deres koder

Dokumenttypekode Dokumenttype Utviklingsstadier
Foreløpige design Teknisk prosjekt Arbeidsutkast
komponent kompleks
- Spesifikasjon - - ! +
05 Liste over originale holdere - - - ?
12 Programtekst - - + ?
13 Programbeskrivelse - - ? ?
20 Liste over driftsdokumenter - - ? ?
30 Skjema - - ? ?
31 Beskrivelse av søknad - - ? ?
32 Systemprogrammeringsveiledning - - ? ?
33 Programmeringsveiledning - - ? ?
34 Brukerhåndbok - - ? ?
35 Språkbeskrivelse - - ? ?
46 Vedlikeholdsmanual - - ? ?
51 Testprogram og metodikk - - ? ?
81 Forklarende merknad ? ? - -
90-99 Andre dokumenter ? ? ? ?

Det er tillatt å kombinere visse typer driftsdokumenter (med unntak av listen over driftsdokumenter og skjemaet). Behovet for å kombinere disse dokumentene er angitt i de tekniske spesifikasjonene. Det sammenslåtte dokumentet tildeles navn og betegnelse på ett av de sammenslåtte dokumentene. Sammenslåtte dokumenter skal spesifisere informasjonen som skal inkluderes i hvert dokument som slås sammen.

GOST 19.102-77. ESPD. Utviklingsstadier.

Etablerer utviklingsstadiene av programmer og programdokumentasjon for datamaskiner, komplekser og systemer, uavhengig av deres formål og anvendelsesområde

Utviklingsstadier, stadier og innhold i arbeidet

Utviklingsstadier

Stadier av arbeidet
Teknisk oppgave Begrunnelse for behovet for å utvikle programmet Formulering av problemet.
Innsamling av kildemateriale.
Utvelgelse og begrunnelse av kriterier for effektivitet og kvalitet på det utviklede programmet.
Begrunnelse for behovet for forskningsarbeid.
Forskningsarbeid Bestemme strukturen til inn- og utdata.
Foreløpig valg av problemløsningsmetoder.
Begrunnelse for gjennomførbarheten av å bruke tidligere utviklede programmer.
Fastsettelse av krav til tekniske midler.
Begrunnelse for den grunnleggende muligheten for å løse problemet.
Utvikling og godkjenning av tekniske spesifikasjoner Fastsettelse av programkrav.
Utvikling av mulighetsstudie for utvikling av programmet.
Fastsettelse av stadier, stadier og tidspunkt for utviklingen av programmet og dokumentasjon for det.
Valg av programmeringsspråk.
Fastsettelse av behovet for forskningsarbeid i påfølgende stadier.
Koordinering og godkjenning av tekniske spesifikasjoner.
Foreløpige design Utvikling av et foreløpig design Foreløpig utvikling av strukturen til inn- og utdata.
Avklaring av metoder for å løse problemet.
Utvikling av en generell beskrivelse av algoritmen for å løse problemet.
Utvikling av mulighetsstudie.
Godkjenning av forprosjekt
Koordinering og godkjenning av forprosjektering
Teknisk prosjekt Teknisk prosjektutvikling Klargjøring av strukturen til inn- og utdata.
Utvikling av en algoritme for å løse problemet.
Bestemme presentasjonsform for inn- og utdata.
Definisjon av semantikk og syntaks av språk.
Utvikling av programstrukturen.
Endelig fastsettelse av maskinvarekonfigurasjonen.
Godkjenning av teknisk design Utvikling av handlingsplan for utvikling og gjennomføring av programmer.
Utvikling av et forklarende notat.
Koordinering og godkjenning av teknisk prosjektering.
Arbeidsutkast Programutvikling Programmering og feilsøking
Utvikling av programvaredokumentasjon Utvikling av programdokumenter i samsvar med kravene i GOST 19.101-77.
Programtesting Utvikling, koordinering og godkjenning av testprogram og metodikk.
Gjennomføring av foreløpige statlige, interdepartementale, aksept og andre typer tester.
Retting av program og programdokumentasjon basert på testresultater.
Gjennomføring Utarbeidelse og overføring av programmet Utarbeidelse og overføring av programmer og programvaredokumentasjon for vedlikehold og (eller) produksjon.
Registrering og godkjenning av handlingen med å overføre programmet for vedlikehold og (eller) produksjon.
Overføring av programmet til fondet for algoritmer og programmer.

Merknader:

  1. Det er tillatt å utelukke det andre trinnet i utviklingen, og i teknisk begrunnede tilfeller - det andre og tredje trinnet. Behovet for disse trinnene er angitt i de tekniske spesifikasjonene.
  2. Det er tillatt å kombinere, ekskludere arbeidsstadier og (eller) deres innhold, samt innføre andre arbeidsstadier etter avtale med kunden.

GOST 19.103-77 ESPD. Utpeking av programmer og programdokumenter

Utviklerlandskoden og utbyggerorganisasjonskoden tildeles på foreskrevet måte.

  • Et registreringsnummer tildeles i stigende rekkefølge, fra 00001 til 99999, for hver utviklingsorganisasjon.
  • Programpublikasjonsnummer eller revisjonsnummer. nummeret på et dokument av denne typen, nummeret på dokumentdelen tildeles i stigende rekkefølge fra 01 til 99. (Hvis dokumentet består av én del, er ikke bindestreken og serienummeret til delen angitt).
  • Revisjonsnummeret til spesifikasjonen og listen over driftsdokumenter for programmet må samsvare med publiseringsnummeret til samme program.

GOST 19.105-78 ESPD. Generelle krav til programdokumenter

Denne standarden fastsetter generelle krav for utførelse av programdokumenter for datamaskiner, komplekser og systemer, uavhengig av deres formål og anvendelsesområde og gitt av standardene til Unified System of Program Documentation (USPD) for enhver metode for å utføre dokumenter på ulike databærere.

Programdokumentet kan presenteres på ulike typer lagringsmedier og består av følgende konvensjonelle deler:
tittel;
informativ;
grunnleggende.

Reglene for utførelse av et dokument og dets deler på hver databærer er fastsatt av ESPD-standardene for reglene for utførelse av dokumenter på de tilsvarende databærerne.

GOST 19.106-78 ESPD. Krav til trykte programdokumenter

Programdokumenter er utarbeidet av:

  • på ark i A4-format (GOST 2.301-68) når du forbereder et dokument ved å skrive eller håndskrift;
  • Kan skrives ut på ark i A3-størrelse;
  • med maskinmetoden for dokumentutførelse er avvik i størrelsen på arkene som tilsvarer A4- og A3-formatene tillatt, bestemt av egenskapene til de tekniske midlene som brukes; på ark med A4- og A3-format, gitt av utdataegenskapene til datautdataenheter, når du produserer et dokument med maskin;
  • på ark med typografiske formater når du produserer et dokument ved hjelp av en typografisk metode.

Materialene til programdokumentet er ordnet i følgende rekkefølge:

Titteldel:

  • godkjenningsark (ikke inkludert i det totale antallet ark i dokumentet);
  • tittelside (første side av dokumentet);
informasjonsdel:
  • merknad;
  • innholdsfortegnelse;
hoveddel:
  • tekst i dokumentet (med bilder, tabeller osv.)
  • liste over begreper og deres definisjoner;
  • liste over forkortelser;
  • applikasjoner;
  • emneindeks;
  • liste over referansedokumenter;
endre loggingsdel:
  • endre registreringsskjema.

En liste over begreper og deres definisjoner, en liste over forkortelser, vedlegg, en emneindeks, en liste over referansedokumenter er gitt om nødvendig.

Følgende standard er fokusert på å dokumentere det resulterende utviklingsproduktet:

GOST 19.402-78 ESPD. Programbeskrivelse

Sammensetningen av dokumentet "Programbeskrivelse" i innholdet kan suppleres med seksjoner og avsnitt hentet fra standardene for andre beskrivende dokumenter og manualer: GOST 19.404-79 ESPD. Forklarende notat, GOST 19.502-78 ESPD. Beskrivelse av søknaden, GOST 19.503-79 ESPD. Systemprogrammeringsveiledning, GOST 19.504-79 ESPD. Programmererveiledning, GOST 19.505-79 ESPD. Brukerhåndbok.

Det er også en gruppe standarder som definerer kravene til opptak av hele settet med programmer og PD som er utarbeidet for overføring av programvare. De genererer konsise regnskapsdokumenter og kan være nyttige for å effektivisere hele administrasjonen av programmer og PD (tross alt, veldig ofte trenger du bare å gjenopprette grunnleggende orden!). Det er også standarder som definerer reglene for vedlikehold av dokumenter i "husholdningen" til PS.

Vi må også fremheve

GOST 19.301-79 ESPD. Testprogram og metodikk, som (i tilpasset form) kan brukes til å utvikle plandokumenter og gjennomføre testarbeid for å vurdere beredskap og kvalitet på nettstasjonen.

Til slutt den siste standarden i henhold til vedtaksåret.

GOST 19.701-90 ESPD. Ordninger av algoritmer, programmer, data og systemer. Konvensjonelle grafiske betegnelser og utførelsesregler.

Den etablerer regler for utførelse av diagrammer som brukes til å representere ulike typer databehandlingsproblemer og midler for å løse dem, og er fullstendig i samsvar med ISO 5807:1985-standarden.

Sammen med ESPD er ytterligere to standarder i kraft på mellomstatlig nivå, også relatert til å dokumentere PS og vedtatt for ikke så lenge siden som det meste av GOST ESPD.

GOST 19781-90 Programvare for informasjonsbehandlingssystemer. Begreper og definisjoner. Utviklet for å erstatte GOST 19.781-83 og GOST 19.004-80 og etablerer begreper og definisjoner innen programvare (programvare) av databehandlingssystemer (SOD), brukt i alle typer dokumentasjon og litteratur inkludert i omfanget av standardiseringsarbeid eller bruk resultatene av dette arbeidet.

GOST 28388-89 Informasjonsbehandlingssystemer. Dokumenter på magnetiske lagringsmedier. Rekkefølge for utførelse og håndtering. Gjelder ikke bare programvare, men også design, teknologiske og andre designdokumenter utført på magnetiske medier.

2.2. Standarder for GOST 34-komplekset

GOST 34 ble unnfanget på slutten av 80-tallet som et omfattende sett med sammenkoblede tverrsektorielle dokumenter. Motivene og de resulterende resultatene er beskrevet nedenfor i "Funksjoner" av GOST 34. Objektene for standardisering er høyttalere av forskjellige (hvilken som helst!) typer og alle typer av deres komponenter, og ikke bare programvare og databaser.

Komplekset er designet for samhandling mellom kunden og utvikleren. I likhet med ISO12207 er det gitt at kunden kan utvikle høyttalere for seg selv (hvis han oppretter en spesialisert avdeling for dette). Ordlyden til GOST 34 er imidlertid ikke fokusert på en så eksplisitt og, i en viss forstand, symmetrisk refleksjon av handlingene til begge parter som ISO12207. Siden GOST 34 hovedsakelig tar hensyn til innholdet i prosjektdokumenter, gjøres distribusjonen av handlinger mellom partene vanligvis basert på dette innholdet.

Av alle eksisterende og ikke implementerte grupper av dokumenter vil vi kun basere oss på Gruppe 0 "Generelle bestemmelser" og Gruppe 6 "Opprettelse, drift og utvikling av AS". De mest populære standardene kan betraktes som GOST 34.601-90 (Stages for å lage et AS), GOST 34.602-89 (TK for å lage et AS) og retningslinjer RD 50-34.698-90 (Krav til innholdet i dokumenter). Standardene sørger for stadier og stadier av arbeidet for å opprette et AS, men gir ikke eksplisitt ende-til-ende prosesser.

For det generelle tilfellet av AS-utvikling er stadiene og stadiene til GOST 34 gitt i tabellen:

1. FT - Utforming av krav til høyttalere. 1.1. Inspeksjon av anlegget og begrunnelse for behovet for å opprette et kjernekraftverk;
1.2. Dannelse av brukerkrav til høyttalere;
1.3. Utarbeidelse av en rapport om utført arbeid og en applikasjon for utvikling av et AS (taktiske og tekniske spesifikasjoner);
2. RK - Utvikling av AS-konseptet. 2.1. Studie av objektet;
2.2. Utføre nødvendig forskningsarbeid;
2.3. Utvikling av muligheter for høyttalerkonseptet som møter brukerkrav
2.4. Utarbeide rapport om utført arbeid
3. TK - Teknisk opprettelse av AS. 3.1. Utvikling og godkjenning av tekniske spesifikasjoner for oppgaven.
4. EP - Utkast til design. 4.1. Utvikling av foreløpige designløsninger for systemet og dets deler;
4.2. Utvikling av dokumentasjon for høyttalersystemet og dets deler.
5. TP - Teknisk design. 5.1. Utvikling av designløsninger for systemet og dets deler;
5.2. Utvikling av dokumentasjon for NPP og dets deler;
5.3. Utvikling og utførelse av dokumentasjon for levering av produkter for å fullføre NPP og/eller tekniske krav (tekniske spesifikasjoner) for deres utvikling;
5.4. Utvikling av prosjekteringsoppgaver i tilstøtende deler av automasjonsobjektprosjektet.
6. RD - Arbeidsdokumentasjon. 6.1. Utvikling av arbeidsdokumentasjon for systemet og dets deler;
6.2. Utvikling eller tilpasning av programmer.
7. VD - Settes i drift. 7.1. Klargjøring av automatiseringsanlegget for å sette anlegget i drift;
7.2. Opplæring av personell;
7.3. Komplett sett med høyttalere med medfølgende produkter (programvare og maskinvare, programvare og maskinvaresystemer, informasjonsprodukter);
7.4. Bygge- og installasjonsarbeid;
7.5. igangkjøring arbeid;
7.6. Gjennomføring av foreløpige tester;
7.7. Gjennomføring av prøvedrift;
7.8. Gjennomføring av akseptprøver.
8. Sp - AC-støtte. 8.1. Utføre arbeid i henhold til garantiforpliktelser;
8.2. Service etter garanti.

Innholdet i dokumenter utviklet på hvert trinn er beskrevet. Dette bestemmer de potensielle mulighetene for å identifisere ende-til-ende arbeid utført parallelt eller sekvensielt på det materielle nivået (det vil si i hovedsak prosesser) og deres konstituerende oppgaver. Denne teknikken kan brukes når du konstruerer en profil av prosjektlivssyklusstandarder, inkludert avtalte delsett av GOST 34 og ISO12207 standarder.

Hovedmotivet: å løse problemet med "Babels tårn".

På 80-tallet oppsto det en situasjon der ulike bransjer og aktivitetsområder brukte dårlig koordinert eller inkonsekvent NTD - "normativ og teknisk dokumentasjon". Dette gjorde det vanskelig å integrere systemer og sikre at de fungerer effektivt sammen. Det var ulike komplekser og standardsystemer som satte krav til ulike typer AS.

Praksisen med å anvende standarder har vist at de i hovedsak (men ikke i henhold til strenge definisjoner) anvender et enhetlig system av konsepter, det er mange vanlige objekter for standardisering, men kravene til standardene er ikke i samsvar med hverandre, det er forskjeller i arbeidets sammensetning og innhold, forskjeller i betegnelse, sammensetning, innhold og utførelse av dokumenter mv.

Selvfølgelig reflekterte denne situasjonen delvis det naturlige mangfoldet i forutsetningene for å utvikle AS, målene til utviklerne og tilnærmingene og teknikkene som ble brukt.

Under disse forholdene var det mulig å analysere et slikt mangfold og deretter fortsette for eksempel på en av to stort sett motsatte måter:

  1. Utvikle ett generalisert konseptuelt og terminologisk system, et generelt utviklingsskjema, et felles sett med dokumenter med deres innhold og definere dem som obligatoriske for alle AS;
  2. Definer også ett generelt konseptuelt og terminologisk system, et generalisert sett med systemkrav, et sett med kvalitetskriterier, men gi maksimal frihet til å velge et utviklingsskjema, sammensetningen av dokumenter og andre aspekter, og pålegge bare et minimum av obligatoriske krav som vil tillate :
    • bestemme kvalitetsnivået på resultatet;
    • velge de spesifikke metodene (med deres livssyklusmodeller, sett med dokumenter osv.) som er best egnet for utviklingsforholdene og samsvarer med informasjonsteknologiene som brukes;
    • arbeid derfor med minimale restriksjoner på de effektive handlingene til høyttalerdesigneren.

Utviklerne av settet med standarder 34 valgte en metode nær den første av de som er angitt ovenfor, det vil si at de tok en vei nærmere ordningene med spesifikke metoder enn standarder som ISO12207. På grunn av det generelle begrepsgrunnlaget, forblir standardene gjeldende i et svært bredt spekter av tilfeller.

Graden av tilpasningsevne er formelt bestemt av evnene:

  • utelate det foreløpige designstadiet og kombinere trinnene "Teknisk design" og "Detaljert dokumentasjon";
  • utelate trinn, kombinere og utelate de fleste dokumenter og deres seksjoner;
  • angi flere dokumenter, deler av dokumenter og arbeid;
  • dynamisk skape den såkalte. ChTZ - private tekniske spesifikasjoner - det er ganske fleksibelt å danne livssyklusen til AS; Som regel brukes denne teknikken på nivå med store enheter (undersystemer, komplekser), av hensyn til hvilke det anses berettiget å opprette en CTZ, men det er ingen vesentlige grunner til å sterkt begrense denne metoden for livssyklusstyring.

Stadiene og milepælene utført av organisasjoner som deltar i etableringen av kjernekraftverk er etablert i kontrakter og tekniske spesifikasjoner, som er nær ISO-tilnærmingen.

Innføringen av en enhetlig, ganske kvalitativt definert terminologi, tilstedeværelsen av en ganske rimelig klassifisering av verk, dokumenter, typer støtte, etc. er absolutt nyttig. GOST 34 bidrar til en mer komplett og høykvalitets sammenføyning av virkelig forskjellige systemer, noe som er spesielt viktig i forhold når flere og mer komplekse integrerte systemer utvikles, for eksempel som CAD-CAM, som inkluderer et prosesskontrollsystem, et kontrollsystem, en CAD-designer, en CAD-teknolog, ASNI og andre systemer.

Det er definert flere viktige bestemmelser som gjenspeiler funksjonene til AS som et standardiseringsobjekt, for eksempel: "Generelt består AS av programvare og maskinvare (PTK), programvare og metodologiske (PMK) komplekser og individuelle komponenter av organisatoriske, teknisk, programvare og informasjonsstøtte."

Separasjonen av konseptene PTC og AS nedfelte prinsippet om at AS ikke er en "IS med en database", men:

  • "et organisatorisk og teknisk system som sikrer utvikling av løsninger basert på automatisering av informasjonsprosesser innen ulike aktivitetsfelt (ledelse, design, produksjon, etc.) eller deres kombinasjoner" (i henhold til RD 50-680-88), som er spesielt relevant i forretningsaspekter -reengineering;
  • "et system bestående av personell og et sett med automatiseringsverktøy for deres aktiviteter, implementering av informasjonsteknologi for å utføre etablerte funksjoner" (i henhold til GOST 34.003-90).

Disse definisjonene indikerer at AS først og fremst er personell som tar beslutninger og utfører andre ledelseshandlinger, støttet av organisatoriske og tekniske midler.

Grad av forpliktelse:

det forrige fullstendige obligatoriske kravet er fraværende, GOST34-materialene har i hovedsak blitt metodisk støtte, oftere for kunder som har i standarden et sett med krav til innholdet i tekniske spesifikasjoner og testing av AS. Samtidig kan nytten av GOST34 øke mange ganger hvis de brukes mer fleksibelt i dannelsen av AS livssyklusprofilen.

Nøkkeldokumentet for samhandling mellom partene er de tekniske spesifikasjonene for opprettelsen av NPP. Den tekniske spesifikasjonen er hovedkildedokumentet for opprettelsen av AS, og den tekniske spesifikasjonen bestemmer de viktigste interaksjonspunktene mellom kunden og utvikleren. I dette tilfellet utvikles de tekniske spesifikasjonene av utviklerorganisasjonen (i henhold til GOST 34.602-89), men kunden utsteder formelt de tekniske spesifikasjonene til utvikleren (i henhold til RD 50-680-88).

2.3. Statlige standarder for den russiske føderasjonen (GOST R)

I den russiske føderasjonen er det en rekke standarder for dokumentering av programvare, utviklet på grunnlag av direkte anvendelse av internasjonale ISO-standarder. Dette? de nyeste standardene på tidspunktet for vedtakelse. Noen av dem er direkte adressert til prosjektledere eller direktører for informasjonstjenester. Samtidig er de urimelig lite kjent blant fagfolk. Her er deres opptreden.

GOST R ISO/IEC 9294-93 Informasjonsteknologi. Programvaredokumentasjonsadministrasjonsveiledning. Standarden samsvarer fullt ut med den internasjonale standarden ISO/IEC TO 9294:1990 og etablerer anbefalinger for effektiv styring av programvaredokumentasjon for ledere som er ansvarlige for opprettelsen av dem. Formålet med standarden er å hjelpe til med å definere en strategi for dokumentering av programvare; valg av dokumentasjonsstandarder; valg av dokumentasjonsprosedyrer; bestemme de nødvendige ressursene; utarbeide dokumentasjonsplaner.

GOST R ISO/IEC 9126-93 Informasjonsteknologi. Evaluering av programvareprodukter. Kvalitetsegenskaper og retningslinjer for deres bruk. Standarden samsvarer fullt ut med den internasjonale standarden ISO/IEC 9126:1991. I sin kontekst forstås en kvalitetsegenskap som "et sett med egenskaper (attributter) til et programvareprodukt som dets kvalitet beskrives og vurderes ved." Standarden definerer seks omfattende egenskaper som, med minimal duplisering, beskriver kvaliteten på programvare (programvare, programvareprodukter): funksjonalitet; pålitelighet; praktisk; effektivitet; akkompagnement; mobilitet. Disse egenskapene danner grunnlaget for videre avklaring og beskrivelse av kvaliteten på programvaren.

GOST R ISO 9127-94 Informasjonsbehandlingssystemer. Brukerdokumentasjon og pakkeinformasjon for forbrukerprogramvarepakker. Standarden samsvarer fullt ut med den internasjonale standarden ISO 9127:1989. For formålene med denne standarden er en forbrukerprogramvarepakke (CPP) definert som "et programvareprodukt designet og solgt for å utføre en spesifikk funksjon og tilhørende dokumentasjon pakket for salg som en enkelt enhet." Brukerdokumentasjon refererer til dokumentasjon som gir sluttbrukeren informasjon om installasjon og drift av programvaren. Informasjon om emballasje refererer til informasjon gjengitt på den ytre emballasjen til PP. Formålet er å gi potensielle kjøpere primærinformasjon om programvaren.

GOST R ISO/IEC 8631-94 Informasjonsteknologi. Programvarekonstruksjoner og symboler for deres representasjon. Beskriver presentasjonen av prosedyrealgoritmer.

2.4. Internasjonal standard ISO/IEC 12207: 1995-08-01

Den første utgaven av ISO12207 ble utarbeidet i 1995 av den felles tekniske komiteen ISO/IEC JTC1 "Information technology, subcommittee SC7, software engineering".

Per definisjon er ISO12207 den grunnleggende standarden for programvarelivssyklusprosesser, fokusert på ulike (hvilken som helst!) typer programvare og typer AS-prosjekter, hvorav programvaren er inkludert som en del. Standarden definerer strategien og den generelle rekkefølgen i opprettelsen og driften av programvare den dekker programvarens livssyklus fra konseptualiseringen av ideer til fullføringen av livssyklusen.

Svært viktige MERKNADER OM STANDARD:

  1. Prosessene som brukes i løpet av programvarens livssyklus må være kompatible med prosessene som brukes under AS-livssyklusen. (Derfor er hensiktsmessigheten av felles bruk av AS og programvarestandarder tydelig.)
  2. Tillegg av unike eller spesifikke prosesser, aktiviteter og oppgaver skal spesifiseres i kontrakten mellom partene. Kontrakt forstås i vid forstand: fra en juridisk formalisert kontrakt til en uformell avtale, kan en avtale defineres av en enkelt part som en oppgave satt til seg selv.
  3. Standarden inneholder i utgangspunktet ikke spesifikke handlingsmetoder, langt mindre forberedte løsninger eller dokumentasjon. Den beskriver arkitekturen til programvarelivssyklusprosesser, men spesifiserer ikke i detalj hvordan de skal implementere eller utføre tjenestene og oppgavene som er inkludert i prosessene, og er ikke ment å foreskrive navnet, formatet eller nøyaktig innhold i den resulterende dokumentasjonen. Beslutninger av denne typen tas av brukeren av standarden.

STANDARDDEFINISJONER:

  1. Et system er kombinasjonen av en eller flere prosesser, maskinvare, programvare, utstyr og mennesker for å muliggjøre tilfredsstillelse av spesifiserte behov eller mål.
  2. Livssyklusmodell- en struktur som inneholder prosesser, handlinger og oppgaver som utføres under utvikling, drift og vedlikehold av et programvareprodukt gjennom hele systemets levetid, fra fastsettelse av kravene til slutten av bruken.
    Mange prosesser og oppgaver er utformet slik at de kan tilpasses i henhold til programvareprosjekter. Tilpasningsprosessen er prosessen med å eliminere prosesser, aktiviteter og oppgaver som ikke er aktuelt for et bestemt prosjekt. Grad av tilpasningsevne: maksimal
  3. Kvalifikasjonskrav- et sett med kriterier eller betingelser (kvalifikasjonskrav) som må tilfredsstilles for å kvalifisere et programvareprodukt til å samsvare (tilfredsstille betingelsene) med spesifikasjonene og klar til bruk i målmiljøet.

Standarden foreskriver ikke en spesifikk livssyklusmodell eller programvareutviklingsmetode, men spesifiserer at partene i bruken av standarden er ansvarlige for å velge en livssyklusmodell for et programvareprosjekt, for å tilpasse prosessene og oppgavene til standarden til denne modellen. , for å velge og bruke metoder for programvareutvikling, og for å utføre handlinger og oppgaver som passer for programvareprosjektet.

ISO12207-standarden er like fokusert på å organisere handlingene til hver av de to partene: leverandøren (utvikleren) og kjøperen (brukeren); kan brukes likt når begge parter er fra samme organisasjon.

Hver livssyklusprosess er delt inn i et sett med handlinger, hver handling i et sett med oppgaver. En veldig viktig forskjell mellom ISO: hver prosess, handling eller oppgave initieres og utføres av en annen prosess etter behov, og det er ingen forhåndsbestemte sekvenser (selvfølgelig, samtidig som logikken i forbindelsene opprettholdes i henhold til den første informasjonen om oppgavene, etc. ).

ISO12207-standarden beskriver:

  1. 5 hovedprosesser for programvarelivssyklus:
    • Oppkjøpsprosess. Bestemmer handlingene til innkjøpsbedriften som kjøper AS, programvareproduktet eller programvaretjenesten.
    • Leveringsprosess. Definerer handlingene til leverandørselskapet som forsyner kjøperen med et system, programvareprodukt eller programvaretjeneste.
    • Utviklingsprosess. Bestemmer handlingene til utviklingsbedriften, som utvikler prinsippet om å konstruere et programvareprodukt og programvareproduktet.
    • Fungerende prosess. Definerer handlingene til operatørselskapet, som sørger for vedlikehold av systemet (og ikke bare programvare) under driften i brukernes interesse. I motsetning til handlingene som er bestemt av utvikleren i bruksanvisningen (denne aktiviteten til utvikleren er gitt i alle de tre standardene som vurderes), bestemmes handlingene til operatøren for å konsultere brukere, motta tilbakemeldinger osv., som han planlegger selv og tar på seg det tilsvarende ansvaret.
    • Vedlikeholdsprosess. Bestemmer handlingene til vedlikeholdspersonell som sørger for vedlikehold av programvareproduktet, som er administrasjon av modifikasjoner av programvareproduktet, støtte for dets nåværende tilstand og funksjonelle egnethet, inkludert installasjon og fjerning av programvareproduktet på datasystemet.
  2. 8 hjelpeprosesser som støtter implementeringen av en annen prosess, som er en integrert del av hele livssyklusen til et programvareprodukt, og sikrer riktig kvalitet på programvareprosjektet:
    • problemløsning;
    • dokumentasjon;
    • konfigurasjonsstyring;
    • kvalitetssikring, som bruker resultatene av de gjenværende prosessene i kvalitetssikringsgruppen, som inkluderer:
      • Verifikasjonsprosess;
      • Sertifiseringsprosess;
      • Deltakende vurderingsprosess;
      • Revisjonsprosess.
  3. 4 organisatoriske prosesser:
    • Ledelsesprosess;
    • Prosessen for etablering av infrastruktur;
    • Forbedringsprosess;
    • Lære prosess.

De er ledsaget av en spesiell tilpasningsprosess, som definerer hovedhandlingene som er nødvendige for å tilpasse standarden til betingelsene for et spesifikt prosjekt.

Forbedringsprosessen her betyr ikke forbedring av AS eller programvare, men forbedring av prosessene med anskaffelse, utvikling, kvalitetssikring osv. som faktisk utføres i organisasjonen.

Det er ingen stadier, faser, stadier gitt, noe som gir graden av tilpasningsevne beskrevet nedenfor.

Standardens "dynamiske" natur bestemmes av måten prosesser og oppgaver er sekvensert, der en prosess kaller en annen eller deler av den når det er nødvendig.

  • utførelsen av anskaffelsesprosessen når det gjelder å analysere og registrere krav til et system eller programvare kan utløse utførelsen av de tilsvarende oppgavene i utviklingsprosessen;
  • i Leveringsprosessen skal leverandøren administrere underleverandører i henhold til Anskaffelsesprosessen og utføre verifisering og kvalifisering mot de aktuelle prosessene;
  • Vedlikehold kan kreve utvikling av systemet og programvaren, som utføres i henhold til Utviklingsprosessen.

Denne naturen gjør det mulig å implementere enhver livssyklusmodell.

Når du utfører analyse av programvarekrav, er det 11 klasser av kvalitetsegenskaper som brukes senere i kvalitetssikring.

I dette tilfellet må utvikleren etablere og dokumentere som programvarekrav:

  1. Funksjons- og aktiveringsspesifikasjoner, inkludert utførelse, fysiske egenskaper og driftsmiljøforhold som programvareelementet må kjøres under;
  2. Eksterne tilkoblinger (grensesnitt) med programvareenheten;
  3. Krav til kompetanse;
  4. Pålitelighetsspesifikasjoner, inkludert spesifikasjoner knyttet til metoder for drift og vedlikehold, miljøeksponering og sannsynligheten for personskade;
  5. Sikkerhetsspesifikasjoner
  6. Menneskelige faktorers spesifikasjoner for ingeniørpsykologi (ergonomi), inkludert de relatert til manuell kontroll, interaksjon mellom menneske og utstyr, personellbegrensninger og områder som krever konsentrert menneskelig oppmerksomhet som er følsomme for menneskelige feil og læring;
  7. Definere data- og databasekrav;
  8. Installasjons- og akseptkrav for det medfølgende programvareproduktet på drifts- og vedlikeholdsstedene (drift);
  9. Brukerdokumentasjon;
  10. Brukerarbeid og ytelseskrav;
  11. Krav til brukerservice.

    (Det er interessant og viktig at disse og lignende egenskaper samsvarer godt med egenskapene til NPP gitt i GOST 34 for typer systemstøtte.)

Standarden inneholder svært få beskrivelser rettet mot databasedesign. Dette kan anses som berettiget, siden ulike systemer og ulike applikasjonsprogramvarepakker ikke bare kan bruke svært spesifikke typer databaser, men heller ikke bruke

Så, ISO12207 har et sett med prosesser, aktiviteter og oppgaver som dekker det bredeste spekteret av mulige situasjoner med maksimal tilpasningsevne.

Den viser et eksempel på hvordan en velorganisert standard bør bygges, inneholdende et minimum av restriksjoner (prinsippet om at "ingen to prosjekter er like"). Samtidig er det tilrådelig å inkludere detaljerte definisjoner av prosesser, dokumentformer etc. i ulike funksjonelle standarder, avdelingsmessige reguleringsdokumenter eller proprietære metoder som kan eller ikke kan brukes i et bestemt prosjekt.

Av denne grunn er det nyttig å betrakte ISO12207 som den sentrale standarden, hvis bestemmelser tas som det første «kjerne»-settet av bestemmelser i prosessen med å konstruere en profil av livssyklusstandarder for et spesifikt prosjekt. Denne "kjernen" kan definere en programvare- og AS-livssyklusmodell, et kvalitetssikringskonsept og en prosjektledelsesmodell

Utøvere bruker en annen måte: de selv oversetter og bruker i sine prosjekter moderne standarder for organisering av livssyklusen til en transformatorstasjon og deres dokumentasjon. Men denne veien lider i det minste av ulempen at forskjellige oversettelser og tilpasninger av standarder laget av forskjellige utviklere og kunder vil variere i mange detaljer. Disse forskjellene gjelder uunngåelig ikke bare navnene, men også deres materielle definisjoner som er introdusert og brukt i standardene. På denne veien er den konstante fremveksten av forvirring uunngåelig, og dette er direkte i motsetning til målene til ikke bare standarder, men også alle kompetente metodologiske dokumenter.

For tiden har All-Russian Research Institute of Standards utarbeidet forslag for å forbedre og utvikle et sett med standarder for å dokumentere programvare.

referanse informasjon

For å kjøpe dokumentasjonsstandarder anbefaler vi å kontakte følgende organisasjoner:

    IPK "Publiseringsstandarder", Territoriell avdeling for distribusjon av vitenskapelig og teknisk dokumentasjon (butikk "Standarder"), 17961, Moskva, st. Donskaya, 8, tlf. 236-50-34, 237-00-02, faks/tlf. 236-34-48 (angående GOST og GOST R).

programmer for tekniske midler og andre programmer, generelle kjennetegn ved inngangs- og utdatainformasjon, samt krav og betingelser av organisatorisk, teknisk og teknologisk art, etc.).

For eksempel: Programmet betjenes på en personlig datamaskin (PC) av typen IBM PC/AT. For å jobbe i interaktiv modus brukes en skjerm, tastatur og mus. For å støtte grafikkmodus kreves en EGA (VGA)-adapter. Inndata lagres på disketter og/eller harddisker. Programmet kjører under OS...

Vedlegget til beskrivelsen kan inneholde referansemateriale (illustrasjoner, tabeller, grafer, eksempler osv.)

Og ikke glem å angi navnet på oppstartsmodulen, samt en beskrivelse av hele prosedyren for å ringe og laste systemet

For eksempel: Programmet lastes ved å skrive inn navnet på oppstartsmodulen på DOS-kommandolinjen - SBM80N.EXE med en mulig indikasjon på navnet på datafilen.

PROGRAMTEKST (GOST 19.401-78)

Kravene til utforming av programtekst er ganske enkle og naturlige for en kompetent programmerer. Det viktigste å være veiledet etter når du lager dette dokumentet er at programteksten skal være lesbar.

Det er fortsatt obligatorisk å kompilere informasjonsdelen - merknader og innhold.

Hoveddelen av dokumentet bør bestå av tekstene til en eller flere seksjoner, som er gitt navn.

Teksten til hver programfil begynner med en "header", som indikerer:

· programnavn,

· dato for opprettelse av programmet,

· versjonsnummer,

· dato for siste endring.

Kommentarer kreves, samt streng overholdelse av innrykksregler. Husk at selv manglende evne til å lage programvaredokumentasjon kan rettferdiggjøres. Men stygg programtekst – aldri. Henvisninger til at denne teksten er forståelig for forfatteren selv blir ikke tatt på alvor. Det skal ikke være noen skam å gi programtekster til andre å lese.

PROGRAM OG TESTMETODOLOGI (GOST 19.301-79)

Dette dokumentet inneholder en beskrivelse av hva og hvordan som må gjøres for å sikre (og overbevise kunden) om at programmet fungerer som det skal. Faktisk er dette dokumentet avgjørende for aksept

tester. Et godt utformet testprogram og metodikk er nøkkelen til å signere akseptbeviset, d.v.s. tingen du brukte så mye krefter og tid på.

Formelt brukes denne GOST til å utvikle planleggingsdokumenter og utføre testarbeid for å vurdere beredskapen og kvaliteten til programvaresystemet. Dokumentet inneholder beskrivelse av gjenstand og formål med testing, krav til program- og programvaredokumentasjon, midler og prosedyre for testing, samt beskrivelse av testeksempler.

Komponentene i dette dokumentet er enklere og klarere beskrevet i form av eksempler.

Testobjekt

Eksempel: Testobjektet er programmet ..., beregnet på

Formål med testing

Eksempel: Kontrollere påliteligheten til programmet.

Programkrav

Eksempel: Driften av programmet skal ikke føre til feil (fatal forstyrrelse av systemet). Organiseringen av dialogen skal gi beskyttelse mot inntasting av feil data. Programmet skal gi diagnostikk av systemtilstanden og meldinger om eventuelle feil som har oppstått... osv.

Krav til programvaredokumentasjon

Eksempel: Innhold i programvaredokumentasjonen presentert under testing:

· beskrivelse av programmet (GOST 19.402-78);

· testprogram og metodikk (GOST 19.301-79);

· programtekst (GOST 19.401-78).

Testmidler og prosedyre

Eksempel: Programmet fungerer i samsvar med driftsbetingelsene til MS DOS-operativsystemet (versjon ikke lavere enn 3.0) på en PC som IBM PC/AT, så vel som på kompatible. En adapter kreves også for drift.

Test prosedyre:

1. Programmet er lansert....

2. Velg...

3. Trykk...

4. Sekvensielt valgt...

Testtilfeller

Eksempel: For testing foreslås ..., hvis beskrivelser finnes i filene ... Innholdet i testfilene og resultatene av programmet er gitt i vedlegg 1.

Og til slutt, la oss vurdere den siste ESPD-standarden som interesserer oss, som kalles

KRAV TIL TRYKTE PROGRAMVAREDOKUMENT (GOST 19.106-78)

Standarden etablerer regler for utførelse av programdokumenter for datamaskiner, komplekser og systemer, uavhengig av deres formål og anvendelsesområde og gitt av ESPD-standarder.

Generelle Krav. Det er nødvendig å legge inn individuelle ord, formler, symboler (for hånd i en tegneskrift), bokstaver i det latinske og greske alfabetet, samt å tegne diagrammer og tegninger i programdokumenter laget ved maskin-, maskin- og håndskrift, med svart blekk eller blekk.

Skrivefeil og grafiske unøyaktigheter oppdaget under utførelsesprosessen kan korrigeres ved å slette en dårlig utført del av teksten (tegning) og bruke den korrigerte teksten (grafikk) på samme ark med maskinskrift eller svart blekk, avhengig av utførelsesmetoden for teksten. dokument.

Skader på dokumentark, flekker og spor av ufullstendig slettet tekst (grafikk) er ikke tillatt.

Programdokumenter er utarbeidet på A4-ark. Unntatt

· Det er akseptabelt å skrive ut på A3-ark;

· med maskinmetoden for dokumentutførelse er avvik i størrelsen på arkene som tilsvarer A4- og A3-formatene tillatt, bestemt av egenskapene til de tekniske midlene som brukes; på ark med A4- og A3-format, gitt av utdataegenskapene til datautdataenheter, når du produserer et dokument med maskin;

· Når du produserer et dokument ved hjelp av en typografisk metode, er det mulig å bruke ark med typografiske formater.

Materialene til programdokumentet er ordnet i følgende rekkefølge:

· titteldel:

- godkjenningsark (ikke inkludert i det totale antallet ark i dokumentet);

- tittelside (første side av dokumentet);

· informasjonsdel:

Merknad;

- innholdsfortegnelse;

· hoveddel:

- tekst til dokumentet (med bilder, tabeller, etc.);

- liste over begreper og deres definisjoner;

- liste over forkortelser;

Applikasjoner;

- emneindeks;

- liste over referansedokumenter;

· endre loggingsdel:

- endre registreringsskjema.

Konstruksjon av dokumentet. Om nødvendig er det tillatt å dele dokumentet i deler. Inndeling i deler utføres på et nivå som ikke er lavere enn seksjonen. Hver del fylles ut separat, og på slutten av innholdet i den første delen skal navnene på de resterende delene oppgis.

Det er tillatt å inkludere deler av programteksten i dokumentet, formatert i samsvar med reglene for språket programteksten er skrevet på.

Abstraktet legges på en egen side (sider), forsynt med overskriften "ABSTRAKT", nummerert og inkludert i dokumentets innhold.

Teksten til hvert dokument er om nødvendig delt inn i avsnitt, og avsnitt i underavsnitt, uavhengig av om dokumentet er delt inn i deler, seksjoner og underavsnitt eller ikke.

Seksjonsoverskrifter er skrevet med store bokstaver og plassert symmetrisk i forhold til høyre og venstre kant av teksten. Underavsnittsoverskrifter skrives fra avsnittet med små bokstaver (bortsett fra den første store bokstaven). Orddeling av ord i overskrifter er ikke tillatt. Det er ingen punktum på slutten av tittelen. Det anbefales å starte hver seksjon på et nytt ark.

Seksjoner, underavsnitt, avsnitt og underavsnitt skal nummereres med arabiske tall med en prikk. Seksjoner må ha et serienummer (1, 2 osv.)

Dokumenttekst. Teksten i dokumentet bør være kort, klar, og utelukke muligheten for feiltolkning. Begreper og definisjoner må være enhetlige og i samsvar med etablerte standarder, og i deres fravær - generelt akseptert i vitenskapelig og teknisk litteratur, og angis i begrepslisten.

Nødvendige forklaringer til teksten i dokumentet kan gis i fotnoter. En fotnote er angitt med et tall med en parentes plassert på nivå med den øvre kanten av skriften.

Hvis en fotnote refererer til et enkelt ord, plasseres fotnotetegnet rett ved siden av dette ordet, men hvis det refererer til en setning som helhet, så på slutten av setningen. Fotnoteteksten er plassert på slutten av siden og atskilt fra hovedteksten med en 3 cm lang strek tegnet på venstre side av siden.

Illustrasjoner. Illustrasjoner kan finnes i teksten til dokumentet og (eller) i vedlegg. Illustrasjoner, hvis det er mer enn én av dem i et gitt dokument, er nummerert med arabiske tall gjennom hele dokumentet.

I vedlegg er illustrasjoner nummerert innenfor hvert vedlegg i den rekkefølgen som er fastsatt for dokumentets hovedtekst. Lenker til illustrasjoner er gitt etter type: "Fig. 12" eller "(Fig. 12)". Illustrasjoner kan ha en tematisk tittel og bildetekst som forklarer innholdet i illustrasjonen.

Formler. Formler i et dokument, hvis det er mer enn én av dem, er nummerert med arabiske tall. Tallet er plassert på høyre side av siden, i parentes på formelnivå. Innenfor hele dokumentet eller dets deler, hvis dokumentet er delt inn i deler, har formlene kontinuerlig nummerering.

Referanser i teksten til formelens serienummer er gitt i parentes, for eksempel: "i formel (3)". Når du deler et dokument i deler, plasseres delenummeret foran serienummeret til formelen og skilles fra den siste prikken, for eksempel: "i formel (1.4)".

Betydningen av symbolene som er inkludert i formelen må angis rett under formelen. Betydningen av hvert tegn skrives ut på en ny linje i den rekkefølgen de er gitt i formelen. Den første linjen i utskriften må begynne med ordet "hvor", uten kolon etter.

Linker. Henvisninger til standarder og andre dokumenter er tillatt i policydokumenter. Det bør henvises til dokumentet som helhet eller til dets seksjoner (med angivelse av dokumentets betegnelse og navn, nummer og navn på seksjonen eller vedlegget).

Det er tillatt å angi kun betegnelsen på dokumentet og (eller) seksjoner uten å angi navnene deres. Henvisninger til enkelte underavsnitt, avsnitt og illustrasjoner av et annet dokument er ikke tillatt. Lenker i dokumentet til avsnitt, illustrasjoner og individuelle underavsnitt er tillatt.

Notater. Merknader til teksten og tabellene angir kun referanse- og forklarende data. En seddel er ikke nummerert. Så etter ordet "merknad" setter de en punktum. Flere notater skal nummereres i rekkefølge med arabiske tall med en prikk. Og i dette tilfellet plasseres et kolon etter ordet "Merk". Teksten til notater kan bare skrives ut med ett intervall.

Forkortelser. Forkortelser av ord i teksten og inskripsjoner under illustrasjoner er ikke tillatt, med unntak av:

· forkortelser etablert i GOST 2.316-68, og generelt akseptert på russisk språk;

· forkortelser som brukes for å betegne programmer og deres deler

Og driftsmoduser, i oppgavekontrollspråk, i programinnstillingsverktøy osv., angitt med latinske bokstaver

alfabet.

Applikasjoner. Illustrert materiale, tabeller eller støttetekst kan presenteres i form av vedlegg. Søknader utarbeides som en fortsettelse av dette dokumentet på etterfølgende sider eller utstedes som et eget dokument.

Hver søknad må starte på en ny side med ordet «Søknad» i øvre høyre hjørne og ha en aktuell overskrift. Hvis det er mer enn ett vedlegg i et dokument, er alle vedlegg nummerert med arabiske tall (uten «Nei»-tegnet), for eksempel:

Vedlegg 1, vedlegg 2 mv.

Ved utstedelse av en søknad som et separat dokument, skal ordet «vedlegg» angis på tittelsiden under navnet på dokumentet, og hvis det er flere søknader, skal det også angis serienummer.

Brukerhåndbok dokumentasjon programvare produktspesifikasjon

Brukerdokumentasjon refererer til dokumentasjon som gir sluttbrukeren informasjon om installasjon og drift av programvarepakken. Emballasjeinformasjon refererer til informasjonen som vises på den ytre emballasjen til programvarepakken. Formålet er å gi potensielle kjøpere innledende informasjon om programvarepakken.

Programvarens brukerdokumentasjon forklarer brukerne hva de må gjøre for å bruke programvaren. Det er nødvendig hvis programmet involverer interaksjon med brukere. Slik dokumentasjon inkluderer dokumenter som veileder brukeren når du installerer et program med passende innstillinger for applikasjonsmiljøet, når du bruker programmet til å løse problemene, og når du administrerer programmet (for eksempel når denne programvaren samhandler med

Med andre systemer). Disse dokumentene omhandler delvis, men tar ikke opp problemer knyttet til

Med modifikasjon av programmer.

I I forbindelse med dette bør det skilles mellom to kategorier brukere: vanlige brukere av programmet og administratorer. Vanlig bruker av programmet(sluttbruker) bruker programmet til å løse sine problemer (i sitt fagområde). Dette kan være en ingeniør som designer en teknisk enhet, eller en kasserer som selger togbilletter ved hjelp av dette programmet. Han kan kanskje ikke mange av detaljene om datamaskindrift eller programmeringsprinsipper. Programadministratoren (systemadministratoren) administrerer bruken av programmet av vanlige brukere og sørger for programvarevedlikehold som ikke er relatert til programmodifisering. Det kan for eksempel regulere tilgangsrettigheter til programmet mellom vanlige brukere, kommunisere med programmets leverandører, eller utføre visse handlinger for å holde programmet i gang dersom det inngår som en del av et annet system.

Sammensetningen av brukerdokumentasjonen avhenger av brukermålgruppene den er rettet mot og av bruksmåten til dokumentene. Publikum her refererer til kontingenten av brukere

som det er behov for viss brukerdokumentasjon. Et vellykket brukerdokument avhenger i stor grad av nøyaktig identifisering av målgruppen det er ment for. Brukerdokumentasjonen bør inneholde informasjonen som trengs av hver enkelt målgruppe. Bruksmåten for et dokument refererer til metoden som bestemmer hvordan dette dokumentet brukes. Vanligvis krever brukeren av ganske store programvaresystemer enten dokumenter for å studere programvaren (bruk i form av instruksjoner) eller for å klargjøre noe informasjon (bruk i form av en oppslagsbok).

Generell funksjonsbeskrivelse av programvaren. Gir en kort beskrivelse av funksjonaliteten til programvaren. Beregnet for brukere som må bestemme hvor mye de trenger et gitt programvareverktøy.

Programvareinstallasjonsveiledning. Beregnet for systemadministratorer. Det må foreskrive i detalj hvordan man installerer systemer i et bestemt miljø. Den må inneholde en beskrivelse av det maskinlesbare mediet som programvaren leveres på, filene som representerer programvaren og minimumskrav til maskinvarekonfigurasjon.

Instruksjoner for bruk av programvaren. Designet for vanlige brukere. Inneholder nødvendig informasjon om bruken av programvaren, organisert i en form som er praktisk for studier.

Oppslagsbok om bruk av programvare. Designet for vanlige brukere. Inneholder nødvendig informasjon om bruken av programvaren, organisert i en form som er praktisk for selektivt søk av individuelle deler.

Programvareadministrasjonsveiledning. Beregnet for systemadministratorer. Den skal beskrive meldingene som genereres når programvaren samhandler med andre systemer og hvordan de skal svare på disse meldingene. I tillegg, hvis programvareverktøyet bruker systemmaskinvare, kan dette dokumentet forklare hvordan du vedlikeholder denne maskinvaren.

Utviklingen av brukerdokumentasjon starter umiddelbart etter opprettelsen av den eksterne beskrivelsen. Kvaliteten på denne dokumentasjonen kan i betydelig grad avgjøre programmets suksess. Det skal være ganske enkelt og brukervennlig (ellers hadde ikke denne programvaren vært verdt å lage i utgangspunktet). Derfor, selv om utkast til brukerdokumenter er laget av kjerneutviklerne av programvaren, brukes ofte profesjonelle tekniske skribenter til å lage de endelige versjonene.

For å sikre kvaliteten på brukerdokumentasjonen er det i tillegg utviklet en rekke standarder som foreskriver fremgangsmåten for utvikling av denne dokumentasjonen, formulerer krav til hver type brukerdokumenter og bestemmer deres struktur og innhold.

1.4 Programmeringsveiledning

Systemdokumentasjonen beskriver programvaren med tanke på utviklingen.

Denne dokumentasjonen er nødvendig hvis programvaren innebærer å studere hvordan den er strukturert (designet) og oppgradering av programmene. Som nevnt er vedlikehold en pågående utvikling. Derfor, hvis det er nødvendig å modernisere et programvareverktøy, er et spesielt team med utvikling og vedlikeholdere involvert i dette arbeidet. Dette teamet vil måtte håndtere den samme dokumentasjonen som definerte aktivitetene til teamet med første (hoved)utviklere av programvaren - med den eneste forskjellen at denne dokumentasjonen for utviklingsteamet som regel vil være utenlandsk (den ble opprettet av et annet lag). Vedlikeholdsutviklingsteamet må studere denne dokumentasjonen for å forstå strukturen og utviklingsprosessen til programvaren som oppgraderes, og gjøre de nødvendige endringene i denne dokumentasjonen, og i stor grad gjenta de teknologiske prosessene som den opprinnelige programvaren ble laget med.

Programvarestøttedokumentasjon kan deles inn i to grupper:

1. dokumentasjon som definerer strukturen til programvareprogrammer og datastrukturer og teknologien for deres utvikling;

2. dokumentasjon for å hjelpe deg å gjøre endringer i programvaren.

Dokumentasjonen til den første gruppen inneholder de endelige dokumentene for hvert teknologisk stadium av programvareutvikling. Den inkluderer følgende dokumenter.

Ekstern beskrivelse av programvaren (Kravdokument). Beskrivelse av programvarearkitekturen

arkitektur), inkludert den eksterne spesifikasjonen for hvert av programmene.

For hvert program, en beskrivelse av dets modulære struktur, inkludert den eksterne spesifikasjonen for hver modul som er inkludert i den.

For hver modul - dens spesifikasjon og beskrivelse av strukturen

(designbeskrivelse).

Modultekster på valgt programmeringsspråk (programkildekodelister).

Valideringsdokumenter som beskriver hvordan validitet ble etablert

hvert programvareprogram og hvordan forsikringsinformasjonen var knyttet til programvarekravene.

Valideringsdokumenter inkluderer først og fremst testdokumentasjon (testdesign og testsuitebeskrivelse), men kan også inkludere resultatene av andre typer programvaretesting, for eksempel bevis på programegenskaper.

Dokumentasjonen til den andre gruppen inneholder

En systemvedlikeholdsveiledning, som beskriver kjente problemer med programvaren, beskriver hvilke deler av systemet som er maskin- og programvareavhengig, og hvordan programvareutvikling tas i betraktning i utformingen.

Et vanlig problem ved vedlikehold av programvare er å sikre at alle representasjonene følger med (forblir konsistente) når programvaren endres. For å hjelpe dette, må relasjoner og avhengigheter mellom dokumenter og deres deler fanges opp i enabase.

Konklusjon Den raske økningen i kompleksiteten og størrelsen på moderne systemer

programmer, med en samtidig økning i ansvaret for funksjonene som utføres, har kraftig økt kravene fra kunder og brukere til deres kvalitet og sikkerhet ved bruk. Et velprøvd middel for å sikre høy effektivitet og kvalitet på funksjon av programmer og programvaresystemer er dokumentasjonsstandarder utviklet med deltakelse av representanter for ledende selskaper i bransjen.

I Russland, innen sikring av livssyklusen og kvaliteten til komplekse programvarepakker, brukes hovedsakelig en gruppe utdaterte GOST-standarder, som ligger etter verdensnivået med 5-10 år.

I løpet av de siste årene har det blitt laget mange ISO-standarder som regulerer prosessene og produktene i programvarens livssyklus og databaser, som kan tjene som grunnlag for kvalitetssikringssystemer for programvare. Det er nødvendig å kjenne og bruke alle profor å forbedre kvaliteten på produktene.

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

Teknisk dokumentasjonssystem for automatiserte kontrollsystemer

GOST 24.207-80

KRAV TIL INNHOLDET I PROGRAMVAREDOKUMENTER
System med teknisk dokumentasjon for datakontrollsystemer. Krav til innhold i dokumenter på programvare

Ved dekret fra USSR State Committee on Standards datert 14. mai 1980 nr. 2101, ble introduksjonsdatoen fastsatt

fra 01.01.1981

Denne standarden gjelder teknisk dokumentasjon for automatiserte kontrollsystemer (ACS) av alle typer, utviklet for alle ledelsesnivåer (bortsett fra nasjonale), og fastsetter krav til innholdet i dokumenter inkludert i samsvar med GOST 24.101-80 som en del av programvaredokumentasjon i ACS-prosjekter.

1. GENERELLE BESTEMMELSER

1.1. Programvaredokumentasjonen er ment å:

  • å beskrive designløsninger for programvare i dokumentet "Description of ACS Software".
  • å etablere krav til et program (sett med programmer) i dokumentet "Tekniske spesifikasjoner";
  • å beskrive løsninger som gir vedlikehold, produksjon og drift av et program (sett med programmer) i dokumentene "Forklarende merknad", "Beskrivelse av søknad", "Beskrivelse av programmet", "Spesifikasjon", "Programmerveiledning", "Operatorens Veiledning”, “Programtekst” , “Skjema”, “Prosedyre og testmetoder”;
  • for å sjekke funksjonaliteten til programmet (sett med programmer) i dokumentet "Beskrivelse av testtilfellet".

1.2. Ved utvikling av dokumenter for deler av et automatisert kontrollsystem, begrenses innholdet i deler av hvert dokument til rammen til den tilsvarende delen.

1.3. Avhengig av formålet og de spesifikke egenskapene til de opprettede automatiserte kontrollsystemene, er det tillatt å inkludere ytterligere seksjoner i dokumenter, hvis innholdskrav ikke er fastsatt av denne standarden. Fraværet av designløsninger for en del av dokumentet registreres i den aktuelle delen med nødvendige forklaringer.

1.4. Krav til innholdet i dokumentene "Tekniske spesifikasjoner", "Forklarende merknad", "Beskrivelse av søknad", "Spesifikasjon", "Operator's Manual", "Programtekst", "Skjema", "Testprosedyre og metodikk" er etablert av 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 og GOST 179.301.

(Endret utgave, endringsforslag nr. 1).

2. KRAV TIL INNHOLD I DOKUMENTER

2.1. Beskrivelse av ACS-programvare

2.1.1. Dokumentet skal inneholde en innledende del og avsnitt:

  • programvare struktur;
  • hovedfunksjonene til programvaredelene;
  • metoder og verktøy for programvareutvikling;
  • operativsystem;
  • verktøy som utvider funksjonene til operativsystemet.

2.1.2. Den innledende delen bør inneholde grunnleggende informasjon om teknisk, informasjon og andre typer automatisert kontrollsystemstøtte som er nødvendig for programvareutvikling, eller en lenke til relevante dokumenter for automatiserte kontrollsystemprosjektet.

2.1.3. "Programvarestruktur"-delen bør inneholde en liste over programvaredeler, som indikerer deres relasjoner og begrunnelsen for å identifisere hver av dem.

2.1.4. Avsnittet "Hovedfunksjoner til programvaredeler" bør inneholde underavsnitt der formålet med og beskrivelsen av hovedfunksjonene for hver del av programvaren er gitt.

(Endret utgave, endringsforslag nr. 1).

2.1.5. Avsnittet "Metoder og verktøy for programvareutvikling" bør inneholde en liste over programmeringsmetoder og verktøy for utvikling av automatiserte kontrollsystemprogramvare, og angi deler av programvaren i utviklingen av hvilke hensiktsmessige metoder og verktøy som bør brukes.

2.1.6. "Operativsystem"-delen bør inneholde:

  • navn, betegnelse og kort beskrivelse av det valgte operativsystemet og dets versjon, der de utviklede programmene vil bli utført, med begrunnelse for valg og indikasjon av kilder der en detaljert beskrivelse av den valgte versjonen er gitt;
  • navnet på håndboken i henhold til hvilken den valgte versjonen av operativsystemet skal genereres;
  • krav til genereringsalternativet for den valgte operativsystemversjonen.

2.1.7. "Verktøy som utvider funksjonene til operativsystemet" bør inneholde underavsnitt der du for hvert verktøy som brukes som utvider funksjonene til operativsystemet, bør angi:

  • navn, betegnelse og kort beskrivelse av produktet, som begrunner behovet for bruk og angir kilden, som gir en detaljert beskrivelse av det valgte produktet;
  • navnet på håndboken, i henhold til hvilket produktet som brukes skal konfigureres for en spesifikk applikasjon;
  • krav for å sette opp verktøyet som brukes.

2.2. Programbeskrivelse

2.2.2. For et program (sett med programmer) oppnådd ved bruk av tidligere utviklet programvare, bør "Programbeskrivelse"-dokumentet suppleres med delen "Programvareoppsett".

2.2.3. "Programvarekonfigurasjon"-delen bør inneholde:

  • navn, betegnelse på programvaren som brukes, beskrivelse av prosedyrene som kreves for å konfigurere dem, eller lenker til driftsdokumentasjonen for disse verktøyene;
  • en liste over elementer av brukt programvare som er nødvendig for å skaffe programmet (sett med programmer);
  • beskrivelse av innstillingene på språket i driftsdokumentasjonen for programvaren som brukes.

2.3. Programmeringsveiledning

2.3.1. Dokumentet om sammensetningen av seksjonene og deres innhold må være i samsvar med GOST 19.504-79 og i tillegg inkludere seksjonen "Informasjon om presentasjonsformen til programmet (sett med programmer)."

2.3.2. Avsnittet «Informasjon om presentasjonsform av programmet (programsett)» skal inneholde opplysninger om mediet programmet er tatt opp på, om innhold og kodesystem for informasjon som er tatt opp på mediet, samt opplysninger som er nødvendig for lese informasjon fra mediet.

2.3.3. For et program (sett med programmer) som kan tilpasses forholdene til en spesifikk applikasjon, inneholder "Programmer's Guide"-dokumentet seksjoner:

  • programstruktur;
  • programinnstillinger;
  • tilleggsfunksjoner;
  • meldinger til systemprogrammereren.

2.3.4. Det er tillatt for et program (sett med programmer) som kan tilpasses betingelsene for en spesifikk applikasjon, i stedet for delene oppført i klausul 2.3.3, å utvikle et eget dokument "System Programmer's Guide" som oppfyller kravene til GOST 19.503-79.

2.4. Test case beskrivelse

2.4.1. Dokumentet må inneholde seksjoner:

  • avtale;
  • innledende data;
  • beregningsresultater;
  • sjekke et program (sett med programmer).

2.4.2. "Formål"-delen skal inneholde en liste over parametere og en kort beskrivelse av funksjonen som implementeres av programmet (settet med programmer) som testes av testeksemplet.

2.4.3. Delen "Innledende data" må inneholde en beskrivelse av de første dataene for testing av programmet (sett med programmer) med presentasjon av de første dataene. Det er tillatt å presentere kildedataene i form av en utskrift fra ADCP.

2.4.4. Seksjonen "Beregningsresultater" bør inneholde resultatene av behandlingen av de første dataene av et program (sett med programmer), slik at man kan evaluere riktig utførelse av funksjonene som testes og verdien av parameterne som testes. Det er tillatt å presentere beregningsresultatene i form av en utskrift fra ADCP.

2.4.5. Avsnittet "Sjekke programmet (sett med programmer)" bør inneholde:

  • en beskrivelse av sammensetningen av de tekniske midlene som er nødvendige for driften av programmet (sett med programmer), eller en lenke til de relevante programdokumentene;
  • beskrivelse av prosedyrer for å generere innledende data for å kontrollere et program (sett med programmer), kalle programmet (settet med programmer) som testes og oppnå beregningsresultater;
  • beskrivelse av operatørhandlinger ved klargjøring av innledende data og testing av et program (sett med programmer) ved hjelp av et testeksempel.
* Gjenutgivelse (mai 1986) med Endring nr. 1, godkjent i august 1985 (IUS 11-85).

GOST 19.101-77

Gruppe T55

INTERSTATE STANDARD

Samlet system for programdokumentasjon

PROGRAMTYPER OG PROGRAMDOKUMENT

Samlet system for programdokumentasjon. Typer programmer og programdokumenter

MKS 35.080

Introduksjonsdato 1980-01-01


Ved resolusjon fra State Committee of Standards of the Council of Ministers of the USSR datert 20. mai 1977 N 1268, ble introduksjonsdatoen satt til 01/01/80

UTGAVE (januar 2010) med endring nr. 1, godkjent i juni 1981 (IUS 9-81).


Denne standarden etablerer typer programmer og programdokumenter for datamaskiner, komplekser og systemer, uavhengig av deres formål og omfang.

Standarden samsvarer fullt ut med ST SEV 1626-79.

(Endret utgave, endringsforslag nr. 1).

1. TYPER PROGRAMMER

1. TYPER PROGRAMMER

1.1. Programmet (i henhold til GOST 19781-90) kan identifiseres og brukes uavhengig og (eller) som en del av andre programmer.

1.2. Programmer er delt inn i typer vist i tabell 1.

Tabell 1

Programtype

Definisjon

Komponent

Et program betraktet som en helhet, som utfører en fullstendig funksjon og brukes uavhengig eller som en del av et kompleks

Kompleks

Et program som består av to eller flere komponenter og (eller) komplekser som utfører sammenhengende funksjoner, og brukes uavhengig eller som en del av et annet kompleks

1.3. Dokumentasjonen utviklet for programmet kan brukes til implementering og overføring av programmet på lagringsmedier, samt til produksjon av et programvareprodukt.

1.2, 1.3. (Endret utgave, endringsforslag nr. 1).

2. TYPER PROGRAMDOKUMENT

2.1. Programvaredokumenter omfatter dokumenter som inneholder informasjon som er nødvendig for utvikling, produksjon, vedlikehold og drift av programmer.

2.2. Typer programdokumenter og deres innhold er gitt i tabell 2.

tabell 2

Type programdokument

Spesifikasjon

Sammensetning av programmet og dets dokumentasjon

Liste over virksomheter som lagrer originale programdokumenter

Programtekst

Opptak av programmet med nødvendige kommentarer

Programbeskrivelse

Informasjon om den logiske strukturen og driften av programmet

Krav som skal verifiseres ved testing av programmet, samt prosedyre og metoder for deres kontroll

Teknisk oppgave

Formål og omfang av programmet, tekniske, gjennomførbarhet og spesielle krav til programmet, nødvendige stadier og vilkår for utvikling, typer tester

Forklarende merknad

Algoritmediagram, generell beskrivelse av algoritmen og (eller) driften av programmet, samt begrunnelse for vedtatte tekniske og teknisk-økonomiske beslutninger

Driftsdokumenter

Informasjon for å sikre funksjon og drift av programmet

2.3. Typer driftsdokumenter og deres innhold er gitt i tabell 3.

Tabell 3

Type driftsdokument

Liste over driftsdokumenter for programmet

Skjema

Hovedkarakteristika for programmet, fullstendighet og informasjon om driften av programmet

Beskrivelse av søknad

Informasjon om formålet med programmet, anvendelsesomfang, metoder som brukes, klasse av problemer som skal løses, restriksjoner for bruk, minimumskonfigurasjon av maskinvare

Informasjon for kontroll, sikring av funksjon og tilpasning av programmet til betingelsene for en spesifikk applikasjon

Programmeringsveiledning

Informasjon for bruk av programmet

Brukerhåndbok

Informasjon for å sikre prosedyren for kommunikasjon mellom operatør og datasystem under programkjøring

Språkbeskrivelse

Beskrivelse av språkets syntaks og semantikk

Informasjon for bruk av test- og diagnoseprogrammer ved service på teknisk utstyr

2.4. Avhengig av implementeringsmetoden og applikasjonens art, er programdokumenter delt inn i original, duplikat og kopi (GOST 2.102-68), beregnet for utvikling, vedlikehold og drift av programmet.

2.5. Typer programdokumenter utviklet på ulike stadier og deres koder er gitt i tabell 4.

Tabell 4

Kode
type dokument

Dokumenttype

Utviklingsstadier

Foreløpige design

Teknisk prosjekt

Arbeidsutkast

komponent

kompleks

Spesifikasjon

Liste over originale holdere

Programtekst

Programbeskrivelse

Liste over driftsdokumenter

Skjema

Beskrivelse av søknad

Systemprogrammeringsveiledning

Programmeringsveiledning

Brukerhåndbok

Språkbeskrivelse

Vedlikeholdsmanual

Testprogram og metodikk

Forklarende merknad

Andre dokumenter


Legende:

- dokumentet er obligatorisk;

- dokumentet er obligatorisk for komponenter som har uavhengig bruk;

- behovet for å utarbeide et dokument bestemmes på utviklingsstadiet og godkjenningen av de tekniske spesifikasjonene;

- - dokumentet er ikke utarbeidet.

2,2-2,5. (Endret utgave, endringsforslag nr. 1).

2.6. Det er tillatt å kombinere visse typer driftsdokumenter (med unntak av listen over driftsdokumenter og skjemaet). Behovet for å kombinere disse dokumentene er angitt i de tekniske spesifikasjonene. Det sammenslåtte dokumentet tildeles navn og betegnelse på ett av de sammenslåtte dokumentene.

Sammenslåtte dokumenter skal spesifisere informasjonen som skal inkluderes i hvert dokument som slås sammen.

2.7. På utviklingsstadiet og godkjenningen av de tekniske spesifikasjonene bestemmes behovet for å utarbeide tekniske spesifikasjoner som inneholder krav til produksjon, kontroll og aksept av programmet.

Tekniske spesifikasjoner utvikles på "Detaljert design"-stadiet.

2.8. Behovet for å utarbeide tekniske spesifikasjoner for komponenter som ikke er beregnet for selvstendig bruk, og komplekser som inngår i andre komplekser, avgjøres etter avtale med kunden.

(Innført i tillegg, endringsforslag nr. 1).



Elektronisk dokumenttekst
utarbeidet av Kodeks JSC og verifisert mot:
offisiell publikasjon
Samlet programvaresystem
dokumentasjon: Lør. GOST. -
M.: Standardinform, 2010