Esimerkkikuvaus ohjelmasta GOST 19.402 78 mukaan. Nuorten hävittäjien kurssi: Ohjelmadokumentaation laatimisesta (dokumentaatio)

Tämä standardi keskittyy tuloksena olevan kehitystuotteen dokumentointiin.

Tarkkaan ottaen on olemassa kaksi erilaista asiakirjaa, joilla on kuitenkin paljon yhteistä. Tämä on YLEINEN KUVAUS (GOST 19.502-78) ja OHJELMAN KUVAUS (GOST 19.402-78). Koska on kuitenkin erittäin vaikeaa luoda molempia todella laadukkaasti turvautumatta lähes täydelliseen päällekkäisyyteen ja repeämään kappaleita, riittäisi toteuttaa yksi, yleisempi, "hybridi" dokumentti. Kutsutaan sitä "Ohjelman kuvaukseksi".

Itse asiassa "Ohjelman kuvausta" sen sisällössä voidaan täydentää osioilla ja kappaleilla, jotka on otettu muiden kuvailevien asiakirjojen ja käsikirjojen standardeista: GOST 19.404-79 ESPD. Selittävä huomautus, GOST 19.503-79 ESPD. Järjestelmäohjelmoijan opas, GOST 19.504-79 ESPD. Ohjelmoijan opas, GOST 19.505-79 ESPD. Käyttöohje ja niin edelleen. Erityisesti selittävästä huomautuksesta voit ottaa algoritmikaavion, yleinen kuvaus ohjelman algoritmi ja (tai) toiminta sekä tehtyjen teknisten ja teknis-taloudellisten päätösten perustelut.

Ohjelman kuvauksen tulee sisältää tieto-osa - huomautus ja sisältö.

Asiakirjan pääosan tulee koostua johdanto-osasta ja seuraavista osista:
toiminnallinen tarkoitus;
logiikan kuvaus.
Käyttöehdot;
koostumus ja toiminnot.

Ohjelman erityispiirteistä riippuen voidaan lisätä lisäosia.

SISÄÄN Johdanto-osa Asiakirja sisältää yleistä tietoa ohjelmasta - koko nimi, nimi, sen mahdolliset sovellukset jne.

Esimerkiksi: Ohjelma "Automaattinen työasema itsekulkevien aseiden kehittäjälle" on tarkoitettu... toteutettu.... Ohjelma tukee...

Luvussa Tarkoitus ilmoittaa ohjelman tarkoitus ja antaa yleinen kuvaus ohjelman toiminnasta, sen tärkeimmistä ominaisuuksista, tiedot ohjelman laajuudelle asetetuista rajoituksista sekä ilmoittaa myös sähköisen tietokoneita ja työssä käytettävät laitteet.

Esimerkiksi: Ohjelma on suunniteltu ratkaisemaan ongelmia... Ohjelma edustaa automatisoidun työaseman ydintä...

Käyttäjällä on mahdollisuus..., toteuttaa..., ajaa..., analysoida..., saada analyysin ja käsittelyn tuloksia..., rakentaa... jne.

Luvussa " Logiikan kuvaus"osoita:
kuvaus ohjelman rakenteesta ja sen pääosista (esimerkiksi: Ohjelma sisältää seuraavat asiat:
käyttöliittymä,
moduuli kaavion polkujen määrittämiseen,
siirtofunktion laskentamoduuli,
moduuli amplitudi- ja vaihetaajuusominaisuuksien rakentamiseen,
moduuli vastauksen muodostamiseen polynomivaikutukseen,
tekstieditori)
kuvaus komponenttien toiminnoista ja niiden välisistä kytkennöistä;
Esimerkiksi: Ohjelma koostuu kuudesta moduulista: liitäntämoduuli; määritelmämoduuli...; laskentamoduuli...; moduuli... jne.
Käyttöliittymämoduuli on rakennettu kahden tyyppiseen dialogiin: kysymys-vastaus-dialogiin ja valikkotyyppiseen dialogiin. Liitäntämoduuli ohjaa...
Määritelmämoduuli... Se on...
Laskentamoduuli... jne.
tiedot ohjelmointikielestä;
Esimerkiksi: Ohjelma on kirjoitettu kielellä ... kääntäjällä ...
kuvaus kunkin komponentin tulo- ja lähtötiedoista;

Esimerkiksi : SYÖTTÖTIEDOT. Ohjelman syöttötiedot ovat tekstitiedosto, joka kuvaa tutkittavan järjestelmän kaavion laajennettua ilmaantuvuusmatriisia.

OUTPUT. Lähtö on:

· näytetään graafisena ja tekstitietoa(järjestelmäanalyysin tulokset);

· tiedostot yhdessä graafisista muodoista - kopiot kuvasta rakennetuista ominaisuuksista (taajuusvaste, vaihevaste jne.);

· tekstitiedostot - suoritettujen tutkimusten raportit;

· järjestelmän tilan diagnostiikka ja viestit kaikista tapahtuvista virheistä.

· kuvaus komponenttien logiikasta (tarvittaessa tulee kirjoittaa kuvaus ohjelmakaavioista). Ohjelman logiikkaa kuvattaessa on luonnollisesti välttämätöntä linkittää se ohjelman tekstiin.

Luvussa Koostumus ja toiminnot esitä kuvaus ohjelmien koostumuksesta ja toiminnasta sekä ongelmien ratkaisemiseen käytetyistä menetelmistä.

Luvussa Käyttöehdot ohjelman toteuttamisen edellyttämät edellytykset ilmoitetaan (vaatimukset tämän ohjelman ja muiden ohjelmien edellyttämille teknisille välineille, syöttö- ja lähtötietojen yleiset ominaisuudet sekä organisatoriset, tekniset ja teknologiset vaatimukset ja ehdot jne.). ).

Esimerkiksi : Ohjelmaa käytetään henkilökohtainen tietokone(PC) tyyppiä IBM PC/AT. Interaktiivisessa tilassa työskentelyyn käytetään näyttöä, näppäimistöä ja hiirtä. Grafiikkatilan tukemiseen tarvitaan EGA (VGA) -sovitin. Syöttötiedot tallennetaan levykkeille ja/tai kiintolevyille. Ohjelma toimii käyttöjärjestelmän alla...

Kuvauksen liite voi sisältää viitemateriaalia (kuvituksia, taulukoita, kaavioita, esimerkkejä jne.)

Älä myöskään unohda ilmoittaa latausmoduulin nimi sekä kuvaus koko menettelystä

Järjestelmän soittaminen ja käynnistäminen

V.E. Karpov

Tämä asiakirja sisältää lyhyen kuvauksen ESPD-standardeista, joiden tunteminen on välttämätöntä, jotta opiskelijat voivat suorittaa ohjelmistojärjestelmien luomiseen liittyviä kursseja ja projekteja. Lisäksi se voi olla hyödyllinen ohjelmistodokumentaation laadun parantamisen kannalta yleisesti.

TEKNISET TIEDOT (GOST 19.201-78)

1. Yleiset määräykset

KEHITTÄMISVAIHEET (GOST 19.102-77)

OHJELMAN KUVAUS (GOST 19.402-78)

OHJELMAN TEKSTI (GOST 19.401-78)

OHJELMA JA TESTAUSMENETELMÄ (GOST 19.301-79)

PAINETTUJEN OHJELMISTOASIAKIRJOJEN VAATIMUKSET (GOST 19.106-78)

Standardointi dokumentoinnin alalla ohjelmisto

Miten eteenpäin

Ohjelmistojen (PS) dokumentaation valmistelu olemassa olevien GOST-standardien mukaisesti

2. Ehdon yleiset ominaisuudet

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

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

Ohjelmointityön ehkä epämiellyttävin ja vaikein vaihe on ohjelmadokumentaation luominen. Valitettavasti yleensä tätä joko ei opeteta ollenkaan tai parhaimmillaan he eivät kiinnitä riittävästi huomiota vastaanotettujen asiakirjojen laatuun. Tämän taiteen hallinta on kuitenkin usein yksi tärkeimmistä ohjelmoijan laadun määrittävistä tekijöistä.

Ensinnäkin kyky luoda ohjelmadokumentaatio määrittää ohjelmoijan ammattitason. Asiakas ei syvenny upeimmankaan ohjelman monimutkaisuuteen ja ominaisuuksiin. Asiakas lukee asiakirjat ensin. Myös psykologisella tekijällä on suuri rooli tässä. Erityisesti entinen Neuvostoliiton ohjelmointikoulu oli (ja on nyt) arvostettu kaikkialla maailmassa. Nykyaikaisia ​​kotimaisia ​​ohjelmoijia ei enää noteerata. Luokka ei ole sama. Nykyään ohjelmia ei enää kirjoiteta, vaan käännetään (ja nämä ovat "kaksi suurta eroa"). Joten "klassiseen" tyyliin luotu ohjelmistodokumentaatiopaketti (jäljempänä PD) luo suotuisimman vaikutelman asiakkaallesi tai työnantajallesi. Lisäksi, jos PD:n kirjoittaja välttää lauseita, kuten "klikkaa vierityspalkkia...", "ruuvi" jne. Valitettavasti tällainen ammattikieltä muistuttava puhe kätkee yleensä joko ajatusten puutteen tai täydellisen tyhjyyden (kirjailijaan teki lähtemättömän vaikutuksen erään hänen tuttavansa tarina tietystä "pelailijasta", joka joko "chattaili" jonkun kanssa tai oli mukana "moderoimassa". " Tai jotain sellaista.). PD:n kieli on eräänlainen byrokraattinen, hyvin konservatiivinen kieli. Sillä on oma erityinen viehätyksensä. Ymmärrä, että termit kiintolevyasema, litteä levyasema, käsikäyttöinen manipulaattori, kuten "hiiri" (tai "pulla", kuten se oli kirjoitettu johonkin vanhasta PD-paketista) kuulostavat täysin erilaiselta kuin vastaava "ruuvi", " flop" ja yksinkertaisesti "hiiri". Muuten, asiat ovat jo edenneet siihen pisteeseen, että jopa erikoisuuskin on kuulemma ilmestynyt - tekninen kirjoittaja, ts. henkilö, joka osaa luoda ohjelmistodokumentaation.

Toiseksi, hyvin suunniteltu (tarkemmin luotu) PD-paketti säästää sinut monilta ongelmilta. Erityisesti voit päästä eroon ärsyttävistä kysymyksistä ja perusteettomista väitteistä yksinkertaisesti ohjaamalla käyttäjän dokumentaatioon. Tämä koskee ennen kaikkea tärkeintä asiakirjaa - toimeksiantoehtoja. Puhumme tästä alla, mutta nyt voimme muistuttaa sinua usean miljoonan dollarin oikeusjutusta IBM:ää vastaan. Tämän kanteen nosti yksi suuri kustantamo, joka oli tyytymätön VT:n laatuun ja ohjelmisto. IBM voitti tapauksen. Ja hän voitti vain siksi, että hän esitti molempien osapuolten allekirjoittaman toimeksiannon. Tämä tapahtui kauan sitten, 70-luvulla, mutta se ei muuta asian ydintä.

Yksi asia vielä. On tärkeää luoda ensimmäinen PD-paketti. Tämä riittää rakentamaan kaikki seuraavat sen perusteella käyttämällä sitä mallina tai mallina. Mutta tämä on tehtävä erittäin tehokkaasti. rauhassa. Erittäin perusteellinen.

Ensin sinun on aseistauduttava GOST: illa. GOST määrittelee kaiken. Se sisältää erityisesti meitä kiinnostavan Unified System of Program Documentation (USPD). Ehkä vaikein asia on saada itse GOST. GOST:n tulee olla vain painetussa alkuperäisessä muodossa. Niitä myydään (ainakin niin oli ennen) erikoisliikkeissä. Erityisesti dokumentoinnin alan standardien hankkimiseksi voit ottaa yhteyttä seuraaviin organisaatioihin:

• IPK "Publishing Standards", NTD:n alueellinen jakeluosasto (myymälä "Standards"), 17961, Moskova, st. Donskaya, 8, puh. 236-50-34, 237-00-02, faksi/puh. 236-34-48 (koskee GOST:ia ja GOST R:ää).
• VNIIKI Gosstandart of Russia (lukusali), 103001, Moskova, Granatny per. nro 4, puh. 290-50-94 (kansainvälisten, ulkomaisten standardien ja muiden tieteellisten ja teknisten asiakirjojen osalta).

Eikä lainauksia tai toissijaisia ​​lähteitä. GOST on laki. Ja vielä enemmän, ei Internetiä (kuvittele, että tuomioistuin antaa tuomion joltain verkkosivustolta ladatun rikoslain tulosteen avulla). Älä luota muihin kuin alkuperäiseen. Kirjoittajan on kuitenkin turvauduttava ESPD:n lainaamiseen, jolloin hän luopuu kaikesta vastuusta.

Aloitetaan yleisistä säännöksistä Yhtenäinen järjestelmä ohjelmistodokumentaatio (jotka on myös määritelty vastaavassa GOST 19.001-77 -standardissa).

Yhtenäinen ohjelmadokumentaatiojärjestelmä on joukko valtion standardeja, jotka määrittävät toisiinsa liittyvät säännöt ohjelmien ja ohjelmadokumentaation kehittämiselle, suorittamiselle ja levittämiselle.

ESPD-standardit määrittelevät yleiset määräykset ja perusstandardit, säännöt kehitysdokumentaation toteuttamiselle, säännöt valmistusdokumentaation toteuttamiselle, säännöt tukidokumentaation toteuttamisesta, säännöt käyttöasiakirjojen toteuttamisesta, säännöt ohjelmadokumentaation levittämisestä ja muut standardit. . ESPD sisältää:

• perustavaa laatua olevat sekä organisatoriset ja metodologiset standardit;
• standardit, jotka määrittelevät tietojenkäsittelyssä käytettävien ohjelma-asiakirjojen muodot ja sisällön;
• standardit, jotka varmistavat ohjelma-asiakirjojen kehittämisen automatisoinnin.

Yleisesti ottaen ESPD-asiakirjojen luettelo on erittäin laaja. Se sisältää erityisesti seuraavat GOST:t:

• GOST 19.001-77 ESPD. Yleiset määräykset.
• GOST 19.101-77 ESPD. Ohjelmatyypit ja ohjelma-asiakirjat (julkaistu uudelleen marraskuussa 1987 muutoksineen).
• GOST 19.102-77 ESPD. Kehitysvaiheet.
• GOST 19.103-77 ESPD. Ohjelmien ja ohjelmadokumenttien nimeäminen.
• GOST 19.104-78 ESPD. Peruskirjoitukset.
• GOST 19.105-78 ESPD. Ohjelmadokumenttien yleiset vaatimukset.
• GOST 19.106-78 ESPD. Painettujen ohjelmadokumenttien vaatimukset.
• GOST 19.201-78 ESPD. Tekninen tehtävä. Sisällön ja suunnittelun vaatimukset.
• GOST 19.202-78 ESPD. Erittely. Sisällön ja suunnittelun vaatimukset.
• GOST 19.301-79 ESPD. Testiohjelma ja menetelmät.
• GOST 19.401-78 ESPD. Ohjelman teksti. Sisällön ja suunnittelun vaatimukset.
• GOST 19.402-78 ESPD. Ohjelman kuvaus.
• GOST 19.404-79 ESPD. Selittävä huomautus. Sisällön ja suunnittelun vaatimukset.
• GOST 19.501-78 ESPD. Lomake. Sisällön ja suunnittelun vaatimukset.
• GOST 19.502-78 ESPD. Sovelluksen kuvaus. Sisällön ja suunnittelun vaatimukset.
• GOST 19.503-79 ESPD. Järjestelmäohjelmoijan opas. Sisällön ja suunnittelun vaatimukset.
• GOST 19.504-79 ESPD. Ohjelmoijan opas.
• GOST 19.505-79 ESPD. Käyttöohje.
• GOST 19.506-79 ESPD. Kielen kuvaus.
• GOST 19.508-79 ESPD. Huolto-ohjekirja. Sisällön ja suunnittelun vaatimukset.
• GOST 19.604-78 ESPD. Säännöt tulostettujen ohjelmadokumenttien muuttamiseen.
• GOST 19.701-90 ESPD. Algoritmien, ohjelmien, tietojen ja järjestelmien kaaviot. Yleissopimukset ja täytäntöönpanosäännöt.
• GOST 19.781-90. Ohjelmistot tietojenkäsittelyjärjestelmiin.

Kuten näette, suurin osa ESPD-kompleksista kehitettiin 70- ja 80-luvuilla. Jotkut näistä standardeista ovat vanhentuneita, eikä niissä ole joitakin haittoja. Ensinnäkin ne eivät heijasta joitain nykyaikaisia ​​suuntauksia ohjelmien ja ohjelmadokumentaation suunnittelussa, ja toiseksi nämä standardit sisältävät useita päällekkäisyyksiä ohjelmadokumentaation fragmenteista. Kuitenkin, paremman puuttuessa meidän on keskityttävä niihin.

Joten ESPD-standardit virtaviivaistavat ohjelmistojärjestelmien dokumentointiprosessia. Ensinnäkin ESPD-standardien edellyttämä ohjelmadokumenttien kokoonpano ei kuitenkaan ole ollenkaan niin "jäykkä" kuin miltä se saattaa näyttää: standardit mahdollistavat lisätyyppien lisäämisen ohjelmistojärjestelmän (PS) dokumentaatioon, ja , toiseksi, asiakkaan vaatimusten perusteella, ne ovat hyväksyttäviä joitain muutoksia sekä vakiintuneiden PD-tyyppien rakenteeseen että sisältöön. Lisäksi voidaan todeta, että ESPD-standardit (ja tämä koskee kaikkia muita PS-alan standardeja - GOST 34, kansainvälinen ISO/IEC-standardi jne.) ovat luonteeltaan neuvoa-antavia. Tosiasia on, että Venäjän federaation standardointilain mukaisesti näistä standardeista tulee pakollisia sopimusperusteisesti - ts. viitattaessa niihin ohjelmiston kehittämistä (toimitusta) koskevassa sopimuksessa.

Ennen kuin alamme pohtia ohjelmistodokumentaation laatimissääntöjä, on tarpeen tehdä seuraava huomautus. Jokaiseen asiakirjaan kannattaa laittaa johdanto. Esittelyssä puhutaan yleisesti. Relevanssista, tarpeellisuudesta jne. Esiintyjän tavoitteena on tässä osoittaa tämän työn tekemisen merkitys ja välttämättömyys. Alku on yleensä vakio: "Nyt olemassa olevat lukuisat järjestelmät... ... avaa todellisia näkymiä..." jne. Tähän lisätään yleensä lainauksia eri henkilöiden puheista (tämä on puhtaasti psykologinen näkökohta): "...kuten sanottiin viime täysistunnossa, kongressissa, konferenssissa jne. Voit aloittaa siitä, että ".. Tänä päivänä alkuperäiskansojen sosiaalisten ja taloudellisten muutosten aikakaudella...yleensä tärkeintä tässä ei ole liioitella.

Ja kauemmas. Kuvatessaan tuotettaan kehittäjä sekoittaa usein komponentin ja kompleksin käsitteet. Nämä ovat erityyppisiä ohjelmia. Komponentti määritellään "ohjelmaksi, jota pidetään yhtenä kokonaisuutena, joka suorittaa täydellisen toiminnon ja jota käytetään itsenäisesti tai osana kompleksia", ja kompleksi on "ohjelma, joka koostuu kahdesta tai useammasta komponentista ja (tai) komplekseista, jotka suorittavat toisiinsa liittyviä yhteyksiä. toimii itsenäisesti tai osana toista kompleksia."

GOST:n mukaan tämä standardi (julkaistu uudelleen marraskuussa 1987) määrittää menettelyn teknisten eritelmien rakentamiseksi ja laatimiseksi tietokoneiden, kompleksien ja järjestelmien ohjelman tai ohjelmistotuotteen kehittämiseksi niiden tarkoituksesta ja laajuudesta riippumatta.

Sinun tulee olla erittäin varovainen ja varovainen luodessasi sitä, koska... Usein taitavasti (ja asiantuntevasti) laadittu tekninen eritelmä määrää koko työn onnistumisen. Teknisistä eritelmistä sovitaan asiakkaan kanssa, joka yleensä pyrkii tuomaan mahdollisimman paljon ristiriitaisia ​​ja paisutettuja vaatimuksia. Toimeenpanijan tehtävänä on päinvastoin helpottaa hänen elämäänsä. Mutta kun allekirjoitukset on asetettu molemmille puolille, on liian myöhäistä toistaa mitään.

Toimeksianto laaditaan A4- ja/tai A3-kokoisille arkeille pääsääntöisesti täyttämättä arkin kenttiä. Arkkien (sivujen) numerot sijoitetaan arkin yläosaan tekstin yläpuolelle.

Tehdäkseen muutoksia ja lisäyksiä tekniseen taustaan ​​ohjelman tai ohjelmistotuotteen myöhemmissä kehitysvaiheissa, siihen julkaistaan ​​lisäys. Teknisten eritelmien lisäysten yhteensovittaminen ja hyväksyminen tapahtuu samalla tavalla kuin teknisille eritelmille on määrätty.

Toimeksiannon tulee sisältää seuraavat kohdat:

• nimi ja soveltamisala;
• kehittämisen perusta;
• kehittämisen tarkoitus;
• ohjelman tai ohjelmistotuotteen tekniset vaatimukset;
• vaiheet ja kehitysvaiheet;
• valvonta- ja hyväksymismenettely;
• sovellukset.

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

Luvussa Nimi ja laajuus ilmoittaa ohjelman tai ohjelmistotuotteen nimi, lyhyt kuvaus käyttöalueesta ja objektista, jossa ohjelmaa tai ohjelmistotuotetta käytetään.

Luvussa Kehittämisen perusta on ilmoitettava:

• asiakirja(t), joiden perusteella kehitys suoritetaan;
• tämän asiakirjan hyväksynyt organisaatio ja sen hyväksymispäivämäärä;
• kehittämisaiheen nimi ja (tai) symboli.

Koulutusprosessin erityispiirteisiin liittyen pohjana voi olla kurssisuunnittelun toimeksianto, laitoksen __.__.päivämääräys. N ___., sopimus __.__. N ___. , ja niin edelleen.

Luvussa Kehittämisen tarkoitus Ohjelman tai ohjelmistotuotteen toiminnallinen ja toiminnallinen tarkoitus on ilmoitettava. Voit rajoittaa itsesi tässä yhteen tai kahteen lauseeseen. Tärkeintä on määritellä selkeästi, mihin tämä ohjelma on tarkoitettu.

Esimerkiksi: Ohjelma on jatkuvan lineaarisen automaattisen ohjausjärjestelmän (ACS) kehittäjälle tarkoitetun automatisoidun työaseman (AWS) ydin, jonka avulla käyttäjä voi ratkaista yksinkertaisten mallien analysointiongelmia.

Luku Ohjelman tai ohjelmistotuotteen tekniset vaatimukset tulee sisältää seuraavat alakohdat:

• toiminnallisia ominaisuuksia koskevat vaatimukset;
• luotettavuusvaatimukset;
• käyttöehdot;
• teknisten välineiden koostumusta ja parametreja koskevat vaatimukset;
• tietojen ja ohjelmistojen yhteensopivuusvaatimukset;
• merkintä- ja pakkausvaatimukset;
• kuljetuksen ja varastoinnin vaatimukset;
• erityisvaatimukset.

Toisin sanoen, tästä alkaa yksityiskohdat. Kuvaa, mitä ohjelman pitäisi tehdä ja miltä sen pitäisi näyttää.

Toiminnallisia ominaisuuksia koskevat vaatimukset. Tässä on ilmoitettava suoritettavien toimintojen koostumukseen, syöttö- ja lähtötietojen järjestämiseen, ajoitusominaisuuksiin jne. liittyvät vaatimukset.

Esimerkiksi: Ohjelman pitäisi antaa ... laskea ... rakentaa ... luoda ...

Syöttötiedot: tekstitiedosto annetulla...

Tulostustiedot: graafiset ja tekstitiedot - järjestelmäanalyysin tulokset...; tekstitiedostot - raportit ... järjestelmän tilan diagnostiikasta ja ilmoituksista kaikista tapahtuneista virheistä.

Luotettavuusvaatimukset. Luotettavan toiminnan varmistamisen vaatimukset on määriteltävä (stabiilin toiminnan varmistaminen, tulo- ja lähtötietojen valvonta, toipumisaika vian jälkeen jne.).

Täällä on vaikea "arvata" mitään. Paras tapaus on, että ohjelmasi toimii vain täysin oikeilla tiedoilla. Yleensä Asiakas ei suostu tähän, mutta voit yrittää.

Esimerkiksi: Ohjelman on toimittava tutkittavan kaavion tietyn laajennetun matriisin kanssa toiminta-algoritmin mukaisesti, luotava virheilmoituksia, kun lähtötiedot on määritetty väärin, ja tuettava interaktiivista tilaa käyttäjälle tarjottujen ominaisuuksien puitteissa.

Käyttöehdot. Käyttöolosuhteet (ympäristön lämpötila, suhteellinen kosteus jne. valituille tallennusvälinetyypeille), joissa määritellyt ominaisuudet on varmistettava, sekä palvelun tyyppi, tarvittava henkilöstömäärä ja pätevyys on ilmoitettava.

Tässä kohdassa ei yleensä ole vaikeuksia. Valitettavasti lauseke asiakkaan ammattitaidosta on välttämättä implikoitu. Tämä on tietysti toinen syy löytää vikoja ohjelmassasi. Tässä voimme kuitenkin rajoittua lauseisiin, kuten "Ohjelman käyttöolosuhteet ovat samat kuin IBM PC:n ja yhteensopivien tietokoneiden käyttöolosuhteet", "Ohjelman tulee olla suunniteltu ei-ammattimaiselle käyttäjälle." ja niin edelleen.

Vaatimukset teknisten välineiden koostumukselle ja parametreille. Ilmoittakaa vaadittu teknisten välineiden koostumus ja ilmoittakaa niiden tekniset ominaisuudet.

Tärkeintä tässä ei ole unohtaa mitään ja huolehtia kaikesta, toisaalta (muuten lipsahtaa sisään jonkinlainen IBM PC/XT, jossa on yksivärinen näyttö ja ilman hiirtä), ja toisaalta ei liioittele sitä kohonneilla vaatimuksilla, muuten asiakas löytää joustavamman urakoitsijan.

Esimerkki: Sinulla on oltava IBM PC -yhteensopiva tietokone, jossa on EGA (VGA) -näytönohjain. Vaadittu levytila ​​- vähintään 600 kt, vapaata tilaa RAM-muisti- vähintään 400 kt. On toivottavaa, että sinulla on EMS-ajuri ja hiirityyppinen manipulaattori.

Tietojen ja ohjelmistojen yhteensopivuuden vaatimukset. Ominaisuudet ovat samat kuin edellisessä kappaleessa. Tässä tulee määritellä vaatimukset tietorakenteille syöttö- ja lähdössä sekä ratkaisumenetelmiä, lähdekoodeja ja ohjelmointikieliä. Tietojen ja ohjelmien suoja on tarvittaessa varmistettava.

Esimerkiksi: Ohjelman tulee toimia itsenäisesti MS DOS OS -version vähintään 3.3 alla. Perusohjelmointikieli on Turbo Pascal 6.0.

Merkintä- ja pakkausvaatimukset sekä kuljetus- ja varastointivaatimukset ovat varsin eksoottisia. Yleisesti ottaen tämä osoittaa ohjelmistotuotteen merkintävaatimukset, pakkausvaihtoehdot ja -tavat. Ja kuljetusta ja varastointia koskevissa vaatimuksissa on ilmoitettava ohjelmistotuotteelle kuljetusolosuhteet, varastointipaikat, varastointiolosuhteet, varastointiolosuhteet, varastointiajat eri olosuhteissa.

Erityisvaatimukset ovat erittäin tärkeä asia. Niitä on parempi välttää, jos mahdollista. Ja ilmoittaa siitä heti.

Esimerkiksi: Ohjelman ajoitusominaisuuksille ei ole erityisiä vaatimuksia. Ohjelman kapasitiivisille ominaisuuksille ei ole erityisiä vaatimuksia.

Tekniset ja taloudelliset indikaattorit. Tämä ohjelmoijan vaikein kohta ei ole aina olemassa. Sitä tarvitaan ensisijaisesti silloin, kun tavoitteenasi on perustella suoritettavan työn valtavaa tehokkuutta ja tärkeyttä. Tämä tuote toimii yleensä erittäin hyvin asiakkaalle. Tämä on ainakin paras perustelu kehityksen ajoitukselle ja rahamäärälle.

Tässä osiossa tulee ilmoittaa: arvioitu taloudellinen tehokkuus, arvioitu vuotuinen tarve (esimerkiksi: odotettu puheluiden määrä koko kompleksiin vuodessa - 365 työkertaa), kehityksen taloudelliset edut verrattuna parhaisiin kotimaisiin ja ulkomaisiin näytteisiin tai analogit.

Lisäksi on suositeltavaa määritellä sekä ohjelman kehittämisen arvioidut kustannukset että ohjelmoinnin monimutkaisuus.

Vaiheet ja kehitysvaiheet(tätä käsitellään tarkemmin alla) määritä tarvittavat kehitysvaiheet, työvaiheet ja työn sisältö (luettelo kehitettävistä, sovittavista ja hyväksyttävistä ohjelmadokumenteista) sekä pääsääntöisesti kehittämisen määräajat ja määrittää esiintyjät.

Vakiovaiheet kuvataan tässä. Tärkeintä on määrittää ajoitus oikein. Jos mahdollista, yritä jakaa vaiheet tasaisesti määräaikojen (ja summien) kesken. Muista, että kaikki projektit eivät pääse loppuvaiheeseen. Ja jokaisesta vaiheesta pitäisi olla raportit. Muista myös, että työprojekti vie eniten aikaa. Mikäli dokumentaatiota ei täytetä ajoissa, Asiakkaalla on täysi oikeus olla hyväksymättä työtä ollenkaan kaikista siitä aiheutuvista seurauksista.

Tärkeimmät ja välttämättömät vaiheet ja vaiheet ovat itse toimeksianto, esisuunnittelu, tekniset ja työsuunnitelmat.

• Alustava suunnittelu. Tässä vaiheessa kehitetään yksityiskohtaisesti tulo- ja lähtötietojen rakenteet ja määritellään niiden esitystapa. Algoritmin yleiskuvausta, itse algoritmia ja ohjelman rakennetta kehitetään. Ohjelman kehittämistä ja toteuttamista varten laaditaan toimintasuunnitelma.
• Tekninen projekti. Sisältää kehitetyn algoritmin ongelman ratkaisemiseksi sekä menetelmiä lähtötietojen seurantaan. Täällä kehitetään työkaluja virheiden käsittelyyn ja diagnostisten viestien antamiseen, määritetään lähtötietojen esittämislomakkeet ja teknisten laitteiden konfiguraatio.
• Työskentely luonnos. Tässä vaiheessa suoritetaan ohjelman ohjelmointi ja virheenkorjaus, ohjelmadokumenttien, ohjelmien ja testausmenetelmien kehittäminen. Testaus- ja virheenkorjausesimerkkejä valmistellaan. Dokumentaatio ja graafinen materiaali viimeistellään. Yleensä täsmennetään, että ohjelman kehittämisen aikana tulee laatia seuraavat asiakirjat:

• ohjelman teksti;
• ohjelman kuvaus;
• testiohjelma ja menetelmät;
• sovelluksen kuvaus;
• käyttöohjeet.

Nämä ovat vakiovaatimuksia. Jos Asiakas suostuu siihen, että kaikkea tätä luetteloa ei voida esittää, tämä tarkoittaa, että hänen aikeensa sinua ja tuotettasi kohtaan eivät ole vakavat.

Graafista materiaalia ei välttämättä ole. Varsinkin kun et aio raportoida työsi tuloksia. Mutta vakavissa projekteissa tämä kohta vaaditaan.

Esimerkiksi: Ohjelman kehittämisen aikana tulee valmistella seuraava graafinen materiaali:

• tekniset ja taloudelliset indikaattorit;
• ohjelman rakenne;
• muoto ohjelman syöttötietojen esittämiseksi;
• yleinen algoritmikaavio (2 arkkia);
• laskennalliset perusalgoritmit;
• esimerkki ohjelman toiminnasta.

Luvussa Valvonta- ja hyväksymismenettely testityypit on määriteltävä ja Yleiset vaatimukset työn vastaanottamiseksi. Jos mahdollista, ilmoita tässä kappaleessa, että "kehityksen valvonta ja hyväksyminen tapahtuu asiakkaan toimittamilla laitteilla", muuten sinua voidaan vaatia tuomaan laitteet mukaasi.

Esimerkiksi: Kehityksen ohjaus ja hyväksyminen suoritetaan testaustestien ja virheenkorjausesimerkkien perusteella. Tämä tarkistaa kaikkien ohjelman toimintojen suorittamisen.

SISÄÄN Sovellukset Tarvittaessa tekniset tiedot toimittaa:

• luettelo tutkimuksista ja muista kehittämisen perusteista;
• algoritmikaaviot, taulukot, kuvaukset, perustelut, laskelmat ja muut dokumentit, joita voidaan käyttää kehityksen aikana;

• muista kehityslähteistä.

Tämä standardi määrittelee ohjelmien kehitysvaiheet, ohjelmadokumentaation sekä työn vaiheet ja sisällön:

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. Algoritmin yleiskuvauksen kehittäminen 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. Teknisten laitteiden 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ö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ä esitellä muita työvaiheita asiakkaan kanssa sovitulla tavalla.

Tämä standardi keskittyy tuloksena olevan kehitystuotteen dokumentointiin.

Tarkkaan ottaen on olemassa kaksi erilaista asiakirjaa, joilla on kuitenkin paljon yhteistä. Tämä on YLEINEN KUVAUS (GOST 19.502-78) ja OHJELMAN KUVAUS (GOST 19.402-78). Koska on kuitenkin erittäin vaikeaa luoda molempia todella laadukkaasti turvautumatta lähes täydelliseen päällekkäisyyteen ja repeämään kappaleita, riittäisi toteuttaa yksi, yleisempi, "hybridi" dokumentti. Kutsutaan sitä "Ohjelman kuvaukseksi".

Itse asiassa "Ohjelman kuvausta" sen sisällössä voidaan täydentää osioilla ja kappaleilla, jotka on otettu muiden kuvailevien asiakirjojen ja käsikirjojen standardeista: GOST 19.404-79 ESPD. Selittävä huomautus, GOST 19.503-79 ESPD. Järjestelmäohjelmoijan opas, GOST 19.504-79 ESPD. Ohjelmoijan opas, GOST 19.505-79 ESPD. Käyttöohje jne. Erityisesti selittävästä huomautuksesta voit ottaa kaavion algoritmista, yleisen kuvauksen algoritmista ja (tai) ohjelman toiminnasta sekä perustelut tehtyille teknisille ja teknis-taloudellisille päätöksille.

Ohjelman kuvauksen tulee sisältää tieto-osa - huomautus ja sisältö.

Asiakirjan pääosan tulee koostua johdanto-osasta ja seuraavista osista:

• toiminnallinen tarkoitus;
• logiikan kuvaus.
• Käyttöehdot;
• koostumus ja toiminnot.

Ohjelman erityispiirteistä riippuen voidaan lisätä lisäosia.

SISÄÄN Johdanto-osa Asiakirja sisältää yleistä tietoa ohjelmasta - koko nimi, nimi, sen mahdolliset sovellukset jne.

Esimerkiksi: Ohjelma "Automaattinen työasema itsekulkevien aseiden kehittäjälle" on tarkoitettu... toteutettu.... Ohjelma tukee...

Luvussa Tarkoitus ilmoittaa ohjelman tarkoitus ja antaa yleinen kuvaus ohjelman toiminnasta, sen tärkeimmistä ominaisuuksista, tiedot ohjelman laajuudelle asetetuista rajoituksista sekä ilmoittaa myös toiminnan aikana käytettävien elektronisten tietokoneiden ja laitteiden tyypit.

Esimerkiksi: Ohjelma on suunniteltu ratkaisemaan ongelmia... Ohjelma edustaa automatisoidun työaseman ydintä...

Käyttäjällä on mahdollisuus..., toteuttaa..., ajaa..., analysoida..., saada analyysin ja käsittelyn tuloksia..., rakentaa... jne.

Luvussa " Logiikan kuvaus"osoita:

• kuvaus ohjelmarakenteesta ja sen pääosista

(esimerkiksi: Ohjelma sisältää seuraavat:

• käyttöliittymä,
• moduuli kaavion polkujen määrittämiseen,
• siirtofunktion laskentamoduuli,
• moduuli amplitudi- ja vaihetaajuusominaisuuksien rakentamiseen,
• moduuli vastauksen muodostamiseen polynomivaikutukseen,
• tekstieditori) .

• kuvaus komponenttien toiminnoista ja niiden välisistä kytkennöistä;

Esimerkiksi: Ohjelma koostuu kuudesta moduulista: liitäntämoduuli; määritelmämoduuli...; laskentamoduuli...; moduuli... jne.

Käyttöliittymämoduuli on rakennettu kahden tyyppiseen dialogiin: kysymys-vastaus-dialogiin ja valikkotyyppiseen dialogiin. Liitäntämoduuli ohjaa...

Määritelmämoduuli... Se on...

Laskentamoduuli... jne.

• tiedot ohjelmointikielestä;

Esimerkiksi: Ohjelma on kirjoitettu kielellä ... kääntäjällä ...

• kuvaus kunkin komponentin tulo- ja lähtötiedoista;

Esimerkiksi: INPUT DATA. Ohjelman syöttödata on tekstitiedosto, joka kuvaa tutkittavan järjestelmän graafin laajennettua ilmaantuvuusmatriisia.

OUTPUT. Lähtö on:

• näytöllä näkyvät graafiset ja tekstitiedot (järjestelmäanalyysin tulokset);
• tiedostot yhdessä graafisista muodoista - kopiot kuvasta rakennetuista ominaisuuksista (taajuusvaste, vaihevaste jne.);
• tekstitiedostot - suoritettujen tutkimusten raportit;
• järjestelmän tilan diagnostiikka ja viestit kaikista tapahtuvista virheistä.

• kuvaus komponenttien logiikasta (tarvittaessa kirjoitetaan kuvaus ohjelmakaavioista).

Ohjelmalogiikkaa kuvattaessa linkki ohjelman tekstiin on välttämätön.

Luvussa Koostumus ja toiminnot esitä kuvaus ohjelmien koostumuksesta ja toiminnasta sekä ongelmien ratkaisemiseen käytetyistä menetelmistä.

Luvussa Käyttöehdot ohjelman toteuttamisen edellyttämät edellytykset ilmoitetaan (vaatimukset tämän ohjelman ja muiden ohjelmien edellyttämille teknisille välineille, syöttö- ja lähtötietojen yleiset ominaisuudet sekä organisatoriset, tekniset ja teknologiset vaatimukset ja ehdot jne.). ).

Esimerkki: Ohjelmaa käytetään IBM PC/AT -tyyppisessä henkilökohtaisessa tietokoneessa (PC). Interaktiivisessa tilassa työskentelyyn käytetään näyttöä, näppäimistöä ja hiirtä. Grafiikkatilan tukemiseen tarvitaan EGA (VGA) -sovitin. Syöttötiedot tallennetaan levykkeille ja/tai kiintolevyille. Ohjelma toimii käyttöjärjestelmän alla...

Kuvauksen liite voi sisältää viitemateriaalia (kuvituksia, taulukoita, kaavioita, esimerkkejä jne.)

Älä myöskään unohda ilmoittaa latausmoduulin nimi sekä kuvaus koko menettelystä

Järjestelmän soittaminen ja käynnistäminen

Ohjelmatekstin suunnittelun vaatimukset ovat melko yksinkertaiset ja pätevälle ohjelmoijalle luontevat. Tärkeintä tätä dokumenttia luotaessa on, että ohjelman tekstin tulee olla luettavaa.

Edelleen on pakollista koota tieto-osa - huomautukset ja sisältö.

Asiakirjan pääosan tulee koostua yhden tai useamman osion teksteistä, joille annetaan nimet.

Kunkin ohjelmatiedoston teksti alkaa otsikolla, joka osoittaa:

• ohjelman nimi,
• kirjoittaja,
• ohjelman luomispäivä,
• versionumero,
• viimeisen muutoksen päivämäärä.

Kommentteja vaaditaan sekä sisennyssääntöjen tiukkaa noudattamista. Muista, että jopa kyvyttömyys luoda ohjelmistodokumentaatiota voi olla perusteltua. Mutta ruma ohjelmateksti - ei koskaan. Viittauksia siihen, että tämä teksti on tekijälle itselleen ymmärrettävä, ei oteta vakavasti. Ei pitäisi olla häpeä antaa ohjelmatekstejä muiden ihmisten luettavaksi.

Alla on esimerkki tällaisesta hyvin luettavasta ohjelmatekstistä (otettu Nikolai Gekhtin verkkosivuilta, sähköposti: [sähköposti suojattu], http://users.omskreg.ru/~geht)

/* Windows 98 -lähteet

Windows 98:n lähdekoodi */ #sisällytä "win31.h" #sisällytä "win95.h" #sisällytä "evenmore.h" #include "oldstuff.h" #include "billrulz.h" #include "monopoly.h" # define INSTALL = HARD char make_prog_look_big; ei ); disable_Netscape(); disable_RealPlayer(); disable_something(athing); ; if(fast_cpu()) ( set_wait_states(lots); set_mouse(speed, very_slow); set_mouse(toiminta, hyppy); set_mouse(reaction, joskus ); ) /* printf("Tervetuloa Windows 3.11:een"); * printf("Tervetuloa Windows 95:een" ) else system_memory = open("a:\swp0001.swp", O_CREATE while(something) ( lepotila(5); get_user_input(); nukkua(5); act_on_user_input(); nukkua(5); ) luo_yleinen_suojausvika();

Tämä asiakirja sisältää kuvauksen siitä, mitä ja miten on tehtävä, jotta voidaan varmistaa (ja vakuuttaa asiakas), että ohjelma toimii oikein. Itse asiassa tämä asiakirja on ratkaiseva hyväksyntätestien kannalta. Hyvin suunniteltu testiohjelma ja -metodologia on avain hyväksymistodistuksen allekirjoittamiseen, ts. asia, johon käytit niin paljon vaivaa ja aikaa.

Muodollisesti tätä GOST:ia käytetään suunnitteluasiakirjojen kehittämiseen ja testitöiden suorittamiseen ohjelmistojärjestelmän valmiuden ja laadun arvioimiseksi. Dokumentti sisältää kuvauksen testauksen kohteesta ja tarkoituksesta, vaatimukset ohjelma- ja ohjelmistodokumentaatiolle, testauksen keinot ja menettelytavat sekä kuvauksen testiesimerkeistä.

Tämän asiakirjan osat on kuvattu helpommin ja selkeämmin esimerkkien muodossa.

Testiobjekti

Esimerkki: Testiobjekti on ohjelma ..., joka on tarkoitettu ...

Testauksen tarkoitus

Esimerkki: Ohjelman luotettavuuden tarkistaminen.

Ohjelman vaatimukset

Esimerkki: Ohjelman toiminta ei saa johtaa häiriöön (järjestelmän kohtalokkaaseen häiriöön). Vuoropuhelun organisoinnin tulisi tarjota suoja virheellisten tietojen syöttämiseltä. Ohjelman tulee tarjota järjestelmän tilan diagnostiikka ja ilmoitukset tapahtuneista virheistä... jne.

Ohjelmistodokumentaatiota koskevat vaatimukset

Esimerkki: Testauksen aikana esitetty ohjelmistodokumentaation sisältö:

• ohjelman kuvaus (GOST 19.402-78);
• testiohjelma ja menetelmät (GOST 19.301-79);
• ohjelman teksti (GOST 19.401-78).

Testausvälineet ja -menettely

Esimerkki: Ohjelma toimii MS DOS -käyttöjärjestelmän (versio vähintään 3.0) käyttöolosuhteiden mukaisesti PC:ssä, kuten IBM PC/AT, sekä yhteensopivissa tietokoneissa. Käyttöön tarvitaan myös EGA (VGA) -sovitin.

TESTAUSMENETTELY:

1. Ohjelma käynnistyy….
2. Valittu...
3. Painettu...
4. Peräkkäin valittu...

Testitapaukset

Esimerkki: Testausta varten ehdotetaan ..., joiden kuvaukset ovat tiedostoissa ... Testitiedostojen sisältö ja ohjelman tulokset on esitetty liitteessä 1.

Ja lopuksi tarkastellaan viimeisintä ESPD-standardia, jota kutsutaan

Tämä standardi määrittelee säännöt tietokoneiden, kompleksien ja järjestelmien ohjelma-asiakirjojen suorittamiselle riippumatta niiden tarkoituksesta ja soveltamisalasta ja jotka ESPD-standardeissa määrätään.

Yleiset vaatimukset. Syötä yksittäisiä sanoja, kaavoja, tavanomaisia ​​merkkejä(käsin piirustusfontilla), latinalaisten ja kreikkalaisten aakkosten kirjaimet sekä kaaviot ja piirustukset tulee tehdä mustalla tai musteella.

Suorituksen aikana havaitut kirjoitusvirheet ja graafiset epätarkkuudet voidaan korjata pyyhkimällä huonosti suoritettu tekstin osa (piirustus) ja lisäämällä korjattu teksti (grafiikka) samalle arkille koneella tai mustalla musteella suoritustavasta riippuen. asiakirja.

Asiakirjaarkkien vaurioituminen, täplät ja epätäydellisesti poistetun tekstin (grafiikka) jäljet ​​eivät ole sallittuja.

Ohjelma-asiakirjat laaditaan A4-arkeille. Sitä paitsi:

• On hyväksyttävää tulostaa A3-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;
• Kun asiakirja tuotetaan typografisella menetelmällä, on mahdollista käyttää typografisten muotojen arkkeja.

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 (kuvien, taulukoiden jne. kanssa);
• luettelo termeistä ja niiden määritelmistä;
• lyhennelista;
• sovellukset;
• aihehakemisto;
• luettelo viiteasiakirjoista;

• muuta lokiosaa:

• muuta rekisteröintilomaketta.

Asiakirjan rakenne. Tarvittaessa asiakirja on sallittu jakaa osiin. Jako osiin suoritetaan tasolla, joka ei ole alempi kuin osa. Jokainen osa täytetään erikseen, ja ensimmäisen osan sisällön lopussa tulee listata muiden osien nimet.

Dokumenttiin saa sisällyttää ohjelman tekstin osia, jotka on muotoiltu sen kielen sääntöjen mukaisesti, jolla ohjelmateksti on kirjoitettu.

Tiivistelmä sijoitetaan erilliselle sivulle (sivuille), joka on varustettu otsikolla "ABSTRAKTI", numeroitu ja sisällytetty asiakirjan sisältöön.

Kunkin asiakirjan teksti jaetaan tarvittaessa kappaleisiin ja kappaleet alakohtiin riippumatta siitä, onko asiakirja jaettu osiin, osiin ja alakohtiin vai ei.

Osion otsikot kirjoitetaan isoilla kirjaimilla ja sijoitetaan symmetrisesti tekstin oikeaan ja vasempaan reunaan nähden. Alaosien otsikot kirjoitetaan kappaleesta pienillä kirjaimilla (paitsi ensimmäinen iso kirjain). Sanojen tavutus otsikoissa ei ole sallittua. Otsikon lopussa ei ole pistettä. On suositeltavaa aloittaa jokainen osa uudelta arkilta.

Jaksot, alakohdat, kappaleet ja alakohdat on numeroitava arabialaisilla numeroilla ja pisteellä. Osioilla on oltava sarjanumero (1, 2 jne.)

Asiakirjan teksti. Asiakirjan tekstin tulee olla lyhyt, selkeä, väärintulkintamahdollisuutta poissulkeva. Termien ja määritelmien on oltava yhdenmukaisia ​​ja vakiintuneiden standardien mukaisia, ja niiden puuttuessa - yleisesti hyväksyttyjä tieteellisessä ja teknisessä kirjallisuudessa, ja ne on esitettävä termiluettelossa.

Tarvittavat selitykset asiakirjan tekstiin voidaan antaa alaviitteissä. Alaviite on osoitettu numerolla, jonka hakasulke on sijoitettu fontin yläreunan tasolle.

Jos alaviite viittaa yhteen sanaan, alaviite sijoitetaan suoraan tämän sanan viereen, mutta jos se viittaa lauseeseen kokonaisuutena, niin lauseen loppuun. Alaviiteteksti sijoitetaan sivun loppuun ja erotetaan päätekstistä 3 cm:n pituisella viivalla, joka on piirretty sivun vasempaan reunaan.

Kuvituksia. Kuvitukset löytyvät asiakirjan tekstistä ja (tai) liitteistä. Kuvat, jos niitä on enemmän kuin yksi tietyssä asiakirjassa, numeroidaan arabialaisilla numeroilla koko asiakirjassa.

Liitteissä kuvat on numeroitu kunkin liitteen sisällä asiakirjan päätekstin mukaisessa järjestyksessä. Viittaukset kuviin on annettu tyypin mukaan: "Kuva 12" tai "(Kuva 12)". Kuvissa voi olla temaattinen otsikko ja kuvateksti, joka selittää kuvituksen sisällön.

Kaavat. Asiakirjan kaavat, jos niitä on useampi kuin yksi, numeroidaan arabialaisin numeroin sivun oikeaan reunaan, suluissa kaavatasolla. Koko asiakirjan tai sen osien sisällä, jos tosite on jaettu osiin, kaavoissa on jatkuva numerointi.

Tekstissä olevat viittaukset kaavan sarjanumeroon on annettu suluissa, esimerkiksi: "kaavassa (3)". Kun asiakirja jaetaan osiin, osanumero sijoitetaan ennen kaavan sarjanumeroa ja erotetaan viimeisestä pisteestä, esimerkiksi: "kaavassa (1.4)".

Kaavaan sisältyvien symbolien merkitys on ilmoitettava suoraan kaavan alapuolella. Jokaisen merkin merkitys tulostetaan uudelle riville siinä järjestyksessä, jossa ne on annettu kaavassa. Transkription ensimmäisen rivin tulee alkaa sanalla "missä", ilman kaksoispistettä sen jälkeen.

Linkit. Viittaukset standardeihin ja muihin asiakirjoihin ovat sallittuja politiikka-asiakirjoissa. On viitattava asiakirjaan kokonaisuudessaan tai sen osiin (ilmoitettaessa asiakirjan nimi ja nimi, jakson tai liitteen numero ja nimi).

On sallittua ilmoittaa vain asiakirjan ja (tai) osien nimitys ilmoittamatta niiden nimiä. Viittaukset toisen asiakirjan yksittäisiin alakohtiin, kappaleisiin ja kuviin eivät ole sallittuja. Asiakirjan sisällä olevat linkit kappaleisiin, kuviin ja yksittäisiin alakohtiin ovat sallittuja.

Huomautuksia Tekstin ja taulukoiden huomautukset sisältävät vain viite- ja selittäviä tietoja. Yhtä nuottia ei ole numeroitu. Laita sanan "huomautus" jälkeen piste. Useat nuotit tulee numeroida järjestyksessä käyttäen arabialaisia ​​numeroita ja pistettä. Laita sanan "Huomautus" jälkeen kaksoispiste. Muistiinpanojen tekstiä saa tulostaa vain kerran.

Lyhenteet. Sanojen lyhenteet tekstissä ja kirjoitukset kuvien alla eivät ole sallittuja, paitsi:

• GOST 2.316-68:ssa vahvistetut ja yleisesti venäjän kielellä hyväksytyt lyhenteet;
• lyhenteet, joita käytetään osoittamaan ohjelmia, niiden osia ja toimintatapoja, tehtävänhallintakielissä, ohjelman konfigurointityökaluissa jne., merkitty latinalaisten aakkosten kirjaimilla.

Sovellukset. Kuvitettu aineisto, taulukot tai tukiteksti voidaan esittää liitteenä. Liitteet laaditaan tämän asiakirjan jatkona seuraaville sivuille tai julkaistaan ​​erillisenä asiakirjana.

Jokaisen hakemuksen tulee alkaa uusi sivu jossa on oikeassa yläkulmassa sanat "Hakemus" ja on temaattinen otsikko. Jos asiakirjassa on useampi kuin yksi liite, kaikki liitteet numeroidaan arabialaisilla numeroilla (ilman numero-merkkiä), esimerkiksi:

Liite 1, Liite 2 jne.

Hakemusta laadittaessa erillisenä asiakirjana on otsikkoon asiakirjan nimen alle mainittava sana ”Liite” ja jos hakemuksia on useita, myös sen järjestysnumero.

Neuvostoliiton valtion standardikomitean 18. joulukuuta 1978 päivätyllä asetuksella nro 3350 vahvistettiin käyttöönottopäivä

01.01 alkaen. 1980

1. Tämä standardi määrittää GOST 19.101-77:n määrittelemän ohjelma-asiakirjan "Ohjelman kuvaus" koostumuksen ja sisällölle.

Standardi on täysin ST SEV 2092-80:n mukainen.

2. Asiakirjan rakenne ja suunnittelu on määritetty standardin GOST 19.105-78 mukaisesti.

Tietoosuuden (huomautukset ja sisältö) laatiminen on pakollista.

3. Ohjelman kuvauksen tulee sisältää seuraavat osat:

• yleistä tietoa;
• toiminnallinen tarkoitus;
• loogisen rakenteen kuvaus;
• käytetyt tekniset keinot;
• syöttötiedot;
• ulostulo.

Ohjelman ominaisuuksista riippuen on mahdollista lisätä lisäosia tai yhdistää yksittäisiä osia.

4. "Yleiset tiedot" -osiossa on ilmoitettava seuraavat tiedot:

• ohjelman nimi ja nimi;
• ohjelman toimintaan tarvittavat ohjelmistot;
• ohjelmointikielet, joilla ohjelma on kirjoitettu.

5. "Toimintatarkoitus" -osiossa tulee ilmoittaa ratkaistavien ongelmien luokat ja (tai) ohjelman tarkoitus sekä tiedot toiminnallisista käytön rajoituksista.

6. Kohdassa "Loogisen rakenteen kuvaus" on ilmoitettava seuraava:

• ohjelma-algoritmi;
• käytetyt menetelmät;
• ohjelman rakenne ja kuvaus sen komponenttien toiminnoista ja niiden välisistä yhteyksistä;
• ohjelman yhdistäminen muihin ohjelmiin.

Ohjelman loogisen rakenteen kuvaus tehdään ottaen huomioon ohjelman lähdekielinen teksti.

3-6.(Muutettu painos, muutos nro 1).

7. Kohdassa "Käytetyt tekniset työkalut" tulee ilmoittaa ohjelmaa ajettaessa käytettävien elektronisten tietokoneiden ja laitteiden tyypit.

• menetelmä kutsua ohjelma vastaavalta tallennusvälineeltä;
• sisäänpääsypisteitä ohjelmaan.

Voit määrittää latausosoitteet, tiedot RAM-muistin käytöstä ja ohjelman koon.

9. "Syötetiedot" -osiossa on ilmoitettava seuraavat tiedot:

• syöttötietojen luonne, organisointi ja alustava valmistelu;
• syötetietojen muoto, kuvaus ja koodausmenetelmä.

10. "Tulostiedot"-osiossa on ilmoitettava seuraavat tiedot:

• lähtötietojen luonne ja organisaatio;
• muoto, kuvaus ja lähtötietojen koodausmenetelmä.

11. Osioiden sisältöä saa havainnollistaa selittävillä esimerkeillä, taulukoilla, kaavioilla, kaavioilla.

12. Ohjelmakuvauksen liite voi sisältää erilaisia ​​materiaaleja, joita ei ole tarkoituksenmukaista sisällyttää kuvauksen osiin.

7-12.(Lisäksi lisätty, tarkistus 1).

* Uudelleenjulkaisu (marraskuu 1987) muutoksella nro 1, hyväksytty syyskuussa 1981 (IUS 11-81)

Yleistä tietoa

Ohjelman nimi ja nimi

Tietokantaohjelma « Maksujen laskeminen yleishyödyllisistä palveluista HOA ».

Ohjelman toimintaan tarvitaan ohjelmisto

Delphi 7 -paketti tukee täysin uusimpia ja olemassa olevia verkkopalveluita.

Delphi 7:n avulla voit luoda monenlaisia ​​ohjelmia: yksinkertaisimmista yhden ikkunan sovelluksista hajautettujen tietokantojen hallintaohjelmiin. Paketti sisältää erilaisia ​​apuohjelmia, joiden avulla voit työskennellä tietokantojen, XML-dokumenttien kanssa, luoda ohjejärjestelmän ja ratkaista muita ongelmia. Seitsemännen version erottuva piirre on .NET-tekniikan tuki.

Ohjelmointikielet, joilla ohjelma on kirjoitettu

Ohjelma on kirjoitettu Object Pascalilla ja se on tarkoitettu kääntäjän käsiteltäväksi.

Toiminnallinen tarkoitus

Tietojärjestelmä"Hyödykkeiden HOA-99 maksujen laskenta" on tarkoitettu automatisoimaan HOA-johtajan työpaikka laskemalla vuokralaisten apuohjelmien maksut.

Loogisen rakenteen kuvaus

Looginen rakenne on esitetty liitteessä A.

Käytetyt menetelmät

ADOConnection-tekniikkaa käytetään yhdistämään tietokanta Delphiin.

ADO – ActiveXDataObjects Microsoft Active X DataObjects -teknologia tarjoaa yleisen pääsyn tietolähteisiin tietokantasovelluksista. Tämän mahdollisuuden tarjoavat yhteisen COM-oliomallin (Component Object Model) pohjalta luodut ja OLE DB -spesifikaatiossa kuvatut rajapintajoukon toiminnot. ADO-palveluntarjoajat tarjoavat yhteyden ADO:n kautta dataa kuluttavan sovelluksen ja tietolähteen (SQL-palvelin, paikallinen DBMS, tiedostojärjestelmä jne.). Jokaiselle tietovarastotyypille on oltava ADO-palveluntarjoaja. Microsoft Jet OLE DB Provider tarjoaa yhteyden Access DBMS -tietoihin. ADO:n avulla voit välttää BDE:n asentamisen ja lisäkirjastojen toimittamisen kehitettävän tietokantasovelluksen loppukäyttäjän tietokoneeseen.

Ohjelman rakenne

Ohjelman tiedostorakenne

Kun kehitetään ja tallennetaan projektia Delphi-ohjelmointiympäristössä, projektitiedostot, lomakkeet ja muut tiedostot tallennetaan sisään jaettu kansio:

*.ddp – tiedosto Delphin kehitys;

*.dfm- tiedosto, jossa on kuvaus lomakkeen rakenteesta;

*.pas- lähde moduuli;

*.dcu- käännetty Delphi-moduuli;

*.dof - nykyiset projektin parametrit;

*.cfg - projektin määritystiedostot

*.dpr- projektitiedosto;

*.exe - suoritettava tiedosto;

*.res – tuloksena oleva tiedosto, resurssitiedosto;

*.gui – tiedosto;

*.chm – viitetiedosto;

*.mdb – Käytä tietokantatiedostoa.

Rakenne ohjelmistomoduulit

Yksikkö – moduulin (tiedoston) nimi.

Liitäntä – käytetään ulkoisten moduulien määrittelyihin.

Käyttökohteet - standardikirjastojen ja moduulien liittäminen.

(Windows, Viestit, SysUtils, luokat, grafiikka, säätimet, lomakkeet, valintaikkunat)

Tyyppi – TForm-luokan kuvaus kenttineen ja menetelmineen.

yksityinen – kuvaus luokan tiedoista (kentistä) ja rutiineista (menetelmistä), jotka ovat yksityisiä (sisäisiä) tälle luokalle.

(Yksityiset ilmoitukset)

Julkinen - muuttujat avoinna kaikille moduuleille.

(Julkiset ilmoitukset)

Var – globaalien muuttujien kuvaus.

Toteutus – Aloittaa suoritettavan koodin osan moduulissa.

Toiminto – käyttäjän toiminnot.

($R *.DFM) – lomaketiedoston yhteys.

menettelyä<имя>(Lähettäjä: TObject);

Var – paikallisten muuttujien kuvaus.

Aktivoitujen toimenpiteiden esto

Teknisiä keinoja käytetty

Tietokonelaitteisto sisältää:

Prosessori: IntelCore i54460, prosessorin taajuus 3,2 GHz, prosessoriytimien määrä - 4, emolevyn piirisarja - Intel H81;

RAM: DIMM, DDR34096 MB 1600 MHz, suurin RAM-kapasiteetti - 16 Gt;

Kiintolevy: 500 Gt, 7200 rpm, SATA III;

Hiiri, näyttö, näppäimistö.

Syötä tiedot

Tulot ovat:

Datamoduuli DFM: ADO Connection BD – tietokantayhteys Delphiin; ADO Table Sob, ADO Table Voda, ADO Table Giljo, ADO Table Otopl, ADO Table Svet, ADO Table Obslug, ADO Table Quit, ADO Table Requisites – taulukko tietokannasta;

Lomakkeen valtuutus: Yhdistelmäruutu Käyttäjänimi – käyttäjän valinta; Muokkaa salasanaa – syötä salasana;

Lomakkeen vaatimukset: DB Edit Adr – laillisen osoitteen syöttäminen, DB Edit Naim TSG – HOA:n nimen syöttäminen, DB Edit Tel – puhelinnumeron syöttäminen, DB Edit INN – INN:n syöttäminen, DB Edit BIK – BIK:n syöttäminen, DB Edit RS – käyttötilin syöttäminen, DB Edit KS – kirjeenvaihtajatilin syöttäminen;

Lomaketaulukko Sobstvennikov: Edit Poisk—haun kirjoittaminen vuokralaisen koko nimellä, DB Edit FIO—vuokralaisen koko nimen kirjoittaminen, DB Edit LS—henkilökohtaisen tilin syöttäminen, DB Edit kolvo—asukkaiden lukumäärän syöttäminen, DB Edit PL—syöttö kokonaispinta-ala, DB Edit Adr—osoitteiden syöttäminen;

Lomaketaulukko Tariffit: DB Muokkaa Naimvoda – syötä veden tariffin nimi, DB Muokkaa edvoda – syötä veden mittayksikkö, DB Muokkaa voda – syötä veden tariffi, DB Muokkaa Naimgiljo – kirjoita tariffin nimi asuminen, DB Edit ed giljo – syötä asunnon mittayksikkö, DB Edit giljo – syötä asunnon tariffi, DB Edit Naim otopl – syötä lämmitystariffin nimi, DB Edit ed otopl – syötä lämmityksen mittayksikkö , DB Edit otopl – lämmitystariffin syöttäminen, DB Edit Naimsvet – valaistustariffin nimen syöttäminen, DB Edit edsvet – valon mittayksikön syöttäminen, DB Edit svet – valaistustariffin syöttäminen, DB Edit Naimobslug – nimen syöttäminen rifanatech. ylläpito, DB Edit edobslug – syötä mittayksikkö teknistä. ylläpito, DB Edit obslug-enter tarifftech. palvelu;

Lomaketaulukko Kvitanzia: DB Edit NP voda - veden alkulukeman syöttäminen, DB Edit KP voda - veden lopullisen mittarilukeman syöttäminen, DB Edit kolvovoda - mittarin määrän syöttäminen vesille, DB Edit NP giljo - mittarin syöttäminen kotelon mittarin alkulukema, DB Edit KP giljo - asuntomittarin loppulukeman syöttäminen, Edit kolvogiljo - asuntomittarin määrän syöttäminen, DB Edit NP otopl - lämpömittarin alkulukeman syöttäminen , DB Edit KP otopl—lämpömittarin loppulukeman syöttäminen, DB Edit kolvootopl—lämpömittarin määrän syöttäminen, DB Edit NP svet—valomittarin alkulukeman syöttäminen, DB Edit KP svet—valon lopullisen lukeman syöttäminen mittari, DB Edit kolvosvet—valomittarin määrän syöttäminen, DB Edit NP obs lug—mittarin alkulukeman syöttäminen huoltoa varten, DB Edit KP obslug—lopullisen mittarilukeman syöttäminen huoltoa varten, DB Edit kolvoobslug—mittarien määrän syöttäminen ylläpitoa varten, DB Lookup -yhdistelmäruutu Number - henkilökohtaisen numeron valinta, DB Lookup -yhdistelmälaatikko LS - henkilökohtaisen tilin valinta, DB Lookup -yhdistelmälaatikko - osoitteen valinta, DB Lookup -yhdistelmälaatikko kolvo - asukkaiden lukumäärän valinta, DB Lookup -yhdistelmälaatikko pl—asuntoalueen valitseminen, DB Lookup Yhdistelmäruutu NaimVoda—Valitse nimen vesitariffi , DB Lookup Combo Box NaimGiljo—valitse asuntotariffin nimi, DB Lookup Combo Box NaimOtopl—valitse lämmitystariffin nimi, DB Lookup Combo laatikko NaimSvet—valitse kevyen tariffin nimi, DB Lookup Yhdistelmälaatikko NaimObslug—valitse ylläpitotariffin nimi, DB Lookup Yhdistelmälaatikko Voda—Valitse vesitariffi, DB Look up Yhdistelmälaatikko Giljo – Valitse majoituksen tariffi, DB Lookup Yhdistelmälaatikko Otopl – lämmitystariffin valinta, DB Lookup Yhdistelmälaatikko Svet – kevyt tariffivalinta, DB Lookup Yhdistelmälaatikko Obslug – Huoltotariffin valinta, DB Lookup Yhdistelmälaatikko Ed Voda – Veden mittayksikön valinta, DB Lookup Yhdistelmälaatikko Ed Giljo – Asunnon mittaus yksikön valinta, DB Lookup Yhdistelmälaatikko Ed Otopl – lämmitysmittayksikön valinta , DB Lookup Yhdistelmälaatikko Ed Svet – valitse valon mittayksikkö, DB Lookup Yhdistelmälaatikko Ed Obslug – valitse mittayksikkö ylläpitoa varten, DB Lookup Yhdistelmälaatikko FIO – valitse vuokralaisen koko nimi;

Lomakkeen vienti: DB Lookup -yhdistelmälaatikko Numero - henkilökohtaisen numeron valinta, DB Lookup -yhdistelmälaatikko LS - henkilökohtaisen tilin valinta, DB Lookup -yhdistelmälaatikko adr - osoitteen valinta, DB Lookup -yhdistelmälaatikko kolvo - asukkaiden lukumäärän valinta, DB Lookup Yhdistelmäruutu pl - asunnon alueen valinta, DB Lookup Yhdistelmälaatikko FIO - vuokralaisen koko nimen valinta , DB Date Time Picker Word - syötä tulostetun kuitin päivämäärä.

Lähtö

Lähtö on:

FormTarifes: DBGridVoda - näyttää tiedot vesitariffeista taulukossa, DBGridGiljo - näyttää tietoja asuntotariffeista taulukossa, DBGridotopl - näyttää tiedot lämmitystariffeista taulukossa, DBGridsvet - näyttää tiedot sähkötariffeista taulukossa, DBGridobslug - näyttötiedot taulukon teknisten palvelujen tariffeista;

FormKvitanzia: DBGridQuit - näytä tiedot kuitista taulukossa;

FormSobstvenniki: DBGridSob - näyttää tiedot omistajista taulukossa.

Ohjelman kuvaus on koottu GOST 19.402-78:n mukaisesti. ESPD. Sisällön ja suunnittelun vaatimukset.

KEHITYSPROSESSI

IS:n "HOA:n yleishyödyllisten palveluiden maksujen laskeminen" kehittämiseen käytämme Delphi7-työkaluympäristöä, jossa on vuorovaikutus MSAccess-ympäristön kanssa, ADO-komponenttien kautta. Ohjelman pääikkuna sisältää seuraavat osat:

Järjestelmävalikko (1);

Työkalupalkki(2);

Ikkuna kaikille pöydille (3);

Komponenttipaletti (4);

Moduuli (6).

Kuva 9 – Pääikkuna Delphi ohjelmat 7

Luodaan ensin käyttäjän valtuutuslomake. Käytämme Combobox-komponenttia kirjautumiseen, Edit-komponenttia salasanaan, Button-komponenttia kirjautumiseen ja Timer- ja ProgressBar-komponenttia kirjautumisen lataamiseen.

Voit lisätä luettelon Combobox-komponentissa napsauttamalla kuvaketta<…>Kohteet-omaisuudessa.

Kuva 11 – ComboBox-komponentin Items-ominaisuuden käyttäminen

Seuraavaksi luodaan päälomake. Lisää päälomakkeeseen "MainMenu" -komponentti Päävalikko-komponentissa voit lisätä valikkoluettelon napsauttamalla kuvaketta<…>Kohteet-omaisuudessa.

Kuva 12 – Kohteet-ominaisuuden käyttäminen MainMenu-komponentissa

Kuva 13 – MainMenu-komponentin asetukset

Komponenttien sijoittamisen helpottamiseksi käytetään DataModule-moduulia datakomponenttien tallentamiseen. DataModule-komponentti on tarkoitettu ainoastaan ​​isännöimään ei-visuaalisia komponentteja tietojen käyttöä varten.

DataModule-ikkunan ja tavallisen lomakkeen ero on siinä, että siihen voidaan sijoittaa vain ei-visuaalisia komponentteja. Nämä eivät voi olla vain tietoihin pääsyn komponentteja, vaan myös muita, joita tarvitaan sovelluksen eri osissa. DataModule-ikkuna sisältää komponentteja, jotka ovat välttämättömiä tietokantataulukoiden kanssa kommunikoinnissa, kuten: ADOConnection, ADOTable ja DataSource .

Kuva 14 - DataModule-ikkuna

MSAccessissa luodun tietokannan liitäntää varten ADO-välilehdellä on ADOConnection-komponentti. Yhteyden muodostamiseksi tietokantaan komponentti asetetaan lomakkeeseen ja LoginPrompt-ominaisuuden arvoksi on asetettu False, jotta salasanaa ei kysytä yhteyden muodostamisen yhteydessä. Tämä tehdään vain käyttöliittymän luontivaiheessa. Seuraavaksi sinun on napsautettava ConnectionString-ominaisuudessa ”…”-kuvaketta, avautuvassa ikkunassa sinun on valittava UseConnectionString ja napsautettava Build-painiketta avautuvassa ikkunassa ”Data Provider” -välilehdessä sinun on valittava MicrosoftJet 4.0 OLE DB Provider -palveluntarjoaja, Yhteys-välilehdellä sinun on annettava tietokannan nimi asianmukaiseen kenttään. Sitten sinun on määritettävä Connected-ominaisuuden arvoksi True, jotta voit muodostaa yhteyden MSAccess-ohjelmaan.

Kuva 15 – Yhteysmerkkijono

Kuva 16 – Yhteyden ominaisuudet

Voit muodostaa yhteyden tiettyyn tietokannan taulukkoon käyttämällä ADOTable-komponenttia, ADO-välilehteä. Valitse Yhteys-ominaisuudesta ADOConnection ja aseta Active-ominaisuuden arvoksi True. (katso sivu 23)

Jotta muut Delphi-komponentit voivat muodostaa yhteyden taulukoihin (ADOTablen kautta), käytetään DataAccess-välilehdellä olevaa DataSource-komponenttia. DataSet-ominaisuudessa sinun on valittava sopiva ADOTable-komponentti. (katso sivu 24)

Voit näyttää tietokantatiedot taulukkomuodossa käyttämällä DataControls-välilehdellä olevaa DBGrid-komponenttia. Valitse DataSource-ominaisuudessa vastaava DataSource-komponentti (katso sivu 22).

Tietokantakenttien syöttämiseksi taulukkomuodossa käytä DataControls-välilehdellä olevaa DBEdit-komponenttia tietolähde. Toinen ominaisuus, DataField, määrittää kentän, joka tulee näyttää tässä komponentissa (katso sivu 29).

Voit linkittää yhden taulukon toiseen taulukkoon käyttämällä DBLookUPCombobox-komponenttia, joka sijaitsee DataControls-välilehdellä. ListSource-ominaisuudesta sinun on valittava viitetaulukon vastaava DataSource-komponentti, ListField-ominaisuudessa sinun on valittava viitteen vastaava kenttä. taulukossa KeyField-ominaisuudessa sinun on valittava avainkenttä. DataSource-ominaisuudesta on valittava kohdetaulukon vastaava DataSource-komponentti, DataField-ominaisuudesta on valittava kohdetaulukon vastaava kenttä (katso sivu 31).

Päivämäärää ja kellonaikaa varten käytetään Win 32 -välilehdellä olevaa DataTimePicker-komponenttia Date-ominaisuudessa sinun on määritettävä muoto: dd.mm.yyyy (katso sivu 30).

Luomme loput lomakkeet ohjelmiston käyttöliittymässä.

Kuva 17 – Ohjelmatietolomake

Hakemiston kanssa työskentelemiseen käytämme Dr.-ohjelmaa. Selittää. Kun luot hakemistoa, näkyviin tulee projektinvalintaikkuna (katso kuva 18). Valitse tässä ikkunassa paikallisen projektin luominen.

Kuva 18 - Projektin luominen

Tämän jälkeen näkyviin tulee projektityökenttä. Projektin työkentässä on kaksi osaa: vasen ja oikea, kun taas vasen osa on jaettu vielä kahteen osaan (katso kuva 19.20).

Kuva 19 - Projektirakenteen luominen

Kuva 20 - Sivun tiedot

Dr.Explain-pääikkunan vasemmassa yläkulmassa voit määrittää suoraan dokumentaation rakenteen ja luoda niihin uusia aiheita ja osioita. Voit tehdä tämän käyttämällä molempia pikanäppäimiä ja napsauttamalla hiiren kakkospainikkeella projektin nimeä. Oletusarvoisesti Dr.Explainin projektissa on kolme sivua: kotisivu; Sisällysluettelo;<НЕ ЗАБЫТЬ: Имя темы>. Aloitussivulla on projektin nimi ja osoitus siitä, mikä tiedosto on (oletus on Käyttöopas).

Kuva 21 – Kotisivu

Kuva 22 - Projektin käyttöliittymä

Luodaan seuraavat osiot hakemistoon (katso kuva 23-27), käännetään sitten ohjelma ja viedään se tiedostomuotoon (*.chm).

Kuva 23 – Käyttöopas

Kuva 24 – Ohjelman tarkoitus

Kuva 25 – Ohjelman suoritustila

Kuva 26 – Ohjelman suoritus

Kuva 27 – Viesti käyttäjälle

Kun olet luonut hakemiston Delphi-ohjelmassa, lisäämme ShellApi-moduulin Delphin yhdistämiseksi hakemistoon.

TESTAUS JA VIRHENETSINTÄ

Luokitteluvirhe

Vianetsintä on ohjelmistotestauksen aikana löydettyjen virheiden paikantaminen ja korjaaminen. Lokalisointi on prosessi, jossa määritetään ohjelmakäsky, jonka suorittaminen aiheutti häiriön normaalissa laskentaprosessissa. Virheen korjaamiseksi on tarpeen selvittää sen syy, eli tunnistaa virheen sisältävä lause tai fragmentti. Virheiden syyt voivat olla sekä ilmeisiä että hyvin piilossa.

Yleensä virheenkorjauksen vaikeus johtuu seuraavista syistä:

Edellyttää ohjelmoijalta syvällistä tietoa käytetyn laitteiston hallinnan erityispiirteistä, käyttöjärjestelmästä, ympäristöstä ja ohjelmointikielestä, toteutettavista prosesseista, erilaisten virheiden luonteesta ja erityispiirteistä, virheenkorjaustekniikoista ja asiaankuuluvista ohjelmistoista;

On mahdollista, että ohjelman eri osien virheet voivat olla vuorovaikutuksessa esimerkiksi siksi, että toinen moduuli pyyhkii muistialueen osoitusvirheiden vuoksi;

Selkeästi määriteltyjä virheenkorjaustekniikoita ei ole.

Käsittelyvaiheen mukaan, jossa virheet ilmenevät, ne erotetaan:

Syntaksivirheet - kääntäjän (kääntäjän, tulkin) tallentamat virheet suorittaessaan ohjelman syntaktista ja osittain semanttista analyysiä;

Linkitysvirheet - linkittäjän (linkkieditorin) havaitsemat virheet yhdistettäessä ohjelmamoduuleja;

Ajonaikaiset virheet ovat virheitä, joita käyttöjärjestelmä, laitteisto tai käyttäjä kohtaa ohjelman suorittamisen aikana.

Syntaksivirheet. Syntaktiset virheet luokitellaan yksinkertaisimmiksi, koska kielen syntaksi on pääsääntöisesti tiukasti formalisoitu ja virheisiin liittyy yksityiskohtainen kommentti, joka osoittaa sen sijainnin. Tällaisten virheiden syiden määrittäminen ei yleensä ole vaikeaa, ja jopa epäselvillä kielen sääntöjen tuntemuksella on mahdollista poistaa kaikki tämän tyyppiset virheet useissa ajoissa.

Asetteluvirheet. Asetteluvirheet, kuten nimestä voi päätellä, liittyvät ratkaisemisen aikana löydettyihin ongelmiin Ulkoiset linkit. Esimerkiksi kutsu toisen moduulin aliohjelmalle tarjotaan, mutta kun moduuleja yhdistetään, tätä aliohjelmaa ei löydy tai parametriluettelot eivät täsmää. Useimmissa tapauksissa tällaiset virheet voidaan myös paikallistaa ja poistaa nopeasti.

Ajonaikaiset virheet. Ennustettavin ryhmä sisältää ajonaikaiset virheet. Käyttöjärjestelmä havaitsee ja dokumentoi jotkin virheet. Tällaisia ​​virheitä voi ilmetä neljällä tavalla:

Koneen komennon suorittamisen ohjauspiirien tallentaman virheilmoituksen esiintyminen, esimerkiksi bittiverkon ylivuoto, nollatilanteella jako, osoitteen rikkominen jne.;

Näyttöön tulee viesti käyttöjärjestelmän havaitsemasta virheestä, esimerkiksi muistin suojausrikkomuksesta, kirjoitusyrityksestä kirjoittaa kirjoitussuojattuihin laitteisiin, määritetyn nimen tiedoston puuttumisesta jne.;

- tietokoneen "jäädyttäminen", sekä yksinkertainen, kun on mahdollista suorittaa ohjelma ilman käyttöjärjestelmää uudelleenkäynnistystä, että "vakava", kun uudelleenkäynnistys on tarpeen työn jatkamiseksi;

Saatujen tulosten ja odotettujen tulosten välinen ristiriita.

Kaikki mahdolliset virheiden syyt voidaan jakaa seuraaviin ryhmiin:

lähdetietojen virheellinen määritelmä,

Loogisia virheitä

Virheiden kertyminen laskentatuloksissa.

Lähdetietojen virheellinen määritys tapahtuu, jos I/O-toimintojen aikana tapahtuu virheitä: siirtovirheitä, muunnosvirheitä, uudelleenkirjoitusvirheitä ja datavirheitä. Lisäksi erityisten teknisten keinojen ja virheettömän ohjelmoinnin avulla voidaan havaita ja estää vain osa näistä virheistä.

Viimeiseen ryhmään kuuluvat:

Muuttujien virheellisen käytön virheet, esimerkiksi epäonnistunut tietotyyppien valinta, muuttujien käyttö ennen niiden alustusta, taulukoiden määritelmää pidemmälle menevien indeksien käyttö, tietotyyppien vastaavuuden rikkomukset käytettäessä löydetyn tietotyypin eksplisiittistä tai implisiittistä uudelleenmäärittelyä muistissa käytettäessä kirjoittamattomia muuttujia, avoimia taulukoita, liittoja, dynaamista muistia, osoitearitmetiikkaa jne.;

Laskentavirheet, esimerkiksi väärät laskelmat ei-aritmeettisilla muuttujilla, virheellinen kokonaislukuaritmeettinen käyttö, virheellinen tietotyyppien muunnos laskelmien aikana, virheet, jotka liittyvät aritmeettisten ja loogisten lausekkeiden toimintojen prioriteettien tuntemattomuuteen jne.;

Virheet moduulien välisessä rajapinnassa, esimerkiksi järjestelmäsopimusten huomioimatta jättäminen, tyyppien ja järjestyksen rikkominen parametreja siirrettäessä, muodollisten ja todellisten parametrien mittayksiköiden yhtenäisyyden noudattamatta jättäminen, paikallisten ja globaalien muuttujien laajuuden rikkominen;

Muut koodausvirheet, esimerkiksi ohjelmalogiikan virheellinen toteutus koodattaessa, huomioimatta tietyn ohjelmointikielen ominaisuudet tai rajoitukset.

Kuva 28 - Ajonaikaiset virheet

Ohjelman virheenkorjaus

Virheenkorjaus on ohjelmistotestauksen aikana löydettyjen virheiden paikallistamista ja korjaamista. Lokalisointi on prosessi, jossa tunnistetaan ohjelmakäsky, jonka suorittaminen aiheutti häiriön normaalissa laskentaprosessissa. Ohjelman virheenkorjauksen aikana tunnistettiin ja korjattiin seuraavat virheet:

– Asetteluvirheet – havaittujen ja korjattujen määrä syntaksivirheet –1.

Kuva 29 – Ei tietokantatiedostoa määritetyssä osoitteessa

– Syntaksivirheet – havaittujen ja korjattujen syntaksivirheiden määrä on 5.

Kuva 30 – Merkki "; "ennen Muu-lausetta

– Suoritusvirheet – havaittujen ja korjattujen suoritusvirheiden määrä on 9.

Kuva 31 – Virhe vietäessä tiedostoon

Testaus

Ohjelmistojen testaus on prosessi, jossa tutkitaan ja testataan ohjelmistotuotetta, jotta saadaan tietoa tuotteen laadusta.

Ohjelmatestauksessa on kaksi periaatetta:

Toiminnallinen testaus (mustan laatikon testaus);

Rakennetestaus (valkoisen laatikon testaus).

Valkoinen laatikko– koodin testaaminen ohjelman logiikan ja sen toiminnan oikeellisuuden suhteen sen kielen kääntäjän näkökulmasta, jolla se on kirjoitettu.

Seuraavat White Box -testausmenetelmät ovat käytettävissä:

Testataan peruspolkua

Peruspolun testausmenetelmän avulla on mahdollista: saada arvio ohjelman kokonaismonimutkaisuudesta; käytä tätä arviota tarvittavan testitapausten määrän määrittämiseen.

Testausolosuhteet

Seuraavat testaustyypit erotellaan: Yksinkertainen ehto on Boolen muuttuja tai relaatiolauseke.

E1<оператор отношения>E2 ,

jossa El, E2 ovat aritmeettisia lausekkeita ja yhtä seuraavista operaattoreista käytetään relaatiooperaattorina:<, >, =, , .

Yhdistelmäehto koostuu useista yksinkertaisista ehdoista, Boolen operaattoreista ja suluista. Käytämme Boolen operaattoreita OR, AND (&), NOT. Ehtoja, jotka eivät sisällä relaatiolausekkeita, kutsutaan Boolen lausekkeiksi.

Syklin testaus

Silmukkatestaus suoritetaan "valkoisen laatikon" periaatteen mukaisesti, kun silmukoita tarkistetaan, päähuomio kiinnitetään silmukkasuunnittelun oikeellisuuteen.

Silmukoita on 4 tyyppiä: yksinkertainen, sisäkkäinen, yhdistetty, jäsentämätön.

Yksinkertaiset syklit. Yksinkertaisten silmukoiden tarkistaminen toistomäärällä P yhtä seuraavista testisarjoista voidaan käyttää: koko syklin suorittaminen; vain yksi silmukan kulku; kaksi sykliä; T silmukka kulkee, missä T<п;п - 1, p, p + 1 sykli kuluu.

Sisäkkäiset silmukat - kanssa Nostamalla silmukan sisäkkäisyyden tasoa mahdollisten polkujen määrä kasvaa jyrkästi. Tämä johtaa käsittämättömään määrään testejä. Testien määrän vähentämiseksi käytetään erityistä tekniikkaa, joka käyttää käsitteitä, kuten sulkeminen ja sisäkkäiset silmukat

Testausvaiheet: sisin silmukka valitaan kaikkien muiden silmukoiden parametrien vähimmäisarvot (sisäiselle silmukalle suoritetaan yksinkertaiset silmukkatestit); siirry seuraavaan sulkemisjaksoon järjestyksessä ja. suorittaa testauksensa säilyttäen samalla kaikkien ulkoisten (kattavien) silmukoiden parametrien vähimmäisarvot ja kaikkien sisäkkäisten silmukoiden tyypilliset arvot.

Yhdistetyt syklit - Jos jokainen silmukoista on riippumaton muista, käytetään yksinkertaisten silmukoiden testaustekniikkaa. Jos on olemassa riippuvuus (esimerkiksi ensimmäisen silmukkalaskurin loppuarvoa käytetään toisen silmukkalaskurin aloitusarvona), käytetään sisäkkäistä silmukkatekniikkaa.

Strukturoimattomat silmukat - Strukturoimattomia silmukoita ei testata. Tämän tyyppiset silmukat on suunniteltava uudelleen käyttämällä strukturoituja ohjelmointirakenteita.

"Mustaa laatikkoa" testattaessa otetaan huomioon ohjelmien järjestelmäominaisuudet ja niiden sisäinen looginen rakenne jätetään huomiotta.

Mustan laatikon testaus tarjoaa seuraavien virheluokkien haun: virheelliset tai puuttuvat toiminnot ulkoisissa tietorakenteissa tai ulkoisen tietokannan ominaisuuksien virheet (vaadittu muistikapasiteetti jne.);

On kolme tapaa testata mustaa laatikkoa:

Ekvivalenssiositus on suosituin tapa testata mustaa laatikkoa. Tässä menetelmässä ohjelman syöttötietoalue jaetaan ekvivalenssiluokkiin. Jokaiselle ekvivalenssiluokalle kehitetään yksi testitapaus.

Raja-arvojen analysointimenetelmä. Suurin osa virheistä tapahtuu syöttöalueen reunoilla, ei keskellä. Raja-arvoanalyysi koostuu testitapausten hankkimisesta, jotka analysoivat raja-arvoja. Tämä testausmenetelmä täydentää ekvivalenssiositusmenetelmää.

VÄLINEN STANDARDI

Yhtenäinen ohjelmadokumentaatiojärjestelmä	GOST 19.402-78
OHJELMAN KUVAUS
Yhtenäinen järjestelmä ohjelmadokumentaatiolle.
Ohjelman kuvaus

Käyttöönottopäivämäärä 01.01.1980

Painos (tammikuu 2010), muutos nro 1, hyväksytty syyskuussa 1981 (IUS 11-81).

Neuvostoliiton valtion standardikomitean 18. joulukuuta 1978 päivätyllä asetuksella nro 3350 käyttöönoton päivämäärä asetettiin alkaen 01.01.80

1. Tämä standardi määrittää GOST 19.101-77:n määrittelemän ohjelma-asiakirjan "Ohjelman kuvaus" sisällön ja sisällölle vaatimukset.

Standardi on täysin ST SEV 2092-80:n mukainen.

(Muutettu painos, muutos nro 1)

2. Asiakirjan rakenne ja suunnittelu on laadittu standardin GOST 19.105-79 mukaisesti.

Ohjelman ominaisuuksista riippuen on mahdollista lisätä lisäosia tai yhdistää yksittäisiä osia.

4. "Yleiset tiedot" -osiossa on ilmoitettava seuraavat tiedot:

ohjelman nimi ja nimi;

ohjelman toimintaan tarvittavat ohjelmistot;

ohjelmointikielet, joilla ohjelma on kirjoitettu.

5. "Toimintatarkoitus" -osiossa tulee ilmoittaa ratkaistavien ongelmien luokat ja (tai) ohjelman tarkoitus sekä tiedot toiminnallisista käytön rajoituksista.

6. Kohdassa "Loogisen rakenteen kuvaus" on ilmoitettava seuraava:

ohjelma-algoritmit;

käytetyt menetelmät;

ohjelman rakenne ja kuvaus sen komponenttien toiminnoista ja niiden välisistä yhteyksistä;

ohjelman yhdistäminen muihin ohjelmiin.

Ohjelman loogisen rakenteen kuvaus tehdään ottaen huomioon ohjelman lähdekielinen teksti.

3-6. (Muutettu painos, muutos nro 1).

7. Kohdassa "Käytettävät tekniset välineet" tulee ilmoittaa ohjelmaa ajettaessa käytettävien elektronisten tietokoneiden ja laitteiden tyypit.

menetelmä kutsua ohjelma vastaavalta tallennusvälineeltä;

sisäänpääsypisteitä ohjelmaan.

Voit määrittää latausosoitteet, tiedot RAM-muistin käytöstä ja ohjelman koon.

9. "Syötetiedot" -osiossa on ilmoitettava seuraavat tiedot:

syöttötietojen luonne, organisointi ja alustava valmistelu;

syötetietojen muoto, kuvaus ja koodausmenetelmä.

10. "Tulostiedot"-osiossa on ilmoitettava seuraavat tiedot:

lähtötietojen luonne ja organisaatio;

muoto, kuvaus ja lähtötietojen koodausmenetelmä.

11. Osioiden sisältöä saa havainnollistaa selittävillä esimerkeillä, taulukoilla, kaavioilla, kaavioilla.

12. Ohjelmakuvauksen liite voi sisältää erilaisia ​​materiaaleja, joita ei ole tarkoituksenmukaista sisällyttää kuvauksen osiin.

7-12. (Lisäksi lisätty, tarkistus 1).

Tämä teos ei ole tekijänoikeudella suojattu. Venäjän federaation siviililain 1259 §:n mukaisesti valtion elinten ja kuntien paikallisten itsehallintoelinten viralliset asiakirjat, mukaan lukien lait, muut asetukset, tuomioistuinten päätökset, muut lainsäädännölliset, hallinnolliset ja oikeudelliset materiaalit, viralliset asiakirjat kansainvälisten järjestöjen tekijänoikeus ei koske niiden virallisia käännöksiä, kansantaideteoksia (folkloreja), tapahtumia ja faktoja, jotka ovat luonteeltaan puhtaasti informatiivisia (päivän uutisraportit, TV-ohjelmat, ajoneuvojen aikataulut jne.). .).