Documentazione tecnica. Documentazione tecnica Esecuzione dei test di accettazione

Annotazione: Una logica continuazione della lezione precedente. Il problema dell'applicazione pratica della norma GOST R ISO/IEC 12207 nelle organizzazioni e nei progetti viene discusso in dettaglio. A questo proposito sono allo studio gli standard GOST R ISO/IEC 15271 e GOST R ISO/IEC 16326.

Dalla lezione precedente dovrebbe essere ovvio che implementare GOST R ISO/IEC 12207 è un compito molto difficile. Innanzitutto non è chiaro cosa significhi “implementare GOST R ISO/IEC 12207”? Può essere considerato implementato se alcuni processi dell'organizzazione coincidono con i processi della norma e altri no? Uno standard può essere considerato implementato se alcuni progetti vengono realizzati in conformità ad esso e altri no? Questo elenco di domande può continuare all’infinito.

Non è un caso che seguendo la norma GOST R ISO/IEC 12207 sia stato sviluppato lo standard GOST R ISO/IEC 15271-02 (GOST 15271, 2002) appositamente dedicato al compito della sua implementazione, denominato “Linee guida per l’applicazione di GOST RISO/IEC 12207”. Passiamo ora a considerarlo.

Norma GOST R ISO/IEC 15271

Il significato della norma è svelato nella sua sezione introduttiva.

"1.2. Utilizzatori della norma.

Questo standard può essere utilizzato da soggetti (individui, organizzazioni) che desiderano applicare GOST R ISO/IEC 12207 nell'implementazione di contratti, indipendentemente dal volume o dalla complessità del progetto, da parte di un'organizzazione specifica per l'autocontrollo o il lavoro di miglioramento processi del ciclo di vita strumenti software.

Questo standard specifica come GOST R ISO/IEC 12207 può essere utilizzato in relazione a diversi tipi di software e quali processi sono appropriati per ciascun caso.

Questo standard integra GOST R ISO/IEC 12207, che non è solo un documento normativo, ma anche uno standard per la gestione di un progetto reale. (Ad esempio, l'ultimo caso si verifica quando GOST R ISO/IEC 12207 è un modello per svolgere parte del lavoro del processo di miglioramento). La presente norma dovrebbe essere letta nel suo complesso, ma in singoli casi possono essere utilizzate sezioni specifiche."

Lo standard GOST R ISO/IEC 15271 è composto da 8 sezioni e 4 Appendici. Le sezioni del contenuto sono così chiamate (numerazione tratta dal testo):

• 4. Concetti di base dello sviluppo di GOST R ISO/IEC 12207.
• 5. Implementazione della norma GOST R ISO/IEC 12207.
• 6. Applicazione nei progetti.
• 7. Applicazione nelle organizzazioni.
• 8. Applicazione modelli del ciclo di vita sistemi.

La sezione 4 è scritta nello stile dei commenti e dei chiarimenti al testo di GOST R ISO/IEC 12207. I chiarimenti più importanti riguardano l'interazione di GOST R ISO/IEC 12207 con gli standard aziendali dell'organizzazione, la distinzione tra i concetti di “ software” e “sistema” e le conseguenti distinzioni tra processi relativi a software e sistemi. Il concetto è descritto in dettaglio gestione della qualità, implementato in GOST R ISO/IEC 12207. In generale, la sezione dà l'impressione di una breve panoramica concettuale di GOST R ISO/IEC 12207, che ricorda un libro di testo.

La sezione 5 presenta un approccio generale all'implementazione, chiamato strategia di implementazione GOST R ISO/IEC 12207. Una strategia, secondo lo standard, è "un tipico metodo di implementazione che dovrebbe essere seguito quando si apportano modifiche alle attività o al progetto di un'organizzazione". La strategia viene implementata come un progetto composto da passaggi obbligatori, descritti in modo informale e senza alcun collegamento con i processi dell'organizzazione. Questi passaggi sono i seguenti:

• a) sviluppo di un piano di attuazione;
• b) applicazione pratica della norma GOST R ISO/IEC 12207;
• c) fornire supporto progetto pilota(S);
• d) formalizzazione della modalità di attuazione;
• e) approvazione delle modalità di attuazione.

Lo sviluppo di un piano di implementazione include la determinazione dell'ambito di applicazione della norma GOST R ISO/IEC 12207. L'ambito può essere, ad esempio, un gruppo di dipartimenti o progetti di un'organizzazione. È inoltre possibile definire l'ambito di applicazione come un insieme di processi chiave per l'organizzazione, che saranno sostituiti dai processi GOST R ISO/IEC 12207. Il piano di implementazione stesso determina la composizione dei progetti realizzati durante l'implementazione (potrebbero esserci molti di loro). Inutile dire che quando si sviluppa un piano di attuazione vengono determinate le risorse necessarie: finanziarie, umane, tecniche, ecc.

Nell'applicazione pratica, come ci si aspetterebbe, si propone di utilizzare il processo di adattamento descritto nello stesso GOST R ISO/IEC 12207.

La strategia in sé non solleva dubbi: una tale sequenza di passaggi può essere piuttosto efficace in condizioni specifiche, ma vale la pena notare che l'approccio formale del progetto all'implementazione di GOST R ISO/IEC 12207 si basa su una comprensione semplificata della realtà situazione. Tenendo conto che i processi di un'organizzazione (così come la sua struttura organizzativa) sono in continua evoluzione, credo che sarebbe metodologicamente più corretto considerare l'implementazione di una norma come un processo continuo, piuttosto che come un progetto limitato nel tempo. Questo processo monitora le modifiche ai processi dell'organizzazione e avvia singoli progetti, ad esempio:

• progetti per l'applicazione della norma GOST R ISO/IEC 12207;
• un progetto per formare tutti i nuovi dipendenti sui processi della norma GOST R ISO/IEC 12207;
• un progetto per introdurre modifiche nei processi implementati in relazione ai cambiamenti nella struttura organizzativa dell'organizzazione; e così via.

L'approccio all'implementazione della norma GOST R ISO/IEC 12207 come processo, soprattutto se si intende iniziare con la sua applicazione in progetti o singoli dipartimenti dell'organizzazione, consentirà di concentrare la responsabilità del risultato complessivo nelle mani del proprietario del processo , consentirà di stabilire un monitoraggio generale dei risultati, ecc. Ovviamente, l'attuazione dovrebbe essere seguita dal supporto dei processi implementati, che è anch'esso naturalmente organizzato come processo.

Maggiori dettagli sull'uso di GOST R ISO/IEC 12207 nei progetti sono descritti nella sezione 6 “Applicazione nei progetti”. La norma si propone di classificare i progetti e a questo scopo introduce un nuovo concetto - " modello del ciclo di vita sistemi" (un elenco di modelli tipici è fornito nell'Appendice C). Che cosa sia un modello non è formalmente definito. Successivamente, la Sezione 8 afferma che "il sistema generale modello del ciclo di vita i sistemi sono suddivisi in fasi (stadi) con successivo adattamento di ciascuno di essi a modelli del ciclo di vita sistema specifico" (di seguito è riportato un elenco delle fasi). In totale, vengono considerati tre modelli di questo tipo: a cascata, incrementale, evolutivo. Vengono analizzati i loro vantaggi e svantaggi, quindi i processi di GOST R ISO/IEC 12207 vengono "sovrapposti" sulla struttura dei modelli. Di conseguenza, questi processi ricevono proprietà aggiuntive, ad esempio, ripetizione ripetuta nel ciclo di vita o sovrapposizione temporale con altri processi. Inoltre, la sezione contiene molte raccomandazioni di vari gradi di utilità riguardanti i singoli aspetti dei progetti Ecco un tipico esempio.

"6.1.3. Caratteristiche del sistema

I sottosistemi e gli elementi di configurazione del sistema devono essere definiti al livello di dettaglio appropriato. È necessario determinare le caratteristiche del sistema, in particolare quelle relative al software. Nel determinare queste caratteristiche, è necessario notare quali di esse sono critiche durante il funzionamento del sistema.

Un elenco indicativo delle caratteristiche a livello di sistema (correlate al software e soggette a considerazione) include:

• interfacce intersistema e intrasistema;
• interfacce utente;
• l'impatto degli errori software sulla protezione e sicurezza del sistema;
• valutazione della potenza di calcolo e dei vincoli temporali;
• disponibilità di programmi attuati con mezzi tecnici;
• Disponibilità di computer adeguati.

Se un sistema include molti sottosistemi o elementi di configurazione, questi devono essere completamente coperti dal lavoro a livello di sistema del processo di sviluppo. Devono essere presi in considerazione tutti i requisiti per le interfacce e l'assemblaggio (integrazione) dei sistemi. Per un sistema piccolo, una sequenza di azioni così rigorosa potrebbe non essere necessaria."

La formulazione approssimativa e vaga nel passaggio sopra è caratteristica dell'intera norma nel suo insieme.

La parte centrale della brevissima sezione 7 “Applicazione nelle organizzazioni” è il testo seguente.

"7.2. Possibilità di applicazione

I motivi per cui GOST R ISO/IEC 12207 è implementato nelle organizzazioni possono essere i seguenti:

• verificare la perfezione di un metodo esistente. Questo di solito è il caso quando il metodo è stato sviluppato dall'organizzazione stessa o ha selezionato e modificato un metodo esistente;
• applicazione pratica di questo metodo per prevenire il rischio associato all'ingresso in nuovi settori di mercato con requisiti più stringenti associati al rischio potenziale;
• sviluppare un nuovo metodo, ad esempio per soddisfare le esigenze di una nuova organizzazione. Possono essere coperte le organizzazioni create attraverso una fusione o una collaborazione aziendale. Ciò potrebbe essere necessario per supportare alcuni modelli di processo per fornire lavoro specifico;
• Gestire l'implementazione di nuove tecnologie, come l'automazione dei processi manuali o la modifica dei metodi utilizzati per implementare un prodotto software. GOST R ISO/IEC 12207 stabilisce criteri che possono essere utilizzati per monitorare l'eccellenza del metodo in questione prima o dopo un cambiamento tecnologico;
• valutazione delle capacità interne della parte in termini di rispetto dei criteri del contratto, ad esempio, come parte che partecipa al processo competitivo (di gara);
• identificare le tappe fondamentali che possono portare allo sviluppo di programmi più avanzati, come l'auditing in conformità con GOST R ISO/IEC 12207 e l'utilizzo del processo di miglioramento stesso."

Anche in assenza di obiezioni sostanziali, è ancora impossibile considerare questo testo come uno standard. Soprattutto, assomiglia a un manuale di formazione e probabilmente sarà richiesto come tale, ma un testo del genere non può essere utilizzato come guida all'azione quando si implementa GOST R ISO/IEC 12207 in un'organizzazione.

Infine, la sezione 8 “Applicazione modelli del ciclo di vita sistemi" contiene definizioni piuttosto vaghe" modelli del ciclo di vita sistemi" e " modelli del ciclo di vita software" e cerca di stabilire una corrispondenza tra loro. Poiché non esistono definizioni precise, è impossibile giudicare i risultati.

In generale, lo standard GOST R ISO/IEC 15271 dà l'impressione di essere un documento puramente ausiliario rispetto a GOST R ISO/IEC 12207, affetto da approssimazione e abbondanza di luoghi comuni. Non è adatto a manager pratici: c'è troppo ragionamento astratto e troppo poca specificità. Per gli studenti e gli specialisti che studiano i processi di gestione IT, manca una visione ampia dell'argomento (dopo tutto, è limitato da GOST R ISO/IEC 12207) ed è sovraccarico di dettagli tecnici non necessari. Tuttavia, la familiarità con GOST R ISO/IEC 15271 è utile, poiché mostra la direzione del pensiero degli specialisti nel campo della gestione IT e dimostra dove e come si stanno sviluppando gli standard moderni. Lo considererei un documento di lavoro provvisorio, anche se sotto forma di standard, ma destinato più alla discussione tra un pubblico interessato di specialisti di gestione IT.

Norma GOST R ISO/IEC 16326

Un altro tentativo di formalizzare il processo di applicazione di GOST R ISO/IEC 12207 è stato fatto nello standard GOST R ISO/IEC 16326 “Linee guida per l’uso di GOST R ISO/IEC 12207 nella gestione dei progetti” (GOST 16326, 2002). Dimostra un tentativo di unire processi del ciclo di vita da GOST R ISO/IEC 12207 con processi di gestione del progetto dal popolare libro di riferimento metodologico PMBOK 1 PMBOK - Corpo di conoscenza sulla gestione dei progetti(PMBOK, 2009) e lo standard ISO 10006 (la versione russa dello standard è contenuta in (GOST 10006, 2005)). Ciò è mostrato schematicamente in Fig. 4.1 riportato nella norma.

Riso. 4.1.

La gamma di utenti dello standard è definita in modo abbastanza preciso nella sezione 1.1.

"1.1. Gamma di utenti

Questo standard è destinato alle entità che utilizzano o pianificano di utilizzare GOST R ISO/IEC 12207 in progetti software, indipendentemente dal loro ambito, prodotti creati, metodologia, volume o complessità. Lo standard è destinato principalmente agli amministratori di progetto responsabili della conformità dei processi di gestione con GOST R ISO/IEC 12207:

• amministratori responsabili dell’organizzazione e del miglioramento continuo processi del ciclo di vita software secondo GOST R ISO/IEC 12207;
• amministratori responsabili della domanda processi del ciclo di vita software secondo GOST R ISO/IEC/12207 a livello di progettazione;
• organizzazioni o persone che sono subappaltatori nell'attuazione di SCP ( Gestione di progetti software. - AB).

Le considerazioni per gli individui includono:

• coinvolto in progetti software, ma non AP ( Amministratori del progetto. -AB);
• che sono amministratori di progetti non software, ma associati al software AP."

Il testo principale, relativamente breve (la sezione 6 "Guida" occupa solo 9 pagine su un totale di 35) è un commento sequenziale sul processo 7.1 "Gestione" da GOST R ISO/IEC 12207 dal punto di vista PMBOK. Lo stile del commento è informale, gli argomenti sono per lo più di natura consultiva. Il commento non va oltre il buon senso comune e non contiene nulla di nuovo. In generale, questa è una lettura utile per i project manager (nella terminologia dei traduttori, “amministratori”), ma niente di più.

L'Appendice A è una grande tabella che illustra le connessioni tra i principali processi del GOST R ISO/IEC 12207 e le attività del processo “Gestione” da essi richiamate. Tutti questi collegamenti sono contenuti nel corpo della norma GOST R ISO/IEC 12207; combinandoli in un'unica tabella non vengono aggiunte nuove informazioni.

L'Appendice B è esattamente la stessa tabella che collega le aree di processo e i singoli processi del PMBOK con le attività del processo di "Gestione" di GOST R ISO/IEC 12207.

Una tabella simile, in cui vengono utilizzati gruppi di processi nel senso PMBOK anziché aree, è riportata nell'Appendice C. Le Appendici B e C riassumono in realtà tutto ciò che è stato detto nella sezione 6 della norma. Non è chiaro perché sia ​​stato necessario presentarli sotto forma di tabelle. Queste tabelle non forniscono alcuna informazione aggiuntiva, dimostrando solo il fatto che esistono collegamenti tra il PMBOK e GOST R ISO/IEC 12207. Tuttavia, lo stato di entrambi gli allegati è “riferimento”, quindi potrebbero non aver avuto alcun valore indipendente.

Un'altra tabella riassuntiva è presentata nell'Appendice D. Mostra le relazioni tra tre fonti: GOST R ISO/IEC 12207, PMBOK e lo standard ISO 10006. Noterò subito che quest'ultimo è stato tradotto in russo solo nel 2005; di conseguenza, la terminologia utilizzata nell'allegato D dello standard GOST R ISO/IEC 16326 2002 differisce da quella successiva. Come nei casi precedenti, il significato di presentare queste relazioni in forma tabellare compatta non è chiaro. Inoltre, il volume totale delle Appendici A-D supera di oltre il doppio il volume della sezione principale 6 “Manuale”.

A mio avviso, GOST R ISO/IEC 16326-2002 non è diverso nella forma e nello scopo da GOST R ISO/IEC 15271-2002. Entrambi soffrono di un eccesso di ragionamento corretto “in generale” e basato solo sul buon senso. Questi argomenti sono ovvi per chiunque abbia esperienza pratica nella gestione di progetti e difficilmente sembrano ragionevoli per coloro che non hanno tale esperienza. A differenza della norma GOST R ISO/IEC 15271-2002, la norma GOST R ISO/IEC 16326-2002 è più formale, ma il significato pratico del formalismo proposto non è chiaro.

Dal punto di vista dell’applicazione pratica nella progettazione dei processi aziendali legati all’IT, entrambi gli standard sono in gran parte inutili. D'altro canto, possono essere richiesti quando si realizzano progetti complessi che includono, oltre allo studio delle pratiche di gestione IT, l'analisi della gestione del progetto e gestione della qualità.

Oltre a quelli discussi sopra, GOST R ISO/IEC 12207 ha dato vita ad una serie di standard che dettagliano quelli in esso contenuti processi del ciclo di vita. Questi includono, ad esempio, GOST R ISO/IEC 15910-2002 “Il processo di creazione della documentazione utente per il software” (GOST 15910, 2002) e GOST R ISO/IEC 14764-2002 “Manutenzione del software” (GOST 14764, 2002). . Alcuni standard ISO simili non sono ancora stati tradotti in russo; È probabile che in futuro aumenterà il numero degli standard ISO GOST R in lingua russa direttamente correlati a GOST R ISO/IEC 12207.

Riferimento secondo GOST R ISO/IEC 12207-2010

oppure, che sono stati formalmente rivisti e successivamente servono come base per ulteriori sviluppi e che possono essere modificati solo attraverso modifiche ufficiali e controllate [dalla clausola 4.6 di GOST R ISO/IEC 12207-2010]

Validazione secondo GOST R ISO/IEC 12207-2010

Conferma (basata sulla presentazione di prove oggettive) che lo scopo o l'applicazione prevista è stata realizzata. Nota - La validazione nel contesto è un insieme di azioni che garantiscono e danno fiducia che sia in grado di realizzare il suo scopo, attuale e futuro [dalla clausola 4.54 di GOST R ISO/IEC 12207-2010]

Verifica secondo GOST R ISO/IEC 12207-2010

Conferma (basata sulla fornitura di prove oggettive) che i requisiti specificati sono stati pienamente soddisfatti. NOTA La verifica nel contesto è un insieme di azioni che confrontano un risultato del ciclo di vita con le caratteristiche richieste per quel risultato. I risultati del ciclo di vita possono essere (ma non sono limitati a) requisiti specificati, descrizione e direttamente [dalla clausola 4.55 di GOST R ISO/IEC 12207-2010]

Garanzia di qualità secondo GOST R ISO/IEC 12207-2010

Tutte le attività pianificate e sistematiche svolte all'interno del quadro e dimostrate in modo appropriato per fornire un'adeguata fiducia che il cliente sia pienamente soddisfatto.

1. Esistono garanzie di qualità sia interne che esterne:
   1. garanzia di qualità interna: entro i limiti della garanzia di qualità fornisce fiducia;
   2. Garanzia di qualità esterna: nelle situazioni contrattuali, la garanzia di qualità fornisce fiducia o ad altri.
2. Alcune attività di assicurazione della qualità e di assicurazione della qualità sono correlate.
3. A meno che i requisiti di qualità non soddisfino pienamente le esigenze, l’assicurazione della qualità non può fornire la garanzia necessaria.

[dalla clausola 4.34 GOST R ISO/IEC 12207-2010]

5.2.2 Riepilogo dei processi del ciclo di vita

Ci sono due importanti divisioni del processo in questo standard. La Sezione 6 fornisce il contesto di sistema per il funzionamento di un prodotto o servizio software autonomo o di un sistema software. La Sezione 7 contiene processi software specifici da utilizzare nell'implementazione di un prodotto o servizio software che costituisce un elemento di un sistema più ampio.

Per agevolare l'uso simultaneo della presente norma internazionale, ai processi corrispondenti del punto 6 vengono assegnate le stesse designazioni dei sottopunti.

In generale, l'insieme dei processi presentati in questo standard è adattato al software o agli input ai risultati dei processi previsti. Molti processi sono simili alle implementazioni di processi specifici del software, ma mantengono importanti differenze basate su obiettivi, risultati e pubblico. Gli utenti sia di questo standard che di questo standard dovrebbero assicurarsi di rivedere le spiegazioni e le note in ciascuno di questi processi specifici.

I processi di accordo definiscono le attività necessarie per sviluppare accordi tra due organizzazioni. Se viene implementato un processo di acquisizione, fornisce i mezzi per condurre affari con il fornitore dei prodotti forniti per l'uso nel sistema operativo, nei servizi di supporto del sistema o negli elementi di sistema sviluppati come parte del progetto. Se viene implementato un processo di consegna, esso fornisce i mezzi per realizzare un progetto in cui il risultato è un prodotto o servizio consegnato alla parte acquirente.

Pertanto, i processi di accordo forniti in questo standard sono mirati ai processi di accordo software da .

I processi di supporto del progetto organizzativo gestiscono la capacità delle organizzazioni di acquisire e fornire prodotti o servizi attraverso l'avvio, il supporto e la gestione del progetto. Questi processi forniscono le risorse e le infrastrutture necessarie per supportare i progetti e garantire il raggiungimento degli obiettivi organizzativi e degli accordi stabiliti. Non pretendono di essere un insieme completo di processi aziendali che implementano la gestione delle attività aziendali di un’organizzazione.

I processi di supporto organizzativo del progetto includono:

a) processo di gestione del modello del ciclo di vita;

B) processo di gestione dell'infrastruttura;

c) processo di gestione del portafoglio progetti;

d) processo di gestione delle risorse umane;

e) processo di gestione della qualità.

In generale, i processi di supporto organizzativo del progetto previsti da questo standard sono processi focalizzati sul software del corrispondente insieme di processi in .

In questa norma il progetto viene scelto come base per descrivere i processi relativi alla pianificazione, valutazione e controllo. I principi associati a questi processi possono essere applicati a qualsiasi area della gestione organizzativa.

Esistono due categorie di processi di progetto. I processi di project management vengono utilizzati per pianificare, eseguire, valutare e gestire lo stato di avanzamento di un progetto. I processi di supporto al progetto garantiscono il raggiungimento degli obiettivi di gestione specializzati. Entrambe le categorie di processi di progetto sono descritte di seguito.

I processi di gestione dei progetti vengono utilizzati per creare e sviluppare piani di progetto, valutare i progressi effettivi e quelli rispetto ai piani e gestire l'avanzamento del progetto fino al completamento. I singoli processi di gestione del progetto possono essere invocati in qualsiasi momento del ciclo di vita e a qualsiasi livello della gerarchia del progetto in risposta ai piani di progetto o al verificarsi di eventi imprevisti. I processi di gestione del progetto vengono applicati ad un livello di rigore e formalizzazione a seconda del rischio e della complessità del progetto:

a) processo di pianificazione del progetto;

b) il processo di gestione e valutazione del progetto.

I processi di supporto al progetto costituiscono un insieme specifico di compiti volti al raggiungimento di specifici obiettivi di gestione. Tutti questi processi sono evidenti nella gestione di qualsiasi attività avviata, discendendo dall'organizzazione nel suo insieme fino a un processo separato del ciclo di vita e ai suoi compiti:

a) processo di gestione delle decisioni;

b) processo di gestione del rischio;

c) processo di gestione della configurazione;

d) processo di gestione delle informazioni;

e) processo di misurazione.

In generale, i processi di supporto al progetto presentati in questo standard sono identici ai processi di supporto al progetto forniti in , ad eccezione di alcune differenze nella forma della loro presentazione. In alcuni casi, i processi di supporto software possono avere relazioni con i processi di supporto del progetto.

I processi tecnici vengono utilizzati per definire i requisiti di sistema, trasformare i requisiti in un prodotto utile, consentire la copia continua del prodotto (ove necessario), applicare il prodotto, fornire i servizi richiesti, mantenere la fornitura di tali servizi e rimuovere il prodotto dalla circolazione quando non viene utilizzato per fornire il servizio.

I processi tecnici definiscono le attività che consentono di implementare le funzioni organizzative e di progettazione per ottimizzare i benefici e ridurre i rischi derivanti da decisioni e azioni tecniche. Queste attività consentono a prodotti e servizi di avere le caratteristiche di tempestività e disponibilità, rapporto costo-efficacia, funzionalità, affidabilità, manutenibilità, produttività, adattabilità e altre caratteristiche di qualità richieste dalle organizzazioni acquisitrici e di supporto. Consente inoltre a prodotti e servizi di soddisfare le aspettative o i requisiti del diritto civile, compresi i fattori di salute, sicurezza e ambiente.

I processi tecnici sono costituiti dai seguenti processi:

a) determinazione dei requisiti dei titolari dei diritti (un caso speciale del processo di determinazione dei requisiti dei titolari dei diritti riportato);

b) analisi dei requisiti di sistema (un caso speciale del processo di analisi dei requisiti);

C) progettazione dell'architettura di sistema (un caso speciale del processo di progettazione dell'architettura riportato);

D) processo di implementazione (un caso speciale del processo di implementazione degli elementi del sistema indicato e ulteriormente sviluppato nella Sezione 7 della presente norma come processo di implementazione del software);

e) il processo di integrazione del sistema (un caso particolare del processo di integrazione riportato);

f) il processo di test di qualificazione del sistema (processo che contribuisce al raggiungimento dei risultati del processo di verifica di cui al punto );

G) il processo di installazione del software (il processo che contribuisce a raggiungere i risultati del processo di trasferimento descritto in);

H) processo di supporto all'accettazione del software (il processo che contribuisce al raggiungimento dei risultati del processo di trasferimento descritto in );

i) il processo operativo del software (un caso speciale del processo operativo indicato);

j) processo di manutenzione del software (un caso speciale del processo di manutenzione di cui al punto );

k) il processo di ritiro del software dalla circolazione (un caso particolare del processo di ritiro e cancellazione riportato).

In generale, i processi tecnici presentati in questo standard sono casi speciali orientati al software o contributi ai risultati dei processi tecnici presentati in . La maggior parte di essi sono simili ai processi di implementazione del software, ma mantengono importanti differenze, ad esempio l'analisi dei requisiti di sistema e l'analisi dei requisiti del software partono da punti di partenza diversi e hanno scopi diversi.

I processi di implementazione del software vengono utilizzati per creare un elemento di sistema specifico (componente) realizzato sotto forma di uno strumento software. Questi processi trasformano comportamenti, interfacce e vincoli di implementazione specificati in azioni che danno come risultato un elemento di sistema che soddisfa i requisiti derivati ​​dai requisiti di sistema.

Un processo speciale è il processo di implementazione del software, che esprime una caratteristica specificatamente software del processo di implementazione indicato.

Il processo di implementazione del software include diversi processi speciali di livello inferiore:

a) il processo di analisi dei requisiti software;

B) processo di progettazione dell'architettura software;

c) processo dettagliato di progettazione del software;

d) processo di progettazione del software;

e) processo di integrazione del software;

f) processo di test di qualificazione del software.

I processi di supporto software forniscono un insieme specificatamente focalizzato di attività volte all'esecuzione di un processo software specializzato. Qualsiasi processo di supporto assiste il processo di implementazione del software nel suo insieme con uno scopo distinto, contribuendo al successo e alla qualità del progetto software. Esistono otto processi di questo tipo:

a) processo di gestione della documentazione del software;

b) processo di gestione della configurazione del software;

c) processo di garanzia della qualità del software;

d) processo di verifica del software;

e) processo di validazione del software;

f) processo di audit del software;

g) processo di audit del software;

H) il processo di risoluzione dei problemi nel software.

Il gruppo di processi di riutilizzo del software è costituito da tre processi che supportano la capacità di un'organizzazione di riutilizzare i componenti del software oltre i confini del progetto. Questi processi sono unici perché, per loro natura, vengono utilizzati al di fuori dei confini di qualsiasi progetto specifico.

I processi di riutilizzo del software sono:

a) processo di progettazione del dominio;

b) processo di gestione del riutilizzo degli asset;

C) il processo di gestione del riutilizzo del programma.

1) Consente di implementare qualsiasi modello di ciclo di vita- questo è possibile, perché Lo standard fornisce un modo per definire l'ordine di esecuzione di processi e attività, in cui un processo può richiamare un altro processo o parti di esso.

2) Fornisce la massima flessibilità– molti processi e compiti sono progettati in modo tale da poter essere adattati in conformità con specifici progetti IS. L’adattamento si riduce all’eliminazione di processi, attività e compiti che non sono applicabili a un progetto specifico.

3) Fondamentalmente la norma non contiene una descrizione di modalità d'azione specifiche, in particolare, spazi vuoti, soluzioni o documentazione, descrive solo l'architettura dei processi del ciclo di vita del software, ma non specifica in dettaglio come eseguire o implementare le attività incluse nei processi.

4) Lo standard contiene pochissime descrizioni riguardanti la progettazione del database- questo è giustificato, perché diversi sistemi informativi e diversi sistemi software possono non solo utilizzare tipi specifici di database, ma anche non utilizzare alcun database.

5) Il valore dello standard è quello contiene insiemi di compiti, caratteristiche di qualità, criteri di valutazione, ecc., fornendo una copertura completa delle soluzioni di progettazione.

6) Sebbene lo standard non prescriva l'uso di uno specifico modello di ciclo di vita o metodo di sviluppo, stabilisce che le parti del progetto sono responsabili di quanto segue:

selezione di un modello di ciclo di vita per il progetto in fase di sviluppo;

adattamento dei processi e dei compiti della norma al modello selezionato;

selezione e applicazione di metodi di sviluppo software;

Esecuzione di attività e compiti appropriati per un determinato progetto software.

GOST 34 standard complessi.

È stato concepito come un insieme completo di documenti intersettoriali interconnessi.

Oggetti di standardizzazione: impianti automatizzati di vario tipo e tutte le tipologie dei loro componenti.

Gli standard GOST prevedono le fasi e le fasi di lavoro per creare un sistema automatizzato, ma non prevedono esplicitamente i processi end-to-end che hanno luogo durante l'implementazione del ciclo di vita.

Secondo GOST, lo sviluppo di un sistema automatizzato è suddiviso nei seguenti passaggi e fasi:

Fase 1 formazione dei requisiti per gli oratori:

Fase a: ispezione della struttura e giustificazione della necessità di sviluppare un sistema automatizzato;

Fase b: formazione dei requisiti del cliente per un sistema automatizzato;

Fase c: sviluppo di una relazione sul lavoro svolto e preparazione di una domanda per lo sviluppo di specifiche tecniche.

Fase 2 sviluppo del concetto:

a: studio dell'oggetto;

b: svolgere le ricerche necessarie;

c: sviluppo di opzioni per il concetto di centrale nucleare che soddisfi le esigenze dei clienti;

d: elaborazione di una relazione sul lavoro svolto.

Fase 3 sviluppo e approvazione delle specifiche tecniche per la realizzazione di centrali nucleari.

Fase 4 sviluppo di un progetto preliminare della centrale nucleare:

a: elaborazione di soluzioni progettuali preliminari per l'intero sistema nel suo complesso e per le sue singole componenti;

b: sviluppo della documentazione.

Fase 5 sviluppo del progetto tecnico:

a: sviluppo di soluzioni progettuali dell'intero sistema e delle sue parti;

b: sviluppo della documentazione relativa al sistema automatizzato e ai sottosistemi in esso compresi;

c: sviluppo ed esecuzione della documentazione per la fornitura di prodotti per il completamento di centrali nucleari o sviluppo ed esecuzione di requisiti tecnici per lo sviluppo di tali prodotti.

Fase 6 sviluppo della documentazione tecnica:

a: sviluppo della documentazione di lavoro per la parte di sistema;

b: sviluppo o adattamento del software.

Fase 7mettere in funzione il sistema sviluppato:

a: predisporre l'oggetto di automazione per la realizzazione di sistemi automatizzati;

b: formazione del personale;

c: dotare gli altoparlanti di software e hardware;

d: lavori di installazione;

d: messa in servizio;

e: prove preliminari;

g: operazione di prova;

h: prove di accettazione.

Fase 8 scorta:

a: esecuzione dei lavori in conformità agli obblighi di garanzia;

b: servizio post-garanzia.