NSV Liidu LIIDU RIIKLIK STANDARD

INFOTEHNOLOOGIA

AUTOMAATSÜSTEEMIDE TESTIMISE LIIGID

GOST 34.603-92

NSVL STANDARDISE- JA METROLOOGIAKOMITEE

Moskva

NSV Liidu LIIDU RIIKLIK STANDARD

Sissejuhatuse kuupäev 01.01.93

See standard kehtib automatiseeritud süsteemide (AS) kohta, mida kasutatakse erinevat tüüpi tegevused (uuringud, disain, juhtimine jne) P.), sealhulgas nende kombinatsioonid, mis on loodud organisatsioonides, ühendustes ja ettevõtetes (edaspidi organisatsioonid)

Standard kehtestab AU testide liigid ja üldnõuded x läbiviimisele.

Selles rahvusvahelises standardis kasutatud terminid ja nende määratlused sõid eniya - vastavalt standardile GOST 34.003.

Selle standardi nõuded, v.a lk., , , on kohustuslikud, lõigete nõuded. , , - soovitatav.

1. ÜLDSÄTTED

1.2. Tuumaelektrijaama testimine on protsess, mille käigus kontrollitakse süsteemi kindlaksmääratud funktsioonide toimimist, tehakse kindlaks ja kontrollitakse süsteemi kvantitatiivsete ja (või) kvalitatiivsete omaduste TOR-i nõuetele vastavust, tuvastatakse ja kõrvaldatakse puudused süsteemi tegevuses. , väljatöötatud dokumentatsioonis.

1.3. AU jaoks on kehtestatud järgmised peamised testitüübid:

1) esialgne;

2) proovioperatsioon qi I;

3) vastuvõtmine.

Märkused:

1. Lubatud lisaks hoiab sõpra x d-s ov Vahelduvvoolu testimine nende osad.

2. Klassifitseerimine lubatud aci vastuvõtukatse aastal ja sõltuvalt vastuvõtukomisjoni staatusest (komisjoni liikmete koosseis ja heakskiidu aste).

3. Kogenud ei kumbagi Vastuvõtukomisjoni staatus määratakse lepingus ja (või) TK.

1.4, Sõltuvalt AU-s testitavate objektide omavahelistest seostest võivad testid olla autonoomsed või keerulised.

1.10. C proovitöö viiakse läbi selleks, et teha kindlaks tuumaelektrijaama kvantitatiivsete ja kvalitatiivsete näitajate tegelikud väärtused ja personali valmisolek töötada tuumaelektrijaama töötingimustes, teha kindlaks TEJ tegelik tõhusus ja korrektne (vajadusel) dokumentatsioon.

1.11. AÜ vastuvõtutestid viiakse läbi selleks, et teha kindlaks AÜ lähteülesannetele vastavus, hinnata proovitöö kvaliteeti ja lahendada AU võimalikkuse küsimus. st MK AS alalises töös.

1.12. Vahelduvvoolu vastuvõtutestid peaksid pr ühikut võimaldada selle eksperimentaalset käitamist rajatises.

1.13. Olenevalt AU-le kehtestatud nõuete tüübist ja katsetest, kontrollimisest või sertifitseerimisest allub sellele:

1) komplekt tarkvara ja tehnilisi vahendeid;

2) personal;

3) personali tegevust TEJ käitamise ajal reguleeriv töödokumentatsioon;

4) AS üldiselt.

1.14. Testide ajal kontrollivad kõlarid:

1) tarkvara ja riistvara tööriistade kompleksi automaatsete funktsioonide täitmise kvaliteet kõik režiimid f un To positsioneerimine Loodi tööaruande kohane AC st AC;

3) operatiivdokumentatsioonis sisalduva dokumentatsiooni täielikkus nimetatud personali täitmiseks nen ja m funktsioneerib kõigil töörežiimidel Nõusolekul Aafrika Liidu loomise tööaruandega;

4) kvantitatiivsed ja (või) kvalitatiivsed omadused täitmine AU automaatsed ja automatiseeritud funktsioonid vastavalt tööaruandele:

5) muud AÜ omadused, millele ta peab TOR järgi vastama.

2) kompleksne.

2.2. A võrguühenduseta testimine

2.2.1. Aafrika Liidu autonoomsed testid tuleks läbi viia aastal vastav võistlevad Aafrika Liidu iga osa jaoks välja töötatud autonoomsete testide programmi ja metoodikaga.

2.2.2. Autonoomsete testide programm näitab:

1) testitavate funktsioonide loetelu;

2) katseobjekti seose kirjeldus teiste TEJ osadega;

3) uuringute läbiviimise ja tulemuste töötlemise tingimused, kord ja meetodid;

4) osade vastuvõtukriteeriumid katsetulemuste põhjal.

Võrguühenduseta testimisprogrammile tuleks lisada võrguühenduseta testimise ajakava.

2.2.3. Ettevalmistatud ja kooskõlastatud testid (testjuhtumid) autonoomse testimise etapis peaksid pakkuma:

1) funktsioonide ja protseduuride täielik kontroll vastavalt kliendiga kokkulepitud nimekirjale;

2) TOR-is kehtestatud arvutuste nõutav täpsus;

3) tarkvara toimimise peamiste ajaliste tunnuste kontrollimine (juhul, kui see on oluline);

4) tarkvara ja riistvara töökindluse ja stabiilsuse kontrollimine.

2.2.4 . Testi esmase infona on soovitatav kasutada killukest kliendiorganisatsiooni reaalsest infost koguses, mis on piisav, et tagada testide vajalik usaldusväärsus.

2.2.5 AU osade autonoomse testimise tulemused tuleks registreerida katsearuannetes. Protokoll peab sisaldama järeldust tuumaelektrijaama osa keerukatele katsetele lubamise võimaluse (võimatuse) kohta.

2.2.6. Kui läbiviidud autonoomsed testid leitakse olevat ebapiisavad või dokumentatsiooni koostist või sisu käsitlevate normatiivdokumentide nõuete rikkumine, võib AU kindlaksmääratud osa läbivaatamiseks tagastada ja määrata. uus termin testid.

2.3. Komplekssed testid

2.3.1. AU terviklik testimine viiakse läbi keeruliste testide abil. Testi tulemused kajastuvad protokollis. Töö lõpetatakse proovikäitamise vastuvõtuakti vormistamisega.

2.3.2. Tuumaelektrijaama või selle osade integreeritud testimise programm näitab:

1) katseobjektide loetelu;

2) esitatava dokumentatsiooni koosseis;

3) testitavate seoste kirjeldus katseobjektide vahel;

4) TEJ osade katsete järjekord;

5) testimise kord ja meetodid, sealhulgas testimiseks vajaliku tarkvara ja seadmete koostis, sealhulgas spetsiaalsed stendid ja katseplatsid.

2.3.3. Kompleksse testimise jaoks tuleb esitada järgmised andmed:

1) integreeritud testimisprogramm;

2) järeldus AÜ vastavate osade autonoomse testimise ning autonoomse testimise käigus tuvastatud vigade ja kommentaaride kõrvaldamise kohta;

3) komplekstestid;

4) tarkvara ja riistvara ning sellega seotud tegevusdokumentatsioon.

2.3.4. Komplekskatsetes on lubatud kasutada lähteteavet, mis on saadud tuumaelektrijaama osade autonoomsetest katsetest.

2.3.5. Põhjalik test peaks:

1) olema loogiliselt seotud;

2) tagada TEJ osade funktsioonide täitmise kontroll kõigis TEJ-le kehtestatud töörežiimides, sealhulgas kõigis nendevahelistes ühendustes;

3) kontrollima süsteemi reageerimist ebaõigele teabele ja hädaolukordadele.

2.3.6. Integreeritud katseprotokoll peaks sisaldama järeldust tuumaelektrijaama proovikäitamiseks vastuvõtmise võimaluse (võimatuse) kohta, samuti vajalike paranduste loendit ja nende rakendamise soovituslikke tähtaegu.

Pärast puuduste kõrvaldamist viiakse läbi korduvad komplekstestid vajalikus mahus.

3. PILOOTITÖÖ

3.1. Proovioperatsioon viiakse läbi vastavalt programmile, mis näitab:

1) AL-i osade ja AL-i kui terviku toimimise tingimused ja kord;

2) kestus proovioperatsioon, mis on piisav selleks, et kontrollida AU õiget toimimist süsteemi iga funktsiooni täitmisel ja personali valmisolekut töötada. AS töötingimused;

3) proovitöö käigus tuvastatud puuduste kõrvaldamise kord.

3.2. AÜ proovitöö ajal peetakse tööpäevikut, kuhu kantakse info AÜ töö kestuse, rikete, rikete, hädaolukordade, automaatikaobjekti parameetrite muutuste, dokumentatsiooni ja tarkvara jooksvate korrigeerimiste ning riistvara reguleerimine. Teave salvestatakse päevikusse kuupäevaga ja vastutav isik. Ajakiri võib sisaldada personali kommentaare Aafrika Liidu toimimise lihtsuse kohta.

3.3. Proovikäitamise tulemuste põhjal otsustatakse TEJ osade ja süsteemi kui terviku esitamise võimalus (või võimatus) vastuvõtutestideks.

Töö lõppeb proovitöö lõpetamise akti sooritamisega ja süsteemi vastuvõtutestidele lubamisega.

4. VASTUVÕTMEKESTID

4.1. Vastuvõtutestid viiakse läbi vastavalt programmile, mis näitab:

1) süsteemis testimiseks eraldatud objektide loetelu ja nõuete loetelu, millele objektid peavad vastama (viitega TOR-i punktidele);

2) süsteemi ja selle osade vastuvõtukriteeriumid;

3) testimise tingimused ja tähtajad;

4) testimise vahendid;

5) katsete läbiviimise eest vastutavate isikute nimed;

6) testimise metoodika ja nende tulemuste töötlemine;

7) koostatava dokumentatsiooni loetelu.

4.2. Vastuvõtu testimiseks tuleb esitada järgmised dokumendid:

1) AL loomise lähteülesanne;

2) proovioperatsioonile vastuvõtmise akt;

3) proovioperatsiooni tööpäevikud;

4) proovikäitamise lõpetamise akt ja TEJ vastuvõtukatsetele lubamine;

5) programm ja testimise metoodika. Vastuvõtukatsed tuleks läbi viia toimivas rajatises.

4.3. Vastuvõtutest peaks eelkõige hõlmama järgmiste asjaolude kontrollimist:

1) funktsioonide teostamise täielikkus ja kvaliteet automaatikaobjekti parameetrite standard-, piir-, kriitilistel väärtustel ja muudes tööaruandes märgitud AU töötingimustes;

2) iga süsteemiliidesega seotud nõude täitmine;

3) personali töö interaktiivses režiimis;

4) vahendid ja meetodid AU töövõime taastamiseks pärast rikkeid;

5) operatiivdokumentatsiooni täielikkus ja kvaliteet.

4.4 . AU funktsioonide täitmise täielikkuse ja kvaliteedi kontrollimine on soovitatav läbi viia kahes etapis. Esimeses etapis testitakse üksikuid funktsioone (ülesandeid, ülesannete komplekse). Samal ajal kontrollivad nad funktsioonide (ülesannete, ülesannete komplekside) TOR-i nõuete täitmist. Teises etapis kontrollitakse ülesannete koostoimet süsteemis ja TOR-i nõuete täitmist süsteemile tervikuna.

4.5 . Kokkuleppel kliendiga võib tööülesannete kontrollimine, olenevalt nende spetsiifikast, toimuda iseseisvalt või kompleksi osana. Komplekside kontrollimisel on soovitatav ülesandeid kombineerida, võttes arvesse kasutatava teabe ja sisemiste seoste ühisust.

4.6. Personali töö kontrollimine interaktiivses režiimis toimub, võttes arvesse süsteemi kui terviku funktsioonide täitmise täielikkust ja kvaliteeti.

Kinnitamisele kuuluvad:

1) operaatorile kättesaadavate teadete, käskkirjade, päringute täielikkus ja nende piisavus süsteemi toimimiseks;

2) dialoogiprotseduuride keerukus, personali võime töötada ilma eriväljaõppeta;

3) süsteemi ja selle osade reaktsioon operaatori vigadele, teenindusrajatised.

4.7. AU tervise taastamise vahendite kontrollimine pärast arvuti rikkeid peaks hõlmama järgmist:

1) töödokumentatsioonis töövõime taastamise soovituste olemasolu ja nende kirjelduse täielikkuse kontrollimine;

3) funktsioonide automaatse taastamise vahendite töövõime (olemasolul).

4.8. Töödokumentatsiooni täielikkuse ja kvaliteedi kontrollimine tuleks läbi viia, analüüsides dokumentatsiooni vastavust regulatiivsete ja tehniliste dokumentide ning TOR-i nõuetele.

4.9. Programmis ette nähtud objektide testimise tulemused registreeritakse protokollides, mis sisaldavad järgmisi jaotisi:

1) katsete eesmärk ja selle TEJ nõuete punkti number, mille jaoks katse tehakse;

2) testides kasutatud riist- ja tarkvara koostis;

3) viide meetodite kohta, mille kohaselt katsed tehti, tulemuste töötlemine ja hindamine;

4) katsetingimused ja lähteandmete omadused;

5) hoiuruumid ja juurdepääsutingimused lõplikule testimisprogrammile;

6) üldistatud testi tulemused;

7) järeldused katsetulemuste ja loodud süsteemi või selle osade vastavuse kohta TEJ-i TOR nõuete teatud paragrahvile.

4.10. Objektide katseprotokollid kogu programmi jooksul koondatakse ühte protokolli, mille alusel tehakse järeldus süsteemi vastavuse kohta TEJ tehniliste kirjelduste nõuetele ja võimalusest anda välja töövõtuakt. TEJ alaliseks tööks.

Tööd lõpetatakse TEJ alalisse kasutusse vastuvõtmise akti vormistamisega.

TEABEANDMED

1. VÄLJATÖÖTANUD JA TUTVUSTATUD Tehnilise Komitee TC 22 poolt Infotehnoloogia", Alamkomitee PC 052 "Automatiseeritud süsteemid"

ARENDAJAD

I.P. Vakhlakov, Ya.G. Vilenchik, F.R. saarmas, cand. tehnika. teadused; L.M. Seidenberg, cand. tehnika. teadused; Yu.B. irz, cand. tehnika. teadused; V.G. Ivanov, V.D. Kostjukov, cand. tehnika. teadused; V.G. Mihhailov, cand. tehnika. teadused; N.V. Stepantšikov

Eelkatsed

EIS-i eeltestid võivad olla autonoomsed ja keerulised.

Autonoomsete testide programm näitab:

testitavate funktsioonide loend;

katseobjekti seose kirjeldus teiste EIS-i osadega;

katsete läbiviimise ja tulemuste töötlemise tingimused, kord ja meetodid;

· Osade aktsepteerimise kriteeriumid katsetulemuste põhjal.

Võrguühenduseta testimisprogrammile tuleks lisada võrguühenduseta testimise ajakava.

Ettevalmistatud ja kooskõlastatud testid (testjuhtumid) autonoomse testimise etapis peaksid pakkuma:

Funktsioonide ja protseduuride täielik kontroll vastavalt kliendiga kokkulepitud nimekirjale;

TOR-is kehtestatud arvutuste vajalik täpsus;

Tarkvara toimimise peamiste ajaliste tunnuste kontrollimine;

Tarkvara ja riistvara töökindluse ja stabiilsuse kontrollimine.

EIS-i osade autonoomsete testide tulemused fikseeritakse katseprotokollides. Protokoll peab sisaldama järeldust EIS-i osa komplekstestidele lubamise võimaluse kohta. Juhul, kui läbiviidud autonoomsed testid osutuvad ebapiisavaks või ilmneb dokumentatsiooni koostist või sisu puudutavate normatiivdokumentide nõuete rikkumine, võib EIS-i nimetatud osa tagastada läbivaatamiseks ja uue. katseperiood on määratud.

Komplekssed testid EIS viiakse läbi keeruliste testide tegemise teel. Põhjalik test peaks:

olema loogiliselt ühendatud;

· tagada EIS-i osade funktsioonide toimimise kontroll kõigis töörežiimides;

· tagada süsteemi reageerimise kontroll ebaõigele teabele ja hädaolukordadele.

Testi tulemused kajastuvad protokollis. Töö lõpetatakse proovikäitamise vastuvõtuakti vormistamisega.

EIS-i keeruliste testide programmis märkige:

testobjektide loend;

esitatava dokumentatsiooni koosseis;

katseobjektide vaheliste testitavate seoste kirjeldus;

EIS-i testimisosade järjestus;

· testimise kord ja meetodid, sealhulgas testimiseks vajaliku tarkvara ja seadmete koostis, sh spetsiaalsed stendid ja katseplatsid.

Integreeritud katseprotokoll peaks sisaldama järeldust EIS-i proovitööks vastuvõtmise võimaluse (võimatuse) kohta, samuti vajalike paranduste loendit ja nende rakendamiseks soovitatud tähtaegu.

Proovioperatsioon viiakse läbi vastavalt programmile, mis näitab:

EIS-i osade ja EIS-i kui terviku toimimise tingimused ja kord;

· proovitöö kestus, mis on piisav EISi korrektse toimimise kontrollimiseks;

Proovitöö käigus tuvastatud puuduste kõrvaldamise kord.

EIS-i proovitöö ajal peetakse tööpäevikut, kuhu kantakse info EIS-i töö kestuse, rikete, rikete, hädaolukordade, automaatikaobjekti parameetrite muutuste, dokumentatsiooni jooksvate korrigeerimiste ning tarkvara, reguleerimine ja tehnilised vahendid. Teave salvestatakse päevikusse koos kuupäeva ja vastutava isikuga. Logi võib sisaldada töötajate kommentaare EIS-i töö lihtsuse kohta.

Proovitöö tulemuste põhjal otsustatakse EIS-i osade ja süsteemi kui terviku esitamise võimalus vastuvõtutestideks.

Töö lõppeb proovitöö lõpetamise akti sooritamisega ja süsteemi vastuvõtutestidele lubamisega.

Projekti elluviimise protsessi viimane etapp tarkvara firmalt 1C, on proovitöö. See on vajalik selleks, et kasutaja saaks kontrollida süsteemi korrektset toimimist ja arendajad saaksid olemasolevad puudused kiiresti kõrvaldada.

Mis on proovioperatsioon?

Sisuliselt võimaldab see etapp teil kontrollida süsteemi valmisolekut selle jaoks tööstuslikuks kasutamiseks. Kasutaja kontrollib koos arendajaga kõiki programmi põhialgoritme ning vajadusel parandab ja silub neid. Just selles etapis toimub andmetöötluse õigsus tegelikud tingimused edasine operatsioon. Asi on selles, et mõningaid tarkvaravigu saab tuvastada ainult suure teabehulgaga töötamisel.

Levinumad vead

Programmi reaalsetes tingimustes kasutamise käigus võivad tekkida mõned vead, kuna süsteem pole suure hulga andmetega töötamiseks valmis. Siin on mõned neist:

• inerts ehk teisisõnu süsteemi tegevusetus mõne dokumendi loomisel. Selle vea tuvastamiseks on soovitatav kontrollida iga dokumendi loomise võimalust maksimaalse arvu positsioonide abil;
• programmil kulub mõne aruande loomiseks väga kaua aega. Tõenäoliselt pole süsteem valmis suure andmemahuga töötama või mõni algoritm ei tööta päris korralikult. Arendaja peab kogu ahelat üle kontrollima ja probleemi lahendama;
• välimus konfliktsituatsioonid mõne objektiga töötamisel. Üldiselt enamikul juhtudel me räägime"keeruliste" elementide kohta;
• probleeme dokumentide läbiviimisega, mis on enamasti põhjustatud valest algoritmist.

Peamised proovioperatsiooni tüübid

Sõltuvalt tarkvara valmistamise viisist saab eristada kahte peamist proovitoimingu tüüpi:

1. on olukordi, kus arendusstaadium on sunnitud "segama" proovitööga. See on asjakohane nendes olukordades, kui tegemist on üsna keerulise konfiguratsiooniga, mis nõuab suurt hulka üksikuid lisandmooduleid. Asi on selles, et arendusprotsessis ei ole alati võimalik kõiki programmile esitatavaid nõudeid arvesse võtta;
2. teine ​​tüüp on "standardne" proovioperatsioon. See kujutab endast olemasoleva tarkvara ja juurutatud tarkvaratoote samaaegset kasutamist. Reeglina kasutatakse siin reaalseid andmebaase, vastaspoolte loendeid ja käimasolevaid toiminguid. Seda tehakse selleks, et kasutaja saaks kindlaks teha, kui õigesti programm konkreetset ülesannet täidab. Kõige sagedamini võimaldavad arendajad selle protsessi optimeerimiseks ajutiselt teavet kahe süsteemi vahel vahetada. Seega kasutavad mõlemad programmid sama teavet, mis vähendab juhusliku vea ohtu.

Iga kasutaja peab olema valmis selleks, et proovitöö etapis kogeb ta teatud puudusi. Kogu point on selles baasmudel programmi on juba korduvalt reaalsetes tingimustes testitud, samas kui spetsiaalne konfiguratsioon installitakse sageli "toores" vormis, mida kontrollitakse alles arendusprotsessi käigus. Reeglina kõrvaldavad arendajad kiiresti kõik puudused ning programm hakkab üsna korrektselt ja stabiilselt töötama. Muuhulgas ei tohiks välistada sellist nüanssi, et juba olemasolev süsteem võib tekitada probleeme uue toote testimisel, sest kaugeltki alati pole võimalik koheselt konfigureerida optimaalseid ühilduvus- ja andmevahetusseadeid süsteemide vahel.

Loomine infosüsteem algab esimeste läbirääkimiste hetkest Tellija ja potentsiaalse Töövõtja vahel ega pruugi kunagi lõppeda, kuna häid ja kasulikke süsteeme täiustatakse ja arendatakse pidevalt.

eeletapp

Selles etapis on vaja mõista tulevase projekti peamisi eesmärke ja eesmärke. Selleks korraldavad Tellija ja Töövõtja võtmeesindajad kohtumisi, kus arutatakse infosüsteemi kontseptsiooni, tehnilisi põhipunkte, tehtavate tööde ajastust ja ulatust, samuti finantseerimiskulusid ja -allikaid. Eeletapi tulemus peaks lisaks tulevase lepingu kokkulepitud tingimustele olema esimene ja kõige põhimõttelisem projektidokument - projekti harta.

Projekti põhikiri määratleb järgmised infosüsteemi arendamise ja juurutamise protsessiga seotud põhipunktid:

• Projekti lühikirjeldus, infosüsteemi loomise eesmärgid ja eesmärgid.
• Töö ulatuse üldine kirjeldus.
• Projekti piirid: tähtajad, eelarve, automaatikaobjektide loetelu.
• Toote kirjeldus: kaasasoleva riist- ja tarkvara loend, litsentside tüüp ja arv jne.
• Projekti organisatsiooniline struktuur: projektimeeskonna liikmete loetelu ja rollid Töövõtja ja Tellija poolt, nende vastutus ja tööülesanded, projekti dokumentide haldussüsteem.
• Infosüsteemi arendamise ja juurutamise põhietapid, nende rakendamise suurendatud ajakava.
• Olulisemad projektist tulenevate kohustuste täitmata jätmise riskid, samuti riskide minimeerimise viisid.

Teisisõnu, projekti harta on just see harta, mille töötab välja projektijuht koos projektimeeskonna põhiliikmetega ning mille on heaks kiitnud töövõtja ja tellija juhtkond ning mida ei tohiks kogu loomise ajal korrigeerida. infosüsteem.

Eeletapi lõpetamiseks võib lugeda hetke, mil allkirjastatakse infosüsteemi arendamise ja juurutamise teenuste leping ning kinnitatakse projekti põhikiri.

Nõuded kogumiseks

Siinkohal on kõik võtmenumbrid - projektis osalejad välja selgitatud ning miski ei takista meil hakata koguma ja kinnitama tulevase infosüsteemi nõudeid. Töövõtja esindajad suhtlevad nii süsteemi tulevaste kasutajate ja administraatoritega kui ka nende juhtkonnaga. Küsitluse käigus ei süstematiseerita mitte ainult rakendatavale lahendusele esitatavaid nõudeid ja soove, vaid analüüsitakse ka dokumentatsiooni, millest peaks saama süsteemi lähteandmete allikas või mille moodustamine peaks selle tulemusena automatiseerima.

tulemus see etapp peaks olema välimus lähteülesanne infosüsteemi arendamiseks ja juurutamiseks. Lähteülesanne peaks põhinema lepingutingimustel ja projekti põhikirjas sätestatud nõuetel ning sisaldama järgmisi jaotisi (Venemaa puhul reguleerib lähteülesannete struktuuri GOST 34.602 89):

• Süsteemi loomise eesmärk ja eesmärk.
• Automatiseerimisobjekti ja peamiste automatiseeritud äriprotsesside kirjeldus.
• Süsteeminõuded: nõuded struktuurile; süsteemi poolt lahendatavad funktsioonid (ülesanded); tehniline ja organisatsiooniline tugi; nõuded töökindlusele, ohutusele jne. ja nii edasi.
• Infosüsteemi loomise töö koosseis ja sisu.
• Kontrollimise ja töötulemuste aktsepteerimise järjekord.
• Nõuded infosüsteemi kasutuselevõtu automaatikaobjekti koostamise tööde mahule.
• Nõuded disaini ja kasutaja dokumentatsiooni koostamisele.

Nõuete kogumise etapi läbimine on lähteülesande kinnitamine Kliendi poolt. Mõnel juhul on Tellijal juba enne projektiga tööde algust lähteülesanne (sisaldub hankedokumentatsioonis). Sel juhul fikseeritakse küsitluse ja nõuete kogumise tulemused privaatses lähteülesandes, täpsustades ja konkretiseerides Üldnõuded algses lähteülesandes toodud infosüsteemi.

Disain

Selles etapis kujundatakse Töövõtja jõupingutustega üksikasjalikult kõik stsenaariumid, mis on seotud infosüsteemi väljatöötamise ja rakendamisega Tellija territooriumil. Seda tehakse kooskõlas Kliendi infokeskkonna (süsteemimaastiku) tingimustega ning loodava süsteemi integreerimise nõuetega teiste Kliendi poolt juba olemasolevate ja opereeritavatega. tarkvaratooted. Projekteerimisetapi tulemuseks peaks olema järgmiste osade kujundus tehniline (kontseptuaalne) projekt:

• Infosüsteemi arhitektuur.
• Infosalvestuse (andmebaasi) struktuuride kirjeldus.
• Disainlahendused, mis on esitatud automatiseerimise stsenaariumide üksikasjaliku kirjeldusega kõigi äriprotsesside jaoks, mida süsteemi juurutamine mõjutab.
• Stsenaariumid arendatud infosüsteemi integreerimiseks väliste tarkvaratoodetega.
• Lähteandmete allikad ja süsteemi esialgse infosisu võimalused.
• Andmetele juurdepääsuõiguste eristamise kontseptsioon kasutaja rollide alusel, mis määravad muuhulgas nende volitused.
• Infosüsteemi kasutajate koolitamise kontseptsioon.

Rakendamine

Kõigi punktis sätestatud infosüsteemi nõuete rakendamise etapp lähteülesanne Ja tehniline projekt. Selle perioodi jooksul töötab Töövõtja välja kõik vajalikud tarkvarakomponendid, loob andmebaasistruktuurid, installib, konfigureerib ja testib oma territooriumil kõiki infosüsteemi komponente, simuleerib integratsioonistsenaariume jne. ja nii edasi. Rakendusfaasi lõpuleviimist kinnitab selliste projektidokumentide ilmumine süsteemi installimise ja konfigureerimise juhendina, programm ja testimisprotseduur süsteem, samuti andmebaasi mall ja register kõigist valminud tarkvaraarendustest.

Infosüsteemi ettevalmistamine tööks

Kõik selle etapi tööd tehakse juba Kliendi kohapeal ja hõlmavad kõigi süsteemi komponentide paigaldamist ja seadistamist Kliendi infokeskkonnas, eeltestimist, kasutaja dokumentatsiooni väljatöötamist, kasutajakoolitust, algandmete laadimist, testimist vastavalt kliendi infokeskkonnale. programm ja metoodika ning muud ettevalmistustööd.

Selleks ajaks, kui kõik ettevalmistustööd on lõpetatud, peaks süsteemi töökord olema välja töötatud ja kinnitatud. Eelkõige peaks määrus määratlema kasutajad ja nende rollid süsteemis vastavalt nende tööülesannetele.

Pilootoperatsioon

Infosüsteemi väljatöötamise ja esmase juurutamise viimane etapp, mille ülesandeks on teatud aja jooksul edukalt läbi viia süsteemi proovioperatsioon ning mille eesmärk on kinnitada, et loodud infosüsteem on just selline tulemus, mida Klient oodatud.

Selle aja jooksul hakkavad kasutajad süsteemi kasutama eelmises etapis välja töötatud eeskirjade kohaselt. Eksperimendi ajal tööstuslik operatsioon vead parandatakse ja lepitakse kokku vajalikes parandustes. Töövõtja kõrvaldab vead, teostab täiustusi ja kui süsteem hakkab toimima vastavalt kõigile talle varem esitatud nõuetele, saab kehtestatud perioodi lõpus protokolli piloottöö eduka lõpetamise kohta.

Pilootoperatsiooni lõpetamisega reeglina infosüsteemi loomise leping lõppeb. Süsteem ise läheb kommertskasutusele ja Täitja, kui Tellija on sellest huvitatud, teeb järeldused eraldi leping selle toetuse eest lepingutingimustega kehtestatud perioodiks.

Süsteemi hooldus ja arendamine

Tööstuslikul kasutamisel võib ilmneda, et loodud infosüsteemile esitatavad mõned nõuded sisaldasid ebatäpsusi ja nõuavad teistsugust sõnastust või täiendusi ning süsteem ise vajab täiustamist. Mitte iga Tellija koosseisus ei ole töötajaid, kes suudavad iseseisvalt kõiki tegelikust olukorrast tingitud muudatusi süsteemi sisse viia, mistõttu sõlmib infosüsteemi hooldamiseks Töövõtjaga eraldi lepingu.

Infosüsteemi kasutajad hakkavad suhtlema Kliendi tugiteenuse esindajatega, kes saavad neilt taotlusi funktsionaalsuse parandamiseks ja defektide kõrvaldamiseks, töötaotluste üleandmiseks ning perioodiliselt teavitavad kasutajaid oma päringu olekust. Võimalike parenduste loetelu ja taotluste menetlemise kord määratakse lepingutingimustega. Kui tekib vajadus tööde järele, mis ei haaku toetuse saamiseks lepingu sisuga, siis sõlmivad Tellija ja Töövõtja eraldi lepingu. seda liiki tööd, mille arvele võib juba praegu omistada tööd opereeritava infosüsteemi kaasajastamise ja arendamise kallal.

Selles etapis kujundatakse Töövõtja jõupingutustega üksikasjalikult kõik stsenaariumid, mis on seotud infosüsteemi väljatöötamise ja rakendamisega Tellija territooriumil. Seda tehakse vastavalt Kliendi infokeskkonna (süsteemimaastiku) tingimustele ning loodava süsteemi integreerimise nõuetele teiste Kliendi poolt juba olemasolevate ja opereeritavate tarkvaratoodetega. Projekteerimisetapi tulemuseks peaks olema järgmiste osade kujundus tehniline (kontseptuaalne) projekt:

Infosüsteemi arhitektuur.

Infosalvestuse (andmebaasi) struktuuride kirjeldus.

Disainlahendused, mis on esitatud automatiseerimise stsenaariumide üksikasjaliku kirjeldusega kõigi äriprotsesside jaoks, mida süsteemi juurutamine mõjutab.

Stsenaariumid arendatud infosüsteemi integreerimiseks väliste tarkvaratoodetega.

Lähteandmete allikad ja süsteemi esialgse infosisu võimalused.

Andmetele juurdepääsuõiguste eristamise kontseptsioon kasutaja rollide alusel, mis määravad muuhulgas nende volitused.

Infosüsteemi kasutajate koolitamise kontseptsioon.

Rakendamine

Kõigi lähteülesandes ja tehnilises projektis sätestatud infosüsteemi nõuete rakendamise etapp. Selle perioodi jooksul töötab Töövõtja välja kõik vajalikud tarkvarakomponendid, loob andmebaasistruktuurid, installib, konfigureerib ja testib oma territooriumil kõiki infosüsteemi komponente, simuleerib integratsioonistsenaariume jne. ja nii edasi. Rakendusfaasi lõpuleviimist kinnitab selliste projektidokumentide ilmumine süsteemi installimise ja konfigureerimise juhendina, programm ja testimisprotseduur süsteem, samuti andmebaasi mall ja register kõigist valminud tarkvaraarendustest.

Infosüsteemi ettevalmistamine tööks

Kõik selle etapi tööd toimuvad juba Kliendi ruumides ja hõlmavad kõikide süsteemi komponentide paigaldamist ja seadistamist Kliendi infokeskkonnas, eeltestimist, kasutajadokumentatsiooni väljatöötamist, kasutajakoolitust, andmete esmast laadimist, süsteemi test vastavalt programmile ja katsemetoodikale ning muudele ettevalmistustöödele.

Selleks ajaks, kui kõik ettevalmistustööd on lõpetatud, peaks süsteemi töökord olema välja töötatud ja kinnitatud. Eelkõige peaks määrus määratlema kasutajad ja nende rollid süsteemis vastavalt nende tööülesannetele.

Pilootoperatsioon

Infosüsteemi väljatöötamise ja esmase juurutamise viimane etapp, mille ülesandeks on teatud aja jooksul edukalt läbi viia süsteemi proovitöö ning eesmärgiks on kinnitada, et loodud infosüsteem on just selline tulemus, mida Klient oodatud.

Selle aja jooksul hakkavad kasutajad süsteemi kasutama eelmises etapis välja töötatud eeskirjade kohaselt. Pilootoperatsiooni käigus parandatakse vead ja lepitakse kokku vajalikes täiustustes. Töövõtja kõrvaldab vead, teostab täiustusi ja kui süsteem hakkab toimima vastavalt kõikidele talle varem esitatud nõuetele, saab kehtestatud perioodi lõpus protokolli piloottöö eduka lõpetamise kohta.

Pilootoperatsiooni lõpetamisega reeglina infosüsteemi loomise leping lõppeb. Süsteem läheb ise kommertskasutusele ning Töövõtja, kui Tellija on sellest huvitatud, sõlmib selle hooldamiseks eraldi lepingu lepingutingimustega kehtestatud perioodiks.