GOST 1.16-78

Gruppe T50

STATUSSTANDARD FOR UNIONEN AV SSR

STATISK STANDARDISERINGSSYSTEM

Forklarende merknad til utkast til standard. Konstruksjon, innhold, presentasjon og design

Statlig standardiseringssystem. Forklarende merknad til utkast til standard. Layout, innhold, formulering og formell presentasjon

Introduksjonsdato 1979-07-01

Ved dekret fra USSR State Committee for Standards av 30. november 1978 N 3205, er innføringsdatoen satt fra 01.07.79

REPUBLIK med endring nr. 1, godkjent i november 1981 (IUS 3-82)


Denne standarden fastsetter kravene til konstruksjon, innhold, presentasjon og utførelse av forklarende notater til utkast til statlige, industrielle, republikanske standarder og standarder for bedrifter av alle slag.

1. GENERELLE BESTEMMELSER

1. GENERELLE BESTEMMELSER

1.1. En forklarende merknad til utkastet til standard blir samlet for hver revisjon av utkastet som sendes for gjennomgang, sendes til godkjenning og sendes til godkjenning.

1.2. En forklarende merknad til utkastet til standard bør utarbeides av organisasjonen (enterprise) - utvikleren av standarden.

Hvis det er flere utviklere, blir en forklarende merknad til utkastet til standard utarbeidet av den ledende organisasjonen (enterprise) -utvikler.

1.3. Det blir utarbeidet en uavhengig forklarende merknad for hver utviklede standard.

Det er tillatt å lage en forklarende merknad med samtidig utvikling, forberedelse for avtale og godkjenning av sammenhengende standarder i samme kategori for homogene standardiseringsobjekter.

2. KRAV TIL KONSTRUKSJON, INNHOLD OG FORKLARENDE MERKNAD

2.1. Tittelen på forklarende merknad angir kategorien og det fulle navnet på standarden, serienummeret på revisjonen av utkastet til standard og (eller) informasjon om utviklingsstadiet til standarden.

For eksempel:

Forklarende merknad

til utkastet til standardstandard "Sytråder fra naturlig silke. Spesifikasjoner" (første utgave, sendt for gjennomgang).

Forklarende merknad

til utkastet til standardstandarden "Kartografiske enheter. Vilkår og definisjoner" (endelig versjon sendt til godkjenning)

2.2. En forklarende merknad til utkastet til standard bør bestå av seksjoner nummerert i hele forklaringsnotatet og betegnet med arabiske tall med en prikk på slutten av nummeret. Seksjonsoverskriftene skal være med store bokstaver.

Om nødvendig kan forklaringsnotatet deles inn i underavsnitt, ledd og underklausuler i henhold til kravene fastsatt i GOST 1.5-68 * for standarder.
________________
* Dokumentet er ikke gyldig på Russland. Erstattet av GOST 1.5-85 (kansellert uten erstatning), heretter i teksten

2.3. Forklaringen skal deles inn i seksjoner i følgende rekkefølge:

grunnlag for utvikling av standarden;

mål og mål for standardutvikling;

data om standardisering av objektet ved begynnelsen av utviklingen av utkastet til standard;

egenskaper ved objektet for standardisering;

vitenskapelig og teknisk nivå av objektet for standardisering;

teknisk og økonomisk effektivitet fra innføringen av standarden;

forventet dato for innføring av standarden og forventet gyldighetsperiode;

forhold til andre standarder;

informasjon om adresselisten for gjennomgang (til alle revisjoner av utkastet til standard, bortsett fra den første);

informasjon om godkjenning (bare til den endelige versjonen av utkastet til standard som er levert for godkjenning);

informasjonskilder;

tilleggsinformasjon.

Når det utarbeides forklarende merknader til den andre og påfølgende (med unntak av den endelige) revisjonen av utkastet til standard, er det tillatt å ikke plassere i disse forklarende merknadene seksjoner hvis innhold ikke er endret.

2.4. En forklarende merknad til hver versjon av utkastet til standard er utarbeidet basert på indikatorer, normer, egenskaper, krav som er inkludert i denne utgaven, med begrunnelse for endringene.

2.5. I avsnittet "Grunnlag for utvikling av standarden" skal angi nummeret på temaet for den godkjente planen, dato og navn på organisasjonen som godkjente vilkårene.

I tilfelle utviklingen av et utkast til standard som ikke er inkludert i standardiseringsplanen (ikke planlagt emne), bør direktivdokumentene fra de overordnede organene som ligger til grunn for utviklingen av standarden angis.

Det bør også angi under hvilket omfattende standardiseringsprogram, om noen, standarden utvikles.

2.6. I avsnittet "Mål og mål for utviklingen av standarden" skal angi de endelige resultatene, hvis oppnåelse vil være sikret ved anvendelse av standarden, og oppgavene som skal løses i utviklingen av standarden.

2.7. I avsnittet "Data om standardisering av objektet ved begynnelsen av utviklingen av utkast til standard" angir informasjon om at standarden utvikles for første gang, eller informasjon om gjeldende standarder, tekniske forhold, instruksjoner, andre dokumenter som er i kraft ved begynnelsen av utviklingen av utkast til standard for dette standardiseringsobjektet.

2.8. I avsnittet "Egenskaper ved standardiseringsobjektet", avhengig av det standardiserte objektet (produkter, indikatorer, normer, egenskaper, krav til en organisatorisk, metodisk og generell teknisk karakter), angir kategorien og typen av standard hovedindikatorene, normene, egenskapene, kravene til utkastet til standard som bestemmer den vitenskapelige og tekniske nivået på objektet for standardisering, og deres mulighetsstudie.

Hovedindikatorene, normene, egenskapene, kravene til utkastet til standard kan være kravene til de viktigste retningene for utvikling av den nasjonale økonomien i Sovjetunionen, indikatorer for standardiseringsplaner og tekniske spesifikasjoner for utvikling av standarder og indikatorer for bruk av materielle ressurser.

I samme seksjon blir informasjon gitt fra rapporter om resultatene av forsknings- og utviklingsarbeid eller lenker til rapporter som indikerer plasseringen av rapporter, samt informasjon om resultatene av patentforskning av objektet for standardisering, om innenlandske og utenlandske funn og oppfinnelser testet i praksis, publisert de siste ti årene før godkjenningen av standarden, og konklusjonen om testing av prototyper eller pilotbatcher av standardiserte produkter.

2.9. Avsnittet "Vitenskapelig og teknisk nivå for standardiseringsobjektet" gir en komparativ analyse av indikatorer, normer, egenskaper, krav som er fastsatt i utkastet til standard;

med indikatorer, normer, egenskaper, krav til standarder (anbefalinger) fra CMEA, ISO, IEC, annet internasjonale organisasjoner;

med indikatorer, normer, egenskaper, krav til innenlandske og utenlandske standarder;

med de beste eksemplene på utstyr og varer fra innenlands produksjon og utenlandske selskaper;

med de høyeste moderne prestasjonene innen vitenskap, teknologi, avansert innenlandsk og utenlandsk erfaring innen dette området.

Denne delen skal gjenspeile samsvar med indikatorer, normer, egenskaper, krav til standardutkastet:

oppgavene som er definert i hovedretningene for utviklingen av Sovjetunionens nasjonale økonomi;

komplekse vitenskapelige og tekniske programmer, inkludert gjenstand for standardisering;

omfattende standardiseringsprogrammer.

I denne delen, basert på dataene ovenfor, gir de en generell konklusjon om det vitenskapelige og tekniske nivået av indikatorer, normer, egenskaper, krav til standardiseringsobjektet.

Hvis, med den endelige versjonen av utkastet til standard som sendes til godkjenning, sendes tabeller over sammenligning av indikatorer eller et kart separat teknisk nivå og produktkvalitet i samsvar med GOST 2.116-71 *, så er bare resultatene angitt i forklarende merknad til denne utgaven komparativ analyse og gi en generell konklusjon om det vitenskapelige og tekniske nivået på indikatorer, normer, egenskaper, krav til standardiseringsobjektet.
________________
GOST 2.116-84. - Merknad fra produsenten av databasen.

2.10. I seksjonen "Teknisk og økonomisk effektivitet fra innføringen av standarden" skal indikere forventet økonomisk effektivitet, økonomiske fordeler med objektet for standardisering og de viktigste kildene til økonomiske fordeler.

I tilfelle det er umulig å telle økonomisk effektivitet den nødvendige begrunnelsen bør gis for implementeringen av standarden. Denne delen indikerer indikatorer sosial effektivitet fra implementeringen av standarden (hvis noen).

2.11. I avsnittet "Anslått dato for ikrafttredelse av standarden og forventet varighet" skal det omfatte:

underbyggelse av forventet dato for ikrafttredelse av standarden, idet det tas hensyn til tiden det tar å iverksette tiltak for å implementere standarden;

begrunnelse av de viktigste tiltakene for implementering av standarden, inkludert begrunnelsen for muligheten for å organisere en sentralisert (spesialisert) produksjon av produkter;

begrunnelse for godkjenning av utkast til standard uten begrensning av gyldighetsperioden eller begrunnelse for forventet varighet av standarden

2.12. Avsnittet "Forhold til andre standarder" skal indikere:

tilhørelse av utkast til standard til settet med standarder som er inkludert i systemet;

data om forholdet mellom utkast til standard og andre standarder, samt standarder og anbefalinger fra CMEA og andre internasjonale organisasjoner;

begrunnede forslag om behovet for å revidere, utvikle endringer eller oppheve eksisterende sammenhengende standarder.

I tilfelle en revisjon av en produktstandard, blir det gitt informasjon om utskiftbarhet av produkter i henhold til utviklede og gjeldende standarder og tiltak for å sikre drift og reparasjon av produkter produsert i henhold til gjeldende standard.

2.13. I avsnittet "Informasjon om utsendelse av tilbakemelding" skal det angis:

antall organisasjoner (bedrifter) som revisjonen av utkastet til standard ble sendt til;

antall organisasjoner (bedrifter) som sendte tilbakemelding;

en kort sammendragsbeskrivelse av anmeldelsene;

resultater av gjennomgang av anmeldelser.

2.14. I avsnittet "Informasjon om godkjenning" bør informasjon gis om godkjenning av utkastet til standard med interesserte organisasjoner (virksomheter); på å holde forliksmøter; å gi kort beskrivelse problemene som ble vurdert på dem; indikere meningsforskjeller som er igjen under utviklingen av standardutkastet.

Hvis standardutkastet ikke kreves avtalt, bør forklarende merknad indikere at standarden ikke er underlagt enighet.

2.15. I seksjonen "Informasjonskilder" skal angi informasjonskildene som brukes i utviklingen av utkastet til standard, inkludert:

normative handlinger i gjeldende lovgivning;

normative handlinger fra departementer, avdelinger, foreninger og virksomheter;

innenlandske standarder og tekniske forhold (deres betegnelser);

utenlandske og internasjonale standarder og andre dokumenter fra internasjonale organisasjoner (deres betegnelser og navn);

patentforskningsrapporter;

rapporter om gjennomført forsknings- og utviklingsarbeid og andre.

2.16. I delen "Tilleggsinformasjon" kan du om nødvendig inkludere:

muligheter for å løse noen problemer og (eller) individuelle problemer på utkastet til standard med en forespørsel til organisasjoner (bedrifter), som sendes for tilbakekalling av utkastet til standard, om å uttrykke sin mening;

og andre spørsmål.

2.17. En forklarende merknad bør oppgis i samsvar med kravene fastsatt i GOST 1.5-68, avsnitt 1, for standarder.

3. KRAV FOR FORKLARENDE MERKNADER

3.1. En forklarende merknad til utkastet til standard bør skrives ut i samsvar med kravene i GOST 6.38-72 *.
________________
* Dokumentet er ikke gyldig på Russland. GOST R 6.30-2003 er i kraft. - Merknad fra produsenten av databasen.

3.2. En forklarende merknad til utkastet til staten, industrien, republikansk standard må signeres av lederen (nestleder) for den ledende organisasjonen (bedrift) -utvikler, lederen for standardiseringstjenesten, lederen for utviklingen (tema) og utøvere.

En forklarende merknad til utkastet til foretaksstandard må signeres av leder av avdelingen (enhets) -utvikler, leder av utviklingen (emne) og utøvere.

Underskrifter plasseres på den siste siden i forklarende merknad til utkast til standard.

3.3. Den forklarende merknaden til utkastet til standard bør være nummerert og ikke omfatte et omslag.

Elektronisk tekst av dokumentet
utarbeidet av Kodeks JSC og verifisert av:
offisiell publikasjon
Statlig system
standardisering: Samling av GOST-er. -
Moskva: Standards Publishing House, 1983

GOST 1.16-78 GSS. Forklarende merknad til utkast til standard. Konstruksjon, innhold, presentasjon og design (med endring nr. 1)

Nedenfor er et eksempel (eksempel) på et prosjektdokument " Forklarende merknad til det tekniske designet for opprettelsen automatisert system ", basert på retningslinjer RD 50-34.698-90... Dette dokumentet er dannet av en IT-spesialist på scenen teknisk utforming av informasjonssystemet.

Som et eksempel på utviklingen av et informasjonssystem ble det brukt et prosjekt for implementering av et informasjons- og analysesystem "Bedriftsdatalager".

Siden nedenfor viser innholdet i den forklarende merknaden til det tekniske designet i samsvar med GOST, inne i hver av seksjonene kort kravene til innholdet og teksten i eksemplets fylling er gitt (uthevet med en loddrett linje).

Deler av forklarende merknad:

Generelle bestemmelser

Viktigste tekniske løsninger

Beslutninger om strukturen til systemet, delsystemer, kommunikasjonsmidler og metoder for informasjonsutveksling mellom systemkomponenter

Løsninger for sammenkobling av AU med tilstøtende systemer, som sikrer kompatibilitet

Løsninger for driftsmodi, diagnostisering av systemdrift

Personal- og arbeidsmodusløsninger

Informasjon om å sikre forbrukeregenskapene til systemet som er spesifisert i de tekniske spesifikasjonene, som bestemmer kvaliteten

Sammensetningen av funksjoner, komplekser av oppgaver implementert av systemet

Sammensetning og plassering av komplekser av tekniske midler

I dag skal vi snakke om innenlandske standarder for designdokumentasjon. Hvordan disse standardene fungerer i praksis, hvorfor de er dårlige og hva som er gode. Når vi utvikler dokumentasjon for offentlige og seriøse privatkunder, har vi vanligvis ikke noe valg - overholdelse av standarder er inkludert i kravene til dokumentasjon av tekniske spesifikasjoner. I praksis måtte jeg forholde meg til forskjellige eksempler misforståelse av strukturen til standarder, hva som skal være i dokumentene og hvorfor disse dokumentene er nødvendige. Som et resultat, noen ganger kommer slike perler ut fra pennen til tekniske forfattere, analytikere og spesialister at det ikke er klart i hvilken bevissthetstilstand de ble skrevet. Men faktisk er alt ganske enkelt. Et søk på Habr returnerte ikke lenker til mer eller mindre komplett materiale om dette emnet, derfor foreslår jeg å fylle ut dette irriterende hullet.

Hva er dokumentasjonsstandarder?

Det er bare 3 hoveddokumentasjonsstandarder i den aktuelle 34-serien:

Den mest elskede og populære standarden for utvikling av tekniske spesifikasjoner. Det eneste du ikke bør glemme er at den er tett forbundet med andre standarder i serien, og hvis du mottok en teknisk spesifikasjon, utført i henhold til denne standarden, er det svært ønskelig å følge andre standarder, selv om det ikke er noen direkte krav til dette. I det minste når det gjelder generell ideologi (om hvilken nedenfor)

Dette er et grunnleggende dokument som gir en komplett liste over GOST 34-dokumentasjon, anbefalinger for koding av dokumenter, hvilke stadier av prosjektet dokumentene tilhører (trinn er beskrevet i GOST 34.601-90), og også hvordan de kan kombineres med hverandre.

Faktisk er denne standarden et stort kommentert bord. Den kan kjøres inn i Excel for enkel bruk.

En omfangsrik standard som beskriver innholdet i prosjektdokumenter med varierende detaljnivå. Ovennevnte GOST 34.201-89 brukes som en indeks.

Det er mange spørsmål og tolkninger av bestemmelsene til RD 50-34.698-90-standarden, som på grunn av deres manglende spesifisitet ofte forstås forskjellig av kunden og entreprenøren eller til og med medlemmer prosjektgruppe... Men dessverre har vi ikke noe mer konkret.

La oss nå vurdere fordeler og ulemper med standarder, og starter tradisjonelt med ulemper.

Ulemper med standarder

Den største ulempen er åpenbar for alle - standardene er gamle. De inneholder et utdatert konsept av arkitekturen til et automatisert system. For eksempel:
• to-lags applikasjoner, bestående av et klientprogram og en databaseserver (ingen tre eller flere "tier" -applikasjoner, ingen Weblogic eller JBoss)
• strukturen til databasetabellene, når den blir beskrevet, vil gi en ide om den logiske datamodellen (det faktum at det kan være noe dvalemodus mellom applikasjonen og databasen, så virket det som et dårlig overskudd)
• brukergrensesnittet er ett vindu (kan det være annerledes? Hva er en "nettleser"?)
• Det er ikke mange rapporter i systemet, de er alle papir og skrives ut på en matriseskriver
• Det utviklede programmet er fokusert på å løse "informasjonsbehandlingsproblemet", som har tydelig input og output og er høyt spesialisert. Informasjonsbehandling er basert på en "algoritme". Noen ganger er det flere "algoritmer". (Objektorientert programmering tok bare sine første skritt den gang og ble ikke seriøst vurdert.)
• databaseadministratoren forstår hvilken informasjon som er i tabellene og deltar aktivt i redigering av systemkataloger (er det virkelig en DBMS-server for 50 forskjellige applikasjoner?)
Følgelig inneholder standarden gjenstander som følgende:

5.8. Tegning av dokumentskjemaet (videoramme)
Dokumentet må inneholde et bilde av formen på dokumentet eller videorammen i samsvar med kravene i statlige standarder for det enhetlige dokumentasjonssystemet R 50-77 og de nødvendige forklaringene.

Betydningen av dokumentet er at sovjetiske bedrifter brukte de såkalte "Printing Areas", hvor det var høyhastighets matriseskrivere, som driverne ofte ble skrevet av ingeniørene selv. Derfor måtte de føre et register over alle dokumenter som måtte skrives ut for å sikre at dokumentene ville se ut som de skulle når de skrives ut.

En "videoramme" er også et dokument som ble vist på en tekstdisplay. Skjermene støttet ikke alltid de nødvendige tegnene og det nødvendige antallet tegn horisontalt og linjer vertikalt (og støttet ikke grafikk i det hele tatt). Derfor, også her, var det nødvendig å i tillegg koordinere skjemaene til alle skjermdokumenter.

Nå forteller ikke ordene "maskin-gram", "videoramme", "ADCP" oss noe. Jeg fant dem heller ikke i bruk, selv om jeg ble uteksaminert fra et spesialisert institutt på 90-tallet. Det var tiden for utseendet til Windows 3.1, VGA-skjermer, tre-tommers disketter og de første innenlandske nettstedene. Men disse ordene er i standarden, og kunden krever noen ganger lunefullt å gi ham et komplett sett med dokumentasjon i samsvar med GOST 34.201-89. Dessuten vandrer lignende formuleringer i TK fra ett departement til et annet og har allerede blitt en slags usagt mal som innholdet blir drevet inn i.

Så dokumentet med det dumme navnet "Tegning av dokumentets form (videoramme)" i prosjektet bør og bør ikke være tomt.

Hva er bra i standarden

Enhver standard er bra for det faktum at den lar kunden og entreprenøren snakke det samme språket og gir en garanti for at kunden, i det minste formmessig, ikke vil ha noen krav "i form" på de overførte resultatene.

Og GOST 34-standardene er også gode ved at de ble utarbeidet av smarte mennesker, testet i årevis, og de har et klart mål - å beskrive så fullstendig som mulig på papiret en kompleks abstrakt enhet som enhver ACS representerer.

Når du kompetent må sette en oppgave for vestlige entreprenører som aldri har hørt om våre GOST-er, kan du også stole på disse standardene, eller rettere sagt på deres innhold, semantiske komponent. For igjen er garantien for fullstendighet av informasjon verdt mye. Uansett hvordan vi unner oss det høye nivået av profesjonalitet, kan vi glemme å inkludere elementære ting i våre krav, mens den samme GOST 34.602-89 "husker" alt. Hvis du ikke forstår hvordan resultatet av vestlige entreprenørers arbeid skal se ut, se på kravene til dokumentasjon for de anbefalte delene. Jeg forsikrer deg om at det er bedre å ikke komme på! Mest sannsynlig er det vestlige analoger av våre standarder, der alt kan være fyldigere, mer moderne og bedre. Dessverre er jeg ikke kjent med dem, siden det ennå ikke har vært en eneste sak om at våre GOST-er ikke ville være nok.

Du kan le av det faktum at skaperne av standarder ikke visste noe om java eller .NET, om HD-skjermer og Internett, men jeg vil ikke råde deg til å undervurdere omfanget av arbeidet deres og verdien for vårt profesjonelle samfunn.

Hvordan lese og forstå GOST serie 34 dokumentasjonsstandarder

Standarden deler alle dokumenter langs to akser - tid og emneområde. Hvis du ser på tabell 2 i GOST 34.201-89, kan du tydelig se denne inndelingen (kolonnene "Stage of creation" og "Part of the project"

Stadier for opprettelse av ACS

Stadier av opprettelse er definert i GOST 34.601-90. Tre av dem er relevante for dokumentasjon:
• Utkast til prosjekt (EP)
• Teknisk design (TP)
• Utvikling arbeidsdokumentasjon (RD)
Foreløpige design følger trinnet i vilkårene og tjener til å utvikle foreløpige designløsninger.

Teknisk prosjekt beskriver det fremtidige systemet fra alle vinkler. Dokumentene fra TP-scenen skal etter å ha lest fullstendig klarhet i de foreslåtte tilnærmingene, metodene, arkitektoniske og tekniske løsningene. I neste fase vil det være for sent å beskrive tilnærminger og rettferdiggjøre tekniske løsninger, så fase P er nøkkelen til vellykket levering av arbeid, siden alle de forskjellige TOR-kravene skal gjenspeiles i dokumentene i fase P. På trinn P kan det hende at systemet ikke eksisterer i det hele tatt.

Arbeidsdokumentasjon designet for vellykket distribusjon, igangkjøring og videre drift nytt system... Dette er dokumenter som inneholder veldig spesifikk informasjon som beskriver fysisk eksisterende enheter, i motsetning til fase P, som beskriver fremtidens prakt.

Deler (seksjoner) av prosjektdokumentasjon for oppretting av et automatisert kontrollsystem

Fagområdet er delt inn i "Bestemmelser". Først ser det ut til at en slik inndeling er overflødig og unødvendig. Men når du begynner å jobbe med dette verktøyet i praksis, når ideologien innebygd i den gradvis.

Et automatisert system i tankene til kompilatorene til GOST er en kombinasjon av maskinvare, programvare og kommunikasjonskanaler som behandler informasjon som kommer fra forskjellige kilder i samsvar med visse algoritmer og gir behandlingsresultatene i form av dokumenter, datastrukturer eller kontrollhandlinger. En primitiv modell av den enkleste automaten.

For å fullstendig beskrive denne "automaten" ble følgende kutt gjort (som på tegningen):

Programvare (MO), som svarer på spørsmålene: hvilken logikk er innebygd i den "svarte boksen"? Hvorfor ble disse algoritmene, nøyaktig slike formler og nøyaktig slike koeffisienter valgt?

Programvaren vet ikke noe om prosessorer eller databaser. Dette er et eget abstrakt område, boligen til "sfæriske hester i vakuum." Men programvaren er veldig tett forbundet med emneområdet, aka Real life. For eksempel kontrollalgoritmer for styringssystemer veitrafikk det kreves å avtale med trafikkpolitiet før kunden er enige om det. Og så forstår du hvorfor de trekkes frem som en egen bok. For i trafikkpolitiet er ingen interessert i hvilket operativsystem applikasjonsserveren skal kjøre på, men hvilket tegn og fartsgrense som dukker opp på resultattavlen i regn eller snø er veldig interessant. De er ansvarlige for sin del, og de kommer ikke til å signere noe annet. På den annen side, når de signerte, vil det ikke være spørsmål til den tekniske siden av spørsmålet - hvorfor valgte de disse og ikke andre tavler eller trafikklys. Visdommen til "forfedrene" manifesteres nøyaktig i slike praktiske tilfeller.

Informasjonsstøtte (IO)... Nok et stykke av systemet. Denne gangen blir den sorte boksen i systemet vårt gjort gjennomsiktig, og vi ser på informasjonen som sirkulerer i den. Tenk deg en modell av det menneskelige sirkulasjonssystemet når alle andre organer er usynlige. Dette er noe lignende, og det er informasjonsstøtte. Den beskriver sammensetningen og rutene for informasjonsoverføring innenfor og utenfor, den logiske organisasjonen av informasjon i systemet, en beskrivelse av referansebøker og kodingssystemer (den som laget programmer for produksjon vet hvor viktig de er). Hovedbeskrivende del faller på TP-scenen, men noen "rudiments" strømmer inn i RD-scenen, som dokumentet "Database catalog". Det er klart at det tidligere inneholdt nøyaktig det som står i tittelen. Men i dag, prøv å danne et slikt dokument for et komplekst komplekst system, når veldig ofte kjøpte delsystemer med deres mystiske informasjonslagre brukes som en del av systemet. Jeg snakker ikke engang om at dette dokumentet ikke er spesielt nødvendig nå.

Eller her er "Statement of Machine Information Media". Det er tydelig at det pleide å inneholde antall magnetiske trommer eller filmruller. Og nå hva skal jeg bringe dit?

Kort sagt, i RD-fasen dokumenter Informasjonsstøtte representerer et ganske skadelig rudiment, siden det formelt sett burde være, men det er ikke mye å fylle dem med.

Programvare (programvare)... Alles favorittdel av prosjektdokumentasjonen. Ja, om ikke bare fordi det bare er ett dokument! Og så forstår alle hva som må registreres der. Men jeg vil likevel gjenta.

I dette dokumentet må vi fortelle med hvilken programvare algoritmene beskrevet i IO kjøres, som behandler informasjonen beskrevet i IO. Det vil si at det ikke er behov for å duplisere informasjon fra andre seksjoner her. Det gir systemets arkitektur, begrunnelsen for de valgte programvareteknologiene, beskrivelsen av dem (alle slags system ting: programmeringsspråk, rammer, operativsystemer, etc.). Også i dette dokumentet beskriver vi hvordan informasjonsbehandlingsverktøy er organisert (meldingskøer, lagringer, sikkerhetskopieringsverktøy, tilgjengelighetsløsninger, alle slags applikasjonsbassenger osv.). Standarden har detaljert beskrivelse innholdet i dette dokumentet som enhver ekspert kan forstå.

Teknisk støtte (TO)... Ikke mindre elsket av alle, en del av prosjektdokumentasjonen. Det lyse bildet blir bare mørkt av overflod av dokumenter som må utvikles. Totalt krever standarden utvikling av 22 dokumenter, hvorav 9 er på TP-stadiet.

Faktum er at standarden gir en beskrivelse av alt teknisk støtte, inkludert maskinvare og nettverk, tekniske systemer og til og med konstruksjonsdelen (hvis nødvendig). Og denne økonomien er regulert av et stort antall standarder og forskrifter, er konsistent i forskjellige organisasjoner, og det er derfor mer praktisk å dele alt i deler og koordinere (redigere) i deler. Samtidig lar standarden deg kombinere noen dokumenter med hverandre, noe som er fornuftig å gjøre hvis hele haugen er koordinert av en person.

Ikke glem også at komplekset av kvalitetsstandarder innebærer regnskap og lagring av tekniske dokumenter, og at våre "bøker" hos kunden kan være spredt i forskjellige arkiver, avhengig av emnet for beskrivelsen. Dette er et annet argument til fordel for fragmentering av dokumentasjon.

Organisasjonsstøtte (OO)... Etter å ha undertrykt ønsket, normalt for en tekniker, om å hoppe over denne delen så snart som mulig, tvert imot vil jeg vurdere det nærmere. Siden, kolleger, har det de siste årene blitt skissert dårlige trender for prosjekter som krever avklaring i denne delen.

På TP-stadiet inneholder seksjonen bare ett dokument “ Beskrivelse organisasjonsstruktur ", Der vi må fortelle kunden hva han skal forberede seg på når det gjelder å endre organisasjonsstrukturen. Plutselig må du organisere en ny avdeling for å betjene systemet ditt, innføre nye stillinger osv.

På RD-scenen vises andre, mer interessante dokumenter, som jeg vil vurdere separat.

Brukerhåndboken... Kommentarer er overflødige, tror jeg.

Metode (teknologi) for datamaskinstøttet design... I dette dokumentet kan du om nødvendig legge inn en beskrivelse av programvarebyggingsprosessen, versjonskontroll, testing osv. Men dette er hvis kunden ønsker å montere programvaren personlig i TK. Hvis han ikke krever det (og ikke betaler for det), er ikke hele ditt indre kjøkken hans sak, og dette dokumentet trenger ikke gjøres.

Teknologisk instruksjon... I forbindelse med moten for formalisering av forretningsprosesser, søker den slu kunden noen ganger å stappe driftsprosedyrene inn i dette dokumentet. Så dette er på ingen måte nødvendig.

Beskrivelse av forretningsprosesser, rolle og stillingsbeskrivelser, arbeidsbestemmelser - alt dette er en ORD, det vil si organisatorisk og administrativ dokumentasjon. Som er produktet av et konsulentprosjekt som, så vidt jeg forstår, ikke kjøpte fra deg. Og de kjøpte et teknisk prosjekt fra deg og også teknisk dokumentasjon for det.

Teknologisk instruksjon er et lag mellom OSD og brukerhåndboken. RP beskriver i detalj som du må gjøre visse handlinger i systemet. Den teknologiske instruksjonen sier hvilken type handlinger må utføres i visse tilfeller knyttet til driften av systemet. Grovt sett er en teknologisk instruksjon en kort fordøyelse av RP for en bestemt stilling eller rolle. Hvis kunden ikke har definert roller, eller han vil at du selv skal definere roller og jobbkrav, må du inkludere de mest grunnleggende rollene i dokumentet, for eksempel: operatør, senioroperatør, administrator. Kundens kommentarer til emnet “men det er ikke slik for oss” eller “men vi liker det ikke” bør ledsages av en liste over roller og beskrivelse av jobbansvar. Fordi virksomheten behandler oss ikke sette... Vi er disse forretningsprosessene automatisere.

Jeg vil skrive om den beskrevne raken hver for seg, med fargerike eksempler, siden dette ikke er første gang det blir gjentatt i forskjellige sektorer av "nasjonaløkonomien".

Beskrivelse teknologisk prosess databehandling (inkludert telebehandling)... Et elendig rudiment fra huletiden, da det var spesielt utpekte "Computer Operators" som matet maskinen med stansede kort og pakket utskriften av resultatet i en konvolutt. Denne instruksjonen er for dem. Hva du skal skrive i det i det XXI århundre - jeg kan ikke fortelle deg det helt sikkert. Skru deg av. Det beste er å bare glemme dette dokumentet.

Systemomfattende løsninger (OR)... Standarden gir 17 dokumenter i OP-seksjonen. For det første er dette nesten alle dokumenter fra den foreløpige utkastet til designfase. For det andre er dette alle slags estimater, beregninger og kort beskrivelse automatiserte funksjoner. Det vil si informasjon for folk ikke fra hoved-IT-produksjonen, men for støttepersonell - ledere, estimatorer, innkjøpsspesialister, økonomer osv.

Og for det tredje inkluderer OR et mega-dokument kalt "Explanatory Note to the Technical Project", som ifølge ideen er en slags Sammendrag, men faktisk skyver mange designere inn i alt det nyttige innholdet i TP-scenen. En slik radikal tilnærming er noen ganger berettiget og til og med gjensidig gunstig for både kunden og entreprenøren, men i visse tilfeller.

Varianter av bruk av GOST 34

1. Full og nøyaktig overholdelse av standarden... Naturligvis vil ingen frivillig skrive en slik sky av dokumenter. Derfor utarbeides et komplett sett med dokumenter kun på den insisterende forespørselen fra kunden, som han sikret i TK og knuste det ovenfra med en avtale. I dette tilfellet må du forstå alt bokstavelig og gi kunden fysiske "bøker" som navnene på dokumentene fra tabell 2 i GOST 34.201-89 vil vises, med unntak av absolutt unødvendige, hvis liste du definitivt må diskutere og fikse skriftlig. Innholdet i dokumentene må også uten fantasi tilsvare RD 50-34.698-90, helt ned til tittelen på seksjonene. For at kundens hjerne skal eksplodere, er noen ganger et stort system delt inn i delsystemer, og det utstedes en egen designdokumentasjon for hvert delsystem. Det ser skremmende ut og er ikke underlagt normal kontroll ved hjelp av et jordisk sinn. Spesielt når det gjelder integrering av delsystemet. Dette forenkler aksept. Det viktigste er at du selv ikke blir forvirret, og at systemet ditt fortsatt fungerer som det skal.
2. Vi elsker GOST-er... Seriøse store selskaper elsker standarder. Fordi de hjelper folk til å forstå hverandre bedre. Hvis kunden din blir lagt merke til forelsket i orden og standardisering, kan du prøve å følge standardideologien til GOST når du utvikler dokumenter, selv om dette ikke kreves av den tekniske spesifikasjonen. Du vil bli bedre forstått og godkjent av koordinerende spesialister, og du vil ikke glemme å ta med i dokumentasjonen viktig informasjon, vil du bedre se målstrukturen til dokumenter, mer nøyaktig planlegge arbeidet med skrivingen og spare deg selv og dine kolleger for mange nerver og penger.
3. Vi bryr oss ikke om dokumentasjonen, så lenge alt fungerer... Forsvinnende slags uansvarlig kunde. Et lignende syn på dokumentasjon kan fremdeles finnes blant små og fattige kunder, så vel som i autoritære "idiotokratier" til overs fra perestroika, hvor sjefen er omgitt av lojale venner - regissører, og alle spørsmål løses i personlige samtaler. Du er fri under slike forhold å glemme dokumentasjon generelt, men det er bedre, likevel, å ikke slå ned synet og i det minste fylle dokumentasjonen skjematisk med innhold. Hvis ikke til denne kunden, så overfør (selg) til den neste.

Konklusjon

Denne artikkelen handlet om GOST-standardene for dokumentasjon av ACS. GOST er gamle, men som det viste seg, er de fortsatt veldig nyttige i husholdningen. Bortsett fra noen åpenbare rudimenter, har strukturen i dokumentasjonen egenskapene til fullstendighet og konsistens, og overholdelse av standarden fjerner mange prosjektrisikoer, hvis eksistens vi kanskje ikke først gjetter.

Jeg håper det presenterte materialet var nyttig for deg, eller i det minste interessant. Til tross for ytre kjedsomhet er dokumentasjon en viktig og krevende jobb, hvor nøyaktighet er like viktig som å skrive god kode. Skriv gode dokumenter, kolleger! Og neste uke skal jeg på to forretningsreiser på rad, så jeg garanterer ikke publisering av nytt materiale (jeg har ikke butikk, jeg skriver fra hodet).

Forklarende merknad til det tekniske prosjektet.

Hovedformålet med å skape IS er å akselerere "salgsprosessen", samt å øke effektiviteten til de ansatte. For å sikre at systemet kan brukes på datamaskinene der det brukes, må programvaren være installert:

• - OS-familie Windows;
• - 1C: Enterprise 8;

Nye data legges inn i systemet før du starter arbeidet, dette er nødvendig for å legge inn de første saldiene. For å begrense uautoriserte endringer, brukes autorisasjon når du går inn i programmet. Hvis passordet er tastet inn feil, vil systemet vise en melding og ikke tillate deg å koble til databasen.

Systemet gjennomfører tre hovedoppgaver:

• - vedlikehold av referansebøker;
• - lagerstyring;
• - registrering av salg;
• - utdata fra rapporter.

Databaseapplikasjonen for IS er utviklet ved bruk av programvaremiljøet 1C: Enterprise 8. For å være vert for systemet brukes personlige datamaskiner som er tilgjengelige for den enkelte entreprenør som systemet utvikles for.

Ordning funksjonell strukturer

De generelle kravene til funksjonaliteten til det utformede systemet er avbildet ved hjelp av VI-diagrammet i figur 1

Tabell -2 Hoveddelen av VI-utføringsskriptet "Legg til katalogdata"

	Rediger katalogdata
	Storekeeper, IP
	Opprettholde oppdatert informasjon om gjenstander fra emneområdet
Kort beskrivelse	Bruker legger til ny gjenstand oppslagsbok og skriver den ned. Systemet lagrer de endrede dataene i databasen
Forutsetning	1. Brukeren er autorisert i systemet. 2. Brukeren har rett til å legge til data i katalogen
Posttilstand	1. Elementet i katalogen er registrert i databasen. 2. Elementet i katalogen vises i form av en liste over katalogen

Tabell -3 Typisk hendelsesforløp for VI-utføringsskriptet "Legg til katalogdata"

Tabell -4 Unntak for VI-kjøringsskriptet "Legg til katalogdata"

Tabell -5 Hoveddel av VI-utførelsesskriptet "Angi varepriser"

Tabell - 6 Typisk hendelsesforløp i VI-utførelsesscenariet "Angi varepriser"

Tabell -7 Unntak fra VI-utføringsskriptet "Angi varepriser"

Tabell -8 Hovedavsnitt i VI-eksekveringsscenario "Registrer varemottak"

Tabell -9 Typisk hendelsesforløp i VI-utførelsesscenariet "Registrer varemottak"

Skuespillernes handlinger	Systemrespons
1. Lagreren utfører kommandoen for å opprette et nytt dokument "Varemottak"	2. Systemet viser dokumentets form
3. Lagreren fyller ut topptekstdetaljene Unntak nr. 1: Storekeeper fyller ut tallfeltet manuelt
4. Butikkinnehaveren legger til en ny rad i tabellseksjonen på Products-siden	5. Systemet viser en ny linje
6. Lagreren fyller ut kolonnen Nomenklatur	7. Systemet erstatter verdien på kolonnene
8. Storekeeper fyller ut Mengde-kolonnen	9. Systemet beregner verdien av mengdekolonnene,
10. Systemet viser i bunnteksten til tabelldelen de totale verdiene for kolonnene Total
11. Lagrer går inn nytt produkt (gå tilbake til trinn 4) eller utfører kommandoen Skriv Unntak nr. 2: Verdien til tallfeltet er ikke unik	12. Systemet registrerer et nytt dokument "Varemottak" i databasen
13. Lagreren utfører kommandoen Skriv ut -	14. Systemet viser det fullførte trykt form kredittseddel
15. Storekeeper utfører kommandoen Print	16. Systemet skriver ut kvitteringsordren
17. Lagreren utfører kommandoen Lukk trykkplaten	18. Systemet lukker trykkplaten
19. Lagrer utfører kommandoen Lukk av dokumentet "Varemottak"	20. Systemet lukker dokumentskjemaet "Varemottak"

Tabell -10 Unntak fra VI-eksekveringsscenario "Registrer varemottak"

Verdiene av kolonnesummen og summen beregnes med formelen:

Beløp \u003d Antall * Pris

Tabell -11 avsnitt av utførelsesscenario VI "Gjør salg"

Tabell -12 Typisk hendelsesforløp i VI-utførelsesscenariet "Making sales"

Skuespillernes handlinger	Systemrespons
Betaling for ett "salgs" -dokument
1. Lederen utfører kommandoen for å opprette et nytt salgsdokument	2. Systemet viser skjemaet "salg"
4. Lederen har dokumentet
5. systemet legger ut dokumentet
9. Systemet skrives ut

Tabell - 13 Unntak fra VI-eksekveringsscenario "Registerdokument"

Tabell -14 seksjon av eksekveringsscenario VI "Reservasjon"

Tabell -15 Typisk hendelsesforløp i VI-utførelsesscenariet "Making sales"

Skuespillernes handlinger	Systemrespons
Vare reservasjon
1. Lederen utfører kommandoen for å opprette et nytt reservasjonsdokument	2. Systemet viser form av dokumenter "reservasjon"
3. Lederen legger inn data om klienten, om kjøpte varer og kjøpte tjenester
4. Lederen har dokumentet Unntak nr. 1 ikke alle felt er fylt ut	5. systemet legger ut dokumentet
6. lederen utfører kommandoen Skriv ut	7. Systemet viser det fullførte trykte skjemaet
8. Lederen utfører kommandoen Skriv ut	9. Systemet skrives ut
10. Lederen utfører kommandoen Lukk utskriftsplaten	11. Systemet lukker trykkplaten
11. Lederen utfører kommandoen Lukk dokumentet "gjengivelse av tjenester"	12. Systemet lukker dokumentskjemaet

Tabell - 16 Unntak fra VI-eksekveringsscenario "Registerdokument"

Tabell -17 VI "Generer en rapport"

Utvikling av katalogstrukturen

Katalog "Motparter" designet for å lagre informasjon om kunder, leverandører.

Tabell -15 Krav til klientkatalogen

Den juridiske statusen er av typeoppregning. Dette betyr at når dette feltet er valgt, vil en liste med tre statuser falle ut: IP, Phys. Person, organisasjon.

skapning håndbok "Ansatte"... Designet for å lagre informasjon om organisasjonens ansatte. Lar deg knytte et salg til en bestemt ansatt.

Tabell -16 Katalogdetaljer Ansatte

skapning håndbok "Lager"... Designet for å bestemme varenes lagringssted. Den enkelte gründer vil ha to lager: Trade Point 1 og Trade Point 2.

skapning referanse bøker "Alternativ Nomenklaturer " og "Ytterligere Eiendommer "... Disse veiledningene er ment å definere tilleggskarakteristikker for en bestemt nomenklatur, det vil si at skjermer kan være identiske, men farger vil variere. Disse katalogene vil bli kalt i form av en varekatalog. Betydningen av disse feltene vises i salgsdokumentet.

skapning håndbok "Nomenklatur"... For å gjøre rede for varer som er kjøpt fra en leverandør, oppretter vi en referansebok "Nomenklatur".

Elementer i nomenklaturkatalogen vil bli kombinert i grupper etter funksjonelt formål, slik at katalogen vil se ut som et hierarki "hierarki av grupper og elementer".

Tabell -17 Detaljer om katalognavnet

Utvikling av strukturen til informasjonsregisteret "Nomenklaturpriser"

For å lagre kostnadene for nomenklaturenheter, oppretter vi et informasjonsregister med navnet "Priser". Frekvensen til registeret er innen et sekund (dvs. priser kan spores når som helst), opptaksmodus er uavhengig.

Tabell -18 Oppbygging av informasjonsregisteret Priser

Den ledende egenskapen indikerer at informasjonsregisterposten er av interesse så lenge objektet, hvis referanse er valgt som verdien av denne dimensjonen i denne posten, eksisterer. Når et objekt slettes, slettes alle informasjonsregisteroppføringer for det objektet automatisk.

Utvikling av strukturen til dokumentet "Varemottak"

Dokumentet "Mottak av varer" er ment å gjenspeile faktumet for mottak av kjøpte varer i organisasjonen.

Tabell 19 detaljer om dokumentet "Mottak av varer (kvitteringsfaktura)"

Tabell -19 Detaljer om tabelldelen av dokumentet "Varemottak"

Det er skrevet en kode for automatisk å beregne verdiene til kolonnene Beløp når verdiene for kolonnene Antall, Pris endres.

Dokumentets form vil være som vist i figur 2




Figur 2- Form av dokumentet Mottak av varer

Utvikling av strukturen til dokumentet "Salg"

Dokumentet som gir tjenester er ment å registrere aktivitetene til den enkelte entreprenør. Den kontrollerer avskrivning av varer, tjenester som er utført, og lar deg også se rapporten om arbeidene til de ansatte.

Tabell -20 Detaljer om dokumentet "Salg"

Tabell -21 Detaljer om tabelldelen av dokumentet Salg

Utvikling av strukturen til dokumentet "Reservation"

"Reserveringsdokumentet" er ment for bestilling av et eksisterende produkt på lageret, og i tilfelle mangel, ta den manglende delen av produktet til klienten. Det er også nødvendig å reservere varer til kunden betaler for bestillingen. Dette dokumentet er ment å kontrollere saldoen på lager for å unngå misforståelser med klienten.

Tabell -20 Detaljer om "Reservation" -dokumentet

Tabell -21 Detaljer om tabelldelen av dokumentet Reservering

Utvikling strukturer dokument "Tast inn første rester "

Dette dokumentet kreves for å legge inn de første saldiene i databasen.

Opplysningene ligner på dokumentet "Faktura".

skapning rapportere "Produkter"

Rapporten "Varer" er ment for rask visning av avskrivning og mottak av varer. Det vil si at det lar brukeren se hvor mange varer som for øyeblikket er lokalisert, og hvor mange som er solgt.

I 1C Enterprise 8-miljøet er det en rapportbygger som lar deg raskt utvikle en rapport ved å generere spørsmål og design basert på tabeller.

skapning rapportere "Register over salgsdokumenter"

Denne rapporten er ment å danne et register over "salgs" -dokumenter. Systemet vil også implementere ulike rapporter, som vil være like i skapelsesstrukturen.

skapning roller og avtale dem brukere

Administrere listen over 1C: Bedriftsbrukere og tildele dem roller i samsvar med deres offisielle plikter - veldig viktige punkter for å organisere grensesnittet til den anvendte løsningen som helhet og differensiere rettighetene og handlingene til de enkelte brukerne.

Du bør begrense brukere fra å utføre handlinger med databaseobjekter. Dermed kan lagringsmannen opprette ”Varemottak” -dokumenter og registrere dokumentene, siden han er ansvarlig for å registrere varemottaket. Lederen må igjen ha tilgang til å legge til kundekataloger, utarbeide dokumentet "salg", "reservasjon", men samtidig må han ikke ha tilgang til varemottak.

Rollekonfigurasjonsobjektene brukes til å beskrive disse tillatelsene. Hver bruker av systemet tildeles en eller flere roller.

Roller opprettes basert på hvilke tillatelser som kreves for at forskjellige brukergrupper skal få tilgang til informasjon. Følgende roller vil bli implementert i systemet vårt:

• - administrator - i 1C: Enterprise-systemet må det være en rolle som inkluderer fulle rettigheter til å jobbe med informasjonssikkerhetsdata;
• - butikkeier;
• - sjef;
• - SP.

Rolletildelingen til brukerne utføres gjennom hovedmenyelementet Administrasjon -\u003e Brukere.



Figur 3 - Opprette en bruker "Administrator" med rollen "Administrator"



Figur 4 - Liste over systembrukere

For alle databaseobjekter, for alle roller, er den interaktive slettingsretten ekskludert.

Redigering kommando grensesnitt seksjoner og arbeider bord

Forbedring av kommandogrensesnittet til applikasjonen, innstilling av synlighet av kommandoer etter rolle og skrivebord gjør applikasjonen mer brukervennlig og gir den et komplett utseende.

Vi vil sortere kommandoene, avhengig av prioritet og bruksfrekvens, i følgende grupper:

• - navigasjonslinje.
• - navigasjonslinje. Normal;
• - navigasjonslinje. også;
• - handlingslinje. Opprett og
• - handlingslinje. Rapporter



Figur 5 - Kommandogrensesnittet til "Materiellregnskap" -delen av brukeren med rollen "Storekeeper"



Figur 6 - Kommandogrensesnittet til delen "Provision of Services" til en bruker med rollen "Manager"




Figur 7 - Kommandogrensesnitt for "Enterprise" -delen til en bruker med rollen "Director"



Figur 8 - Kommandogrensesnitt for delen "Retail.Electronic" av en bruker med rollen "Administrator"

Skrivebordet er designet for å imøtekomme de mest brukte dokumentene, rapportene, referansebøkene, etc. Når 1C: Enterprise lanseres, blir Desktop-delen aktiv som standard, og de nødvendige skjemaene åpnes umiddelbart i applikasjonsarbeidsområdet.




Figur 9 - Skrivebord for en bruker med rollen "Storekeeper"




Figur 10 - Skrivebord for en bruker med rollen "Manager"

automasjon engros programdokumentasjon