GOST-standardi ohjelmistodokumentaatiolle. Ohjelmistodokumentaation rekisteröinti Unified Data Systemin mukaisesti, Unified Data System Software GOST:n mukaan

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

Automaattisten ohjausjärjestelmien tekninen dokumentointijärjestelmä

GOST 24.207-80

VAATIMUKSET OHJELMISTOASIAKIRJOJEN SISÄLLÖLLE
Tietokoneohjausjärjestelmien teknisen dokumentaation järjestelmä. Ohjelmiston asiakirjojen sisältövaatimukset

Käyttöönottopäivä vahvistettiin Neuvostoliiton valtion standardikomitean 14. toukokuuta 1980 antamalla asetuksella nro 2101

1.1.1981 alkaen

Tämä standardi koskee kaikentyyppisten automaattisten ohjausjärjestelmien (ACS) teknistä dokumentaatiota, joka on kehitetty kaikille johtamistasoille (lukuun ottamatta kansallisia), ja siinä asetetaan vaatimukset GOST 24.101-80:n mukaisten asiakirjojen sisällölle osana standardia. ohjelmistodokumentaatio ACS-projekteissa.

1. YLEISET MÄÄRÄYKSET

1.1. Ohjelmistodokumentaatio on tarkoitettu:

  • kuvailla ohjelmistojen suunnitteluratkaisuja asiakirjassa “Description of ACS Software”.
  • asettaa vaatimukset ohjelmalle (ohjelmasarjalle) "Tekniset tiedot" -asiakirjassa;
  • kuvailla ratkaisuja, jotka tarjoavat ohjelman (ohjelmasarjan) ylläpitoa, tuotantoa ja käyttöä asiakirjoissa "Selitys", "Sovelluskuvaus", "Ohjelman kuvaus", "Spesifikaatio", "Ohjelman opas", "Käyttäjän opas". Opas", "Ohjelman teksti" , "Lomake", "Menettely ja testausmenetelmät";
  • tarkistaa ohjelman (ohjelmasarjan) toimivuus asiakirjasta "Kokeilutilan kuvaus".

1.2. Kun kehitetään dokumentteja automatisoidun ohjausjärjestelmän osille, kunkin asiakirjan osioiden sisältö rajoittuu vastaavan osan puitteisiin.

1.3. Luotujen automatisoitujen ohjausjärjestelmien tarkoituksesta ja erityispiirteistä riippuen asiakirjoihin voidaan sisällyttää lisäosia, joiden sisältövaatimuksia ei ole asetettu tässä standardissa. Asiakirjan osan suunnitteluratkaisujen puuttuminen kirjataan asianmukaiseen osioon tarvittavilla selityksillä.

1.4. Asiakirjojen "Tekniset tiedot", "Selvittävä huomautus", "Sovelluskuvaus", "Spesifikaatio", "Käyttöopas", "Ohjelman teksti", "Lomake", "Testausmenettely ja -menetelmät" sisältövaatimukset ovat GOST:n asettamat. 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 ja GOST 19.301

(Muutettu painos, muutos nro 1).

2. ASIAKIRJOJEN SISÄLTÖÄ KOSKEVAT VAATIMUKSET

2.1. ACS-ohjelmiston kuvaus

2.1.1. Asiakirjan tulee sisältää johdanto-osa ja osiot:

  • ohjelmistojen rakenne;
  • ohjelmiston osien päätoiminnot;
  • ohjelmistokehitysmenetelmät ja -työkalut;
  • käyttöjärjestelmä;
  • voimaannuttamisen työkaluja käyttöjärjestelmä.

2.1.2. Johdanto-osassa tulee sisältää perustiedot ohjelmistokehityksen edellyttämästä teknisestä, tieto- ja muun tyyppisestä automaattisen ohjausjärjestelmän tuesta tai linkin automaattisen ohjausjärjestelmän projektin asiaankuuluviin asiakirjoihin.

2.1.3. "Ohjelmiston rakenne" -osiossa tulisi olla luettelo ohjelmiston osista, joista käy ilmi niiden suhteet ja perustelut kunkin tunnistamiselle.

2.1.4. Kohdassa ”Ohjelmiston osien päätoiminnot” tulee sisältää alakohdat, joissa kunkin ohjelmiston osan päätoiminto ja kuvaus päätoiminnoista on esitetty.

(Muutettu painos, muutos nro 1).

2.1.5. Kohdassa ”Ohjelmistokehitysmenetelmät ja -työkalut” tulee sisältää luettelo ohjelmointimenetelmistä ja työkaluista automatisoitujen ohjausjärjestelmien ohjelmistojen kehittämiseen, jossa mainitaan ohjelmiston osat, joiden kehittämisessä tulee käyttää sopivia menetelmiä ja työkaluja.

2.1.6. "Käyttöjärjestelmä"-osion tulee sisältää:

  • nimi, nimi ja lyhyt kuvaus valitusta käyttöjärjestelmästä ja sen versiosta, jossa kehitetyt ohjelmat suoritetaan, sekä valinnan perustelut ja lähteet tarvittaessa Yksityiskohtainen kuvaus valittu versio;
  • sen käsikirjan nimi, jonka mukaan valittu käyttöjärjestelmän versio tulee luoda;
  • vaatimukset valitun käyttöjärjestelmäversion luontivaihtoehdolle.

2.1.7. "Työkalut, jotka laajentavat käyttöjärjestelmän ominaisuuksia" -osion tulee sisältää alaosia, joissa jokaisesta käytetystä työkalusta, joka laajentaa käyttöjärjestelmän ominaisuuksia, on ilmoitettava:

  • tuotteen nimi, nimitys ja lyhyt kuvaus, jossa perustellaan sen käytön tarve ja mainitaan lähde, joka sisältää yksityiskohtaisen kuvauksen valitusta tuotteesta;
  • sen käsikirjan nimi, jonka mukaan käytettävä tuote tulisi konfiguroida tiettyä sovellusta varten;
  • vaatimukset käytetyn työkalun asentamiselle.

2.2. Ohjelman kuvaus

2.2.2. Ohjelmalle (ohjelmasarja), joka on saatu käyttämällä aiemmin kehitettyä ohjelmisto, "Ohjelman kuvaus" -asiakirjaa tulee täydentää "Ohjelmiston asetukset" -osalla.

2.2.3. "Ohjelmiston asetukset" -osiossa tulisi olla:

  • nimi, käytetyn ohjelmiston nimi, kuvaus niiden määrittämiseen tarvittavista toimenpiteistä tai linkit näiden työkalujen käyttödokumentaatioon;
  • luettelo ohjelman hankkimiseen tarvittavista käytetyistä ohjelmistoista (ohjelmasarja);
  • asetusten kuvaus käytetyn ohjelmiston käyttödokumentaation kielellä.

2.3. Ohjelmoijan opas

2.3.1. Osioiden koostumusta ja niiden sisältöä koskevan asiakirjan on oltava GOST 19.504-79:n mukainen, ja lisäksi sen on sisällettävä osio "Tiedot ohjelman esitysmuodosta (ohjelmasarja)."

2.3.2. Kohdassa ”Tietoja ohjelman esitysmuodosta (ohjelmasarja)” tulee sisältää tiedot välineestä, jolle ohjelma on tallennettu, välineelle tallennettujen tietojen sisällöstä ja koodausjärjestelmästä sekä tiedot, jotka ovat tarpeen tiedon lukeminen mediasta.

2.3.3. Ohjelman (ohjelmasarjan), joka voidaan mukauttaa tietyn sovelluksen olosuhteisiin, "Ohjelmoijan opas" -asiakirja sisältää osiot:

  • ohjelman rakenne;
  • ohjelman asetukset;
  • lisäominaisuuksia;
  • viestit järjestelmän ohjelmoijalle.

2.3.4. Ohjelmalle (ohjelmasarjalle), joka voidaan räätälöidä tietyn sovelluksen olosuhteisiin, on sallittu kohdassa 2.3.3 lueteltujen osioiden sijaan kehittää erillinen GOST:n vaatimukset täyttävä asiakirja ”Järjestelmän ohjelmoijan opas”. 19.503-79.

2.4. Testitapauksen kuvaus

2.4.1. Asiakirjan tulee sisältää osiot:

  • nimittäminen;
  • alkutiedot;
  • laskennan tulokset;
  • ohjelman (ohjelmasarjan) tarkistaminen.

2.4.2. "Tarkoitus"-osion tulee sisältää luettelo parametreista ja lyhyt kuvaus toiminnosta, jonka testiesimerkillä testattava ohjelma (ohjelmasarja) toteuttaa.

2.4.3. Kohdassa "Alkutiedot" tulee olla kuvaus ohjelman (ohjelmasarjan) testauksen lähtötiedoista alkutietojen esittämisellä. Lähdetiedot saa esittää ADCP:n tulosteena.

2.4.4. "Laskentatulokset" -osiossa tulisi olla ohjelman (ohjelmasarjan) suorittaman alkutietojen käsittelyn tulokset, jotta voidaan arvioida testattavien funktioiden oikea suoritus ja testattavien parametrien arvo. Laskentatulokset voidaan esittää tulosteena ADCP:stä.

2.4.5. Kohdan "Ohjelman tarkistaminen (ohjelmasarja)" tulee sisältää:

  • kuvaus ohjelman toiminnan edellyttämien teknisten välineiden koostumuksesta (ohjelmasarja) tai linkki asiaankuuluviin ohjelma-asiakirjoihin;
  • kuvaus menettelyistä lähtötietojen generoimiseksi ohjelman (ohjelmasarjan) tarkistamiseksi, testattavan ohjelman (ohjelmajoukon) kutsumiseksi ja laskentatulosten saamiseksi;
  • kuvaus operaattorin toimista valmisteltaessa alkutietoja ja testattaessa ohjelmaa (ohjelmajoukkoa) testiesimerkin avulla.
* Uudelleenjulkaisu (toukokuu 1986) muutoksella nro 1, hyväksytty elokuussa 1985 (IUS 11-85).

OHJELMISTON KEHITTÄMISKULTTUURI

Minkä tahansa ohjelmisto, yksinkertaisesta Verkkosivusto voimakkaaksi tietokannan hallintajärjestelmät, on korkean teknologian tuote ja sen on täytettävä seuraavat kriteerit:

  • luotettavuus;
  • hätätilanteiden asianmukainen käsittely;
  • helppo päivitettävyys.

Ohjelmat voivat täyttää nämä vaatimukset vain, jos ne noudattavat huolellisesti kaikkia ohjelmistokehitysteknologiat.

Ovat yleisiä ohjelman kehittämisen vaiheet:

  • ohjelmavaatimusten määrittäminen;
  • teknisten eritelmien kehittäminen;
  • ohjelmaluonnoksen kehittäminen;
  • ohjelmien koodaus;
  • ohjelman kokoonpano;
  • Ohjelmistomoduulien testaus;
  • ohjelman koekäyttö;
  • ohjelmistokehitys;
  • ohjelman ottaminen käyttöön pysyvästi;
  • ohjelman tuki;
  • vaatimusten määrittäminen uusi versio ohjelmat;

varten ohjelmavaatimusten määrittely Kehittäjän on saatava vastaus kysymykseen: "Kuinka kiinnostunut asiakas on ohjelman kehittämisestä?"

Jos asiakas ei ole valmis osallistumaan aktiivisesti tapaamisiin ja konferensseihin kehittäjän kanssa tai sanoo, että työhön on muita ehdokkaita, ohjelman työstäminen tulee olla valmis tässä vaiheessa.

Jos asiakkaan aikomukset ovat vakavat, niin ohjelman vaatimusten määrittely on todennäköisesti useamman kuin yhden kokouksen kysymys, jossa on tarpeen selvittää ja selventää asioita:

  • Mikä on ohjelman tarkoitus?
  • Ohjelman käyttäjäkunta.
  • Sääntely (laki-, viite)perusta, johon ohjelmassa algoritmisoidut prosessit perustuvat.
  • Ohjelman jatkokehityksen mahdollisuus ja tarve.
  • Yhteyshenkilö, joka on valtuutettu ratkaisemaan kaikki ongelmat asiakkaan puolesta.
  • Olemassa olevien materiaalien saatavuus tai asiakas suunnittelee valmistautuvansa käytettäväksi ohjelmassa (!!! Tämä kohta on erityisen tärkeä web-sivustojen kehittämisen kannalta).

Teknisten eritelmien kehittäminen mieluiten asiakkaan tulisi suorittaa. Käytännössä tämän tekee usein kehittäjä, koska asiakkaalla ei ole päteviä ohjelmistokehityksen alalla tuntevia asiantuntijoita. Tehtäväehdot on yleensä kehitetty GOST 19.201-78 "ESPD. Tekninen tehtävä. Sisällön ja suunnittelun vaatimukset." Tapauksissa, joissa teknisiä ohjelmistoja kehitetään osana automatisoidut järjestelmät Käytetään GOST 34.602-89 "Tietotekniikkaa". Tekniset tiedot automatisoidun järjestelmän luomiseksi."

Tekniset eritelmät käyvät läpi hyväksymismenettelyn asiakkaan ja kehittäjän välillä sen jälkeen, kun kehittäjän viranomaisvalvontapalvelu on tarkistanut niiden toteutuksen oikein.

Perustuu hyväksyttyihin teknisiin eritelmiin suunnitteludokumentaatiota kehitetään (hanke). Projektin sisältö riippuu ohjelmistotyypistä ja kehittäjän yrityksen perinteistä.

Hankkeen pakollisten osien tulee olla:

  • selittävä huomautus (standardin GOST 19.404-79 "ESPD. Selittävä huomautus. Sisältöä ja suunnittelua koskevat vaatimukset" mukaisesti).
  • ohjelman kuvaus (GOST 19.402-78 "ESPD. Ohjelman kuvaus" mukaisesti).
  • luettelo hankkeessa käytetyistä termeistä. Verkkosivustojen osalta projekti sisältää:
  • Web-sivuston suunnittelun luonnos;
  • luettelo sivuston osana käytetyistä materiaaleista;
  • tietokannan rakenne (jos sellainen on)

Tietokantojen kanssa toimiville ohjelmille niiden rakenne on pakollinen osa.

Projekti on dokumentti, jonka pohjalta ohjelmaa kehitetään, eikä ohjelman rakenteeseen ja toimintoihin tehtäviä muutoksia voida hyväksyä ilman hankkeeseen muutoksia. Projekti on se dokumentti, jonka perusteella ohjelmaa myöhemmin analysoidaan ja valmistellaan myöhempien versioiden julkaisua.

Toteuttaa ohjelman koodaamista Suunnittelija antaa ohjelmoijalle tehtävät ohjelmamoduulien koodaamista varten. Tehtävä määrittelee vaatimukset moduulin tulo- ja lähtötietojen rakenteelle, moduulissa käytettävien muuttujien nimet, moduulin tietojenkäsittelyn algoritmi sekä ohjelmointitekniikat (tarvittaessa). Ohjelmakoodi Mukana on yksityiskohtainen selostus, jonka laatu määrää ohjelman myöhempien versioiden julkaisumahdollisuuden.

Koodissa tulee kuvata tarkasti kunkin moduulin tulo- ja lähtötietojen merkitys sekä itse moduulin merkitys ja toiminnot. Tämä on tärkeää ohjelman rakentamisen onnistumisen kannalta.

Vaiheittain ohjelma rakentaa Projektipäällikkö vastaa. Tässä vaiheessa ohjelma muodostuu yhdeksi kokonaisuudeksi. Koska kaikki ohjelman komponentit ovat eri ohjelmoijien luomia, tämä vaihe on erityisen tärkeä kaikkien luotujen moduulien epäjohdonmukaisuuksien ja yhteensopimattomuuden poistamiseksi.

Ohjelman testaus tehdään seuraavasti:

  1. Testausta varten määritetään laitteet.
  2. Testausta varten kehitetään skenaarioita (testitapauksia).
  3. Skenaarioiden perusteella tarkistetaan ohjelman toiminta normaalitilassa (tarkistetaan niiden toimintojen oikea suoritus, joita ohjelman oletetaan suorittavan).
  4. Ohjelman toiminta epänormaaleissa tiloissa tarkistetaan (tarkistetaan, toimiiko ohjelma vakaasti tiloissa, joita voi syntyä vain silloin, kun käyttäjät rikkovat ohjelman käyttösääntöjä, esimerkiksi syöttämällä kirjaimia numerokenttään).
  5. Testaus suoritetaan ohjelmanhallinnan ja käyttöliittymän laadun helpottamiseksi.
  6. Testaustiedot ja sen tulokset käsitellään ja dokumentoidaan standardin GOST 34.603-92 ”Tietotekniikka. Automaattisten järjestelmien testaustyypit."
  7. Kun virheet havaitaan, ne korjataan ja testaus toistetaan.
  8. Kun kaikki virheet on korjattu, ohjelma siirretään koekäyttöön.

Asiakkaalle vaiheessa koekäyttö ohjelma lähetetään ja vaadittu asiakirjapaketti:

  • luettelo operatiivisista asiakirjoista (standardin GOST 19.507-79 "ESPD. Käyttöasiakirjojen luettelo" mukaisesti)
  • lomake (GOST 19.501-78 "ESPD. Lomake. Sisällön ja suunnittelun vaatimukset" mukaisesti)
  • sovelluksen kuvaus (GOST 19.502-78 "ESPD. Sovelluksen kuvaus. Sisältö- ja suunnitteluvaatimukset" mukaisesti)
  • järjestelmäohjelmoijan käsikirja (standardin GOST 19.503-79 "ESPD. Järjestelmäohjelmoijan käsikirja. Sisällön ja suunnittelun vaatimukset" mukaisesti)
  • käyttöopas (standardin GOST 19.505-79 "ESPD. Käyttöohje. Sisällön ja suunnittelun vaatimukset" mukaisesti).

Tehtävän tyypistä riippuen voidaan lisäksi lähettää seuraavat tiedot:

  • ohjelmoijan käsikirja (GOST 19.504-79 "ESPD. Ohjelmoijan käsikirja. Sisällön ja suunnittelun vaatimukset" mukaisesti)
  • käsikirja t/o:ssa (GOST 19.508-79 "ESPD. Manual on" mukaisesti huolto. Sisällön ja suunnittelun vaatimukset").

Lavalla koekäyttö Ohjelma tallentaa asiakkaan kommentit ja havaitut virheet.

Tämän perusteella se valmistetaan ohjelmistokehitys eli kommenttien ja virheiden poistaminen ja ohjelma siirtyy asiakkaalle sisään jatkuvaa toimintaa.

Ohjelman tuki Monimutkaisuudesta riippuen sen suorittaa joko asiakas tai kehittäjä. Tuki koostuu seuraavan tyyppisten töiden suorittamisesta:

  • neuvottelut;
  • laitteiston ylläpito, jossa ohjelmaa käytetään;
  • tietokantojen tarkistus ja analysointi;
  • tietojenkäsittelyteknologioiden oikeellisuuden tarkistaminen;
  • uusien ohjelmavaatimusten dokumentointi ja analysointi.

Viimeinen kohta on perusta aloitukselle uuden version kehittäminen ohjelmasta.

Vain pätevä ohjelmankehitysprosessi varmistaa ne korkealaatuinen ja pitkä elämä!!!

Ohjelmistotuotteiden yhtenäinen dokumentointijärjestelmä - ESPD - kuuluu GOST-luokkaan 19 ja on jaettu 10 ryhmään:
1. Perusstandardit.
2. Kehitysdokumentaation toteuttamissäännöt.
3. Säännöt valmistusdokumentaation toteuttamiseksi.
4. Tukiasiakirjojen täytäntöönpanosäännöt.
5. Säännöt operatiivisen dokumentaation toteuttamiseksi.
6. Kiertosäännöt ohjelman dokumentaatio.

Standardi numero 0 sisältää yleiset säännökset, standardit 7 ja 8 on varattu ja numero 9 sisältää muita standardeja, jotka eivät sisälly ensimmäiseen 6:een.

Nämä ovat lyhyitä kuvauksia luokan 19 GOST:ista; lisätietoja on hakuteoksissa.

  • GOST 19.001-77 - yksi järjestelmä ohjelmiston dokumentaatio.
  • GOST 19.101-77 - ohjelmatyypit ja ohjelmaasiakirjat.
  • GOST 19.102-77 - ohjelmien ja ohjelmadokumentaation kehitysvaiheet.
  • GOST 19.105-78 - vaatimukset ohjelmadokumenttien, kompleksien ja järjestelmien suunnittelulle niiden tarkoituksesta ja laajuudesta riippumatta. GOST 19.105-78 sisältää täydellisen luettelon asiakirjoista, jotka on liitettävä valmiin ohjelmistotuotteen mukana.

Luettelo GOST 19.105-78:n ilmoittamista asiakirjoista:

1. Asiakirjat, jotka sisältävät ohjelmistotuotteen kehittämiseen ja valmistukseen tarvittavia tietoja.
1.1. Specification – ohjelman kokoonpano ja sen dokumentaatio.
1.2. Alkuperäisten haltijoiden luettelo - luettelo yrityksistä, joissa alkuperäinen ohjelmadokumentaatio on tallennettu.
1.3. Ohjelmateksti – tallenna ohjelmateksti tarvittavin kommentein.
1.4. Ohjelman kuvaus – tiedot ohjelman loogisesta ja toiminnallisesta rakenteesta.
1.5. Testausohjelma ja -metodologia - ohjelmaa testattaessa varmennettavat vaatimukset, menettelytapa ja menetelmät niiden ohjaamiseksi.
1.6. Tehtävä – ohjelman tarkoitus ja soveltamisala, tekniset ja erityisvaatimukset, tarvittavat kehitysvaiheet ja ehdot, testityypit.

1.7. Selitys – algoritmikaavio, algoritmin yleinen kuvaus, ohjelman suorittama toiminto. Selitys tehdyistä teknisistä päätöksistä.

2. Ohjelmistotuotteen käytössä käytetyt asiakirjat.
Lista operatiivisista asiakirjoista – luettelo ohjelman operatiivisista asiakirjoista.
Muoto – ohjelman pääominaisuudet, täydellisyys, yleistä tietoa ohjelman käytöstä.
Sovelluksen kuvaus - tiedot ohjelman tarkoituksesta, soveltamisalasta, ratkaistavien tehtävien luokasta, käyttörajoituksista, vaaditusta laitteiston konfiguraatiosta.
Järjestelmäohjelmoijan opas - tiedot toimivuuden tarkistamiseen ja varmistamiseen, ohjelman käyttöönottoon.
Ohjelmoijan opas - tietoja konfiguroidun ohjelman käyttämisestä.
Käyttöopas - tiedot, jotka varmistavat käyttäjän ja tietokoneen välisen yhteydenpidon ohjelman suorittamisen aikana.
Kielen kuvaus – kuvaus ohjelmassa käytetyn kielen syntaksista ja semantiikasta.
Huoltokäsikirja - tietoa testiohjelmien käytöstä teknisiä laitteita huollettaessa.

Muut GOST-luokka 19:

  • GOST 19.201-78 - menettely teknisten eritelmien rakentamiseksi ja laatimiseksi ohjelman tai ohjelmistotuotteen kehittämiseksi.
  • GOST 19.202-78 - muoto ja menettely GOST 19.101-77:ssä määriteltyjen ohjelmistotuotteiden eritelmien laatimiseksi.
  • GOST 19.301-79 - ohjelma ja menetelmä ohjelmistotuotteiden testaamiseen.
  • GOST 19.401-78 - menettely ohjelmatekstin muodostamiseksi ja muotoiluksi ohjelmistotuotteita kehitettäessä.
  • GOST 19.402-78 - ohjelman kuvaus.
  • GOST 19.403-79 - alkuperäisten haltijoiden luettelon täyttömuoto ja sisältö, määritelty GOST 19.105-78:ssa.
  • GOST 19.404-79 - selittävän huomautuksen täyttötapa ja sisältö, määritelty GOST 19.105-78:ssa.
  • GOST 19.501-78 - ohjelmistotuotteen lomakkeen täyttömuoto ja sisältö, määritelty GOST 19.105-78:ssa.
  • GOST 19.502-78 - GOST 19.105-78:ssa määritelty hakemuskuvauksen täyttömuoto ja sisältö.
  • GOST 19.503-79 - GOST 19.105-78:ssa määritelty järjestelmän ohjelmoijan käsikirjan täyttömuoto ja sisältö.
  • GOST 19.504-79 - ohjelmoijan käsikirjan täyttömuoto ja sisältö, määritelty GOST 19.105-78:ssa.
  • GOST 19.505-79 - käyttöoppaan täyttömuoto ja sisältö, määritelty GOST 19.105-78:ssa.
  • GOST 19.506-79 - GOST 19.105-78 määritellyn kielen kuvauksen täyttömuoto ja sisältö.
  • GOST 19.507-79 - GOST 19.105-78:ssa määritelty operatiivisten asiakirjojen luettelon täyttötapa ja sisältö.
  • GOST 19.508-79 – GOST 19.105-78:ssa määritelty huoltokäsikirjan täyttötapa ja sisältö.
  • GOST 19.701-90 - kaaviot algoritmeista, ohjelmista, tiedoista ja järjestelmistä.

Raportissani tukeudun:

  • artikkeli "Ohjelmiston alan standardointi", osaston johtaja V.V. Vasyutkovich ja vanhempi tutkija S.S. Samotokhin. Venäjän federaation valtion standardin koko venäläinen tutkimuslaitos;
  • E.Z. Zinderin artikkeli "Sorrelaatio ja standardien käyttö järjestelmien elinkaaren organisoimiseksi";
  • GOST:ien ja muiden standardien tekstit.

1. Ohjelmistokehityksen perusasiat

Kun ohjelmoija-kehittäjä saa ohjelmointitehtävän muodossa tai toisessa, hänen edessään, projektipäällikön edessä ja koko projektiryhmä kysymyksiä herää:

  • mitä pitäisi tehdä varsinaisen ohjelman lisäksi?
  • mitä ja miten pitää dokumentoida?
  • mitä välittää käyttäjille ja mitä? saattajapalvelu?
  • kuinka hallita tätä koko prosessia?
  • Mitä itse ohjelmointitehtävään tulisi sisällyttää?

Mainittujen ongelmien lisäksi on muitakin.

Vastasivatko ohjelmistodokumentaation valtion standardit kerran näihin ja moniin muihin kysymyksiin? GOST ESPD:n 19. sarjan standardit. Mutta silloinkin ohjelmoijalla oli paljon valituksia näistä standardeista. Jotain piti kopioida dokumentaatioon monta kertaa (kuten näytti - perusteettomasti), ja paljon ei ollut säädetty, kuten esimerkiksi integroidun tietokannan kanssa toimivien ohjelmien dokumentoinnin erityispiirteet.

Tällä hetkellä kysymys ohjelmistojen dokumentointia säätelevästä järjestelmästä on edelleen ajankohtainen.

2. Ehdon yleiset ominaisuudet

Ohjelmistodokumentaation alan kotimaisen sääntelykehyksen perustana on joukko Unified System of Program Documentation (USPD) -standardeja. Suurin ja suurin osa ESPD-kompleksista kehitettiin 70- ja 80-luvuilla. Nyt tämä kompleksi on alueella toimiva IVY-maiden välisten standardien järjestelmä (GOST). Venäjän federaatio perustuu valtioiden väliseen standardointisopimukseen.

ESPD-standardit kattavat pääasiassa sen osan dokumentaatiosta, joka syntyy ohjelmistokehitysprosessissa ja liittyy suurimmaksi osaksi ohjelmiston toiminnallisten ominaisuuksien dokumentointiin. On huomattava, että ESPD-standardit (GOST 19) ovat luonteeltaan neuvoa-antavia. Tämä koskee kuitenkin myös kaikkia muita PS-alan standardeja (GOST 34, kansainvälinen standardi ISO/IEC jne.). Tosiasia on, että Venäjän federaation standardointilain mukaisesti näistä standardeista tulee pakollisia sopimusperusteisesti - toisin sanoen, kun niihin viitataan ohjelmiston kehittämistä (toimitusta) koskevassa sopimuksessa.

ESPD:n tilasta kokonaisuutena puhuttaessa voidaan todeta, että useimmat ESPD:n standardit ovat moraalisesti vanhentuneita.

Tärkeimpien haittojen joukossa ESPD voidaan syyttää:

  • suuntautuminen yhteen, "kaskadi"-malliin elinkaari(LC) PS;
  • selkeiden suositusten puute ohjelmistojen laatuominaisuuksien dokumentoimiseksi;
  • järjestelmällisen yhteyden puute muihin olemassa oleviin kotimaisiin standardijärjestelmiin elinkaari- ja tuotedokumentaatiossa yleensä, esimerkiksi ESKD;
  • epäselvä lähestymistapa PS:n dokumentoimiseen markkinakelpoisena tuotteena;
  • ohjelmiston itsedokumentointia koskevien suositusten puute, esimerkiksi näyttövalikoiden ja käyttäjän operatiivisen avun ("apu") muodossa;
  • PS:tä koskevien mahdollisten asiakirjojen koostumuksesta, sisällöstä ja suunnittelusta ei ole annettu suosituksia, jotka ovat kansainvälisten ja alueellisten standardien suositusten mukaisia.

Joten ESPD tarvitsee täydellisen tarkistuksen, joka perustuu ISO/IEC 12207-95 -standardiin ohjelmistojen elinkaariprosesseja varten (tätä standardia käsitellään tarkemmin myöhemmin).

On sanottava, että ESPD-kompleksin ohella Venäjän federaation virallinen sääntelykehys PS:n ja siihen liittyvien alueiden dokumentoinnin alalla sisältää useita lupaavia standardeja (kotimainen, valtioiden välinen ja kansainvälinen taso).

Kansainvälinen standardi ISO/IEC 12207: 1995-08-01 ohjelmistotuotteiden elinkaaren järjestämiseen - näennäisesti hyvin epämääräinen, mutta melko uusi ja jokseenkin "muodikas" standardi.

Monimutkaiset standardit GOST 34 automatisoitujen järjestelmien (AS) luomisesta ja kehittämisestä - yleistetty, mutta elinkaarirakenteessa koettu erittäin jäykkä. projektin dokumentaatio. Mutta monet pitävät näitä standardeja byrokraattisina jopa haitallisina ja konservatiivisina siinä määrin, että ne ovat vanhentuneita. Missä määrin tämä on totta ja missä määrin GOST 34 on edelleen hyödyllinen, on hyödyllistä ymmärtää.

Artikkelissaan E.Z. Zinder käsittelee menetelmää yksityiskohtaisesti Oracle CDM(Custom Development Method) sovelluksen kehittämiseen tietojärjestelmä tilauksesta - suunnitteluasiakirjan aihioiden tasolle yksityiskohtainen materiaali, joka on suunniteltu käytettäväksi suoraan Oraclen työkaluihin perustuvissa ydinvoimaprojekteissa.

2.1. Lyhyt johdatus ESPD-standardeihin

Kuitenkin ennen koko kompleksin tarkistamista monia ESPD-standardeja voidaan käyttää hyödyllisesti ohjelmistojen dokumentointikäytännössä. Tämä kanta perustuu seuraaviin:

  • ESPD-standardit lisäävät ohjelmiston dokumentointiprosessiin tilauselementin;
  • ESPD-standardien edellyttämä ohjelmadokumenttien kokoonpano ei ole ollenkaan niin "jäykkä" kuin jotkut saattavat ajatella: standardit mahdollistavat lisätyyppien lisäämisen ohjelmiston dokumentaatioon.
  • ESPD-standardit mahdollistavat myös vakiintuneiden PD-tyyppien rakenteen ja sisällön joustavan muuttamisen asiakkaan ja käyttäjän tarpeiden mukaan.

Samanaikaisesti standardien soveltamistyyli voi vastata nykyaikaista yleistä standardien mukauttamistyyliä projektin erityispiirteisiin: asiakas ja projektipäällikkö valitsevat projektiin sopivan standardien ja PD:n alajoukon, täydentävät valittu PD tarvittavilla osioilla ja sulkea pois tarpeettomat, sitoa näiden dokumenttien luominen projektissa käytettävään elinkaarikaavioon.

ESPD-standardit (kuten muut GOST-standardit) on jaettu taulukossa annettuihin ryhmiin:

ESPD-standardin nimitys perustuu luokituskriteereihin:

ESPD-standardin nimen tulee sisältää:

  • numero 19 (määritetty ESPD-standardien luokkaan);
  • yksi numero (pisteen jälkeen), joka osoittaa taulukossa määritellyn standardien luokitusryhmän koodin;
  • kaksinumeroinen luku (viivan jälkeen), joka osoittaa standardin rekisteröintivuoden.

Luettelo ESPD-asiakirjoista

  1. GOST 19.001-77 ESPD. Yleiset määräykset.
  2. GOST 19.101-77 ESPD. Ohjelmatyypit ja ohjelmadokumentit.
  3. GOST 19.102-77 ESPD. Kehitysvaiheet.
  4. GOST 19.103-77 ESPD. Ohjelmien ja ohjelmadokumenttien nimeäminen.
  5. GOST 19.104-78 ESPD. Peruskirjoitukset.
  6. GOST 19.105-78 ESPD. Ohjelmadokumenttien yleiset vaatimukset.
  7. GOST 19.106-78 ESPD. Painettujen ohjelmadokumenttien vaatimukset.
  8. GOST 19.201-78 ESPD. Tekninen tehtävä. Sisällön ja suunnittelun vaatimukset.
  9. GOST 19.202-78 ESPD. Erittely. Sisällön ja suunnittelun vaatimukset.
  10. GOST 19.301-79 ESPD. Testausmenettely ja -menetelmät.
  11. GOST 19.401-78 ESPD. Ohjelman teksti. Sisällön ja suunnittelun vaatimukset.
  12. GOST 19.402-78 ESPD. Ohjelman kuvaus.
  13. GOST 19.404-79 ESPD. Selittävä huomautus. Sisällön ja suunnittelun vaatimukset.
  14. GOST 19.501-78 ESPD. Lomake. Sisällön ja suunnittelun vaatimukset.
  15. GOST 19.502-78 ESPD. Sovelluksen kuvaus. Sisällön ja suunnittelun vaatimukset.
  16. GOST 19.503-79 ESPD. Järjestelmäohjelmoijan opas. Sisällön ja suunnittelun vaatimukset.
  17. GOST 19.504-79 ESPD. Ohjelmoijan opas.
  18. GOST 19.505-79 ESPD. Käyttöohje.
  19. GOST 19.506-79 ESPD. Kielen kuvaus.
  20. GOST 19.508-79 ESPD. Huolto-ohjekirja. Sisällön ja suunnittelun vaatimukset.
  21. GOST 19.604-78 ESPD. Säännöt tulostettujen ohjelmadokumenttien muuttamiseen.
  22. GOST 19.701-90 ESPD. Algoritmien, ohjelmien, tietojen ja järjestelmien kaaviot. Yleissopimukset ja täytäntöönpanosäännöt.
  23. GOST 19.781-90. Ohjelmistot tietojenkäsittelyjärjestelmiin.

Termit ja määritelmät

Kaikista ESPD-standardeista keskitymme vain niihin, joita voidaan käyttää useammin käytännössä.

Ensin osoitamme standardin, jota voidaan käyttää ohjelmointitehtäviä luotaessa.

GOST (ST SEV) 19.201-78 (1626-79). ESPD. Tekninen tehtävä. Sisällön ja suunnittelun vaatimukset. (Uudelleenjulkaistu marraskuussa 1987 versiolla 1).

Tekninen spesifikaatio (TOR) sisältää joukon vaatimuksia ohjelmistolle, ja sitä voidaan käyttää kriteerinä kehitetyn ohjelman tarkistamiseen ja hyväksymiseen. Siksi tekninen eritelmä, joka on melko täysin koottu (ottaen huomioon mahdollisuus ottaa käyttöön lisäosia) ja asiakkaan ja kehittäjän hyväksymä, on yksi PS-projektin perusasiakirjoista.

Toimeksiannon tulee sisältää seuraavat kohdat:

  • käyttöönotto;
  • syitä kehitykseen;
  • kehittämisen tarkoitus;
  • ohjelman tai ohjelmistotuotteen vaatimukset;
  • ohjelmistodokumentaatiota koskevat vaatimukset;
  • tekniset ja taloudelliset indikaattorit;
  • vaiheet ja kehitysvaiheet;
  • valvonta- ja hyväksymismenettely;
  • Sovellukset voivat sisältyä teknisiin eritelmiin.

Ohjelman tai ohjelmistotuotteen ominaisuuksista riippuen on mahdollista selventää osioiden sisältöä, lisätä uusia osioita tai yhdistää yksittäisiä.

Seuraava standardi
GOST (ST SEV) 19.101-77 (1626-79). ESPD. Ohjelmatyypit ja ohjelma-asiakirjat (julkaistu uudelleen marraskuussa 1987 tarkistuksella 1).
Perustaa ohjelmia ja ohjelmadokumentteja tietokoneille, komplekseille ja järjestelmille niiden tarkoituksesta ja laajuudesta riippumatta.

Ohjelmien tyypit

Ohjelmadokumenttien tyypit

Ohjelmadokumentin tyyppi
Erittely Ohjelman kokoonpano ja sen dokumentaatio
Luettelo yrityksistä, jotka säilyttävät alkuperäisiä ohjelmadokumentteja
Ohjelman teksti Ohjelman tallentaminen tarvittavilla kommenteilla
Ohjelman kuvaus Tietoja ohjelman loogisesta rakenteesta ja toiminnasta
Ohjelmaa testattaessa varmennettavat vaatimukset sekä niiden hallinnan menettelytavat ja menetelmät
Tekninen tehtävä Ohjelman tarkoitus ja laajuus, ohjelman tekniset, toteutettavuus- ja erityisvaatimukset, tarvittavat kehitysvaiheet ja -ehdot, testityypit
Selittävä huomautus Algoritmikaavio, yleinen kuvaus ohjelman algoritmista ja (tai) toiminnasta sekä tehtyjen teknisten ja teknis-taloudellisten päätösten perustelut
Toiminnalliset asiakirjat Tiedot ohjelman toiminnan ja toiminnan varmistamiseksi

Toiminnallisten asiakirjojen tyypit

Toiminnallisen asiakirjan tyyppi
Luettelo ohjelman operatiivisista asiakirjoista
Lomake Ohjelman pääominaisuudet, täydellisyys ja tiedot ohjelman toiminnasta
Sovelluksen kuvaus Tiedot ohjelman tarkoituksesta, sovelluksen laajuudesta, käytetyistä menetelmistä, ratkaistavien ongelmien luokasta, käyttörajoituksista, laitteiston vähimmäiskokoonpanosta
Tietoa ohjelman tarkistamiseen, toimivuuden varmistamiseen ja mukauttamiseen tietyn sovelluksen olosuhteisiin
Ohjelmoijan opas Tietoja ohjelman käytöstä
Käyttöohje Tiedot, jotka varmistavat viestintämenettelyn käyttäjän ja tietokonejärjestelmän välillä ohjelman suorittamisen aikana
Kielen kuvaus Kuvaus kielen syntaksista ja semantiikasta
Tietoja testi- ja diagnoosiohjelmien käytöstä teknisten laitteiden huollossa

Toteutustavasta ja sovelluksen luonteesta riippuen ohjelmadokumentit jaetaan alkuperäisiin, kaksoiskappaleisiin ja kopioihin (GOST 2.102-68), jotka on tarkoitettu ohjelman kehittämiseen, ylläpitoon ja käyttöön.

Eri vaiheissa kehitetyt ohjelmadokumentit ja niiden koodit

Asiakirjan tyypin koodi Dokumentti tyyppi Kehitysvaiheet
Alustava suunnittelu Tekninen projekti Työskentely luonnos
komponentti monimutkainen
- Erittely - - ! +
05 Luettelo alkuperäisistä omistajista - - - ?
12 Ohjelman teksti - - + ?
13 Ohjelman kuvaus - - ? ?
20 Lista operatiivisista asiakirjoista - - ? ?
30 Lomake - - ? ?
31 Sovelluksen kuvaus - - ? ?
32 Järjestelmäohjelmoijan opas - - ? ?
33 Ohjelmoijan opas - - ? ?
34 Käyttöohje - - ? ?
35 Kielen kuvaus - - ? ?
46 Huolto-ohjekirja - - ? ?
51 Testiohjelma ja menetelmät - - ? ?
81 Selittävä huomautus ? ? - -
90-99 Muut asiakirjat ? ? ? ?

Tietyntyyppisten operatiivisten asiakirjojen yhdistäminen on sallittua (poikkeuksena operatiivisten asiakirjojen luettelo ja lomake). Tarve yhdistää nämä asiakirjat on ilmoitettu teknisissä eritelmissä. Yhdistetylle asiakirjalle annetaan yhden yhdistetyn asiakirjan nimi ja nimitys. Yhdistetyissä asiakirjoissa on määritettävä tiedot, jotka on sisällytettävä jokaiseen yhdistettävään asiakirjaan.

GOST 19.102-77. ESPD. Kehitysvaiheet.

Määrittää tietokoneiden, kompleksien ja järjestelmien ohjelmien ja ohjelmadokumentaation kehitysvaiheet niiden tarkoituksesta ja käyttöalueesta riippumatta

Kehitysvaiheet, työn vaiheet ja sisältö

Kehitysvaiheet

Työvaiheet
Tekninen tehtävä Perustelut ohjelman kehittämistarpeelle Ongelman muotoilu.
Lähdemateriaalien kokoelma.
Kehitettävän ohjelman tehokkuutta ja laatua koskevien kriteerien valinta ja perustelut.
Tutkimustyön tarpeen perustelut.
Tutkimustyö Syöttö- ja lähtötietojen rakenteen määrittäminen.
Ongelmanratkaisumenetelmien alustava valinta.
Perustelut aiemmin kehitettyjen ohjelmien käyttökelpoisuudesta.
Teknisten välineiden vaatimusten määrittäminen.
Perustus ongelman ratkaisemisen perustavanlaatuiselle mahdollisuudelle.
Teknisten eritelmien kehittäminen ja hyväksyminen Ohjelmavaatimusten määrittäminen.
Toteutettavuustutkimuksen laatiminen ohjelman kehittämistä varten.
Ohjelman kehittämisen vaiheiden, vaiheiden ja ajoituksen sekä sen dokumentoinnin määrittäminen.
Ohjelmointikielten valinta.
Tutkimustyön tarpeen määrittäminen myöhemmissä vaiheissa.
Teknisten eritelmien koordinointi ja hyväksyminen.
Alustava suunnittelu Esisuunnittelun kehittäminen Syöttö- ja lähtötietojen rakenteen alustava kehitys.
Selvitys menetelmistä ongelman ratkaisemiseksi.
Kehitys yleinen kuvaus algoritmi ongelman ratkaisemiseksi.
Toteutettavuustutkimuksen kehittäminen.
Esisuunnitelman hyväksyminen
Esisuunnitelman koordinointi ja hyväksyminen
Tekninen projekti Tekninen projektikehitys Syöttö- ja lähtötietojen rakenteen selventäminen.
Algoritmin kehittäminen ongelman ratkaisemiseksi.
Syöttö- ja lähtötietojen esitystavan määrittäminen.
Kielen semantiikan ja syntaksin määritelmä.
Ohjelmarakenteen kehittäminen.
Laitteiston kokoonpanon lopullinen määrittäminen.
Teknisen suunnittelun hyväksyminen Toimintasuunnitelman laatiminen ohjelmien kehittämistä ja toteuttamista varten.
Selittävä huomautus.
Teknisen suunnittelun koordinointi ja hyväksyminen.
Työskentely luonnos Ohjelman kehittäminen Ohjelmointi ja virheenkorjaus
Ohjelmistodokumentaation kehittäminen Ohjelma-asiakirjojen kehittäminen GOST 19.101-77 vaatimusten mukaisesti.
Ohjelman testaus Testiohjelman ja -menetelmien kehittäminen, koordinointi ja hyväksyminen.
Alustavien tila-, osastojen välisten, hyväksymis- ja muiden testien suorittaminen.
Ohjelman ja ohjelmadokumentaation korjaus testitulosten perusteella.
Toteutus Ohjelman valmistelu ja lähettäminen Ohjelmien ja ohjelmistodokumentaation valmistelu ja siirto ylläpitoon ja (tai) tuotantoon.
Ohjelman ylläpitoon ja (tai) tuotantoon siirtämistä koskevan asiakirjan rekisteröinti ja hyväksyminen.
Ohjelman siirto algoritmien ja ohjelmien rahastoon.

Huomautuksia:

  1. On sallittua sulkea pois toinen kehitysvaihe ja teknisesti perustelluissa tapauksissa toinen ja kolmas vaihe. Näiden vaiheiden tarve on ilmoitettu teknisissä tiedoissa.
  2. Työvaiheita ja (tai) niiden sisältöä saa yhdistää, sulkea pois sekä ottaa käyttöön muita työvaiheita asiakkaan kanssa sovitulla tavalla.

GOST 19.103-77 ESPD. Ohjelmien ja ohjelmadokumenttien nimeäminen

Kehittäjän maakoodi ja kehittäjän organisaatiokoodi määritetään määrätyllä tavalla.

  • Jokaiselle kehitysorganisaatiolle annetaan rekisteröintinumero nousevassa järjestyksessä, alkaen 00001-99999.
  • Ohjelman julkaisunumero tai versionumero. tämän tyyppisen asiakirjan numero, asiakirjan osan numero on annettu nousevassa järjestyksessä 01 - 99. (Jos asiakirja koostuu yhdestä osasta, yhdysviivaa ja osan sarjanumeroa ei ilmoiteta).
  • Ohjelman eritelmän versionumeron ja operatiivisten asiakirjojen luettelon tulee vastata saman ohjelman julkaisunumeroa.

GOST 19.105-78 ESPD. Ohjelmadokumenttien yleiset vaatimukset

Tämä standardi asettaa yleiset vaatimukset tietokoneiden, kompleksien ja järjestelmien ohjelmadokumenttien suorittamiselle niiden tarkoituksesta ja sovellusalueesta riippumatta ja jotka ovat Unified System of Program Documentation (USPD) -standardien mukaisia ​​kaikille asiakirjojen suoritusmenetelmille erilaisissa tiedostoissa. tietovälineitä.

Käytäntöasiakirjan voi esittää osoitteessa erilaisia ​​tyyppejä tietovälineitä ja koostuu seuraavista tavanomaisista osista:
otsikko;
tiedottava;
perus.

Asiakirjan ja sen osien toteuttamista koskevat säännöt kullakin tietovälineellä on vahvistettu ESPD-standardeissa vastaavilla tietovälineillä olevien asiakirjojen suorittamista koskevista säännöistä.

GOST 19.106-78 ESPD. Painettujen ohjelmadokumenttien vaatimukset

Ohjelma-asiakirjat laativat:

  • A4-kokoisille arkeille (GOST 2.301-68) valmisteltaessa asiakirjaa kirjoituskoneella tai käsin;
  • Voidaan tulostaa A3-kokoisille arkeille;
  • asiakirjojen koneellisella suoritusmenetelmällä sallitaan poikkeamat A4- ja A3-muotoa vastaavien arkkien koosta käytettävien teknisten keinojen ominaisuuksien mukaan; A4- ja A3-formaatin arkeille, jotka edellyttävät tietojen tulostuslaitteiden tulostusominaisuuksia, kun asiakirja tuotetaan koneella;
  • typografisten muotojen arkeilla, kun asiakirja tuotetaan typografisella menetelmällä.

Ohjelma-asiakirjan materiaalit on järjestetty seuraavassa järjestyksessä:

Otsikko osa:

  • hyväksymislomake (ei sisälly asiakirjan arkkien kokonaismäärään);
  • otsikkosivu (asiakirjan ensimmäinen sivu);
tieto osa:
  • huomautus;
  • sisällysluettelo;
pääosa:
  • asiakirjan teksti (kuvia, taulukoita jne.)
  • luettelo termeistä ja niiden määritelmistä;
  • lyhennelista;
  • sovellukset;
  • aihehakemisto;
  • luettelo viiteasiakirjoista;
muuta lokiosaa:
  • muuta rekisteröintilomaketta.

Tarvittaessa toimitetaan luettelo termeistä ja niiden määritelmistä, luettelo lyhenteistä, liitteet, aihehakemisto, luettelo viiteasiakirjoista.

Seuraava standardi keskittyy tuloksena olevan kehitystuotteen dokumentointiin:

GOST 19.402-78 ESPD. Ohjelman kuvaus

Asiakirjan "Ohjelman kuvaus" koostumusta sen sisällössä voidaan täydentää osilla ja kappaleilla, jotka on otettu muiden kuvailevien asiakirjojen ja käsikirjojen standardeista: GOST 19.404-79 ESPD. Selittävä huomautus, GOST 19.502-78 ESPD. Sovelluksen kuvaus, GOST 19.503-79 ESPD. Järjestelmäohjelmoijan opas, GOST 19.504-79 ESPD. Ohjelmoijan opas, GOST 19.505-79 ESPD. Käyttöohje.

On myös joukko standardeja, jotka määrittelevät vaatimukset ohjelmistojen siirtoa varten laadittujen koko ohjelmasarjan ja PD:n tallentamiselle. Ne luovat ytimekkäitä kirjanpitoasiakirjoja ja voivat olla hyödyllisiä ohjelmien ja PD:n koko hallinnan virtaviivaistamisessa (loppujen lopuksi sinun on usein vain palautettava perusjärjestys!). On myös standardeja, jotka määrittelevät säännöt asiakirjojen säilyttämiselle PS:n "kotitaloudessa".

Meidän on myös korostettava

GOST 19.301-79 ESPD. Testausohjelma ja -metodologia, jolla (sovitetussa muodossa) voidaan kehittää suunnitteluasiakirjoja ja suorittaa testaustyötä sähköaseman valmiuden ja laadun arvioimiseksi.

Lopuksi uusin standardi hyväksymisvuoden mukaan.

GOST 19.701-90 ESPD. Algoritmien, ohjelmien, tietojen ja järjestelmien kaaviot. Perinteiset graafiset nimitykset ja suoritussäännöt.

Se määrittelee säännöt erityyppisten tietojenkäsittelyongelmien kuvaamiseen käytettävien kaavioiden suorittamiselle sekä keinot niiden ratkaisemiseksi ja on täysin yhteensopiva ISO 5807:1985 -standardin kanssa.

ESPD:n ohella valtioiden välisellä tasolla on voimassa kaksi muuta standardia, jotka liittyvät myös PS:n dokumentointiin ja jotka on otettu käyttöön vasta vähän aikaa sitten kuin suurin osa GOST ESPD:stä.

GOST 19781-90 Ohjelmistot tietojenkäsittelyjärjestelmiin. Termit ja määritelmät. Kehitetty korvaamaan standardit GOST 19.781-83 ja GOST 19.004-80 ja määrittelee termit ja määritelmät tietojenkäsittelyjärjestelmien (SOD) ohjelmistojen (ohjelmistojen) alalla, joita käytetään kaikentyyppisissä dokumentaatioissa ja kirjallisuudessa, jotka sisältyvät standardointityön piiriin tai käyttävät tämän työn tuloksia.

GOST 28388-89 Tietojenkäsittelyjärjestelmät. Asiakirjat magneettisilla tallennusvälineillä. Toteutus- ja käsittelyjärjestys. Koskee ohjelmistojen lisäksi myös suunnittelu-, teknologisia ja muita suunnitteluasiakirjoja, jotka on toteutettu magneettisille tietovälineille.

2.2. GOST 34 -kompleksin standardit

GOST 34 suunniteltiin 80-luvun lopulla kattavaksi joukoksi toisiinsa yhdistettyjä sektoreiden välisiä asiakirjoja. Motiivit ja tuloksena saadut tulokset on kuvattu alla GOST 34:n "Ominaisuudet" -kohdassa. Standardointikohteita ovat erityyppiset (mikä tahansa!) kaiuttimet ja kaikentyyppiset niiden komponentit, eivät vain ohjelmistot ja tietokannat.

Kompleksi on suunniteltu asiakkaan ja kehittäjän väliseen vuorovaikutukseen. ISO12207:n tapaan edellytetään, että asiakas voi kehittää kaiuttimia itselleen (jos hän luo tähän erikoisyksikön). GOST 34:n sanamuoto ei kuitenkaan ole keskittynyt niin selkeään ja tietyssä mielessä symmetriseen molempien osapuolten toimien heijastukseen kuin ISO12207. Koska GOST 34 kiinnittää huomiota pääasiassa projektiasiakirjojen sisältöön, toimien jakaminen osapuolten välillä tapahtuu yleensä tämän sisällön perusteella.

Kaikista olemassa olevista ja toteuttamattomista dokumenttiryhmistä perustumme vain ryhmään 0 ”Yleiset määräykset” ja ryhmään 6 ”AS:n luominen, toiminta ja kehittäminen”. Suosituimpia standardeja voidaan pitää GOST 34.601-90 (AS:n luomisen vaiheet), GOST 34.602-89 (TK AS:n luomiseen) ja ohjeet RD 50-34.698-90 (asiakirjojen sisällön vaatimukset). Standardit määrittelevät AS:n luomisen vaiheet ja vaiheet, mutta eivät nimenomaisesti säädä päästä päähän -prosesseja.

AS-kehityksen yleisessä tapauksessa GOST 34:n vaiheet ja vaiheet on annettu taulukossa:

1. FT - Kaiuttimien vaatimusten muodostus. 1.1. Laitoksen tarkastus ja ydinvoimalaitoksen perustamistarpeen perustelut;
1.2. Kaiuttimien käyttäjävaatimusten muodostaminen;
1.3. Raportin laatiminen tehdystä työstä ja hakemuksen AS:n kehittämiseen (taktiset ja tekniset tiedot);
2. RK - AS-konseptin kehittäminen. 2.1. Objektin tutkimus;
2.2. Tarvittavan tutkimustyön suorittaminen;
2.3. Vaihtoehtojen kehittäminen kaiutinkonseptille, joka vastaa käyttäjien vaatimuksia
2.4. Raportin laatiminen tehdystä työstä
3. TK - AS:n tekninen luominen. 3.1. Tehtävän teknisten eritelmien kehittäminen ja hyväksyminen.
4. EP - Luonnossuunnittelu. 4.1. Järjestelmän ja sen osien alustavien suunnitteluratkaisujen kehittäminen;
4.2. Dokumentaation kehittäminen AU:ta ja sen osia varten.
5. TP - Tekninen suunnittelu. 5.1. Suunnitteluratkaisujen kehittäminen järjestelmälle ja sen osille;
5.2. Dokumentaation kehittäminen ydinvoimalaa ja sen osia varten;
5.3. Dokumentaation kehittäminen ja toteutus kaiuttimien ja/tai täydentävien tuotteiden toimittamiseksi tekniset vaatimukset(tekniset tiedot) niiden kehittämistä varten;
5.4 Suunnittelutehtävien kehittäminen automaatiolaitosprojektin viereisissä osissa.
6. RD - Työdokumentaatio. 6.1. Työdokumentaation kehittäminen järjestelmää ja sen osia varten;
6.2. Ohjelmien kehittäminen tai mukauttaminen.
7. VD - Käyttöönotto. 7.1. Automaatiolaitoksen valmistelu laitoksen käyttöönottoa varten;
7.2. Henkilöstön koulutus;
7.3. Täydellinen kaiutinsarja toimitetuilla tuotteilla (ohjelmistot ja laitteistot, ohjelmistot ja laitteistot, tietotuotteet);
7.4 Rakennus- ja asennustyöt;
7.5 Käyttöönotto työt;
7.6 Alustavien testien suorittaminen;
7.7. Koetoiminnan suorittaminen;
7.8 Hyväksymistestien suorittaminen.
8. Sp - AC-tuki. 8.1. Töiden suorittaminen takuuvelvoitteiden mukaisesti;
8.2. Takuun jälkeinen huolto.

Kussakin vaiheessa kehitettyjen asiakirjojen sisältö kuvataan. Tämä määrittää potentiaaliset mahdollisuudet tunnistaa sisällöllisellä tasolla rinnakkain tai peräkkäin suoritettavat päästä-päähän -työt (eli pohjimmiltaan prosessit) ja niihin liittyvät tehtävät. Tätä tekniikkaa voidaan käyttää luotaessa profiilia projektin elinkaaristandardeista, mukaan lukien sovitut GOST 34- ja ISO12207 -standardien osajoukot.

Päämotiivi: "Baabelin tornin" ongelman ratkaiseminen.

80-luvulla syntyi tilanne, jossa eri toimialat ja toimialat käyttivät huonosti koordinoitua tai epäjohdonmukaista NTD:tä - "normatiivista ja teknistä dokumentaatiota". Tämä vaikeutti järjestelmien integrointia ja niiden tehokkaan yhteistoiminnan varmistamista. Siellä oli erilaisia ​​​​standardikomplekseja ja järjestelmiä, jotka asettivat vaatimukset erilaisia ​​tyyppejä AC.

Standardien soveltamiskäytäntö on osoittanut, että niissä sovelletaan olennaisesti (mutta ei tiukkojen määritelmien mukaan) yhtenäistä käsitejärjestelmää, yhteisiä standardointikohteita on monia, mutta standardien vaatimukset eivät ole keskenään johdonmukaisia, niissä on eroja. työn koostumus ja sisältö, erot asiakirjojen nimeämisessä, koostumuksessa, sisällössä ja toteutuksessa jne.

Tietysti tämä tilanne heijasteli osittain AS:n kehittämisen edellytysten luonnollista monimuotoisuutta, kehittäjien tavoitteita sekä käytettyjä lähestymistapoja ja tekniikoita.

Näissä olosuhteissa oli mahdollista analysoida tällaista monimuotoisuutta ja sitten edetä esimerkiksi yhdellä kahdesta pitkälti vastakkaisesta tavasta:

  1. Kehitetään yksi yleinen käsitteellinen ja terminologinen järjestelmä, yleinen kaava kehitys, yleinen setti asiakirjat sisällöineen ja määritellä ne pakollisiksi kaikille AS:ille;
  2. Määrittele myös yksi yleinen käsitteellinen ja terminologinen järjestelmä, yleistetty kompleksi Laitteistovaatimukset, joukon laatukriteerejä, mutta tarjoavat suurimman vapauden kehityssuunnitelman, asiakirjojen kokoonpanon ja muiden näkökohtien valinnassa, asettaen vain vähimmäisvaatimukset, jotka mahdollistaisivat:
    • määrittää tuloksen laatutaso;
    • valita ne erityiset menetelmät (elinkaarimallien, dokumenttien jne. kanssa), jotka sopivat parhaiten kehitysolosuhteisiin ja vastaavat käytettyjä tietoteknologioita;
    • työskennellä siten minimaalisilla rajoituksilla kaiuttimen suunnittelijan tehokkaalle toiminnalle.

Standardijoukon 34 kehittäjät valitsivat menetelmän, joka oli lähellä ensimmäistä edellä mainituista, eli he valitsivat polun lähemmäksi tiettyjen menetelmien kaavioita kuin standardeja, kuten ISO12207. Käsitteellisen perustan yhtenäisyydestä johtuen standardit ovat kuitenkin edelleen sovellettavissa erittäin moniin sovelluksiin. laaja valikoima tapauksia.

Sopeutumiskyky määräytyy muodollisesti kykyjen mukaan:

  • jättää pois alustava suunnitteluvaihe ja yhdistää "Tekninen suunnittelu" ja "Yksityiskohtainen dokumentointi" -vaiheet;
  • jättää pois vaiheet, yhdistää ja jättää pois useimmat asiakirjat ja niiden osat;
  • syötä lisäasiakirjoja, asiakirjoja ja töitä;
  • luomalla dynaamisesti ns. ChTZ - yksityiset tekniset tiedot - se on melko joustava muodostaa AS:n elinkaaren; Pääsääntöisesti tätä tekniikkaa käytetään suurten yksiköiden (alajärjestelmien, kompleksien) tasolla, joiden vuoksi katsotaan perustelluksi luoda CTZ, mutta ei ole merkittäviä syitä rajoittaa voimakkaasti tätä elinkaarihallintamenetelmää.

Ydinvoimalaitosten rakentamiseen osallistuvien organisaatioiden suorittamat vaiheet ja virstanpylväät on määritelty sopimuksissa ja teknisissä eritelmissä, mikä on lähellä ISO-lähestymistapaa.

Yhtenäisen, melko laadullisesti määritellyn terminologian käyttöön ottaminen, melko kohtuullisen teosten, asiakirjojen, tukityyppien jne. luokituksen olemassaolo on varmasti hyödyllistä. GOST 34 edistää todella erilaisten järjestelmien täydellisempää ja laadukkaampaa yhdistämistä, mikä on erityisen tärkeää olosuhteissa, joissa kehitetään yhä monimutkaisempia integroituja järjestelmiä, kuten esimerkiksi CAD-CAM, joka sisältää prosessinohjausjärjestelmän, ohjausjärjestelmä, CAD-suunnittelija, CAD-teknikko, ASNI ja muut järjestelmät.

On määritelty useita tärkeitä säännöksiä, jotka heijastavat AS:n ominaisuuksia standardointikohteena, esimerkiksi: ”yleensä AS koostuu ohjelmisto- ja laitteisto- (PTK), ohjelmisto- ja metodologisista (PMK) komplekseista ja yksittäisiä komponentteja organisatorinen, tekninen, ohjelmisto- ja tietotuki."

PTC:n ja AS:n käsitteiden erottaminen vahvisti periaatteen, jonka mukaan AS ei ole "tietokannan sisältävä IS", vaan:

  • "organisaatio- ja tekninen järjestelmä, joka varmistaa automaatioon perustuvien ratkaisujen kehittämisen tietoprosesseja eri toiminta-aloilla (johtaminen, suunnittelu, tuotanto jne.) tai niiden yhdistelmillä" (RD 50-680-88 mukaan), mikä on erityisen tärkeää liiketoiminnan uudelleensuunnittelun kannalta;
  • "Järjestelmä, joka koostuu henkilöstöstä ja joukosta automaatiotyökaluja heidän toimintaansa ja joka toteuttaa tietotekniikkaa vakiintuneiden toimintojen suorittamiseen" (GOST 34.003-90:n mukaan).

Nämä määritelmät osoittavat, että AS on ennen kaikkea henkilöstöä, joka tekee päätöksiä ja suorittaa muita johtamistoimia organisatorisin ja teknisin keinoin.

Velvoitteen aste:

aiempi täysi pakollinen vaatimus puuttuu, GOST34-materiaalit ovat pääosin tulleet metodologiseksi tueksi, useammin asiakkaille, joilla on standardissa joukko vaatimuksia teknisten eritelmien sisällöstä ja ydinvoimalaitosten testien suorittamisesta. Samalla GOST34:n hyödyllisyys voi moninkertaistua, jos niitä käytetään joustavammin AS-elinkaariprofiilin muodostuksessa.

Osapuolten välisen vuorovaikutuksen keskeinen asiakirja on ydinvoimalan rakentamisen tekniset eritelmät. TK on tärkein alkuperäinen dokumentti AS:n luomista ja sen hyväksymistä varten tekniset eritelmät määrittelevät tärkeimmät asiakkaan ja kehittäjän väliset vuorovaikutuskohdat. Tässä tapauksessa kehittäjäorganisaatio kehittää tekniset tiedot (standardin GOST 34.602-89 mukaisesti), mutta asiakas antaa tekniset tiedot muodollisesti kehittäjälle (RD 50-680-88:n mukaan).

2.3. Venäjän federaation valtion standardit (GOST R)

Venäjän federaatiossa on useita standardeja ohjelmistojen dokumentoimiseksi, jotka on kehitetty kansainvälisten ISO-standardien suoran soveltamisen perusteella. Tämä? uusimmat standardit hyväksymishetkellä. Jotkut niistä on osoitettu suoraan projektipäälliköille tai tietopalveluiden johtajille. Samaan aikaan ne ovat kohtuuttoman vähän tunnettuja ammattilaisten keskuudessa. Tässä heidän esityksensä.

GOST R ISO/IEC 9294-93 Tietotekniikka. Ohjelmiston dokumentaation hallintaopas. Standardi on täysin kansainvälisen ISO/IEC TO 9294:1990 -standardin mukainen ja antaa suosituksia ohjelmistodokumentaation tehokkaaseen hallintaan niiden luomisesta vastaaville esimiehille. Standardin tarkoituksena on auttaa määrittämään strategia ohjelmistojen dokumentoimiseksi; dokumentointistandardien valinta; dokumentointimenettelyjen valinta; tarvittavien resurssien määrittäminen; dokumentaatiosuunnitelmien laatiminen.

GOST R ISO/IEC 9126-93 Tietotekniikka. Ohjelmistotuotteiden arviointi. Laatuominaisuudet ja ohjeet niiden käyttöön. Standardi on täysin kansainvälisen standardin ISO/IEC 9126:1991 mukainen. Laatuominaisuus ymmärretään kontekstissaan "ohjelmistotuotteen ominaisuuksien (attribuuttien) joukkona, jonka avulla sen laatu kuvataan ja arvioidaan". Standardi määrittelee kuusi kattavaa ominaisuutta, jotka kuvaavat ohjelmiston (ohjelmistot, ohjelmistotuotteet) laatua mahdollisimman vähäisellä päällekkäisyydellä: toiminnallisuutta; luotettavuus; käytännöllisyys; tehokkuus; säestys; liikkuvuus. Nämä ominaisuudet muodostavat perustan ohjelmiston laadun lisäselvityksille ja kuvauksille.

GOST R ISO 9127-94 Tietojenkäsittelyjärjestelmät. Kuluttajaohjelmistopakettien käyttäjädokumentaatio ja pakkaustiedot. Standardi on täysin kansainvälisen ISO 9127:1989 -standardin mukainen. Tässä standardissa kuluttajaohjelmistopaketti (CPP) määritellään "ohjelmistotuotteeksi, joka on suunniteltu ja myyty suorittamaan tietty toiminto; ohjelma ja siihen liittyvä dokumentaatio on pakattu myyntiin yhtenä kokonaisuutena". Käyttäjädokumentaatiolla tarkoitetaan dokumentaatiota, joka tarjoaa loppukäyttäjälle tietoja ohjelmiston asennuksesta ja käytöstä. Pakkauksessa olevat tiedot viittaavat PP:n ulkopakkauksessa oleviin tietoihin. Sen tarkoituksena on tarjota mahdollisille ostajille ensisijaiset tiedot ohjelmistosta.

GOST R ISO/IEC 8631-94 Tietotekniikka. Ohjelmistorakenteet ja symboleja esittelylleen. Kuvaa prosessialgoritmien esittämistä.

2.4. Kansainvälinen standardi ISO/IEC 12207: 1995-08-01

ISO12207:n ensimmäinen painos valmisteli vuonna 1995 yhteinen tekninen komitea ISO/IEC JTC1 " Tietotekniikka,SC7-alikomitea, Ohjelmistotuotanto."

Määritelmän mukaan ISO12207 on ohjelmistojen elinkaariprosessien perusstandardi, joka keskittyy erilaisiin (kaikkiin!) ohjelmistotyyppeihin ja AS-projektityyppeihin, joihin ohjelmisto sisältyy osana. Standardi määrittelee strategian ja yleisen järjestyksen ohjelmistojen luomisessa ja toiminnassa, ja se kattaa ohjelmiston elinkaaren ideoiden konseptoinnista elinkaaren loppuunsaattamiseen.

Erittäin tärkeät HUOMAUTUKSET STANDARDISTA:

  1. Ohjelmiston elinkaaren aikana käytettävien prosessien tulee olla yhteensopivia AS:n elinkaaren aikana käytettyjen prosessien kanssa. (Tämä selittää tarkoituksenmukaisuuden jakaminen kaiuttimien ja ohjelmistojen standardit.)
  2. Ainutlaatuisten tai erityisten prosessien, toimintojen ja tehtävien lisääminen tulee määritellä osapuolten välisessä sopimuksessa. Sopimus ymmärretään laajasti: laillisesti virallistetusta sopimuksesta epäviralliseen sopimukseen, yksi osapuoli voi määritellä sopimuksen itselleen asetetuksi tehtäväksi.
  3. Standardi ei pohjimmiltaan sisällä erityisiä toimintatapoja, saati sitten valmistettuja ratkaisuja tai dokumentaatiota. Se kuvaa ohjelmistojen elinkaariprosessien arkkitehtuuria, mutta ei täsmennä yksityiskohtaisesti, kuinka prosesseihin sisältyvät palvelut ja tehtävät tulee toteuttaa tai suorittaa, eikä sen tarkoitus ole määrätä tuloksena olevan dokumentaation nimeä, muotoa tai tarkkaa sisältöä. Tämän tyyppiset päätökset tekee standardin käyttäjä.

STANDARDI MÄÄRITELMÄT:

  1. Järjestelmä on yhden tai useamman prosessin, laitteiston, ohjelmiston, laitteiston ja ihmisten yhdistelmä, joka mahdollistaa tiettyjen tarpeiden tai tavoitteiden tyydyttämisen.
  2. Elinkaarimalli- rakenne, joka sisältää prosesseja, toimia ja tehtäviä, joita suoritetaan ohjelmistotuotteen kehittämisen, käytön ja ylläpidon aikana koko järjestelmän elinkaaren ajan vaatimusten määrittelystä käytön loppuun asti.
    Monet prosessit ja tehtävät on suunniteltu niin, että ne voidaan mukauttaa ohjelmistoprojektien mukaan. Sopeutumisprosessi on prosessi, jossa poistetaan prosesseja, toimintoja ja tehtäviä, jotka eivät sovellu tiettyyn projektiin. Sopeutumiskyky: maksimi
  3. Pätevyysvaatimus- joukko kriteerejä tai ehtoja (pätevyysvaatimukset), jotka on täytettävä, jotta ohjelmistotuote voidaan luokitella spesifikaatioidensa mukaiseksi (ehdot täyttäväksi) ja käyttövalmiiksi kohdeympäristössä.

Standardi ei vaadi tietty malli Elinkaari- tai ohjelmistokehitysmenetelmä, mutta määrittelee, että standardin käyttäjät vastaavat ohjelmistoprojektin elinkaarimallin valinnasta, standardin prosessien ja tehtävien mukauttamisesta tähän malliin, ohjelmistokehitysmenetelmien valinnasta ja soveltamisesta. , ohjelmistoprojektiin sopivien toimien ja tehtävien suorittamiseen.

ISO12207-standardi keskittyy yhtä lailla organisoimaan kummankin osapuolen toimintaa: toimittaja (kehittäjä) ja ostaja (käyttäjä); voidaan soveltaa yhtä hyvin, kun molemmat osapuolet ovat samasta organisaatiosta.

Jokainen elinkaaren prosessi on jaettu joukkoon toimia, jokainen toimenpide joukkoon tehtäviä. Erittäin tärkeä ero ISO:n välillä: jokaisen prosessin, toiminnon tai tehtävän käynnistää ja suorittaa toinen prosessi tarpeen mukaan, eikä siinä ole ennalta määrättyjä sarjoja (tietenkin, samalla kun säilytetään tehtävien lähtötietojen mukainen yhteyksien logiikka jne.). ).

ISO12207-standardi kuvaa:

  1. 5 tärkeintä ohjelmiston elinkaaren prosessia:
    • Hankintaprosessi. Määrittää AS:n, ohjelmistotuotteen tai ohjelmistopalvelun ostavan ostoyrityksen toimet.
    • Toimitusprosessi. Määrittää toimittajayrityksen toimet, joka toimittaa ostajalle järjestelmän, ohjelmistotuotteen tai ohjelmistopalvelun.
    • Kehitysprosessi. Määrittää ohjelmistotuotteen ja ohjelmistotuotteen rakentamisen periaatetta kehittävän kehitysyrityksen toimet.
    • Toimiva prosessi. Määrittää operaattoriyrityksen toimet, joka huolehtii järjestelmän (eikä pelkästään ohjelmiston) ylläpidosta sen toiminnan aikana käyttäjien edun mukaisesti. Toisin kuin toiminnot, jotka kehittäjä määrittelee käyttöohjeissa (tämä kehittäjätoiminto on säädetty kaikissa kolmessa tarkasteltavassa standardissa), operaattorin toimet käyttäjien konsultoimiseksi, palautetta jne., jonka hän suunnittelee itse ja ottaa vastaavat vastuut.
    • Huoltoprosessi. Määrittää ohjelmistotuotteen ylläpitoa suorittavan huoltohenkilöstön toimet, joka on ohjelmistotuotteen muutosten hallinta, sen nykyisen tilan ja toiminnallisen soveltuvuuden tukeminen, mukaan lukien ohjelmistotuotteen asennus ja poistaminen tietokonejärjestelmään.
  2. 8 apuprosessia, jotka tukevat toisen prosessin toteuttamista, jotka ovat kiinteä osa ohjelmistotuotteen koko elinkaarta ja varmistavat ohjelmistoprojektin asianmukaisen laadun:
    • ongelmanratkaisu;
    • dokumentointi;
    • kokoonpanon hallinta;
    • laadunvarmistus, jossa käytetään laadunvarmistusryhmän jäljellä olevien prosessien tuloksia, jotka sisältävät:
      • Varmennusprosessi;
      • Sertifiointiprosessi;
      • Osallistuva arviointiprosessi;
      • Tarkastusprosessi.
  3. 4 organisaatioprosessia:
    • Hallintoprosessi;
    • Infrastruktuurin luomisprosessi;
    • Parannusprosessi;
    • Oppimisprosessi.

Niihin liittyy erityinen mukautusprosessi, joka määrittelee tärkeimmät toimenpiteet, jotka ovat tarpeen standardin mukauttamiseksi tietyn projektin olosuhteisiin.

Parannusprosessilla ei tässä tarkoiteta AS:n tai ohjelmiston parantamista, vaan organisaatiossa todellisuudessa suoritettavien hankinta-, kehitys-, laadunvarmistus- jne. prosessien parantamista.

Vaiheita, vaiheita, vaiheita ei ole annettu, mikä antaa alla kuvatun mukautumisasteen.

Standardin "dynaaminen" määräytyy prosessien ja tehtävien järjestyksen mukaan, jossa prosessi kutsuu tarvittaessa toista tai osaa siitä.

  • Hankintaprosessin suorittaminen järjestelmän tai ohjelmiston vaatimusten analysoinnin ja tallentamisen osalta voi laukaista kehitysprosessin vastaavien tehtävien suorittamisen;
  • Toimitusprosessissa toimittajan on johdettava alihankkijoita hankintaprosessin mukaisesti ja suoritettava varmennus ja kelpuuttaminen asiaankuuluvien prosessien suhteen;
  • Ylläpito voi edellyttää järjestelmän ja ohjelmiston kehittämistä, joka suoritetaan Kehitysprosessin mukaisesti.

Tämä luonne mahdollistaa minkä tahansa elinkaarimallin toteuttamisen.

Ohjelmistovaatimusanalyysiä suoritettaessa on 11 laatuominaisuuksien luokkaa, joita käytetään myöhemmin laadunvarmistuksessa.

Tässä tapauksessa kehittäjän on määritettävä ja dokumentoitava ohjelmistovaatimukset:

  1. Toiminnalliset ja käyttöönottospesifikaatiot, mukaan lukien suoritus, fyysiset ominaisuudet ja käyttöympäristöolosuhteet, joissa ohjelmisto on suoritettava;
  2. Ulkoiset liitännät (rajapinnat) ohjelmistoyksikön kanssa;
  3. Pätevyysvaatimukset;
  4. Luotettavuuseritelmät, mukaan lukien käyttö- ja huoltomenetelmiin, ympäristöaltistukseen ja henkilövahinkojen todennäköisyyteen liittyvät tiedot;
  5. Turvallisuustiedot
  6. Teknisen psykologian (ergonomian) inhimillisten tekijöiden eritelmät, mukaan lukien ne, jotka liittyvät manuaaliseen ohjaukseen, ihmisen ja laitteiden väliseen vuorovaikutukseen, henkilöstön rajoituksiin ja inhimillisille virheille ja oppimiselle herkkiä inhimillisen huomion vaativille alueille;
  7. Tieto- ja tietokantavaatimusten määrittely;
  8. Toimitetun ohjelmistotuotteen asennus- ja hyväksymisvaatimukset käyttö- ja huoltopaikoilla (käyttö);
  9. Käyttäjän dokumentaatio;
  10. Käyttäjien työ- ja suorituskykyvaatimukset;
  11. Käyttäjien palveluvaatimukset.

    (On mielenkiintoista ja tärkeää, että nämä ja vastaavat ominaisuudet vastaavat hyvin GOST 34:ssä järjestelmätuen tyypeille säädettyjä ydinvoimalan ominaisuuksia.)

Standardi sisältää hyvin vähän tietokannan suunnitteluun tarkoitettuja kuvauksia. Tätä voidaan pitää perusteltuna, koska eri järjestelmät ja erilaiset sovellusohjelmistopaketit eivät vain pysty käyttämään hyvin tietyntyyppisiä tietokantoja, vaan eivät myöskään

ISO12207 sisältää siis joukon prosesseja, toimintoja ja tehtäviä, jotka kattavat mahdollisimman laajan valikoiman mahdollisia tilanteita mahdollisimman mukautuvilla.

Se näyttää esimerkin siitä, kuinka hyvin organisoitu standardi tulisi rakentaa ja sisältää mahdollisimman vähän rajoituksia (periaate "ei kahta samanlaista projektia"). Samalla on suositeltavaa sisällyttää yksityiskohtaiset määritelmät prosesseista, dokumenttien muodoista jne. erilaisiin toiminnallisiin standardeihin, osastojen säädösasiakirjoihin tai omistettuihin menetelmiin, joita voidaan käyttää tai olla käyttämättä tietyssä projektissa.

Tästä syystä on hyödyllistä pitää ISO12207 keskeisenä standardina, jonka säännökset otetaan ensimmäiseksi "ydin" säännöskokonaisuudeksi laadittaessa tietyn projektin elinkaaristandardien profiilia. Tämä "sauva" voi määrittää ohjelmiston ja AS:n elinkaarimallin, kaaviokuva laadunvarmistus, projektinhallintamalli

Ammatinharjoittajat käyttävät toista tapaa: he kääntävät sen itse ja käyttävät sitä projekteissaan. nykyaikaiset standardit sähköaseman elinkaaren järjestämiseen ja niiden dokumentointiin. Mutta tämä polku kärsii ainakin siitä haitasta erilaisia ​​käännöksiä ja eri kehittäjien ja asiakkaiden tekemät standardien mukautukset vaihtelevat monissa yksityiskohdissa. Nämä erot eivät väistämättä koske vain nimiä, vaan myös niiden sisällöllisiä määritelmiä, jotka on otettu käyttöön ja joita käytetään standardeissa. Näin ollen tällä tiellä jatkuva hämmennys on väistämätöntä, ja tämä on suoraan vastoin paitsi standardien, myös kaikkien pätevien metodologisten asiakirjojen tavoitteita.

Tällä hetkellä All-Russian Research Institute of Standards on valmistellut ehdotuksia ohjelmistojen dokumentointistandardien parantamiseksi ja kehittämiseksi.

viitetiedot

Asiakirjastandardien ostamiseksi suosittelemme ottamaan yhteyttä seuraaviin organisaatioihin:

    IPK "julkaisustandardit", Tieteellisten ja teknisten asiakirjojen jakelun alueellinen osasto (kauppa "Standards"), 17961, Moskova, st. Donskaya, 8, puh. 236-50-34, 237-00-02, faksi/puh. 236-34-48 (koskee GOST:ia ja GOST R:ää).

1. Yleiset määräykset

LLC "PROMNOVATSIYA" (OGRN, osoite jne.), jäljempänä "Kehittäjä", sitoutuu suojelemaan ja ylläpitämään käyttäjien antamien tietojen luottamuksellisuutta, kun he käyttävät Kehittäjäsivustoa (jäljempänä "sivusto") ja ohjelmistoa. Kehittäjän luoma (jäljempänä Ohjelma). Tämä käytäntö määrittelee säännöt, joiden mukaisesti Sivuston tai Ohjelman käyttäjän (jäljempänä Käyttäjä), joka on saanut niihin laillisen pääsyn laillisin ehdoin, tietojen käsittely tapahtuu.

Ohjelman käytön ehto on Käyttäjän suostumus tälle käytännölle, joka on julkaistu Kehittäjän verkkosivustolla osoitteessa: http://privacypolicy.site. Jokaisella Ohjelman käyttökerralla ja/tai todellisella käyttökerralla käyttäjä hyväksyy tämän käytännön ehdot sekä sopimusehdot, jotka määrittävät kyseisen ohjelman käyttöä koskevat säännöt ja jotka on julkaistu Sivustolla versioissa, jotka olivat voimassa silloin, kun Sivustoa tai Ohjelmaa todellisuudessa käytetään.

2. Henkilötietojen käyttö

Hyväksymällä tämän käytännön ehdot sekä käyttämällä Ohjelmaa tai Sivustoa, Käyttäjä hyväksyy ja hyväksyy niiden tietojen käsittelyn, jotka tulevat Kehittäjän saataville Käyttäjän Ohjelman tai Sivuston käytön aikana.

Kehittäjä käyttää Käyttäjän henkilötietoja ylläpitoon ja tarjottujen palvelujen laadun parantamiseen. Osa henkilökohtaisia ​​tietoja voidaan toimittaa pankille tai maksujärjestelmä, jos näiden tietojen antaminen johtuu menettelystä, jolla varoja siirretään siihen maksujärjestelmään, jonka palveluita Käyttäjä haluaa käyttää. Kehittäjä tekee kaikkensa pitääkseen Käyttäjän henkilötiedot turvassa. Henkilötietoja voidaan luovuttaa Venäjän federaation lainsäädännön määrittelemissä tapauksissa tai kun hallinto pitää tällaisia ​​toimia tarpeellisina noudattaakseen oikeudellista menettelyä, oikeuden määräystä tai oikeusprosessia, joka on tarpeen, jotta Käyttäjä voi työskennellä Sivuston tai Ohjelman kanssa. Muissa tapauksissa Käyttäjän Kehittäjälle välittämiä tietoja ei missään olosuhteissa luovuteta kolmansille osapuolille.

Käyttäjän tietoja käsitellään ohjelman tai Sivuston käytön aloittamisesta hetkeen, jolloin niiden käyttö lopetetaan, ellei Ohjelman tai Sivuston toimivuus toisin määrää ja/tai sovellettavassa laissa ei toisin määrätä.

3. Tämän käytännön vaikutus

Kehittäjä pidättää oikeuden tehdä muutoksia ja lisäyksiä tähän käytäntöön. Käytännön uusi versio tulee voimaan siitä hetkestä, kun se on julkaistu sivustolla. Käyttäjä sitoutuu tutustumaan säännöllisesti uusiin käytäntöihin.

Kehittäjän sivusto voi sisältää linkkejä muille sivustoille. Sivusto ei ole vastuussa näiden sivustojen sisällöstä, laadusta ja turvallisuuskäytännöistä. Tämä tietosuojalausunto koskee vain tietoja, jotka on julkaistu suoraan Kehittäjän sivustolla tai Ohjelmassa.