STANDARD DI STATO DELL'UNIONE DELLA SSR

TECNOLOGIE DELL'INFORMAZIONE

TIPI DI COLLAUDO SISTEMI AUTOMATIZZATI

GOST 34.603-92

COMITATO DI STANDARDIZZAZIONE E METROLOGIA DELL'URSS

Mosca

STANDARD DI STATO DELL'UNIONE DELLA SSR

Data di introduzione 01.01.93

Questo standard si applica ai sistemi automatizzati (AS) utilizzati in vari tipi attività (ricerca, progettazione, gestione, ecc.) P.), comprese le loro combinazioni create in organizzazioni, associazioni e imprese (di seguito denominate organizzazioni)

Lo standard stabilisce i tipi di test dell'AU e i requisiti generali per l'esecuzione di x.

Termini utilizzati nella presente norma internazionale e relative definizioni mangiò eniya - in conformità con GOST 34.003.

I requisiti di questo standard, eccetto pp., , , sono obbligatori, i requisiti dei paragrafi. , , - consigliato.

1. DISPOSIZIONI GENERALI

1.2. Il test NPP è un processo di verifica delle prestazioni delle funzioni specificate del sistema, determinazione e verifica della conformità ai requisiti del TOR delle caratteristiche quantitative e (o) qualitative del sistema, identificazione ed eliminazione delle carenze nelle azioni del sistema , nella documentazione sviluppata.

1.3. Per l'UA, sono stabiliti i seguenti tipi principali di test:

1) preliminare;

2) operazione di prova chi IO;

3) accettazione.

Appunti:

1. Consentito inoltre tenendo l'amico x in d ov Test CA le loro parti.

2. Classificazione consentita aci test d'ingresso in e a seconda dello status del comitato di accettazione (la composizione dei membri del comitato e il livello di approvazione).

3. Esperto nessuno dei due Lo stato della commissione di accettazione è stabilito nel contratto e (o) TK.

1.4, A seconda delle interconnessioni degli oggetti testati nell'UA, i test possono essere autonomi o complessi.

1.10. L'operazione di prova di C viene eseguita al fine di determinare i valori effettivi delle caratteristiche quantitative e qualitative della centrale nucleare e la prontezza del personale a lavorare nelle condizioni di funzionamento della centrale nucleare, determinare l'effettiva efficienza della centrale nucleare e documentazione corretta (se necessaria).

1.11. I test di accettazione dell'AU vengono effettuati per determinare la conformità dell'AU ai termini di riferimento, valutare la qualità dell'operazione di prova e risolvere la questione della possibilità di cioè MK AS in funzionamento permanente.

1.12. I test di accettazione AC dovrebbero pr unità per consentirne il funzionamento sperimentale presso la struttura.

1.13. A seconda del tipo di requisiti imposti all'AU e di prove, verifiche o certificazioni, essa è sottoposta a:

1) un set di software e mezzi tecnici;

2) personale;

3) documentazione operativa che regola le attività del personale durante il funzionamento della centrale nucleare;

4) COME in generale.

1.14. Durante i test, i relatori controllano:

1) la qualità dell'esecuzione di funzioni automatiche da parte di un complesso di strumenti software e hardware Tutto modalità f un A posizionamento AC secondo la dichiarazione di lavoro è stato creato cioè AC;

3) la completezza della documentazione contenuta nella documentazione operativa per il personale specificato per l'esecuzione nen e m funzioni in tutte le modalità operative Con il consenso della dichiarazione di lavoro sulla creazione dell'AU;

4) caratteristiche quantitative e (o) qualitative compimento funzioni automatiche e automatizzate dell'AU in conformità con la dichiarazione di lavoro:

5) altre proprietà dell'AU, alle quali deve corrispondere ai sensi del TOR.

2) complesso.

2.2. UN prova offline

2.2.1. I test autonomi dell'UA dovrebbero essere eseguiti in corrispondente competere con il programma e la metodologia dei test autonomi sviluppati per ciascuna parte dell'UA.

2.2.2. Il programma delle prove autonome indica:

1) elenco delle funzioni da testare;

2) descrizione della relazione dell'oggetto di prova con altre parti della centrale nucleare;

3) condizioni, procedure e modalità per l'esecuzione delle prove e l'elaborazione dei risultati;

4) criteri di accettazione per le parti basati sui risultati dei test.

Un programma di test offline deve essere allegato al programma di test offline.

2.2.3. I test preparati e coordinati (casi di test) nella fase di test autonomi dovrebbero fornire:

1) un controllo completo delle funzioni e delle procedure secondo l'elenco concordato con il cliente;

2) la precisione richiesta dei calcoli, stabilita nel TOR;

3) verifica delle principali caratteristiche temporali del funzionamento del software (nei casi in cui questa sia significativa);

4) verificare l'affidabilità e la stabilità del funzionamento del software e dell'hardware.

2.2.4 . Come informazione iniziale per il test, si consiglia di utilizzare un frammento di informazioni reali dell'organizzazione cliente in quantità sufficiente a garantire la necessaria affidabilità dei test.

2.2.5 I risultati delle prove autonome di parti dell'UA dovrebbero essere registrati nei rapporti di prova. Il protocollo deve contenere una conclusione sulla possibilità (impossibilità) di ammettere una parte della centrale nucleare a test complessi.

2.2.6. Nel caso in cui le prove autonome effettuate siano ritenute insufficienti, o venga rilevata una violazione dei requisiti dei documenti normativi sulla composizione o sul contenuto della documentazione, la parte specificata dell'AU può essere restituita per la revisione e nominata nuovo termine test.

2.3. Prove complesse

2.3.1. Il test completo dell'AU viene eseguito eseguendo test complessi. I risultati del test si riflettono nel protocollo. Il lavoro si completa con l'esecuzione del certificato di accettazione per il funzionamento di prova.

2.3.2. Il programma di sperimentazione integrata della centrale nucleare o di parti della centrale indica:

1) elenco degli oggetti di prova;

2) la composizione della documentazione presentata;

3) una descrizione delle relazioni in fase di test tra gli elementi di test;

4) la sequenza dei test delle parti della centrale nucleare;

5) la procedura ei metodi di collaudo, compresa la composizione del software e delle apparecchiature necessarie per il collaudo, compresi stand speciali e siti di prova.

2.3.3. Per i test complessi, è necessario presentare:

1) programma di test integrato;

2) conclusione sui test autonomi delle parti pertinenti dell'UA ed eliminazione degli errori e dei commenti identificati durante i test autonomi;

3) test complessi;

4) software e hardware e relativa documentazione operativa.

2.3.4. In test complessi, è consentito utilizzare come informazioni iniziali ottenute da test autonomi di parti della centrale nucleare.

2.3.5. Il test completo dovrebbe:

1) essere logicamente collegati;

2) garantire la verifica dell'esecuzione delle funzioni delle parti della centrale nucleare in tutte le modalità operative stabilite nel capitolato d'oneri per la centrale nucleare, comprese tutte le connessioni tra di esse;

3) fornire un controllo sulla risposta del sistema a informazioni errate ea situazioni di emergenza.

2.3.6. Il protocollo di prova integrato dovrebbe contenere una conclusione sulla possibilità (impossibilità) di accettare la centrale nucleare per l'operazione di prova, nonché un elenco dei miglioramenti necessari e le scadenze raccomandate per la loro attuazione.

Dopo l'eliminazione delle carenze, vengono eseguiti ripetuti test complessi nel volume richiesto.

3. FUNZIONAMENTO PILOTA

3.1. L'operazione di prova viene eseguita secondo il programma, che indica:

1) le condizioni e la procedura per il funzionamento di parti dell'UA e dell'UA nel suo complesso;

2) durata operazione di prova, sufficiente a verificare il corretto funzionamento dell'UA nello svolgimento di ogni funzione del sistema e la disponibilità del personale ad operare. condizioni operative del SA;

3) la procedura per eliminare le carenze individuate durante l'operazione di prova.

3.2. Durante l'operazione di prova dell'AU, viene tenuto un registro di lavoro, in cui vengono inserite informazioni sulla durata dell'operazione AU, guasti, guasti, emergenze, modifiche ai parametri dell'oggetto di automazione, adeguamenti in corso alla documentazione e al software e regolazione dell'hardware. Le informazioni sono registrate nel giornale con la data e persona responsabile. Il giornale può includere commenti del personale sulla facilità di funzionamento dell'AU.

3.3. Sulla base dei risultati dell'operazione di prova, viene presa una decisione sulla possibilità (o impossibilità) di presentare parti della centrale nucleare e il sistema nel suo insieme per i test di accettazione.

I lavori si concludono con l'esecuzione di un atto sul completamento dell'operazione di prova e l'ammissione del sistema ai test di collaudo.

4. PROVE DI ACCETTAZIONE

4.1. I test di accettazione vengono eseguiti secondo il programma, che indica:

1) un elenco di oggetti allocati nel sistema per il collaudo e un elenco di requisiti che gli oggetti devono soddisfare (con riferimento ai punti del TOR);

2) criteri di accettazione del sistema e delle sue parti;

3) condizioni e termini di collaudo;

4) mezzi per il collaudo;

5) nomi delle persone responsabili dell'esecuzione dei test;

6) metodologia di prova ed elaborazione dei relativi risultati;

7) un elenco della documentazione da redigere.

4.2. Per i test di accettazione, deve essere presentata la seguente documentazione:

1) termini di riferimento per la creazione dell'UA;

2) atto di accettazione per operazione di prova;

3) registri di lavoro dell'operazione di prova;

4) atto di completamento dell'operazione sperimentale e di ammissione della centrale nucleare ai test di collaudo;

5) programma e metodologia di prova. I test di accettazione dovrebbero essere eseguiti in una struttura funzionante.

4.3. I test di accettazione dovrebbero includere principalmente la verifica di:

1) la completezza e la qualità dell'implementazione delle funzioni a valori standard, limitanti, critici dei parametri dell'oggetto di automazione e in altre condizioni operative dell'AU specificate nella dichiarazione di lavoro;

2) soddisfacimento di ogni requisito relativo all'interfaccia di sistema;

3) il lavoro del personale in modalità interattiva;

4) mezzi e modalità per il ripristino dell'operatività dell'UA dopo guasti;

5) completezza e qualità della documentazione operativa.

4.4 . Si raccomanda di effettuare la verifica della completezza e della qualità dello svolgimento delle funzioni dell'UA in due fasi. Nella prima fase vengono testate le singole funzioni (compiti, complessi di compiti). Allo stesso tempo, controllano il rispetto dei requisiti del TOR per le funzioni (compiti, complessi di compiti). Nella seconda fase viene verificata l'interazione dei compiti nel sistema e il rispetto dei requisiti del TOR per il sistema nel suo insieme.

4.5 . Previo accordo con il cliente, la verifica degli incarichi, a seconda delle loro specificità, può essere svolta autonomamente o come parte di un complesso. Si consiglia di combinare le attività durante il check-in dei complessi, tenendo conto della comunanza delle informazioni utilizzate e delle connessioni interne.

4.6. Il controllo del lavoro del personale in modalità interattiva viene effettuato tenendo conto della completezza e della qualità dell'esecuzione delle funzioni del sistema nel suo insieme.

Con riserva di verifica:

1) la completezza di messaggi, direttive, richieste a disposizione dell'operatore e la loro sufficienza per il funzionamento del sistema;

2) la complessità delle procedure di dialogo, la capacità del personale di lavorare senza una formazione specifica;

3) la reazione del sistema e delle sue parti agli errori dell'operatore, alle strutture di servizio.

4.7. Il controllo dei mezzi per ripristinare la salute dell'UA dopo i guasti del computer dovrebbe includere:

1) verificare la presenza nella documentazione operativa di raccomandazioni per il ripristino dell'operatività e la completezza della loro descrizione;

3) operatività dei mezzi di ripristino automatico delle funzioni (se presenti).

4.8. La verifica della completezza e della qualità della documentazione operativa dovrebbe essere effettuata analizzando la documentazione per la conformità ai requisiti dei documenti normativi e tecnici e TOR.

4.9. I risultati dei test degli oggetti previsti dal programma sono registrati nei protocolli contenenti le seguenti sezioni:

1) lo scopo delle prove e il numero della sezione dei requisiti del TOR per la centrale nucleare, per la quale viene eseguita la prova;

2) la composizione dell'hardware e del software utilizzato nelle prove;

3) l'indicazione delle modalità secondo le quali sono state effettuate le prove, elaborazione e valutazione dei risultati;

4) condizioni di prova e caratteristiche dei dati iniziali;

5) impianti di stoccaggio e condizioni di accesso al programma di collaudo finale;

6) risultati dei test generalizzati;

7) conclusioni sui risultati del test e sulla conformità del sistema creato o delle sue parti a una determinata sezione dei requisiti del TOR per la centrale nucleare.

4.10. I rapporti di prova degli oggetti in tutto il programma sono riassunti in un unico protocollo, sulla base del quale si giunge a una conclusione sulla conformità del sistema ai requisiti delle specifiche tecniche per la centrale nucleare e sulla possibilità di emettere un atto di accettazione del NPP per il funzionamento permanente.

Il lavoro è completato dall'esecuzione dell'atto di accettazione della centrale nucleare in funzionamento permanente.

DATI INFORMATIVI

1. SVILUPPATO E INTRODOTTO dal Comitato Tecnico TC 22" Tecnologie dell'informazione", Sottocommissione PC 052 "Sistemi automatizzati"

SVILUPPATORI

IP Vakhlakov, Ya.G. Vilenchik, F.R. Lontra, cand. tech. scienze; LM Seidenberg, cand. tech. scienze; Yu.B. irz, cand. tech. scienze; V.G. Ivanov, V.D. Kostyukov, cand. tech. scienze; V.G. Mikhailov, cand. tech. scienze; N.V. Stepanchikov

Prove preliminari

I test preliminari EIS possono essere autonomi e complessi.

Il programma delle prove autonome indica:

elenco delle funzioni da testare;

descrizione della relazione dell'oggetto di prova con altre parti dell'EIS;

condizioni, procedure e metodi per l'esecuzione delle prove e l'elaborazione dei risultati;

· Criteri per l'accettazione delle parti in base ai risultati dei test.

Un programma di test offline deve essere allegato al programma di test offline.

I test preparati e coordinati (casi di test) nella fase di test autonomi dovrebbero fornire:

Controllo completo delle funzioni e delle procedure secondo la lista concordata con il cliente;

la necessaria accuratezza dei calcoli, stabilita nel TOR;

Verifica delle principali caratteristiche temporali del funzionamento del software;

Verifica dell'affidabilità e della stabilità del funzionamento di software e hardware.

I risultati dei test autonomi delle parti EIS sono registrati nei rapporti di prova. Il protocollo deve contenere una conclusione sulla possibilità di ammettere una parte del SIA a test complessi. Nel caso in cui le verifiche autonome effettuate risultino insufficienti, o si evidenzi una violazione dei requisiti dei documenti normativi sulla composizione o sul contenuto della documentazione, la parte specificata del SIA può essere restituita per la revisione e un nuovo periodo di prova è assegnato.

Prove complesse L'EIS viene eseguito eseguendo test complessi. Il test completo dovrebbe:

essere logicamente connesso;

· fornire il controllo delle prestazioni delle funzioni di parti di EIS in tutte le modalità operative;

· fornire il controllo della reazione del sistema alle informazioni errate e alle emergenze.

I risultati del test si riflettono nel protocollo. Il lavoro si completa con l'esecuzione del certificato di accettazione per il funzionamento di prova.

Nel programma di test complessi di EIS indicare:

un elenco di oggetti di prova;

la composizione della documentazione presentata;

una descrizione delle relazioni da testare tra gli oggetti di prova;

la sequenza delle parti di prova dell'EIS;

· la procedura ei metodi di collaudo, inclusa la composizione del software e delle apparecchiature necessarie per il collaudo, inclusi stand speciali e siti di prova.

Il protocollo di test integrato dovrebbe contenere una conclusione sulla possibilità (impossibilità) di accettazione dell'EIS per l'operazione di prova, nonché un elenco dei miglioramenti necessari e le scadenze raccomandate per la loro attuazione.

L'operazione di prova viene eseguita secondo il programma, che indica:

condizioni e procedura per il funzionamento di parti dell'EIS e dell'EIS nel suo insieme;

· la durata dell'operazione di prova, sufficiente a verificare il corretto funzionamento del SIA;

La procedura per eliminare le carenze individuate durante l'operazione di prova.

Durante il funzionamento di prova dell'EIS, viene conservato un registro di lavoro, in cui vengono inserite informazioni sulla durata del funzionamento dell'EIS, guasti, guasti, emergenze, modifiche ai parametri dell'oggetto di automazione, adeguamenti in corso alla documentazione e software, regolazione e mezzi tecnici. Le informazioni sono registrate nel giornale con la data e la persona responsabile. Il registro può contenere commenti del personale sulla facilità di funzionamento dell'EIS.

Sulla base dei risultati dell'operazione di prova, viene presa una decisione sulla possibilità di presentare parti dell'EIS e il sistema nel suo insieme per i test di accettazione.

I lavori si concludono con l'esecuzione di un atto sul completamento dell'operazione di prova e l'ammissione del sistema ai test di collaudo.

La fase finale del processo di attuazione del progetto Software dalla società 1C, è un'operazione di prova. È necessario affinché l'utente possa verificare il corretto funzionamento del sistema e gli sviluppatori possano eliminare rapidamente le carenze esistenti.

Cos'è l'operazione di prova?

In sostanza, questa fase consente di verificare la prontezza del sistema per il suo uso industriale. L'utente, insieme allo sviluppatore, controlla tutti i principali algoritmi del programma e, se necessario, li corregge e ne esegue il debug. È in questa fase che la correttezza del trattamento dei dati in condizioni reali ulteriore operazione. Il fatto è che alcuni difetti del software possono essere identificati solo quando si lavora con una grande quantità di informazioni.

I difetti più comuni

Nel processo di utilizzo del programma in condizioni reali, possono sorgere alcuni difetti dovuti alla "impreparazione" del sistema per lavorare con una grande quantità di dati. Ecco qui alcuni di loro:

• inerzia, o in altre parole, l'inerzia del sistema durante la creazione di alcuni documenti. Per identificare questo errore, si consiglia di verificare la possibilità di creare ciascun documento utilizzando il numero massimo di posizioni;
• il programma impiega molto tempo per generare alcuni report. Molto probabilmente, il sistema non è pronto per lavorare con una grande quantità di dati o qualche algoritmo non funziona correttamente. Lo sviluppatore deve ricontrollare l'intera catena e risolvere il problema;
• aspetto situazioni di conflitto quando si lavora con alcuni oggetti. Generalmente, nella maggior parte dei casi, noi stiamo parlando sugli elementi "complessi";
• problemi con la conduzione di documenti, che sono spesso causati da un algoritmo errato.

Principali tipi di operazione di prova

A seconda di come viene prodotto il software, si possono distinguere due tipi principali di operazioni di prova:

1. ci sono situazioni in cui la fase di sviluppo è costretta a "mescolarsi" con l'operazione di prova. Ciò è rilevante in quelle situazioni in cui si tratta di una configurazione piuttosto complessa che richiede un gran numero di singoli componenti aggiuntivi. Il fatto è che nel processo di sviluppo non è sempre possibile tenere conto di tutti i requisiti del programma;
2. il secondo tipo è l'operazione di prova “standard”. Rappresenta l'uso simultaneo del software esistente e del prodotto software implementato. Di norma, qui vengono utilizzati database reali, elenchi di controparti e operazioni in corso. Questo viene fatto in modo che l'utente possa determinare quanto correttamente il programma esegue una particolare attività. Molto spesso, per ottimizzare questo processo, gli sviluppatori consentono di scambiare temporaneamente informazioni tra i due sistemi. Pertanto, entrambi i programmi utilizzeranno le stesse informazioni, il che ridurrà al minimo il rischio di un errore accidentale.

Ogni utente deve essere preparato al fatto che nella fase dell'operazione di prova incontrerà alcune carenze. Il punto è questo modello base il programma è già stato ripetutamente testato in condizioni reali, mentre una configurazione specializzata viene spesso installata in forma “grezza”, verificata solo durante il processo di sviluppo. Di norma, gli sviluppatori eliminano rapidamente tutte le carenze e il programma inizia a funzionare in modo abbastanza corretto e stabile. Tra l'altro, non si dovrebbe escludere una tale sfumatura che già sistema esistente può causare problemi durante il test di un nuovo prodotto, perché non è sempre possibile configurare immediatamente le impostazioni ottimali di compatibilità e scambio di dati tra i sistemi.

Creazione sistema informativo inizia dal momento delle prime trattative tra il Cliente e il potenziale Appaltatore e potrebbe non finire mai, poiché sistemi validi e utili vengono costantemente migliorati e sviluppati.

fase preliminare

In questa fase, è necessario comprendere gli scopi e gli obiettivi principali del progetto futuro. Per fare ciò, i principali rappresentanti del Committente e dell'Appaltatore organizzano riunioni in cui discutono il concetto del sistema informativo, i punti tecnici chiave, i tempi e l'entità del lavoro svolto, nonché i costi e le fonti di finanziamento. Il risultato della fase preliminare, oltre ai termini concordati del futuro contratto, dovrebbe essere il primo e più fondamentale documento di progetto - carta del progetto.

La carta del progetto definisce i seguenti punti fondamentali relativi al processo di sviluppo e implementazione di un sistema informativo:

• Breve descrizione del progetto, obiettivi e obiettivi della creazione di un sistema informativo.
• Descrizione generale dello scopo del lavoro.
• Confini del progetto: termini, budget, elenco degli oggetti di automazione.
• Descrizione del prodotto: elenco di hardware e software forniti, tipo e numero di licenze, ecc.
• Struttura organizzativa del progetto: l'elenco e i ruoli dei membri del team di progetto da parte dell'Appaltatore e del Committente, le loro responsabilità e doveri, il sistema di gestione dei documenti di progetto.
• Le principali fasi di sviluppo e implementazione del sistema informativo, un programma ampliato per la loro attuazione.
• I rischi più significativi di inadempimento degli obblighi previsti dal progetto, nonché i modi per ridurre al minimo i rischi.

In altre parole, la carta del progetto è precisamente la carta che viene sviluppata dal project manager insieme ai membri principali del team di progetto, approvata dalla direzione dell'appaltatore e del cliente, e non dovrebbe essere modificata durante l'intero periodo di creazione il sistema informativo.

Il completamento della fase istruttoria può essere considerato il momento in cui viene firmato il contratto per i servizi per lo sviluppo e l'implementazione del sistema informativo e viene approvato il charter del progetto.

Requisiti di raccolta

A questo punto sono state individuate tutte le figure chiave - partecipanti al progetto, e nulla vieta di iniziare a raccogliere e approvare i requisiti per il futuro sistema informativo. I rappresentanti del contraente comunicano con i futuri utenti e amministratori del sistema, nonché con la loro direzione. Durante il sondaggio, non solo vengono sistematizzati i requisiti e i desideri per la soluzione implementata, ma viene analizzata anche la documentazione, che dovrebbe diventare la fonte dei dati iniziali del sistema o la cui formazione dovrebbe essere automatizzata di conseguenza.

risultato questa fase dovrebbe essere l'apparenza termine di paragone per lo sviluppo e l'implementazione del sistema informativo. I termini di riferimento dovrebbero essere basati sui termini del contratto e sui requisiti stabiliti nella carta del progetto e contenere le seguenti sezioni (per la Russia, la struttura dei termini di riferimento è regolata da GOST 34.602 89):

• Scopo e scopo della creazione del sistema.
• Descrizione dell'oggetto di automazione e dei principali processi aziendali automatizzati.
• Requisiti di sistema: requisiti di struttura; funzioni (attività) risolte dal sistema; tecnico e supporto organizzativo; requisiti di affidabilità, sicurezza, ecc. e così via.
• La composizione e il contenuto del lavoro sulla creazione di un sistema informativo.
• L'ordine di controllo e accettazione dei risultati del lavoro.
• Requisiti per lo scopo del lavoro per la preparazione di un oggetto di automazione per la messa in funzione del sistema informativo.
• Requisiti per la composizione del progetto e della documentazione per l'utente.

Il completamento della fase di raccolta dei requisiti è l'approvazione dei Termini di Riferimento da parte del Cliente. In alcuni casi, prima dell'inizio dei lavori sul progetto, il Cliente dispone già di un capitolato d'oneri (incluso nella documentazione di gara). In questo caso, i risultati dell'indagine e della raccolta dei requisiti sono registrati in termini di riferimento privati, dettagliando e concretizzando Requisiti generali al sistema informativo presentato nel capitolato d'oneri originario.

Progetto

In questa fase, grazie agli sforzi dell'Appaltatore, vengono progettati in dettaglio tutti gli scenari relativi allo sviluppo e all'implementazione di un sistema informativo sul territorio del Cliente. Ciò avviene in conformità con le condizioni dell'ambiente informativo (paesaggio del sistema) del Cliente e i requisiti per l'integrazione del sistema che viene creato con altri già disponibili e gestiti dal Cliente. prodotti software. Il risultato della fase di progettazione dovrebbe essere la progettazione delle sezioni successive progetto tecnico (concettuale).:

• Architettura del sistema informativo.
• Descrizione delle strutture di archiviazione delle informazioni (database).
• Progettare soluzioni presentate da una descrizione dettagliata degli scenari di automazione per tutti i processi aziendali interessati dall'implementazione del sistema.
• Scenari per l'integrazione del sistema informativo sviluppato con prodotti software esterni.
• Fonti dei dati iniziali e opzioni per il contenuto informativo iniziale del sistema.
• Il concetto di differenziazione dei diritti di accesso ai dati in base ai ruoli degli utenti, che ne determinano, tra l'altro, i poteri.
• Il concetto di formazione degli utenti del sistema informativo.

Implementazione

La fase di attuazione di tutti i requisiti per il sistema informativo di cui all'art termine di paragone E progetto tecnico. Durante questo periodo, il Contraente sviluppa tutti i componenti software necessari, crea strutture di database, installa, configura e testa tutti i componenti del sistema informativo sul proprio territorio, simula scenari di integrazione, ecc. e così via. Il completamento della fase di implementazione è confermato dalla comparsa di tali documenti di progetto come un manuale per l'installazione e la configurazione del sistema, programma e procedura di prova sistema, nonché un modello di database e un registro di tutti gli sviluppi software completati.

Preparazione del sistema informativo per il funzionamento

Tutto il lavoro di questa fase è già in corso presso la sede del cliente e comprende l'installazione e la configurazione di tutti i componenti del sistema nell'ambiente informativo del cliente, il test preliminare, lo sviluppo della documentazione per l'utente, la formazione dell'utente, il caricamento dei dati iniziali, il test in conformità con il programma e metodologia e altri lavori preparatori.

Quando tutto il lavoro preparatorio sarà completato, la procedura operativa per il sistema dovrebbe essere sviluppata e approvata. Il regolamento, in particolare, dovrebbe definire gli utenti ei loro ruoli nel sistema, in accordo con le loro responsabilità lavorative.

Operazione pilota

L'ultima fase dello sviluppo e dell'implementazione iniziale di un sistema informativo, il cui compito è condurre con successo un'operazione di prova del sistema per un certo periodo, e l'obiettivo è confermare che il sistema informativo creato è esattamente il risultato che il Cliente atteso.

Durante questo periodo, gli utenti iniziano a utilizzare il sistema in conformità con le normative sviluppate nella fase precedente. Durante lo sperimentale operazione industriale gli errori vengono corretti e vengono concordati i miglioramenti necessari. L'Appaltatore elimina gli errori, esegue miglioramenti e, a condizione che il sistema inizi a funzionare in conformità con tutti i requisiti che gli sono stati presentati in precedenza, alla fine del periodo stabilito, riceve un protocollo sul completamento con successo dell'operazione pilota.

Con il completamento dell'operazione pilota, di norma, termina il contratto per la creazione di un sistema informativo. Il sistema stesso entra in esercizio commerciale e l'Appaltatore, se il Cliente è interessato, conclude contratto separato per il suo supporto, per il periodo stabilito dai termini del contratto.

Manutenzione e sviluppo del sistema

L'operazione industriale può rivelare che alcuni requisiti per il sistema informativo creato contenevano inesattezze e richiedono una diversa formulazione o aggiunte, e il sistema stesso deve essere migliorato. Non tutti i Clienti dispongono di personale nel proprio organico in grado di introdurre autonomamente nel sistema tutte le modifiche dettate dalla situazione reale, pertanto stipula un accordo separato con l'Appaltatore per la manutenzione del sistema informativo.

Gli utenti del sistema informativo iniziano a comunicare con i rappresentanti del servizio di supporto del Cliente, che ricevono da loro richieste di miglioramento della funzionalità ed eliminazione dei difetti, trasferiscono richieste di lavoro e notificano periodicamente agli utenti lo stato della loro richiesta. L'elenco dei possibili miglioramenti e la procedura per l'elaborazione delle domande è determinato dai termini del contratto. Se è necessario un lavoro che non rientra nell'essenza del contratto di supporto, il Cliente e l'Appaltatore stipulano un contratto separato per questa specie lavoro, che può già essere attribuito al lavoro sulla modernizzazione e lo sviluppo del sistema informativo gestito.

In questa fase, grazie agli sforzi dell'Appaltatore, vengono progettati in dettaglio tutti gli scenari relativi allo sviluppo e all'implementazione di un sistema informativo sul territorio del Cliente. Ciò avviene in conformità con le condizioni dell'ambiente informativo (paesaggio del sistema) del cliente e i requisiti per l'integrazione del sistema creato con altri prodotti software già disponibili e gestiti dal cliente. Il risultato della fase di progettazione dovrebbe essere la progettazione delle sezioni successive progetto tecnico (concettuale).:

Architettura del sistema informativo.

Descrizione delle strutture di archiviazione delle informazioni (database).

Progettare soluzioni presentate da una descrizione dettagliata degli scenari di automazione per tutti i processi aziendali interessati dall'implementazione del sistema.

Scenari per l'integrazione del sistema informativo sviluppato con prodotti software esterni.

Fonti dei dati iniziali e opzioni per il contenuto informativo iniziale del sistema.

Il concetto di differenziazione dei diritti di accesso ai dati in base ai ruoli degli utenti, che ne determinano, tra l'altro, i poteri.

Il concetto di formazione degli utenti del sistema informativo.

Implementazione

La fase di implementazione di tutti i requisiti per il sistema informativo stabiliti nel capitolato d'oneri e nel progetto tecnico. Durante questo periodo, il Contraente sviluppa tutti i componenti software necessari, crea strutture di database, installa, configura e testa tutti i componenti del sistema informativo sul proprio territorio, simula scenari di integrazione, ecc. e così via. Il completamento della fase di implementazione è confermato dalla comparsa di tali documenti di progetto come un manuale per l'installazione e la configurazione del sistema, programma e procedura di prova sistema, nonché un modello di database e un registro di tutti gli sviluppi software completati.

Preparazione del sistema informativo per il funzionamento

Tutto il lavoro di questa fase è già in corso presso la sede del Cliente e comprende l'installazione e la configurazione di tutti i componenti del sistema nell'ambiente informativo del Cliente, il test preliminare, lo sviluppo della documentazione per l'utente, la formazione dell'utente, il caricamento iniziale dei dati, prova di sistema in conformità con il programma e la metodologia di prova e altri lavori preparatori.

Quando tutto il lavoro preparatorio sarà completato, la procedura operativa per il sistema dovrebbe essere sviluppata e approvata. Il regolamento, in particolare, dovrebbe definire gli utenti ei loro ruoli nel sistema, in accordo con le loro responsabilità lavorative.

Operazione pilota

L'ultima fase dello sviluppo e dell'implementazione iniziale di un sistema informativo, il cui compito è condurre con successo un'operazione di prova del sistema per un certo periodo, e l'obiettivo è confermare che il sistema informativo creato è esattamente il risultato che il Cliente atteso.

Durante questo periodo, gli utenti iniziano a utilizzare il sistema in conformità con le normative sviluppate nella fase precedente. Durante l'operazione pilota, gli errori vengono corretti e vengono concordati i miglioramenti necessari. L'Appaltatore elimina gli errori, esegue miglioramenti e, a condizione che il sistema inizi a funzionare in conformità con tutti i requisiti che gli sono stati presentati in precedenza, alla fine del periodo stabilito, riceve un protocollo sul completamento con successo dell'operazione pilota.

Con il completamento dell'operazione pilota, di norma, termina il contratto per la creazione di un sistema informativo. Il sistema stesso entra in esercizio commerciale e l'Appaltatore, se il Cliente è interessato a ciò, stipula un contratto separato per la sua manutenzione, per il periodo stabilito dai termini del contratto.