STANDARDUL DE STAT AL UNIUNII SSR

TEHNOLOGIA DE INFORMAȚIE

TIPURI DE TESTARE SISTEME AUTOMATICE

GOST 34.603-92

COMITETUL DE STANDARDIZARE SI METROLOGIE URSS

Moscova

STANDARDUL DE STAT AL UNIUNII SSR

Data introducerii 01.01.93

Acest standard se aplică sistemelor automate (AS) utilizate în tipuri variate activități (cercetare, proiectare, management etc.) P.), inclusiv combinațiile lor create în organizații, asociații și întreprinderi (denumite în continuare organizații)

Standardul stabilește tipurile de teste ale UA și cerințele generale pentru efectuarea x.

Termenii utilizați în acest standard internațional și definițiile acestora a mancat eniya - în conformitate cu GOST 34.003.

Cerințele acestui standard, cu excepția pp., , , sunt obligatorii, cerințele alineatelor. , , - recomandat.

1. DISPOZIȚII GENERALE

1.2. Testarea NPP este un proces de verificare a performanței funcțiilor specificate ale sistemului, determinarea și verificarea conformității cu cerințele TOR a caracteristicilor cantitative și (sau) calitative ale sistemului, identificarea și eliminarea deficiențelor în acțiunile sistemului. , în documentația elaborată.

1.3. Pentru UA, sunt stabilite următoarele tipuri principale de teste:

1) preliminar;

2) operațiune de probă qi eu;

3) acceptare.

Note:

1. Permis în plusținând prietenul x în d ov Testarea AC părțile lor.

2. Clasificare permisă aci test de admitere in si in functie de statutul comisiei de acceptare (compunerea membrilor comitetului si nivelul de aprobare).

3. Experimentat nici Statutul comisiei de acceptare este stabilit în contract și (sau) TK.

1.4, În funcție de interconexiunile obiectelor testate în UA, testele pot fi autonome sau complexe.

1.10. Operarea de probă a CNE se efectuează pentru a determina valorile reale ale caracteristicilor cantitative și calitative ale CNE și gradul de pregătire a personalului de a lucra în condițiile de funcționare a CNE, pentru a determina eficiența reală a CNE și documentație corectă (dacă este necesar).

1.11. Testele de acceptare ale UA sunt efectuate pentru a determina conformitatea UA cu termenii de referință, pentru a evalua calitatea operațiunii de probă și pentru a rezolva problema posibilității de adică MK AS în funcțiune permanentă.

1.12. Testele de acceptare AC ar trebui să pr unitati pentru a permite funcționarea sa experimentală la instalație.

1.13. În funcție de tipul de cerințe impuse UA și de teste, verificare sau certificare, aceasta este supusă:

1) un set de software și mijloace tehnice;

2) personalul;

3) documentația operațională care reglementează activitățile personalului în timpul funcționării CNE;

4) AS în general.

1.14. În timpul testelor, difuzoarele verifică:

1) calitatea execuției funcțiilor automate de către un complex de instrumente software și hardware toate moduri f un La poziționare AC conform declarației de lucru a fost creat adică AC;

3) caracterul complet al documentației cuprinse în documentația operațională pentru personalul specificat pentru execuție nenși m funcții în toate modurile de funcționare Cu acordul declarației de lucru privind crearea UA;

4) caracteristici cantitative și (sau) calitative împlinire funcții automate și automatizate ale UA în conformitate cu declarația de lucru:

5) alte proprietăți ale UA, cărora trebuie să le corespundă conform TOR.

2) complex.

2.2. A testare offline

2.2.1. Testele autonome ale AU ar trebui efectuate în corespunzător concurează cu programul și metodologia de teste autonome dezvoltate pentru fiecare parte a UA.

2.2.2. Programul de teste autonome indică:

1) lista de funcții de testat;

2) descrierea relației obiectului testat cu alte părți ale CNE;

3) condiții, procedură și metode pentru efectuarea testelor și a rezultatelor prelucrării;

4) criterii de acceptare pentru piese bazate pe rezultatele testelor.

Un program de testare offline ar trebui să fie atașat programului de testare offline.

2.2.3. Testele (cazurile de testare) pregătite și coordonate în etapa de testare autonomă ar trebui să ofere:

1) o verificare completă a funcțiilor și procedurilor conform listei convenite cu clientul;

2) acuratețea necesară a calculelor, stabilită în TOR;

3) verificarea principalelor caracteristici temporale ale funcționării software-ului (în cazurile în care aceasta este semnificativă);

4) verificarea fiabilității și stabilității funcționării software-ului și hardware-ului.

2.2.4 . Ca informație inițială pentru test, se recomandă utilizarea unui fragment de informații reale ale organizației client într-o cantitate suficientă pentru a asigura fiabilitatea necesară a testelor.

2.2.5 Rezultatele testării autonome ale părților AU ar trebui înregistrate în rapoartele de testare. Protocolul trebuie să conțină o concluzie privind posibilitatea (imposibilitatea) admiterii unei părți din CNE la teste complexe.

2.2.6. În cazul în care testele autonome efectuate se dovedesc a fi insuficiente sau se dezvăluie o încălcare a cerințelor documentelor de reglementare privind compoziția sau conținutul documentației, partea specificată a UA poate fi returnată pentru revizuire și numită. termen nou teste.

2.3. Teste complexe

2.3.1. Testarea cuprinzătoare a AU este efectuată prin efectuarea de teste complexe. Rezultatele testului sunt reflectate în protocol. Lucrarea se finalizează cu executarea certificatului de recepție la exploatare de probă.

2.3.2. Programul de testare integrată a CNE sau părți ale CNE indică:

1) lista obiectelor de testare;

2) componența documentației depuse;

3) o descriere a relațiilor testate între elementele de testare;

4) succesiunea testelor pieselor CNE;

5) procedura și metodele de testare, inclusiv compoziția software-ului și a echipamentelor necesare pentru testare, inclusiv standuri speciale și locuri de testare.

2.3.3. Pentru teste complexe, trebuie depuse următoarele:

1) program integrat de testare;

2) concluzia privind testarea autonomă a părților relevante ale UA și eliminarea erorilor și comentariilor identificate în timpul testării autonome;

3) teste complexe;

4) software și hardware și documentația operațională aferentă.

2.3.4. În testele complexe, este permisă utilizarea ca informație inițială obținută din testele autonome ale părților CNE.

2.3.5. Testul cuprinzător ar trebui:

1) să fie legate logic;

2) să asigure verificarea îndeplinirii funcțiilor părților CNE în toate modurile de funcționare stabilite în TdR pentru CNE, inclusiv toate legăturile dintre acestea;

3) să ofere o verificare a răspunsului sistemului la informații incorecte și la situații de urgență.

2.3.6. Protocolul de testare integrat ar trebui să conțină o concluzie cu privire la posibilitatea (imposibilitatea) acceptării CNE pentru funcționarea de probă, precum și o listă de îmbunătățiri necesare și termene recomandate pentru implementarea acestora.

După eliminarea deficiențelor, se efectuează teste complexe repetate în volumul necesar.

3. OPERAREA PILOT

3.1. Operațiunea de probă se efectuează în conformitate cu programul, care indică:

1) condițiile și procedura de funcționare a unor părți ale UA și a UA în ansamblu;

2) durata operațiune de probă, suficient pentru a verifica funcționarea corectă a UA la îndeplinirea fiecărei funcții a sistemului și disponibilitatea personalului de a lucra. condițiile de funcționare ale AS;

3) procedura de eliminare a deficiențelor identificate în timpul operațiunii de probă.

3.2. În timpul funcționării de probă a AU, se păstrează un jurnal de lucru, în care sunt introduse informații cu privire la durata operațiunii AU, defecțiuni, defecțiuni, urgențe, modificări ale parametrilor obiectului de automatizare, ajustări în curs ale documentației și software-ului și reglarea hardware-ului. Informațiile sunt înregistrate într-un jurnal cu data și persoana responsabila. Jurnalul poate include comentarii din partea personalului cu privire la ușurința de operare a UA.

3.3. Pe baza rezultatelor operațiunii de probă, se ia o decizie cu privire la posibilitatea (sau imposibilitatea) de a prezenta părți ale CNE și a sistemului în ansamblu pentru testele de acceptare.

Lucrarea se încheie cu executarea unui act privind finalizarea operațiunii de probă și admiterea sistemului la teste de recepție.

4. TESTE DE ACCEPTARE

4.1. Testele de acceptare sunt efectuate în conformitate cu programul, care indică:

1) o listă de obiecte alocate în sistem pentru testare și o listă de cerințe pe care obiectele trebuie să le respecte (cu referire la punctele din TOR);

2) criteriile de acceptare pentru sistem și părțile sale;

3) condiții și termeni de testare;

4) mijloace de testare;

5) numele persoanelor responsabile cu efectuarea testelor;

6) metodologia de testare și prelucrarea rezultatelor acestora;

7) o listă cu documentația de întocmit.

4.2. Pentru testarea de acceptare trebuie prezentată următoarea documentație:

1) termenii de referință pentru crearea UA;

2) act de acceptare pentru operațiune de probă;

3) jurnalele de lucru ale operațiunii de probă;

4) actul de finalizare a exploatării de probă și admiterea CNE la probele de recepție;

5) programul și metodologia de testare. Testarea de acceptare ar trebui să fie efectuată într-o unitate funcțională.

4.3. Testarea de acceptare ar trebui să includă în primul rând verificarea:

1) integralitatea și calitatea implementării funcțiilor la valorile standard, limită, critice ale parametrilor obiectului de automatizare și în alte condiții de funcționare ale UA specificate în declarația de lucru;

2) îndeplinirea fiecărei cerinţe legate de interfaţa sistemului;

3) munca personalului într-un mod interactiv;

4) mijloace și metode de restabilire a operabilității AU după defecțiuni;

5) completitudinea și calitatea documentației operaționale.

4.4 . Verificarea completității și calității îndeplinirii funcțiilor UA se recomandă să fie efectuată în două etape. În prima etapă, funcțiile individuale (sarcini, complexe de sarcini) sunt testate. În același timp, ei verifică îndeplinirea cerințelor TOR pentru funcții (sarcini, complexe de sarcini). În a doua etapă, se verifică interacțiunea sarcinilor din sistem și îndeplinirea cerințelor TOR pentru sistem în ansamblu.

4.5 . Prin acord cu clientul, verificarea sarcinilor, in functie de specificul acestora, poate fi efectuata autonom sau ca parte a unui complex. Este recomandabil să combinați sarcinile la verificarea în complexe, ținând cont de comunitatea informațiilor utilizate și a conexiunilor interne.

4.6. Verificarea muncii personalului într-un mod interactiv se efectuează ținând cont de caracterul complet și de calitatea performanței funcțiilor sistemului în ansamblu.

Sub rezerva verificării:

1) caracterul complet al mesajelor, directivelor, solicitărilor de care dispune operatorul și suficiența acestora pentru funcționarea sistemului;

2) complexitatea procedurilor de dialog, capacitatea personalului de a lucra fără pregătire specială;

3) reacția sistemului și a părților sale la erorile operatorului, instalațiile de service.

4.7. Verificarea mijloacelor de restabilire a sănătății UA după defecțiuni ale computerului ar trebui să includă:

1) verificarea prezenței în documentația operațională a recomandărilor pentru restabilirea operabilității și a caracterului complet al descrierii acestora;

3) operabilitatea mijloacelor de restabilire automată a funcțiilor (dacă există).

4.8. Verificarea completității și calității documentației operaționale ar trebui să fie efectuată prin analiza documentației pentru conformitatea cu cerințele documentelor de reglementare și tehnice și TOR.

4.9. Rezultatele testării obiectelor prevăzute de program sunt înregistrate în protocoalele care conțin următoarele secțiuni:

1) scopul încercărilor și numărul secțiunii din cerințele TOR pentru CNE, pentru care se efectuează testarea;

2) compoziția hardware-ului și software-ului utilizat în teste;

3) o indicare a metodelor în conformitate cu care au fost efectuate testele, prelucrarea și evaluarea rezultatelor;

4) condițiile de testare și caracteristicile datelor inițiale;

5) facilitati de depozitare si conditii de acces la programul final de testare;

6) rezultatele testelor generalizate;

7) concluzii despre rezultatele testelor și conformitatea sistemului creat sau a părților sale cu o anumită secțiune a cerințelor TOR pentru CNE.

4.10. Rapoartele de testare a obiectelor de-a lungul programului sunt rezumate într-un singur protocol, pe baza căruia se face o concluzie despre conformitatea sistemului cu cerințele specificațiilor tehnice pentru CNE și posibilitatea emiterii unui act de acceptare a CNE pentru funcționare permanentă.

Lucrarea se finalizează prin executarea actului de recepție în exploatare permanentă a CNE.

DATE INFORMAȚII

1. DEZVOLTAT ȘI INTRODUS de Comitetul Tehnic TC 22 " Tehnologia de informație", Subcomisia PC 052 "Sisteme automatizate"

DEZVOLTATORII

I.P. Vakhlakov, Ya.G. Vilenchik, F.R. Vidra, cand. tehnologie. științe; L.M. Seidenberg, cand. tehnologie. științe; Yu.B. irz, cand. tehnologie. științe; V.G. Ivanov, V.D. Kostiukov, cand. tehnologie. științe; V.G. Mihailov, cand. tehnologie. științe; N.V. Stepanchikov

Teste preliminare

Testele preliminare EIS pot fi autonome și complexe.

Programul de teste autonome indică:

lista de funcții de testat;

descrierea relației obiectului de testare cu alte părți ale EIS;

condiții, procedură și metode pentru efectuarea testelor și a rezultatelor prelucrării;

· Criterii de acceptare a pieselor bazate pe rezultatele testelor.

Un program de testare offline ar trebui să fie atașat programului de testare offline.

Testele (cazurile de testare) pregătite și coordonate în etapa de testare autonomă ar trebui să ofere:

Verificarea completă a funcțiilor și procedurilor conform listei convenite cu clientul;

acuratețea necesară a calculelor, stabilită în TOR;

Verificarea principalelor caracteristici temporale ale funcționării software-ului;

Verificarea fiabilității și stabilității funcționării software-ului și hardware-ului.

Rezultatele testelor autonome ale pieselor EIS sunt consemnate în rapoartele de testare. Protocolul trebuie să conțină o concluzie privind posibilitatea admiterii unei părți din EIS la teste complexe. În cazul în care testele autonome efectuate se dovedesc a fi insuficiente sau se dezvăluie o încălcare a cerințelor documentelor de reglementare privind compoziția sau conținutul documentației, partea specificată a EIS poate fi returnată pentru revizuire și un nou se atribuie perioada de testare.

Teste complexe EIS se realizează prin efectuarea de teste complexe. Testul cuprinzător ar trebui:

să fie conectat logic;

· să asigure verificarea performanței funcțiilor părților EIS în toate modurile de funcționare;

· să asigure verificarea reacției sistemului la informații incorecte și urgențe.

Rezultatele testului sunt reflectate în protocol. Lucrarea se finalizează cu executarea certificatului de recepție la exploatare de probă.

În programul de teste complexe ale EIS indicați:

o listă de obiecte de testare;

componența documentației depuse;

o descriere a relațiilor care trebuie testate între obiectele de testare;

secvența părților de testare ale EIS;

· procedura și metodele de testare, inclusiv compoziția software-ului și a echipamentelor necesare pentru testare, inclusiv standuri speciale și locuri de testare.

Protocolul de testare integrat ar trebui să conțină o concluzie cu privire la posibilitatea (imposibilitatea) acceptării EIS pentru operarea de probă, precum și o listă a îmbunătățirilor necesare și a termenelor limită recomandate pentru implementarea acestora.

Operațiunea de probă se efectuează în conformitate cu programul, care indică:

condițiile și procedura de funcționare a părților EIS și a EIS în ansamblu;

durata operațiunii de probă suficientă pentru a verifica funcționarea corectă a EIS;

Procedura de eliminare a deficiențelor identificate în timpul operațiunii de probă.

În timpul funcționării de probă a EIS, se păstrează un jurnal de lucru, în care se introduc informații cu privire la durata de funcționare a EIS, defecțiuni, defecțiuni, urgențe, modificări ale parametrilor obiectului de automatizare, ajustări în curs ale documentației și software, ajustare și mijloace tehnice. Informațiile sunt înregistrate în jurnal cu data și persoana responsabilă. Jurnalul poate conține comentarii ale personalului cu privire la ușurința de operare a EIS.

Pe baza rezultatelor operațiunii de probă, se ia o decizie cu privire la posibilitatea de a prezenta părți ale EIS și a sistemului în ansamblu pentru testele de acceptare.

Lucrarea se încheie cu executarea unui act privind finalizarea operațiunii de probă și admiterea sistemului la teste de recepție.

Etapa finală a procesului de implementare a proiectului software de la firma 1C, este operațiune de probă. Este necesar pentru ca utilizatorul să poată verifica funcționarea corectă a sistemului, iar dezvoltatorii să poată elimina rapid deficiențele existente.

Ce este operațiunea de probă?

În esență, această etapă vă permite să verificați pregătirea sistemului pentru acesta uz industrial. Utilizatorul, împreună cu dezvoltatorul, verifică toți algoritmii principali ai programului și, dacă este necesar, îi corectează și depanează. În această etapă corectitudinea prelucrării datelor în conditii reale operare ulterioară. Chestia este că unele defecte ale software-ului pot fi identificate numai atunci când se lucrează cu o cantitate mare de informații.

Cele mai frecvente defecte

În procesul de utilizare a programului în condiții reale, pot apărea unele defecte din cauza „nepregătirii” sistemului pentru a lucra cu o cantitate mare de date. Aici sunt câțiva dintre ei:

• inerția, sau cu alte cuvinte, inacțiunea sistemului la crearea unor documente. Pentru identificarea acestei erori, se recomandă să se verifice posibilitatea creării fiecărui document folosind numărul maxim de poziții;
• programul durează foarte mult timp pentru a genera unele rapoarte. Cel mai probabil, sistemul nu este pregătit să funcționeze cu o cantitate mare de date sau un algoritm nu funcționează destul de corect. Dezvoltatorul trebuie să verifice de două ori întregul lanț și să remedieze problema;
• aspect situatii conflictuale când se lucrează cu unele obiecte. În general, în majoritatea cazurilor, vorbim despre elemente „complexe”;
• probleme cu realizarea documentelor, care sunt cel mai adesea cauzate de un algoritm incorect.

Principalele tipuri de operațiuni de probă

În funcție de modul în care este produs software-ul, se pot distinge două tipuri principale de operațiuni de probă:

1. există situații în care stadiul de dezvoltare este forțat să „se amestece” cu operațiunea de probă. Acest lucru este relevant în acele situații când vine vorba de o configurație destul de complexă care necesită un număr mare de suplimente individuale. Chestia este că, în procesul de dezvoltare, nu este întotdeauna posibil să se țină cont de toate cerințele pentru program;
2. al doilea tip este operațiunea de probă „standard”. Reprezintă utilizarea simultană a software-ului existent și a produsului software implementat. De regulă, aici sunt utilizate baze de date reale, liste de contrapărți și operațiuni în derulare. Acest lucru se face astfel încât utilizatorul să poată determina cât de corect efectuează programul o anumită sarcină. Cel mai adesea, pentru a optimiza acest proces, dezvoltatorii fac posibil schimbul temporar de informații între cele două sisteme. Astfel, ambele programe vor folosi aceleași informații, ceea ce va minimiza riscul unei erori accidentale.

Fiecare utilizator trebuie să fie pregătit pentru faptul că în etapa de operare de probă va întâmpina anumite neajunsuri. Ideea este că model de bază Programul a fost deja testat în mod repetat în condiții reale, în timp ce o configurație specializată este adesea instalată într-o formă „brută”, verificată doar în timpul procesului de dezvoltare. De regulă, dezvoltatorii elimină rapid toate deficiențele, iar programul începe să funcționeze destul de corect și stabil. Printre altele, nu ar trebui să excludem deja o astfel de nuanță sistem existent poate fi cauza problemelor la testarea unui produs nou, deoarece este departe de a fi întotdeauna posibilă configurarea imediată a setărilor optime de compatibilitate și schimb de date între sisteme.

Creare Sistem informaticîncepe din momentul primelor negocieri între Client și potențialul Contractor și s-ar putea să nu se termine niciodată, deoarece sistemele bune și utile sunt în mod constant îmbunătățite și dezvoltate.

etapa preliminara

În această etapă, este necesar să înțelegem principalele scopuri și obiective ale viitorului proiect. Pentru aceasta, reprezentanții cheie ai Clientului și Antreprenorului organizează întâlniri la care discută despre conceptul sistemului informațional, punctele tehnice cheie, calendarul și sfera lucrărilor efectuate, precum și costul și sursele de finanțare. Rezultatul etapei preliminare, pe lângă termenii conveniți ai viitorului contract, ar trebui să fie primul și cel mai fundamental document de proiect - carta de proiect.

Carta proiectului definește următoarele puncte fundamentale legate de procesul de dezvoltare și implementare a unui sistem informațional:

• Scurtă descriere a proiectului, scopurile și obiectivele creării unui sistem informațional.
• Descrierea generală a domeniului de activitate.
• Limitele proiectului: termeni, buget, lista obiectelor de automatizare.
• Descrierea produsului: lista cu hardware-ul și software-ul furnizat, tipul și numărul de licențe etc.
• Structura organizatorică a proiectului: lista și rolurile membrilor echipei de proiect din partea Antreprenorului și a Clientului, responsabilitățile și atribuțiile acestora, sistemul de management al documentelor de proiect.
• Principalele etape de dezvoltare și implementare a sistemului informațional, un program extins pentru implementarea acestora.
• Cele mai semnificative riscuri de neîndeplinire a obligațiilor din cadrul proiectului, precum și modalități de minimizare a riscurilor.

Cu alte cuvinte, carta de proiect este tocmai carta care este elaborată de managerul de proiect împreună cu membrii principali ai echipei de proiect, aprobată de conducerea Antreprenorului și a Clientului, și nu trebuie ajustată pe toată perioada creării. sistemul informatic.

Finalizarea etapei preliminare poate fi considerată momentul în care se semnează contractul de servicii pentru dezvoltarea și implementarea sistemului informațional și se aprobă carta proiectului.

Cerințe de colectare

În acest moment, toate cifrele cheie - participanții la proiect au fost identificate și nimic nu ne împiedică să începem să colectăm și să aprobăm cerințele pentru viitorul sistem informațional. Reprezentanții contractorului comunică cu viitorii utilizatori și administratori ai sistemului, precum și cu managementul acestora. Pe parcursul sondajului, nu sunt sistematizate doar cerințele și dorințele pentru soluția implementată, ci este analizată și documentația, care ar trebui să devină sursa datelor inițiale ale sistemului, sau a cărei formare ar trebui automatizată ca urmare.

rezultat această etapă ar trebui să fie aspectul termeni de referinta pentru dezvoltarea si implementarea sistemului informatic. Termenii de referință ar trebui să se bazeze pe termenii contractului și pe cerințele stabilite în carta proiectului și să conțină următoarele secțiuni (pentru Rusia, structura termenilor de referință este reglementată de GOST 34.602 89):

• Scopul și scopul creării sistemului.
• Descrierea obiectului de automatizare și a principalelor procese de afaceri automatizate.
• Cerințe de sistem: cerințe de structură; funcții (sarcini) rezolvate de sistem; tehnic și suport organizatoric; cerințe de fiabilitate, siguranță etc. și așa mai departe.
• Compoziția și conținutul lucrărilor privind crearea unui sistem informațional.
• Ordinea de control și acceptare a rezultatelor muncii.
• Cerințe pentru sfera de activitate pentru pregătirea unui obiect de automatizare pentru punerea în funcțiune a sistemului informațional.
• Cerințe pentru compoziția proiectării și a documentației utilizator.

Finalizarea etapei de colectare a cerințelor reprezintă aprobarea Termenilor de referință de către Client. În unele cazuri, înainte de începerea lucrărilor la proiect, Clientul are deja un termen de referință (inclus în documentația de licitație). În acest caz, rezultatele sondajului și colectării cerințelor sunt înregistrate în termeni de referință privat, detaliind și concretizând Cerințe generale la sistemul informatic prezentat în caietul de sarcini inițial.

Proiecta

In aceasta etapa, prin eforturile Antreprenorului, sunt concepute in detaliu toate scenariile legate de dezvoltarea si implementarea unui sistem informatic pe teritoriul Clientului. Aceasta se realizează în conformitate cu condițiile mediului informațional (peisaj de sistem) al Clientului și cu cerințele pentru integrarea sistemului fiind creat cu altele deja disponibile și operate de către Client. produse software. Rezultatul fazei de proiectare ar trebui să fie proiectarea următoarelor secțiuni proiect tehnic (conceptual).:

• Arhitectura sistemului informatic.
• Descrierea structurilor de stocare a informațiilor (bază de date).
• Soluții de proiectare prezentate printr-o descriere detaliată a scenariilor de automatizare pentru toate procesele de afaceri afectate de implementarea sistemului.
• Scenarii pentru integrarea sistemului informatic dezvoltat cu produse software externe.
• Surse de date inițiale și opțiuni pentru conținutul informațional inițial al sistemului.
• Conceptul de diferențiere a drepturilor de acces la date pe baza rolurilor de utilizator, care determină, printre altele, puterile acestora.
• Conceptul de instruire a utilizatorilor sistemului informatic.

Implementarea

Etapa de implementare a tuturor cerințelor pentru sistemul informațional stabilit în termeni de referintaȘi proiect tehnic. În această perioadă, Antreprenorul dezvoltă toate componentele software necesare, creează structuri de baze de date, instalează, configurează și testează toate componentele sistemului informațional de pe teritoriul său, simulează scenarii de integrare etc. și așa mai departe. Finalizarea fazei de implementare este confirmată de apariția unor astfel de documente de proiect ca manual de instalare și configurare a sistemului, programul și procedura de testare sistem, precum și un șablon de bază de date și un registru al tuturor dezvoltărilor software finalizate.

Pregatirea sistemului informatic pentru functionare

Toate lucrările din această etapă se desfășoară deja pe site-ul Clientului și includ instalarea și configurarea tuturor componentelor sistemului în mediul informațional al Clientului, testarea preliminară, dezvoltarea documentației utilizatorului, instruirea utilizatorilor, încărcarea datelor inițiale, testarea în conformitate cu prevederile program și metodologie și alte lucrări pregătitoare.

Până la finalizarea tuturor lucrărilor pregătitoare, procedura de operare a sistemului ar trebui să fie dezvoltată și aprobată. Regulamentul, în special, ar trebui să definească utilizatorii și rolurile acestora în sistem, în conformitate cu responsabilitățile lor.

Operare pilot

Ultima etapă a dezvoltării și implementării inițiale a unui sistem informatic, a cărei sarcină este de a efectua cu succes o operațiune de probă a sistemului pentru un anumit timp, iar scopul este de a confirma că sistemul informațional creat este exact rezultatul că Clientul asteptat.

În această perioadă, utilizatorii încep să opereze sistemul în conformitate cu reglementările elaborate în etapa anterioară. În timpul experimentului operare industriala erorile sunt remediate și sunt convenite îmbunătățirile necesare. Antreprenorul elimină erorile, efectuează îmbunătățiri și, cu condiția ca sistemul să înceapă să funcționeze în conformitate cu toate cerințele care i-au fost prezentate anterior, la sfârșitul perioadei stabilite, primește un protocol privind finalizarea cu succes a operațiunii pilot.

Odată cu finalizarea operațiunii pilot, de regulă, contractul de realizare a unui sistem informatic încetează. Sistemul în sine intră în exploatare comercială, iar Antreprenorul, dacă Clientul este interesat de acest lucru, încheie contract separat pentru susţinerea acestuia, pe perioada stabilită prin clauzele contractului.

Întreținerea și dezvoltarea sistemului

Operarea industrială poate dezvălui că unele cerințe pentru sistemul informațional creat conțineau inexactități și necesită o formulare sau completări diferite, iar sistemul în sine trebuie îmbunătățit. Nu fiecare Client are personal în personalul său care este capabil să introducă în mod independent toate schimbările dictate de situația reală în sistem, prin urmare, încheie un acord separat cu Antreprenorul pentru întreținerea sistemului informațional.

Utilizatorii sistemului informatic încep să comunice cu reprezentanții serviciului de asistență al Clientului, care primesc solicitări de la aceștia pentru îmbunătățirea funcționalității și eliminarea defectelor, solicitări de transfer pentru lucru și notifică periodic utilizatorii cu privire la starea solicitării lor. Lista posibilelor îmbunătățiri și procedura de procesare a cererilor este determinată de termenii contractului. Dacă există o nevoie de lucrări care nu se încadrează în esența contractului de asistență, atunci Clientul și Antreprenorul întocmesc un contract separat pentru această specie lucru, care poate fi deja atribuit lucrărilor de modernizare și dezvoltare a sistemului informațional operat.

In aceasta etapa, prin eforturile Antreprenorului, sunt concepute in detaliu toate scenariile legate de dezvoltarea si implementarea unui sistem informatic pe teritoriul Clientului. Aceasta se realizează în conformitate cu condițiile mediului informațional (peisajul sistemului) al Clientului și cu cerințele pentru integrarea sistemului fiind creat cu alte produse software deja disponibile și operate de către Client. Rezultatul fazei de proiectare ar trebui să fie proiectarea următoarelor secțiuni proiect tehnic (conceptual).:

Arhitectura sistemului informatic.

Descrierea structurilor de stocare a informațiilor (bază de date).

Soluții de proiectare prezentate printr-o descriere detaliată a scenariilor de automatizare pentru toate procesele de afaceri afectate de implementarea sistemului.

Scenarii pentru integrarea sistemului informatic dezvoltat cu produse software externe.

Surse de date inițiale și opțiuni pentru conținutul informațional inițial al sistemului.

Conceptul de diferențiere a drepturilor de acces la date pe baza rolurilor de utilizator, care determină, printre altele, puterile acestora.

Conceptul de instruire a utilizatorilor sistemului informatic.

Implementarea

Etapa de implementare a tuturor cerințelor pentru sistemul informatic stabilite în Termenii de Referință și Proiectul Tehnic. În această perioadă, Antreprenorul dezvoltă toate componentele software necesare, creează structuri de baze de date, instalează, configurează și testează toate componentele sistemului informațional de pe teritoriul său, simulează scenarii de integrare etc. și așa mai departe. Finalizarea fazei de implementare este confirmată de apariția unor astfel de documente de proiect ca manual de instalare și configurare a sistemului, programul și procedura de testare sistem, precum și un șablon de bază de date și un registru al tuturor dezvoltărilor software finalizate.

Pregatirea sistemului informatic pentru functionare

Toate lucrările din această etapă se desfășoară deja la sediul Clientului și includ instalarea și configurarea tuturor componentelor sistemului în mediul informațional al Clientului, testarea preliminară, dezvoltarea documentației utilizatorului, instruirea utilizatorilor, încărcarea inițială a datelor, testarea sistemuluiîn conformitate cu programul și metodologia de testare și alte lucrări pregătitoare.

Până la finalizarea tuturor lucrărilor pregătitoare, procedura de operare a sistemului ar trebui să fie dezvoltată și aprobată. Regulamentul, în special, ar trebui să definească utilizatorii și rolurile acestora în sistem, în conformitate cu responsabilitățile lor.

Operare pilot

Ultima etapă a dezvoltării și implementării inițiale a unui sistem informatic, a cărei sarcină este de a efectua cu succes o operațiune de probă a sistemului pentru un anumit timp, iar scopul este de a confirma că sistemul informațional creat este exact rezultatul că Clientul asteptat.

În această perioadă, utilizatorii încep să opereze sistemul în conformitate cu reglementările elaborate în etapa anterioară. În timpul operațiunii pilot, erorile sunt remediate și sunt convenite îmbunătățirile necesare. Antreprenorul elimină erorile, efectuează îmbunătățiri și, cu condiția ca sistemul să înceapă să funcționeze în conformitate cu toate cerințele care i-au fost prezentate anterior, la sfârșitul perioadei stabilite, primește un protocol privind finalizarea cu succes a operațiunii pilot.

Odată cu finalizarea operațiunii pilot, de regulă, contractul de realizare a unui sistem informatic încetează. Sistemul propriu-zis intră în exploatare comercială, iar Antreprenorul, dacă Clientul este interesat de acest lucru, încheie un contract separat de întreținere a acestuia, pe perioada stabilită prin termenii contractului.