Standard IEEE. Prolozova N.O., Nazarova O.B., Davletkireeva L.Z.

La manutenzione è sempre stata riconosciuta come una delle fasi principali del ciclo di vita del software. Già a metà degli anni '70 si riconosceva che la manutenzione è una fase che assorbe oltre il 50% dei costi di sviluppo e implementazione di uno strumento software.

Dall'efficacia del lavoro in fase di supporto e manutenzione dipende la continuità dei processi aziendali e la sicurezza delle informazioni aziendali necessarie alla vita delle aziende.

Per i sistemi software complessi che richiedono l'uso a lungo termine e il mantenimento di più versioni, esiste l'urgente necessità di regolamentarne il ciclo di vita, formalizzare e applicare profili standard e certificazione di qualità dei programmi.

L'uso di documenti normativi e normativi rende il ciclo di vita del software più definito, prevedibile nella struttura, nel contenuto, nella qualità e nei costi. La documentazione, il contenuto informativo e la comprensibilità determinano la composizione e la qualità della documentazione di supporto.

Per organizzare in modo corretto ed efficace la fase più lunga e importante del ciclo di vita del software - Manutenzione del software, che richiede il maggior dispendio di tempo, manodopera e risorse materiali, è necessario considerare le raccomandazioni previste dalle normative internazionali e nazionali norme contenenti disposizioni per l'organizzazione ottimale di questa fase.

Innanzitutto è necessario analizzare l'interpretazione della fase di supporto nelle varie norme.

La manutenzione del software è definita dallo standard IEEE per la manutenzione del software (IEEE 1219) come la modifica di un prodotto software dopo il rilascio in servizio per eliminare guasti, migliorare le prestazioni e/o altre caratteristiche (attributi) del prodotto o adattare il prodotto per l'uso in un ambiente modificato. È interessante notare che questa norma affronta anche le questioni relative alla preparazione alla manutenzione prima che il sistema venga messo in funzione, tuttavia, strutturalmente ciò avviene a livello della corrispondente applicazione informativa inclusa nella norma.

A sua volta, lo standard del ciclo di vita 12207 (IEEE, ISO/IEC, GOST R ISO/IEC) posiziona la manutenzione come uno dei principali processi del ciclo di vita. Questo standard descrive la manutenzione come il processo di modifica di un prodotto software in termini di codice e documentazione per risolvere problemi che si presentano durante il funzionamento o per realizzare la necessità di migliorare determinate caratteristiche del prodotto. La sfida è modificare il prodotto mantenendone l’integrità.

Lo standard internazionale ISO/IEC 14764 (Standard for Software Engineering – Software Maintenance) definisce la manutenzione del software negli stessi termini dello standard 12207, enfatizzando il lavoro di preparazione per le attività di manutenzione prima che il sistema entri in funzione, come questioni di pianificazione, normative e operazioni di supporto.

Dopo la messa in funzione della sottostazione, è necessario mantenerne le prestazioni al livello dei requisiti stabiliti nelle specifiche tecniche. Questa attività include sia l'eliminazione di problemi tecnici ed errori del software sia il possibile aumento della funzionalità. Per l'organizzazione di questi lavori è necessario fare riferimento alle disposizioni specificate nelle norme.

Diverse fonti, in particolare lo standard IEEE 1216, definiscono tre categorie di lavori di manutenzione: adeguamento, adattamento e miglioramento. Questa classificazione è stata aggiornata nella norma ISO/IEC 14764 con l'introduzione di un quarto componente.

Pertanto oggi parliamo di quattro categorie di sostegno:

1. Supporto correttivo comporta modifiche causate dalla necessità di eliminare (correggere) errori effettivi nel prodotto software. Il supporto correttivo viene effettuato se il prodotto software non soddisfa i requisiti stabiliti.

2. Supporto adattivo associato alla necessità di adattare il prodotto software all'ambiente (condizioni) modificato. Questi cambiamenti sono legati all'implementazione di nuovi requisiti per l'interfaccia del sistema, il sistema stesso o i mezzi tecnici.

3. Supporto totale determina modifiche per migliorare le caratteristiche prestazionali del software e la sua manutenibilità. Tali modifiche potrebbero comportare la fornitura di nuove funzionalità agli utenti, la revisione della tecnologia per lo sviluppo dei documenti di accompagnamento o modifiche ai documenti stessi.

4. Supporto preventivo è mirato ai cambiamenti causati dalla necessità di eliminare (correggere) potenziali errori (nascosti) in un prodotto software. La manutenzione preventiva viene solitamente eseguita per prodotti software relativi alla garanzia o alla protezione della vita umana.

La manutenibilità è uno degli indicatori della qualità del software, nonché una caratteristica importante per il cliente, il fornitore e l'utente.

La manutenibilità o manutenibilità di un sistema software è definita, ad esempio, dal Glossario standard IEEE 610.12-90 per la terminologia dell'ingegneria del software, aggiornamento 2002) come la facilità di manutenzione, estensione, adattamento e regolazione per soddisfare requisiti specifici. La norma ISO/IEC 9126-01 (Ingegneria del software - Qualità del prodotto - Parte 1: Modello di qualità, 2001) considera la manutenibilità come una delle caratteristiche di qualità.

La manutenibilità deve essere determinata prima dello sviluppo del software, vale a dire che è stato preparato un accordo appropriato tra il cliente e il fornitore come parte del lavoro di "preparazione" del processo di ordinazione secondo (ISO/IEC, #M12291 1200009075 GOST R ISO/ CEI) 12207#S. Lo sviluppatore crea un piano di supporto, che dovrebbe riflettere metodi specifici per garantire la manutenibilità del software, risorse adeguate e un algoritmo per l'esecuzione del lavoro.

La qualità di uno strumento software è un aspetto importante della manutenzione del prodotto software. I manutentori devono disporre di un programma di garanzia della qualità del software che copra le sei caratteristiche di qualità definite nella norma ISO/IEC 9126. I manutentori del software devono disporre di un processo appropriato per definire, descrivere, selezionare, applicare e migliorare le metodologie per valutare (misurare) le caratteristiche del software .

Per ridurre il costo di ulteriore supporto, durante tutto il processo di sviluppo è necessario specificare, valutare e controllare le caratteristiche che influenzano la manutenibilità. L'implementazione regolare di tale lavoro facilita l'ulteriore manutenzione, aumentandone la manutenibilità (come caratteristica di qualità), cosa piuttosto difficile da ottenere poiché tali caratteristiche vengono spesso ignorate durante lo sviluppo.

Come discusso in precedenza, la manutenzione del software è una fase costosa del ciclo di vita, per ottimizzare il lavoro di cui è necessario applicare vari metodi per stimare il costo di manutenzione.

Il costo del lavoro di supporto è influenzato da molti fattori diversi. La norma ISO/IEC 14764 afferma che “esistono due metodi più diffusi per stimare il costo della manutenzione: – il modello parametrico e l’utilizzo dell’esperienza”. Molto spesso, entrambi questi approcci vengono combinati per migliorare l’accuratezza della valutazione.

Esistono vari metodi per valutare internamente la produttività del personale di supporto per confrontare le prestazioni di diversi gruppi di supporto. L'organizzazione di manutenzione deve determinare i parametri con cui verrà valutato il lavoro rilevante. Gli standard IEEE 1219 e ISO/IEC 9126-01 (Ingegneria del software - Qualità del prodotto - Parte 1: Modello di qualità, 2001) offrono metriche specializzate focalizzate specificamente sui problemi di manutenzione e sui programmi correlati.

Il lavoro di manutenzione deve essere rigorosamente regolamentato e descritto, contenente input e output dettagliati del processo. Questi processi sono coperti da standard IEEE 1219 e ISO/IEC 14764.

Il processo di manutenzione inizia secondo lo standard IEEE 1219 dal momento in cui il software viene messo in funzione e riguarda questioni come la pianificazione delle attività di manutenzione.

Lo standard ISO/IEC 14764 chiarisce quanto previsto dallo standard sul ciclo di vita 12207 relativo al processo di manutenzione. Il lavoro di manutenzione descritto in questo standard è simile al lavoro in IEEE 1219, tranne per il fatto che è raggruppato in modo leggermente diverso.

Diamo uno sguardo più da vicino agli estratti dello standard GOST R ISO/IEC 14764-2002, che contiene il testo autentico completo dello standard internazionale ISO/IEC 14764.

In conformità con GOST R ISO/IEC 14764-2002, che descrive il processo di manutenzione del software, i dettagli del processo di manutenzione del software devono essere documentati in modo che il personale di supporto agisca all'interno di un unico processo. Il sistema di indicatori di qualità (metriche) dovrebbe facilitare l'implementazione del processo di manutenzione e contribuire al miglioramento (modernizzazione) di questo software.

Il manutentore deve (5.5.2.1 GOST R ISO/IEC 12207) analizzare la segnalazione del problema o la proposta di modifica per il suo impatto sulle questioni organizzative, sul sistema esistente e sulle connessioni di interfaccia con altri sistemi.

Sulla base dell'analisi, il manutentore deve (5.5.2.3 GOST R ISO/IEC 12207) sviluppare opzioni per implementare la modifica. Prima di apportare modifiche al sistema, il manutentore deve (vedi 5.5.2.5 GOST R ISO/IEC 12207) ottenere l'approvazione per l'opzione di modifica selezionata in conformità al contratto e la conferma che la modifica apportata soddisfa i requisiti stabiliti nel contratto (vedi 5.5 .4.2 GOST R ISO/IEC 12207). Il manutentore deve (5.5.2.4 GOST R ISO/IEC 12207) documentare: un rapporto sul problema o una proposta di modifica, i risultati della sua analisi e le opzioni per implementare le modifiche.

Per controllare adeguatamente il trasferimento del sistema, è necessario sviluppare, documentare ed eseguire un piano di trasferimento per la struttura (5.5.5.2 GOST R ISO/IEC 12207). Gli utenti devono essere coinvolti nel lavoro pianificato.

Per le attività di supporto, ci sono una serie di lavori e pratiche unici che devono essere considerati quando si organizza il supporto. SWEBOK (Software Engineering Body of Knowledge) fornisce i seguenti esempi di questo tipo di caratteristiche uniche.

Trasmissione:l'attività controllata e coordinata di trasferimento di software dagli sviluppatori al gruppo, servizio o organizzazione responsabile di ulteriore supporto.

Accettare/rifiutare le richieste di modifica : Le richieste di modifiche possono essere accettate e trasferite al lavoro, oppure respinte per vari motivi giustificati: il volume e/o la complessità delle modifiche richieste, nonché lo sforzo richiesto per questo. Le decisioni appropriate possono essere prese anche sulla base della priorità, della valutazione della fattibilità, della mancanza di risorse (inclusa la mancanza di capacità di coinvolgere gli sviluppatori nella risoluzione dei compiti di modifica, se ce n'è una reale necessità), della pianificazione approvata per l'implementazione nel prossimo rilascio, ecc.

Mezzi per avvisare il personale di manutenzione e tenere traccia dello stato delle richieste di modifica e delle segnalazioni di bug : una funzione di supporto dell'utente finale che avvia gli sforzi per valutare la necessità, la priorità e il costo delle modifiche associate a una richiesta o a un problema segnalato.

Analisi d'impatto:analisi delle possibili conseguenze delle modifiche apportate al sistema esistente.

Supporto software: lavoro di consultazione degli utenti, svolto in risposta alle loro richieste di informazioni, ad esempio, riguardanti regole aziendali pertinenti, verifica, contenuto dei dati e domande specifiche degli utenti e le loro segnalazioni di problemi (errori, guasti, comportamenti imprevisti, incomprensioni su aspetti del lavoro con il sistema, ecc.); P.).

Contratti e obblighi: Questi includono il classico accordo sul livello di servizio (SLA), così come altri aspetti contrattuali, sulla base dei quali il gruppo di supporto/servizio/organizzazione esegue il lavoro rilevante.

In aggiunta, ci sono ulteriori attività che supportano il processo di manutenzione, descritte da SWEBOK come attività del personale di manutenzione che non comportano un'esplicita interazione con gli utenti, ma sono necessarie per svolgere le attività correlate. Tale lavoro comprende: pianificazione della manutenzione, gestione della configurazione, verifica e certificazione, valutazione della qualità del software, vari aspetti di revisione, analisi e valutazione, audit e formazione degli utenti. Tale lavoro speciale (interno) comprende anche la formazione del personale di supporto.

La tabella 1 seguente fornisce una breve panoramica dei principali standard utilizzati nell'organizzazione della manutenzione dei sistemi informativi.

Tabella 1. Norme nel campo della manutenzione dei sistemi informativi

Oltre agli standard internazionali e nazionali che regolano il processo di manutenzione dei sistemi informativi discussi sopra, esistono vari documenti regolamentari e standard intraaziendali (aziendali), la cui base sono standard internazionali. In questo caso, particolare attenzione è rivolta alla qualità della documentazione, che determina in gran parte la competitività del software. Quando si creano prodotti software complessi e si garantisce il loro ciclo di vita, è necessario selezionare gli standard necessari e creare l'intero set di documenti, ad es. un profilo che garantisca la regolamentazione di tutte le fasi e i lavori di manutenzione.

Consideriamo l'applicazione degli standard per la manutenzione dei sistemi informativi utilizzando un esempio specifico.Il funzionamento di alta qualità del sistema richiede un costante adattamento ai processi aziendali in evoluzione dell’organizzazione, nonché una risposta rapida ai guasti e alla risoluzione dei problemi. In relazione a ciò, la direzione della ditta ZAO SoftInCom ha deciso la necessità di stipulare un accordo con gli sviluppatori del sistema informativo aziendale (CIS) Orient Express per l'aggiornamento e la manutenzione del sistema.

La manutenzione del CIS Eastern Express include il supporto di diversi tipi (secondo GOST R ISO IEC 14764-2002). Vale a dire, supporto correttivo, che è associato ai cambiamenti causati dalla necessità di eliminare (correggere) gli errori effettivi nel prodotto software. Il supporto correttivo viene effettuato se il prodotto software non soddisfa i requisiti stabiliti. Oltre al supporto adattivo e completo che modernizza il prodotto software.

La necessità di supporto correttivo appare quando si verificano errori di sistema, nonché errori causati dall'utente. Gli errori causati dall'utente includono, ad esempio, la cancellazione accidentale di dati importanti, che porta alla necessità di utilizzare un backup del sistema. Gli errori di sistema si verificano abbastanza spesso, soprattutto dopo l'installazione di nuove versioni, poiché le nuove versioni implicano cambiamenti piuttosto gravi nelle tecnologie di elaborazione dati esistenti e nell'inclusione di nuovi moduli.

La necessità di supporto adattivo sorge quando si verificano cambiamenti nel funzionamento di qualsiasi processo aziendale (effettuare una promozione, modificare moduli stampati esterni, ordini dalla sede centrale, ecc.), o quando eseguire qualsiasi operazione è scomodo, il che richiede modifiche nell'interfaccia del sistema.

Il supporto completo viene fornito molto meno frequentemente rispetto ad altri tipi di supporto. Viene eseguito quando si verificano molti incidenti, richieste e desideri simili da parte degli utenti, nonché dopo che i progettisti CIS hanno analizzato le capacità del sistema.

Il lavoro di supporto può essere suddiviso in quattro fasi: analisi di difetti e modifiche, implementazione delle modifiche, valutazione e accettazione dei risultati del supporto, trasferimento su un'altra piattaforma. Ciascuna di queste fasi contiene input e output specifici e deve essere documentata.

La tabella 2 mostra le principali fasi del sostegno e i risultati nel paragrafo relativo alla documentazione di accompagnamento.

Tabella 2. Fasi del processo di manutenzione del sistema informativo

In conformità con 5.5.2.1 di GOST R ISO/IEC 12207, il manutentore deve analizzare le segnalazioni degli utenti del problema. Per automatizzare la registrazione e la registrazione delle richieste degli utenti del CIS Orient Express, viene utilizzato il sistema di registrazione degli incidenti MantisBT. Basato sui dati registrati nel sistema MantisBT genera un documento “Rapporto sui difetti identificati dagli utenti” contenente i seguenti campi: numero dell'incidente, data di creazione, categoria, essenza dell'incidente, soluzione proposta.

Sulla base dell'analisi, il manutentore deve (5.5.2.3 GOST R ISO/IEC 12207) sviluppare opzioni per implementare le modifiche. A tale scopo, è in fase di sviluppo il documento "Giornale degli adeguamenti preparati e approvati alla nuova versione base del CIS", contenente i seguenti dati: categoria, difetto identificato dall'organizzazione di supporto, difetto identificato dagli utenti del CIS, adeguamento.

Successivamente, il manutentore deve (5.5.4.2 GOST R ISO/IEC 12207) ottenere conferma che la modifica apportata soddisfa i requisiti stabiliti nel contratto. A tal fine viene generato un documento “Notifica agli utenti in merito al rilascio di una nuova versione del CIS” e si prevede la conferma del consenso all'installazione della nuova versione.

Per controllare adeguatamente il trasferimento del sistema, deve esserci

La struttura del ciclo di vita del software secondo lo standard ISO/IEC 12207 si basa su tre gruppi di processi (Fig. 1):

· principali processi del ciclo di vita del software (acquisto, consegna, sviluppo, esercizio, supporto);

· processi ausiliari che assicurano l'implementazione dei processi principali (documentazione, gestione della configurazione, garanzia della qualità, verifica, certificazione, valutazione, audit, problem solving);

· processi organizzativi (gestione del progetto, realizzazione dell'infrastruttura del progetto, definizione, valutazione e miglioramento del ciclo di vita stesso, formazione).

Riso. 1. Processi del ciclo di vita del software.

Processo di acquisizione(processo di acquisizione). Consiste in azioni

e compiti del cliente che acquista il software. Questo processo copre i seguenti passaggi:

1) avvio dell'acquisizione;

2) preparazione delle proposte di offerta;

3) preparazione e adeguamento del contratto;

4) supervisione delle attività del fornitore;

5) accettazione e completamento dei lavori.

Processo di consegna(processo di fornitura). Copre le attività e i compiti svolti dal venditore che fornisce al cliente un prodotto o servizio software. Questo processo include i seguenti passaggi:

1) inizio della consegna;

2) preparare una risposta alle proposte di offerta;

3) preparazione del contratto;

4) pianificazione;

5) esecuzione e controllo;

6) ispezione e valutazione;

7) consegna e ultimazione dei lavori.

Processo di sviluppo(processo di sviluppo). Prevede le azioni e i compiti eseguiti dallo sviluppatore e copre la creazione del software e dei suoi componenti in conformità con i requisiti specificati, compresa la preparazione della documentazione operativa e di progettazione, la preparazione dei materiali necessari per testare la funzionalità e la qualità adeguata del software prodotti, materiali necessari per l'organizzazione del personale di formazione, ecc.

Il processo di sviluppo comprende i seguenti passaggi:

1) analisi dei requisiti di sistema;

2) progettazione dell'architettura del sistema;

3) analisi dei requisiti software;

4) progettazione dell'architettura software;

5) progettazione dettagliata del software;

6) codifica e test del software;

7) integrazione software;

8) test di qualificazione del software;

9) integrazione del sistema;

10) test di qualificazione del sistema;

11) installazione software;

12) accettazione del software.

Processo operativo(processo operativo). Copre le azioni e i compiti dell'operatore, l'organizzazione che gestisce il sistema. Questo processo include i seguenti passaggi:

1) test operativi;

2) funzionamento del sistema;

3) supporto agli utenti.

Processo di manutenzione(processo di manutenzione). Prevede le azioni e i compiti svolti dall'organizzazione di accompagnamento (servizio di scorta). Questo processo viene attivato quando i cambiamenti (modifiche) del prodotto software e della relativa documentazione sono causati da problemi o necessità di ammodernamento o adattamento del software. Secondo lo standard IEEE-90, per manutenzione si intende apportare modifiche al software al fine di correggere errori, migliorare le prestazioni o adattarsi a mutate condizioni operative o

requisiti. Le modifiche apportate al software esistente non devono violare

la sua integrità. Il processo di manutenzione comprende il trasferimento del software in un altro ambiente (migrazione) e termina con la disattivazione del software.

Il processo di manutenzione copre le seguenti azioni:

1) analisi dei problemi e richieste di modifica del software;

2) modifica del software;

3) ispezione e accettazione;

4) trasferimento del software in un altro ambiente;

5) dismissione del software.

Il gruppo di processi ausiliari comprende:

Documentazione;

Gestione della configurazione; garanzia di qualità;

Verifica; certificazione;

Valutazione partecipativa;

Risoluzione del problema.

Processo di documentazione(processo di documentazione). Fornisce una descrizione formalizzata delle informazioni create durante il ciclo di vita del software. Il processo di documentazione comprende i seguenti passaggi:

1) progettazione e sviluppo;

2) rilascio della documentazione;

3) supporto documentale.

Processo di gestione della configurazione(processo di gestione della configurazione). Implica l'uso di procedure amministrative e tecniche durante tutto il ciclo di vita del software per determinare lo stato dei componenti software nel sistema, gestire le modifiche del software, descrivere e preparare report sullo stato dei componenti software e sulle richieste di modifica, garantire completezza, compatibilità e correttezza dei componenti software, gestire l'archiviazione e la consegna BY. Secondo lo standard IEEE-90 per configurazione del software si intende l'insieme delle sue caratteristiche funzionali e fisiche.

caratteristiche stabilite nella documentazione tecnica e implementate nel software.

La gestione della configurazione consente di organizzare, tenere sistematicamente conto e controllare le modifiche al software in tutte le fasi del ciclo di vita. I principi generali e le raccomandazioni per la gestione della configurazione del software si riflettono nella bozza dello standard ISO/I EC CD 12207-2: 1995 "Tecnologia dell'informazione - Processi del ciclo di vita del software. Parte 2.

Gestione della configurazione per il software". Il processo di gestione della configurazione include le seguenti azioni:

1) identificazione della configurazione;

2) controllo della configurazione;

3) contabilità dello stato della configurazione;

4) valutazione della configurazione;

5) gestione e consegna dei rilasci.

Processo di garanzia della qualità(processo di garanzia della qualità). Fornisce un'adeguata garanzia che il software e i relativi processi del ciclo di vita siano conformi ai requisiti specificati e ai piani approvati. La qualità del software è intesa come un insieme di proprietà che caratterizzano la capacità del software di soddisfare requisiti specifici. Per ottenere valutazioni affidabili del software in creazione, il processo di garanzia della sua qualità deve avvenire indipendentemente dalle entità direttamente collegate allo sviluppo del software. Possono essere utilizzati i risultati di altri processi di supporto quali verifica, validazione, valutazione congiunta, audit e risoluzione dei problemi. Il processo di assicurazione della qualità comprende le seguenti attività:

1) garantire la qualità del prodotto;

2) garantire la qualità del processo;

3) garantire altri indicatori di qualità del sistema.

Processo di verifica(processo di verifica). Consiste nel determinare che i prodotti software che sono il risultato di una certa azione soddisfano pienamente i requisiti o le condizioni determinate dalle azioni precedenti (verifica in senso stretto significa prova formale della correttezza del software).

Processo di attestazione(processo di validazione). Si tratta di determinare la completezza della conformità dei requisiti specificati e del sistema o prodotto software creato con il loro scopo funzionale specifico. La certificazione di solito si riferisce alla conferma e alla valutazione dell'affidabilità dei test del software.

Processo di valutazione partecipativa(processo di revisione congiunta). Ha lo scopo di valutare lo stato dei lavori sul progetto e il software creato durante l'esecuzione di tali lavori (azioni). Si concentra principalmente sul controllo della pianificazione e della gestione delle risorse, del personale, delle attrezzature e degli strumenti del progetto.

Processo di audit(processo di audit). Si tratta di una determinazione del rispetto dei requisiti, dei piani e dei termini contrattuali.

Processo di risoluzione dei problemi(processo di risoluzione del problema). Implica l'analisi e la risoluzione dei problemi (comprese le incoerenze rilevate), indipendentemente dalla loro origine o fonte, scoperti durante lo sviluppo, il funzionamento, la manutenzione o altri processi. Ogni problema rilevato deve essere identificato, descritto, analizzato e risolto.

L'insieme dei processi organizzativi del ciclo di vita del software comprende:

Controllo;

Creazione di infrastrutture;

Miglioramento;

Rilascio di nuove versioni;

Formazione scolastica.

Processo di gestione(processo di gestione). Consiste in attività e compiti che possono essere svolti da chiunque ne gestisca i processi. Questa parte (manager) è responsabile della gestione del rilascio del prodotto, della gestione del progetto e della gestione delle attività dei processi correlati, come acquisizione, consegna, sviluppo, funzionamento, manutenzione, ecc.

Processo di creazione delle infrastrutture(processo infrastrutturale). Copre la selezione e il supporto (manutenzione) di tecnologia, standard e strumenti, la selezione e l'installazione di hardware e software utilizzati per lo sviluppo, il funzionamento o la manutenzione del software. L'infrastruttura deve essere modificata e mantenuta in conformità con i cambiamenti nei requisiti per i processi pertinenti. L'infrastruttura, a sua volta, è uno degli oggetti della gestione della configurazione.

Processo di miglioramento(processo di miglioramento). Prevede la valutazione, misurazione, controllo e miglioramento dei processi del ciclo di vita del software. Il miglioramento dei processi del ciclo di vita del software è finalizzato ad aumentare la produttività di tutti gli specialisti coinvolti in essi migliorando la tecnologia utilizzata, i metodi di gestione, la selezione degli strumenti e la formazione

personale.

Processo di apprendimento(processo di formazione). Copre la formazione iniziale e il successivo sviluppo continuo del personale.

Nel campo IT, gli standard più pratici sono pubblicati dalle seguenti organizzazioni:

• Istituto degli ingegneri elettrici ed elettronici(IEEE, www.ieee.org) è da molti anni un'organizzazione scientifica e tecnica leader, anche nella creazione di standard di documentazione del software. La maggior parte degli standard sono sviluppati da vari comitati composti da ingegneri professionisti esperti e responsabili. Alcuni standard IEEE sono diventati anche standard ANSI (American National Standards Institute). Principalmente gli standard IEEE hanno costituito la base per la preparazione di MU per CP. Schmidt M. Implementazione degli standard di ingegneria del software IEEE.
• Organizzazione internazionale per la standardizzazione (ISO) ha un’enorme influenza in tutto il mondo, soprattutto tra le organizzazioni di produttori che hanno rapporti con l’Unione Europea (UE). Attualmente, praticamente tutti gli standard IT moderni tradotti e adottati nella Federazione Russa sono standard preparati dall'ISO in collaborazione con la Commissione Elettrotecnica Internazionale - IEC. Sapete che particolare attenzione viene prestata alle questioni relative alla garanzia della qualità del prodotto a livello internazionale, pertanto, secondo il decreto del governo russo n. 113 del 02/02/1998, il rispetto dei requisiti della norma ISO 9000 (una serie di standard che regolano la gestione della qualità presso le imprese) è un prerequisito per ottenere l'ordine del governo.
• Istituto di tecnologie di ingegneria del software(Software Engineering Institute - SEI, sei.cmu.edu - più di 1000 articoli) è stato istituito dal Dipartimento della Difesa degli Stati Uniti presso la Carnegie Mellon University per aumentare il livello della tecnologia software tra gli appaltatori del Dipartimento della Difesa. Il lavoro di SEI è stato adottato anche da molte aziende commerciali che considerano il miglioramento del processo di sviluppo software un obiettivo aziendale strategico. Considereremo uno degli standard sviluppati da SEI chiamato Capability Maturity Model (CMM).
• Consorzio per la tecnologia di manipolazione degli oggetti(Object Management Group, www.omg.org) è un'organizzazione senza scopo di lucro con circa 700 aziende associate. OMG stabilisce gli standard per il calcolo distribuito orientato agli oggetti. Va notato che OMG utilizza il linguaggio di modellazione unificato UML come standard per descrivere i progetti. Studieremo UML in dettaglio, perché... l'uso di questo linguaggio insieme al processo unificato di Rational è la base per sviluppare il nucleo del progetto del corso.

Concetto di ciclo di vita del sistema

La necessità di standardizzazione dello sviluppo del software è meglio descritta nell'introduzione dello standard GOST R ISO/IEC 12207-99 “Tecnologia dell'informazione. Processi del ciclo di vita del software": “Il software è parte integrante della tecnologia dell'informazione e dei sistemi tradizionali come quelli dei trasporti, militari, medici e finanziari. Esistono molti standard, procedure, metodi, strumenti e tipi di ambienti operativi diversi per lo sviluppo e la gestione del software. Questa diversità crea sfide nella progettazione e gestione del software, soprattutto quando si combinano prodotti e servizi software. La strategia di sviluppo del software richiede il passaggio da questa moltitudine a un ordine comune che consentirà ai professionisti del software di “parlare la stessa lingua” durante lo sviluppo e la gestione del software. Questo standard internazionale fornisce quell’ordine generale”.

Norma GOST R ISO/IEC 12207-99 definisce il concetto di base di un sistema software - “ciclo di vita” (GOST R ISO/IEC TO 15271-2002 “Tecnologia dell'informazione. Linee guida per l'applicazione di GOST R ISO/IEC 12207”).

GOST R ISO/IEC 12207-99 introduce il concetto di modello del ciclo di vita come una struttura costituita da processi che coprono la vita di un sistema dalla definizione dei requisiti fino alla fine del suo utilizzo. Si propone di correggere questa definizione e di dividerla in due definizioni:

1. ciclo vitale– un insieme di processi suddivisi in opere e compiti, e comprendente lo sviluppo, il funzionamento e la manutenzione di un prodotto software, che copre la vita del sistema dalla definizione dei requisiti fino alla cessazione del suo utilizzo.
2. modello del ciclo di vita– una struttura che determina la sequenza di processi, lavori e compiti eseguiti durante tutto il ciclo di vita di un sistema software, nonché le relazioni tra loro.

I processi del ciclo di vita sono divisi in tre gruppi: principale, ausiliario e organizzativo.

Il gruppo dei processi principali comprende: acquisizione, fornitura, sviluppo, gestione e supporto. I principali processi del ciclo di vita sono implementati sotto il controllo delle principali parti coinvolte nel ciclo di vita del software. La parte principale è una di quelle organizzazioni che avvia o esegue lo sviluppo, il funzionamento o la manutenzione di prodotti software. Le parti principali sono il cliente, il fornitore, lo sviluppatore, l'operatore e il personale di supporto del software.

Figura - Principali processi del ciclo di vita dell'IS

Il gruppo di processi ausiliari comprende processi che garantiscono l'esecuzione dei processi principali:

• documentazione;
• gestione della configurazione;
• garanzia di qualità;
• verifica;
• certificazione;
• grado;
• verifica;
• risoluzione dei problemi.

L’insieme dei processi organizzativi comprende i processi:

• gestione del progetto;
• creazione di infrastrutture di progetto;
• definire, valutare e migliorare il ciclo di vita stesso;
• formazione scolastica.

Nel testo di GOST 12207-99 Il lavoro che fa parte dei processi principali, ausiliari e organizzativi è caratterizzato in modo molto generale, infatti se ne delineano solo le direzioni, quindi per iniziare la progettazione saranno necessari standard e letteratura aggiuntiva che rivelino il contenuto di ogni singolo processo o, meglio ancora, lavoro individuale.
Del gruppo dei processi principali, il processo di sviluppo è di maggiore interesse.
Va notato che GOST 34.601-90 “Sistemi automatizzati. Fasi di creazione" il processo di creazione di un sistema automatizzato è suddiviso nelle seguenti fasi:

• formazione dei requisiti per i relatori,
• sviluppo del concetto di AC,
• compito tecnico,
• progetto preliminare,
• progetto tecnico,
• documentazione di lavoro,
• la messa in produzione,
• accompagnamento.

Le fasi sono suddivise in fasi, il cui contenuto si sovrappone al contenuto di una serie di attività descritte in GOST 12207-99.

Processo di sviluppo

processo di sviluppo prevede le azioni e i compiti eseguiti dallo sviluppatore e copre il lavoro sulla creazione del software e dei suoi componenti in conformità con i requisiti specificati, compresa la preparazione della progettazione e della documentazione operativa; preparazione dei materiali necessari per testare le prestazioni e la qualità adeguata dei prodotti software, materiali necessari per l'organizzazione della formazione del personale, ecc.

Figura - Struttura del processo di sviluppo

Lavoro preparatorio

inizia con la selezione di un modello del ciclo di vita del PS che corrisponda alla scala, al significato e alla complessità del progetto. Le attività e i compiti del processo di sviluppo devono corrispondere al modello scelto. Il promotore deve selezionare, adattare alle condizioni del progetto e utilizzare standard, metodi e strumenti di sviluppo concordati con il cliente, nonché elaborare un piano di esecuzione del lavoro.

Analisi dei requisiti

L'analisi dei requisiti software implica la determinazione delle seguenti caratteristiche per ciascun componente software:

• funzionalità, comprese le caratteristiche prestazionali e l'ambiente operativo del componente;
• interfacce esterne;
• specifiche di affidabilità e sicurezza;
• requisiti ergonomici;
• requisiti per i dati utilizzati;
• requisiti di installazione e accettazione;
• requisiti per la documentazione utente;
• requisiti per il funzionamento e la manutenzione.

Progetto di architettura

sistema ad alto livello consiste nel determinare i componenti delle sue apparecchiature, del software e delle operazioni eseguite dal personale che gestisce il sistema. L'architettura del sistema deve essere conforme ai requisiti di sistema e agli standard e alle pratiche di progettazione accettati.
La progettazione di un'architettura software include le seguenti attività (per ciascun componente software):

• trasformazione dei requisiti del software in un'architettura che definisce ad alto livello la struttura del software e la composizione dei suoi componenti;
• Sviluppo e documentazione di interfacce software per sistemi software e banche dati;
• sviluppo di una versione preliminare della documentazione per l'utente;
• sviluppo e documentazione dei requisiti di test preliminari e di un piano di integrazione del software.

Design dettagliato

Il PS prevede i seguenti compiti:

• descrizione dei componenti software e delle interfacce tra loro a livello inferiore, sufficiente per la loro successiva codifica e test indipendenti;
• sviluppare e documentare una progettazione dettagliata del database;
• sviluppo e documentazione dei requisiti di test e di un piano di test per componenti software;

Codifica e test

Il PS copre i seguenti compiti:

• sviluppo (codifica) e documentazione di ciascun componente software e database, nonché una serie di procedure di test e dati per testarli;
• testare ogni componente software e database per verificarne la conformità ai relativi requisiti. I risultati dei test sui componenti devono essere documentati;
• aggiornare (se necessario) la documentazione utente;
• aggiornamento del piano di integrazione PS.

Per ciascuno dei componenti aggregati, vengono sviluppati set di test e procedure di test per verificare ciascuno dei requisiti di qualificazione durante i successivi test di qualificazione. Un requisito di qualificazione è un insieme di criteri o condizioni che devono essere soddisfatti per qualificare un prodotto software come conforme alle specifiche e pronto per l'uso sul campo.

GOST R ISO/IEC 12119-2000 “Tecnologia dell'informazione. Pacchetti software. Requisiti di qualità e test" contiene istruzioni che determinano la procedura per testare un prodotto per verificarne la conformità ai suoi requisiti di qualità. Il test è un processo ad alta intensità di lavoro. Secondo alcuni esperti, la percentuale
La distribuzione del tempo tra i processi di progettazione – sviluppo – testing è nel rapporto 40-20-40. A questo proposito, i sistemi di automazione dei test si stanno diffondendo. Lo standard IEEE 1209-1992, "Pratica consigliata per la valutazione e la selezione degli strumenti CASE", stabilisce i requisiti generali per la funzionalità degli strumenti di automazione dei test.

Integrazione del sistema

consiste nell'assemblare tutti i suoi componenti, comprese le sottostazioni e le apparecchiature. Dopo l'integrazione, il sistema, a sua volta, viene sottoposto a test di qualificazione per verificarne la conformità con una serie di requisiti. Contestualmente viene predisposta e verificata anche la documentazione completa del sistema.

Installazione del sistema

effettuata dal committente in conformità con il piano nell'ambiente e sulle attrezzature previste dal contratto. Durante il processo di installazione viene controllata la funzionalità del software e dei database.

Accettazione del sistema

prevede la valutazione dei risultati dei test di qualificazione del software e del sistema e la documentazione dei risultati della valutazione, che vengono eseguiti dal cliente con l'aiuto dello sviluppatore. Lo sviluppatore esegue il trasferimento finale del software al cliente in conformità al contratto, fornendo al contempo la formazione e il supporto necessari. Il nostro corso è principalmente finalizzato ad un esame dettagliato dei primi quattro lavori del processo di sviluppo del software. Ciascuno di questi lavori sarà dedicato ad una sezione separata, e ora per un'ulteriore presentazione è necessario spendere qualche parola sui modelli del ciclo di vita del PS.

Modelli del ciclo di vita del software

Modello del ciclo di vita– una struttura che determina la sequenza di processi, lavori e compiti eseguiti durante tutto il ciclo di vita di un sistema informativo, nonché le relazioni tra loro.

Ad oggi, due principali modelli di ciclo di vita sono diventati più diffusi:

• modello a cascata (cascata);
• modello a spirale.

Modello a cascata

Modello a cascata dimostra un approccio classico allo sviluppo di vari sistemi in vari ambiti applicativi. Per lo sviluppo dei sistemi informativi questo modello è stato ampiamente utilizzato negli anni '70 e nella prima metà degli anni '80. È il modello a cascata che costituisce la base della serie GOST 34.xxx e dello standard DOD-STD-2167A del Dipartimento della Difesa degli Stati Uniti. Elabora GOST 12207-99 in GOST 34.601-90 “Sistemi automatizzati. Fasi della creazione" sono chiamati stadi e differiscono leggermente nella composizione.
Il modello a cascata prevede l'organizzazione sequenziale dei processi. Inoltre, il passaggio al processo successivo avviene solo dopo che tutto il lavoro su quello precedente è stato completamente completato. Ogni processo si conclude con il rilascio di un set completo di documentazione, sufficiente affinché il lavoro possa essere proseguito da un altro team di sviluppo.

Lo svantaggio principale del modello a cascata è che errori e carenze in qualsiasi fase compaiono, di regola, nelle fasi successive del lavoro, il che porta alla necessità di tornare indietro. Secondo la società di consulenza The Standish Group, nel 1998 negli Stati Uniti più del 28% dei progetti di sistemi informativi aziendali (progetti IT) si sono conclusi con un fallimento; quasi il 46% dei progetti IT sono stati completati oltre il budget (una media del 189%); e solo il 26% dei progetti rientra nei tempi e nel budget assegnati.

Inoltre, gli svantaggi del modello a cascata includono:

• difficoltà nel parallelizzare il lavoro;
• complessità della gestione del progetto;
• alto livello di rischio e investimento inaffidabile (il ritorno alle fasi precedenti può essere associato non solo a errori, ma anche a cambiamenti avvenuti nell'area tematica o nei requisiti del cliente durante lo sviluppo. Inoltre, restituire il progetto per la revisione a causa di questi motivi non garantire che l’ambito tematico non cambi nuovamente quando sarà pronta la prossima versione del progetto: ciò significa infatti che esiste la possibilità che il processo di sviluppo “vada per cicli” e che il sistema non arrivi mai al punto di messa in servizio (i costi del progetto aumenteranno costantemente e i tempi di consegna del prodotto finito subiranno costantemente ritardi).

Modello a spirale

A differenza della cascata, comporta un processo iterativo di sviluppo di un sistema informativo. Il modello a spirale è stato proposto a metà degli anni '80 da Barry Boehm. Ogni giro della spirale corrisponde alla creazione di un frammento o versione di un prodotto software, in cui vengono chiariti gli obiettivi e le caratteristiche del progetto, viene determinata la sua qualità e viene pianificato il lavoro per il giro successivo della spirale. Ad ogni iterazione, i dettagli del progetto vengono approfonditi e specificati in modo coerente e vengono raccolti dati metrici, che vengono utilizzati per ottimizzare le iterazioni successive. Tuttavia, i meccanismi per garantire l'integrità della documentazione diventano più complicati (quando un particolare requisito o definizione viene fornito nel testo una sola volta), il che richiede l'uso di strumenti speciali.
Caratteristiche principali del modello a spirale:

• rifiuto di fissare requisiti e assegnare priorità alle esigenze degli utenti;
• sviluppare una sequenza di prototipi partendo dai requisiti con la massima priorità;
• identificazione e analisi del rischio ad ogni iterazione;
• Valutazione dei risultati alla fine di ogni iterazione e pianificazione dell'iterazione successiva.

Sviluppo rapido di applicazioni

Negli anni '90 del XX secolo, sulla base del modello a spirale, è stata fondata una tecnologia pratica chiamata "sviluppo rapido di applicazioni" - RAD (Rapid Application Development). In questo caso, il ciclo di vita consisteva di quattro fasi:

• analisi e pianificazione dei requisiti,
• progetto,
• implementazione,
• implementazione.

Principi di base del RAD:

• sviluppare applicazioni in iterazioni;
• il completamento facoltativo del lavoro in ciascuna fase del ciclo di vita del software;
• coinvolgimento obbligatorio degli utenti nel processo di sviluppo;
• l'uso di strumenti di gestione della configurazione che facilitano l'apporto di modifiche al progetto e il mantenimento del sistema finito;
• l'uso della prototipazione per comprendere e soddisfare meglio le esigenze degli utenti;
• test e sviluppo del progetto, svolti contestualmente allo sviluppo;
• sviluppo da parte di un piccolo team di professionisti ben gestito;
• gestione competente dello sviluppo del sistema, pianificazione chiara e controllo dell'esecuzione del lavoro.

All'inizio del 2001, un certo numero di esperti leader nel campo dell'ingegneria del software (Martin Fowler, Kent Beck, ecc.) formarono un gruppo chiamato Agile Alliance per supportare e sviluppare un nuovo approccio alla progettazione: "sviluppo rapido del software" (Agile Software Development). Sviluppo). Un'implementazione di questo approccio è Extreme Programming (XP).

I principi dell’Extreme Programming sono i seguenti:

1. Il team è composto da tre a dieci programmatori. Uno o più clienti devono essere in grado di fornire costantemente competenze continue.
2. I programmi sono sviluppati in iterazioni di tre settimane. Ogni iterazione produce codice funzionante e testato che può essere immediatamente utilizzato dai clienti. Il sistema completo viene spedito agli utenti finali alla fine di ogni periodo di rilascio, che può richiedere da due a cinque iterazioni.
3. L'unità di requisiti software raccolti è una “user story”, scritta su una scheda, che descrive la funzionalità dal punto di vista dell'utente che può essere sviluppata in un'unica iterazione. Clienti e programmatori pianificano il lavoro per l'iterazione successiva in questo modo:
   • i programmatori stimano il tempo per completare ogni scheda;
   • i clienti stabiliscono le priorità, le modificano e le rivedono secondo necessità. Lo sviluppo di una storia inizia con la discussione tra i programmatori e l'esperto del cliente.
4. I programmatori lavorano in coppia e seguono rigorosi standard di codifica stabiliti all'inizio del progetto. Creano test unitari per tutto ciò che scrivono e garantiscono che tali test vengano eseguiti ogni volta che il codice viene sottoposto al controllo della versione obbligatorio e alla gestione della configurazione.
5. Mentre i programmatori lavorano, i clienti visitano i programmatori per chiarire le idee, scrivere test di accettazione del sistema da eseguire durante l'iterazione e alla fine dell'iterazione selezionare le storie da implementare nell'iterazione successiva.
6. Ogni giorno il team tiene riunioni operative in cui i programmatori parlano di ciò su cui stanno lavorando, di cosa sta andando bene e di cosa ha bisogno di aiuto. Alla fine di ogni iterazione, c'è un altro incontro in cui si valuta cosa è andato bene e su cosa occorre lavorare la prossima volta. Questo elenco viene pubblicato affinché tutti possano vederlo mentre lavorano alla successiva iterazione.
7. Una persona del team viene designata come “mentore”. Insieme ai membri del team valuta il loro utilizzo delle tecniche di base: programmazione e test delle coppie, rotazione delle coppie, mantenimento di soluzioni progettuali semplici, comunicazione, ecc. ai fini del miglioramento continuo del processo di sviluppo.

L'approccio allo sviluppo rapido del software non è universale ed è applicabile solo a progetti di una certa classe. Per caratterizzare tali progetti, Alistair Coburn ha introdotto due parametri: criticità e scala.
La criticità è determinata dalle conseguenze causate da difetti nel software e può avere uno dei quattro livelli:

• C – i difetti causano la perdita di convenienza;
• D – i difetti causano la perdita di fondi recuperabili (materiali o finanziari);
• E – i difetti causano la perdita di fondi insostituibili;
• L – i difetti rappresentano una minaccia per la vita umana.

La scala è determinata dal numero di sviluppatori che partecipano al progetto:

• da 1 a 6 persone – piccola scala;
• da 6 a 20 persone – scala media;
• oltre 20 persone – su larga scala.

Secondo Coburn, lo sviluppo rapido del software è applicabile solo a progetti di piccole e medie dimensioni con bassa criticità (C o D). Ciò significa che le tecnologie RAD e XP sono più adatte per progetti relativamente piccoli sviluppati per un cliente specifico e non sono applicabili alla realizzazione di programmi di calcolo complessi, sistemi operativi o programmi per la gestione di oggetti complessi in tempo reale, nonché sistemi da cui dipende la sicurezza delle persone.

Processo di sviluppo software unificato

Attualmente, si continua a lavorare per creare una sorta di processo di sviluppo dell’IS universale. Nel 1999 I dipendenti razionali Ivar Jacobson, Gradi Booch e James Rumbaugh hanno pubblicato il libro Unified Software Development Process, che è stato tradotto in russo e pubblicato dalla casa editrice Peter nel 2002. Il processo unificato è un tentativo di combinare modelli a cascata e iterativi J C.

Allo stesso tempo, il ciclo di vita è diviso in 4 fasi:

1. Inizio: viene effettuata una prima valutazione del progetto.
   • viene creato un modello semplificato dei casi d’uso contenente i casi d’uso più critici dal punto di vista implementativo;
   • viene realizzata una versione di prova dell'architettura contenente i sottosistemi più importanti;
   • i rischi sono identificati e classificati in ordine di priorità;
   • è prevista la fase di progettazione;
   • l'intero progetto nel suo insieme viene valutato approssimativamente;
2. chiarimento (elaborazione): la maggior parte dei casi d'uso vengono descritti in dettaglio e viene sviluppata l'architettura del sistema. Al termine della fase di progettazione, il project manager calcola le risorse necessarie per completare il progetto. È necessario rispondere alla domanda: i casi d’uso, l’architettura e il piano sono sufficientemente sviluppati affinché sia ​​possibile dare obblighi contrattuali per eseguire l’opera e procedere alla predisposizione e firma delle “Specifiche Tecniche”?;
3. costruzione– creazione del prodotto. Al termine di questa fase, il prodotto include tutti i casi d'uso che gli sviluppatori e il cliente hanno deciso di includere nella release corrente;
4. implementazione (transizione)- rilascio del prodotto. La versione beta del prodotto viene testata dal reparto test dell'azienda e allo stesso tempo viene organizzato il funzionamento di prova del sistema da parte degli utenti. Gli sviluppatori quindi risolvono eventuali bug rilevati e incorporano alcuni dei miglioramenti suggeriti in una versione principale pronta per un'ampia distribuzione.

Ciascuna fase USDP può includere una o più iterazioni, a seconda delle dimensioni del progetto. Durante ogni iterazione possono essere eseguiti 5 thread principali e un certo numero di thread di lavoro aggiuntivi.
I principali flussi di lavoro in USDP includono:

• definizione dei requisiti (RD);
• analisi (A);
• disegno (P);
• implementazione (P);
• prova (T).

Ulteriori thread di lavoro possono includere:

• lavoro di garanzia della qualità (K),
• documentazione (D),
• gestione del progetto (P),
• gestione della configurazione (CM),
• realizzazione e gestione delle infrastrutture (I)
• e altri.

Figura - Modello del ciclo di vita secondo il processo di sviluppo del software unificato

La scelta del modello del ciclo di vita dipende in gran parte dal tipo e dalla scala del sistema che si sta sviluppando. Per lo sviluppo della maggior parte dei sistemi di controllo automatizzati con tempo libero, è applicabile il modello del ciclo di vita iterativo, mentre il modello a cascata è più adatto per i sistemi in tempo reale. Durante le lezioni, quando studieremo le questioni relative alla progettazione IS, presteremo particolare attenzione all'uso dell'Unified Modeling Language (UML) e poiché i suoi creatori sono Grady Booch e James Rumbaugh, ci rivolgeremo anche all'ideologia del processo di sviluppo unificato.

Figura - Documenti normativi che accompagnano il processo di sviluppo

Supportare i processi del ciclo di vita

Processo di garanzia della qualità

Processo di garanzia della qualità fornisce adeguate garanzie che il sistema software e i processi del suo ciclo di vita siano conformi ai requisiti specificati e ai piani approvati. La qualità del software è intesa come un insieme di proprietà che caratterizzano la capacità del software di soddisfare requisiti specificati.

Figura - Struttura dei processi del ciclo di vita ausiliario

Nel contesto di GOST R ISO/IEC 9126-93. "Tecnologie dell'informazione. Valutazione di prodotti software. Caratteristiche di qualità e linee guida per il loro utilizzo" per caratteristica di qualità si intende "un insieme di proprietà (attributi) di un prodotto software mediante le quali la sua qualità viene descritta e valutata".

Lo standard definisce sei caratteristiche complete che descrivono la qualità del software con duplicazioni minime:

• funzionalità– un insieme di attributi legati all'essenza dell'insieme di funzioni e alle loro proprietà specifiche. Le funzioni sono quelle che realizzano bisogni dichiarati o anticipati;
• affidabilità– un insieme di attributi relativi alla capacità del software di mantenere il proprio livello di prestazioni in condizioni specificate per un periodo di tempo specificato;
• praticità– un insieme di attributi relativi all'ambito di lavoro richiesto per l'uso e alla valutazione individuale di tale uso da parte di una gamma di utenti specificata o prevista;
• efficienza– un insieme di attributi relativi alla relazione tra il livello di qualità del funzionamento del software e la quantità di risorse utilizzate in condizioni specificate
• manutenibilità– un insieme di attributi relativi allo scopo del lavoro richiesto per effettuare cambiamenti specifici (modifiche);
• mobilità– un insieme di attributi legati alla capacità del software di essere trasferito da un ambiente all'altro.

GOST 28195-89 “Valutazione della qualità del software. Disposizioni generali" al livello superiore, primo, individua 6 indicatori - fattori di qualità: affidabilità, correttezza, facilità d'uso, efficienza, versatilità e manutenibilità. Questi fattori sono dettagliati collettivamente da 19 criteri di qualità al secondo livello. Ulteriore dettaglio degli indicatori di qualità è rappresentato da metriche ed elementi di valutazione, di cui sono circa 240. Si raccomanda che ciascuno di essi sia valutato da esperti in un intervallo da 0 a 1. Si propone di selezionare la composizione dei fattori, dei criteri e delle metriche utilizzate a seconda dello scopo, delle funzioni e delle fasi del ciclo di vita del software.

Lo standard GOST 28806-90 “Qualità del software. Termini e definizioni" vengono formalizzati i concetti generali di programma, strumento software, prodotto software e la loro qualità. Vengono fornite le definizioni dei 18 termini più comunemente utilizzati associati alla valutazione delle caratteristiche del programma. I concetti degli indicatori di qualità di base forniti in GOST 28195-89 sono stati chiariti.
La questione della garanzia della qualità del software richiede un'attenzione particolare, poiché secondo il governo della Federazione Russa n. 113 del 02/02/1998, il rispetto dei requisiti dello standard internazionale per la garanzia e la gestione della qualità ISO 9000 è un prerequisito per ricevere un ordine del governo.
Allo stato attuale non è sufficiente disporre solo di metodi per valutare la qualità del software prodotto e utilizzato (controllo dell’output); è necessario essere in grado di pianificare la qualità, misurarla in tutte le fasi del ciclo di vita del software e adeguarla il processo di produzione del software per migliorare la qualità.

Le norme della serie ISO 9000 sono troppo generiche. Ogni azienda che produce software e desidera implementare un efficace sistema di gestione della qualità basato sugli standard della serie ISO 9000 deve tenere conto delle specificità del proprio settore e sviluppare un sistema di indicatori di qualità che rifletta l'impatto reale dei fattori di qualità sul prodotto software. A tal fine, molte organizzazioni hanno istituito un processo di verifica separato, sistematico e completo, ovvero la garanzia della qualità, che inizia con il lancio del progetto, prevede ispezioni e test e, idealmente, è condotto da qualche organizzazione indipendente. In realtà, molto spesso, il controllo di qualità viene effettuato da un gruppo di colleghi dell'autore dell'opera.
Lo scopo dell'ispezione è verificare la presenza di difetti in parti del progetto:

• documentazione,
• requisiti,
• risultati dell'analisi,
• progetto,
• elenchi, ecc.

L'importanza dell'ispezione viene dimostrata confrontando il costo, il rilevamento e la correzione di un difetto durante l'ispezione e durante l'integrazione secondo Fagin, M., "Design and Code Inspections to Reduce Errors in Program Development", IBM Systems Journal. Alcuni autori ritengono che questi dati siano molto sottostimati.

La questione della ricerca dei difetti cominciò a essere presa molto più sul serio dopo che un satellite americano del valore di diversi miliardi di dollari, inviato su Venere, perse il controllo a causa di un errore di battitura nella subroutine di correzione della traiettoria: al posto della virgola fu inserito un punto e virgola.
La valutazione e il miglioramento della qualità vengono effettuati attraverso l'uso di metriche - caratteristiche quantitative di determinati indicatori di processo.

Per effettuare un sopralluogo sono necessari i seguenti passaggi:

1. Il processo di ispezione inizia con la pianificazione.È in fase di sviluppo una classificazione dei difetti per descrizione, gravità e tipologia. La selezione delle metriche in base alle quali verrà effettuata l'ispezione, la selezione degli strumenti per la raccolta e l'analisi dei dati ottenuti, nonché la distribuzione dei ruoli tra gli ispettori vengono effettuate:
   • Il leader è responsabile del corretto svolgimento dell'ispezione.
   • Il correttore di bozze è responsabile delle attività del team e le indirizza nella giusta direzione. Il correttore di bozze partecipa all'ispezione.
   • Il registrar è responsabile della registrazione della descrizione e della classificazione dei difetti, come è consuetudine nel team. All'ispezione partecipa anche il cancelliere.
   • Un ispettore specializzato è uno specialista in un campo ristretto a cui appartiene il frammento ispezionato.
2. Se necessario, può essere organizzato un seminario di revisione per comprendere meglio l'oggetto dell'ispezione.
3. Condurre un'ispezione. Gli ispettori controllano l'intero lavoro sul posto di lavoro (ad esempio, controllano se il codice del programma ispezionato corrisponde al progetto dettagliato). Gli ispettori in genere registrano tutti i difetti in un database (ad esempio accessibile tramite una rete) insieme a descrizioni e classificazioni. Le parti ispezionate del sistema devono essere logicamente complete.
4. Si tiene una riunione di ispezione durante la quale i partecipanti presentano i loro risultati.
5. L'autore corregge i difetti (fase di revisione).
6. Nell'incontro finale al termine del lavoro, il correttore di bozze e l'autore si assicurano che tutti i difetti siano stati corretti. Ciò tuttavia non implica una revisione dettagliata dell’intero lavoro da parte di un correttore di bozze. Tutte le correzioni restano di responsabilità dell'autore, che è responsabile del proprio lavoro.
7. Come per gli altri processi, il gruppo si riunisce per discutere il processo di ispezione stesso e decidere come migliorarlo.

L'azienda conserva registrazioni del tempo impiegato nelle ispezioni e della quantità di lavoro ispezionato per un ulteriore utilizzo nella valutazione di ispezioni future. In condizioni di rigorosi vincoli di tempo, il cosiddetto un sistema di “tutela” in cui ogni membro del team è accudito dal suo collega.
Per tenere conto di tutti i fattori di controllo della qualità, è conveniente utilizzare le liste di controllo. Tali elenchi contengono elementi che devono essere controllati in sequenza.
Ad esempio, il Software Quality Assurance Plan (SQAP) secondo lo standard IEEE 739-1989 specifica:

• chi sarà responsabile della qualità: un individuo, un manager, un gruppo, un'organizzazione, ecc.;
• quale documentazione è richiesta;
• quali metodi verranno utilizzati per garantire la qualità: ispezione, test, ecc.;
• quali attività dovrebbero essere svolte durante la gestione del processo: riunioni, audit, revisioni, ecc.

Affidabilità e sicurezza

Una delle caratteristiche più significative incluse nel concetto di qualità è la proprietà dell'affidabilità.
Secondo la definizione stabilita in GOST 13377-75 “Affidabilità nella tecnologia. Termini e definizioni”, l'affidabilità è la proprietà di un oggetto di eseguire funzioni specificate, mantenendo nel tempo i valori degli indicatori operativi stabiliti entro limiti specificati corrispondenti a modalità e condizioni specificate di utilizzo, manutenzione, riparazione, conservazione e trasporto. Pertanto, l'affidabilità è una proprietà interna del sistema, inerente al momento della sua creazione e manifestata nel tempo durante il funzionamento e il funzionamento.
L'affidabilità del funzionamento di una sottostazione è ampiamente caratterizzata dalla stabilità, ovvero dalla capacità di funzionare senza guasti, e dalla ripristinabilità di uno stato operativo dopo che si sono verificati guasti o guasti.
Il monitoraggio dell'affidabilità e della sicurezza dei programmi creati e modificati dovrebbe accompagnare l'intero ciclo di vita del software attraverso un efficace sistema tecnologico appositamente organizzato per garantirne la qualità. La verifica e la conferma della qualità del software complesso e critico deve essere assicurata dalla certificazione da parte di laboratori certificati orientati al problema.

Gli standard di sicurezza delle informazioni sono divisi in due gruppi:

• standard di valutazione progettati per valutare e classificare la proprietà intellettuale e le apparecchiature di sicurezza in base ai requisiti di sicurezza: lo standard del Dipartimento della Difesa degli Stati Uniti "Criteri per la valutazione di sistemi informatici affidabili", "Criteri armonizzati dei paesi europei", lo standard internazionale "Criteri per la valutazione della sicurezza delle tecnologie dell'informazione”, Documenti guida della Commissione tecnica statale della Russia;
• specifiche che regolano vari aspetti dell'implementazione e dell'uso di strumenti e tecniche di sicurezza, pubblicate dall'Internet Engineering Task Force (IETF) e dalle sue suddivisioni, il Security Working Group.

Gli standard di valutazione più significativi includono:

• Commissione tecnica statale della Russia. Documento guida. Strutture informatiche. Firewall. Protezione contro l'accesso non autorizzato alle informazioni. Indicatori di sicurezza contro l'accesso non autorizzato alle informazioni. – Mosca, 1997 – classifica i firewall in base al livello di filtraggio del flusso di dati del modello di riferimento a sette livelli.
• ISO/IEC 15408:1999 Criteri per valutare la sicurezza della tecnologia dell'informazione.

Il secondo gruppo comprende i seguenti documenti:

• X.800 “Architettura di sicurezza per l’interconnessione di sistemi aperti”. Vengono evidenziati i principali servizi di sicurezza della rete: autenticazione, controllo degli accessi, garanzia della riservatezza e/o dell'integrità dei dati. Per implementare i servizi sono previsti i seguenti meccanismi di sicurezza della rete e le loro combinazioni: crittografia, firma digitale elettronica, controllo degli accessi, controllo dell'integrità dei dati, autenticazione, aggiunta del traffico, controllo dell'instradamento, notarizzazione.
• La specifica Internet Community RFC 1510, Kerberos Network Authentication Service (V5), affronta il problema dell'autenticazione in un ambiente distribuito eterogeneo con il supporto al concetto di single sign-on alla rete;
• X.500 "Servizi di directory: una panoramica di concetti, modelli e servizi", X.509 "Servizi di directory: framework di certificati di attributi e chiavi pubbliche".

Processi di verifica, certificazione e audit

Verifica, qualificazione e audit sono parte integrante del piano di controllo qualità SQAP IEEE 739-1989.
La verifica risponde alla domanda: “Stiamo facendo ciò che abbiamo pianificato in questa fase?” La certificazione e l’audit rispondono alla domanda: “L’impianto in costruzione soddisfa le esigenze del cliente?”
Lo standard IEEE 1012-1986 Software Verification and Validation Plan (SVVP) combina i processi di certificazione e audit chiamati convalida e definisce il modo in cui vengono eseguiti.

Durante il processo di verifica vengono verificate le seguenti condizioni:

• la coerenza dei requisiti del sistema e il grado in cui vengono prese in considerazione le esigenze degli utenti;
• la capacità del fornitore di soddisfare i requisiti specificati;
• conformità dei processi del ciclo di vita PS selezionati con i termini del contratto;
• adeguatezza degli standard, delle procedure e dell'ambiente di sviluppo ai processi del ciclo di vita del PS;
• conformità delle specifiche di progettazione della sottostazione ai requisiti specificati;
• correttezza della descrizione nelle specifiche di progettazione dei dati di input e output, sequenza di eventi, interfacce, logica, ecc.;
• conformità del codice alle specifiche e ai requisiti di progettazione;
• testabilità e correttezza del codice, sua conformità agli standard di codifica accettati;
• corretta integrazione dei componenti software nel sistema;
• adeguatezza, completezza e coerenza della documentazione.

Processo di revisione congiunta

Processo di revisione congiunta ha lo scopo di valutare lo stato dei lavori su un progetto e si concentra principalmente sul monitoraggio della pianificazione e gestione delle risorse, del personale, delle attrezzature e degli strumenti del progetto.
La valutazione viene applicata sia durante la gestione del progetto che durante la realizzazione tecnica del progetto e viene effettuata durante tutta la durata del contratto. Questo processo può essere eseguito da due parti qualsiasi coinvolte nel contratto, con una parte che verifica l'altra.

Processo di risoluzione dei problemi

Processo di risoluzione dei problemi implica l'analisi e la risoluzione dei problemi (comprese le incongruenze rilevate), indipendentemente dalla loro origine o fonte, scoperti durante lo sviluppo, il funzionamento, la manutenzione o altri processi. Il processo di risoluzione dei problemi è strettamente correlato alla gestione del rischio. I fattori che portano al fallimento del progetto si manifestano sotto forma di rischi. La gestione del rischio consiste nell’identificazione, pianificazione dell’eliminazione, definizione delle priorità, eliminazione (o mitigazione).

Le ragioni per l’emergere di rischi possono essere le seguenti:

1. Formulazione dei requisiti poco chiara e/o incompleta;
2. Coinvolgimento insufficiente delle parti interessate nel progetto;
3. Scarsa pianificazione - mancanza di una gestione competente del progetto;
4. Frequenti cambiamenti nei requisiti causati da cambiamenti nell'ambito, negli obiettivi del progetto e per altri motivi;
5. Imperfezione della tecnologia di progettazione utilizzata;
6. Mancanza di conoscenze o competenze tra gli artisti.

Esistono due modi per prevenire i rischi:

1. apportare modifiche ai requisiti di progetto che eliminino la causa del rischio;
2. sviluppo di tecnologie che risolvano il problema associato all'emergere del rischio.

Durante il processo di gestione del progetto, il manager deve di volta in volta avviare il processo di identificazione dei rischi in varie parti del progetto al fine di compilare un elenco dei rischi in attesa di trattamento. Per ciascun rischio vengono determinati tre valori: la probabilità che il rischio si verifichi; danni causati al progetto da questo rischio se si verifica; stimare il costo per eliminare il rischio. Tutti i valori utilizzano la stessa scala, ad esempio 1 – 10.

Processo di gestione della documentazione e della configurazione

“La gestione della documentazione dei progetti software richiede notevoli sforzi organizzativi, perché... la documentazione è un sistema complesso, soggetto a continui cambiamenti che possono essere apportati contemporaneamente da più persone" (E.Braude)

Il processo di documentazione prevede una descrizione formalizzata delle informazioni create durante il ciclo di vita del PS. Questo processo consiste in un insieme di attività che pianificano, progettano, sviluppano, producono, modificano, distribuiscono e mantengono i documenti necessari a tutte le parti interessate (manager, specialisti tecnici e utenti del sistema).

GOST R ISO/IEC 9294-93. "Tecnologie dell'informazione. Software Documentation Management Guide" stabilisce raccomandazioni per una gestione efficace della documentazione software. Lo scopo dello standard è quello di assistere nella definizione di una strategia per la documentazione del software; scelta degli standard di documentazione; scelta delle procedure di documentazione; determinazione delle risorse necessarie; elaborazione di piani di documentazione.

Gestione documenti significa mantenerlo completo e coerente (alcuni autori includono qui la gestione della configurazione).

Completezza della documentazione caratterizzato dal numero di standard e documenti normativi che costituiscono la base dell'insieme di documentazione che accompagna un particolare processo nel ciclo di vita del software.
Coerenza della documentazione significa che l'insieme dei documenti non contiene contraddizioni interne. Ciò si ottiene collocando ciascuna specifica in un solo posto: questa è chiamata documentazione olistica. L'integrità della documentazione è garantita attraverso l'uso di collegamenti ipertestuali.

Ogni esigenza deve essere tracciabile Per raggiungere questo obiettivo, a ogni requisito viene assegnato un numero univoco, a cui viene poi fatto riferimento durante lo sviluppo del concetto, la progettazione e fino all'elenco dei metodi.

• // requisito 4.3
• // autore
• // versione
• // argomenti
• ...elenco dei metodi...

Le parti del progetto includono non solo il codice sorgente dei programmi, ma anche tutta la documentazione, compreso il piano del progetto. Nel corso della loro vita, i progetti subiscono cambiamenti in due direzioni:

• Innanzitutto, questa è l'acquisizione di nuove parti,
• In secondo luogo, ottenere nuove versioni di parti esistenti. Per tenere traccia correttamente di queste modifiche, viene utilizzato un insieme appositamente organizzato di procedure amministrative e tecniche relative al processo di gestione della configurazione.

Per tenere traccia delle parti di un progetto, è necessario definirne i confini e identificare gli elementi di configurazione (Configuration Items - CI). Gli elementi di configurazione possono essere classi, meno spesso funzioni, set di dati significativi: tabelle globali, documentazione. La contabilità dello stato della configurazione viene effettuata registrando lo stato dei componenti software, preparando rapporti su tutte le modifiche implementate e rifiutate delle versioni dei componenti software. Una serie di report fornisce una riflessione inequivocabile dello stato attuale del sistema e dei suoi componenti, oltre a mantenere una cronologia delle modifiche.
Esistono strumenti software speciali per la gestione della configurazione (ad esempio, Microsoft Visual SourceSafe, Microsoft Visual Studio Team Foundation Server, IBM Rational ClearCase, Subversion, ecc.).

In genere, i sistemi di gestione della configurazione soddisfano i seguenti requisiti minimi:

• la capacità di definire elementi di configurazione;
• memorizzare nel database di gestione della configurazione cronologie complete delle versioni di ciascun oggetto creato o modificato durante il processo di sviluppo del sistema (questo include codice del programma sorgente, librerie, programmi eseguibili, modelli, documentazione, test, pagine web e directory);
• supporto per team di sviluppo geograficamente remoti;
• negazione dei diritti di modifica per impedire a più di una persona di lavorare su un elemento di configurazione contemporaneamente;
• controllo delle modifiche apportate a tutti gli oggetti del sistema;
• assemblare versioni del software da componenti del progetto.

L'IEEE ha sviluppato lo standard IEEE 828-1990"Piano di gestione della configurazione software (SCMP)." Il titolo dello standard e un esempio di Piano di Gestione della Configurazione sono riportati nel libro di Eric Braude.

Figura - Documenti normativi dei processi del ciclo di vita ausiliari

Processi del ciclo di vita organizzativo

I processi organizzativi del ciclo di vita includono: il processo di creazione dell'infrastruttura, il processo di miglioramento, il processo di formazione, il processo di gestione.

Figura - Struttura dei processi del ciclo di vita organizzativo

Processo di creazione delle infrastrutture

è il processo di creazione e fornitura (mantenimento) dell'infrastruttura, che può contenere hardware e software, strumenti, metodologie, standard e condizioni per lo sviluppo, il funzionamento o la manutenzione. Nella 1a fase di creazione dell'infrastruttura viene effettuata la scelta di un sistema di supporto alla progettazione CASE, la scelta di un linguaggio di programmazione e di un DBMS; organizzazione dei servizi di supporto - amministratori di sistema, amministratori di rete, amministratori di database, segretarie, ecc.
Quando si risolve il problema della selezione utilizzando fonti letterarie, è necessario analizzare le capacità dei sistemi strumentali più comuni al fine di costruire una classificazione e quindi, all'interno di un determinato gruppo di classificazione, determinare i parametri in base ai quali verrà effettuata la selezione.
La stessa procedura di selezione prevede le seguenti fasi:

1. Vengono identificati gli indicatori di base del sistema selezionato, che sono significativi quando si progetta un determinato ACS, tenendo conto delle sue caratteristiche, limiti, risorse, ecc.
2. Tutti gli indicatori sono riassunti in una tabella (vedi Tabella 5), ​​nella quale, sulla base delle valutazioni degli esperti, a ciascun indicatore viene assegnato un coefficiente di peso Vi (ad esempio, da 1 a 10), che caratterizza la significatività di tale indicatore rispetto ad altri. La somma dei valori di tutti i coefficienti di ponderazione deve essere pari al limite superiore del coefficiente di ponderazione (ad esempio 10).
3. Utilizzando dati ottenuti da fonti letterarie e/o da esperti, per ciascun i-esimo indicatore per ciascun j-esimo sistema si determina il grado di utilità Ui,j (da 1 - minimo, a 10 - massimo). Ad esempio, un sistema di gestione della configurazione relativamente costoso potrebbe avere un punteggio di utilità pari a 1, mentre un sistema disponibile gratuitamente avrebbe un punteggio di utilità pari a 10.
4. Per ogni sistema jesimo confrontato, il valore della funzione di valutazione viene calcolato utilizzando la formula: Fj = V1 x U1,j + V2 x U2,j + …=Σ Vi x Ui,j
5. Sulla base del valore della funzione di valutazione, si giunge ad una conclusione sull'opportunità di utilizzare un particolare sistema in un dato progetto, tenendo conto dei criteri selezionati e delle restrizioni specificate. Il sistema per il quale il valore della funzione di valutazione è maggiore è il migliore in termini di scelta tra le alternative confrontate.

Processo di apprendimento

è il processo di erogazione della formazione iniziale e continua al personale. L'ordinazione, la consegna, lo sviluppo, il funzionamento e la manutenzione dei prodotti software dipendono in gran parte dalle qualifiche del personale. Pertanto, la formazione del personale deve essere pianificata ed effettuata in anticipo per prepararlo al lavoro relativo all'ordinazione, alla fornitura, allo sviluppo, al funzionamento o alla manutenzione di un progetto software.

Processo di miglioramento

è il processo di definizione, valutazione, misurazione, controllo e miglioramento di qualsiasi processo del ciclo di vita del software. Nella pratica ingegneristica, quando si sviluppa l'IS, vengono utilizzate metriche: caratteristiche quantitative di determinati indicatori.

Le metriche più comunemente utilizzate sono:

• la quantità di lavoro svolto, misurata in unità fisiche (ad esempio, il numero di righe di codice);
• tempo dedicato al lavoro;
• tasso di difetti (ad esempio, numero di difetti per 1000 righe di codice, numero di difetti per pagina di documentazione, ecc.).

I valori metrici preliminari o desiderati vengono previsti in anticipo e poi confrontati con i risultati ottenuti.
Poiché le metriche relative alla difettosità svolgono un ruolo speciale, ne elenchiamo alcune:

1. Il numero di difetti per mille righe di codice software identificati entro 12 settimane dalla consegna del progetto.
2. Scostamenti nella pianificazione in ciascuna fase: (Durata effettiva - Durata pianificata) / Durata pianificata.
3. Scostamenti nel costo: (Costo effettivo - Costo pianificato) / Costo pianificato.
4. Tempo totale di progettazione / Tempo totale di programmazione (secondo alcune stime dovrebbe essere almeno il 50%).
5. Il grado in cui i difetti compaiono e vengono rilevati in una determinata fase è uno dei parametri più semplici.

Quando i risultati del rilevamento dei difetti vengono confrontati con gli standard dell'organizzazione, viene valutato l'intero processo di creazione del sistema nel suo complesso, non solo un progetto specifico. I dati accumulati sui difetti in ciascuna fase vengono tabulati come mostrato, ad esempio, nella tabella.

Analisi della fase di “Formazione dei Requisiti”. mostra che il grado di rilevamento dei difetti è inferiore al normale in tutte le fasi del progetto. Sono stati riscontrati più difetti di progettazione immediatamente nella fase di produzione e meno difetti nelle fasi successive. In genere ciò si ottiene attraverso l'ispezione.

La sequenza di azioni che devono essere intraprese durante tutto il ciclo di vita del progetto per migliorarlo potrebbe, ad esempio, essere questa:

1. Identificare e definire le metriche che verranno utilizzate dal team in ogni fase, tra cui:
   • tempo dedicato alla ricerca, all'implementazione e all'analisi dei risultati;
   • dimensione (ad esempio, numero di righe di codice);
   • il numero di difetti rilevati nel modulo (ad esempio, numero di righe di codice) e l'origine del rilevamento del difetto;
   • valutazione della qualità su una scala da 1 a 10.
2. Documentare le informazioni ricevute in SQAP.
3. Raccogli le statistiche in ogni fase.
4. Assegnare gli sviluppatori responsabili della raccolta dei dati in ogni fase, ad esempio, "responsabile della qualità".
5. Pianificare le revisioni dei dati metrici che saranno utili in futuro. È necessario decidere in anticipo quali possono essere i valori delle metriche e quali devono essere. I dati ottenuti diventeranno la base per creare un database di progetti aziendali.

Modello di Maturità della Capacità Organizzativa

Il processo di miglioramento della tecnologia di creazione del software si riflette nei piani strategici dell'organizzazione, nella sua struttura, nelle tecnologie utilizzate, nella cultura sociale generale e nel sistema di gestione.
All’inizio degli anni ’90, l’American Software Engineering Institute (SEI della Carnegie Mellon University (Pittsburgh, Pennsylvania, USA)) ha formato un modello di maturità tecnologica delle organizzazioni CMM (Capability Maturity Model). Attualmente, in Occidente, una società di sviluppo incontra notevoli difficoltà nell'ottenere un ordine se non è certificata secondo CMM.
CMM è un materiale metodologico che definisce le regole per formare un sistema di gestione per la creazione e la manutenzione del software e metodi per il miglioramento graduale e continuo della cultura produttiva. Lo scopo del CMM è fornire alle organizzazioni di sviluppo le istruzioni necessarie sulla scelta di una strategia per migliorare la qualità dei processi analizzando il grado della loro maturità tecnologica e i fattori che maggiormente influenzano la qualità dei prodotti. Ad ogni livello del SMM vengono stabiliti dei requisiti il ​​cui adempimento garantisce la stabilizzazione degli indicatori di processo più significativi.

Processo di gestione

La gestione del progetto riguarda il raggiungimento di un equilibrio tra costi, capacità, qualità e pianificazione. Esistono diversi aspetti associati al processo di gestione del progetto: gestione del personale, pianificazione, stima dei costi del progetto.

Gestione personale

È noto che i dati empirici determinano il numero ottimale di membri del team.

Figura - Dipendenza dell'efficacia del team di sviluppo dalla sua composizione

Questa dipendenza porta alla necessità di utilizzare strutture di gestione gerarchiche

Figura - Struttura gestionale gerarchica

Nonostante il numero di collegamenti di ciascun dipendente sia soddisfacente, questi non partecipano alla formulazione del problema, il che viola uno dei requisiti principali dell'analisi del sistema: il numero massimo possibile di parti interessate dovrebbe partecipare alla discussione del problema .
Uno schema alternativo per organizzare un team di dipendenti è chiamato “team of equals”. In questo caso, tutti i membri del team si trovano allo stesso livello della gerarchia e i ruoli sono distribuiti tra loro. Inoltre, la distribuzione dei ruoli può cambiare dopo un certo periodo di tempo. Il problema di aumentare il numero delle comunicazioni in un grande progetto in questo caso viene risolto evidenziando il ruolo del responsabile della comunicazione esterna.

Nel concetto di programmazione estrema proposto da Kent Beck. l'accento è posto sul rapporto continuo tra sviluppatori e cliente (e il cliente viene reso uno dei partecipanti allo sviluppo), sul desiderio di semplificare radicalmente il processo di sviluppo del sistema e sulla programmazione in coppia. Inoltre, con la programmazione in coppia, gli sviluppatori lavorano insieme solo su un computer, a turno. Ciò implementa una forma di ispezione continua.

Preparazione di un programma

Esistono molti standard che descrivono la creazione e il mantenimento dei piani di gestione dei progetti software. Si consiglia di utilizzare il Software Project Management Plan (SPMP) IEEE 1058.1-1987. L'SPMP fornisce un programma che definisce come e quando le varie fasi del progetto dovrebbero essere completate. Al completamento di ogni successiva fase di progettazione, il programma deve essere integrato e adattato. La forma più comune per presentare la pianificazione di un progetto è un diagramma di Gantt.

Figura: visualizzazione approssimativa di un diagramma di Gantt

Si consiglia di includere nel piano periodi buffer in cui non è pianificata l'esecuzione di processi. Nella maggior parte dei casi, una pianificazione sotto forma di diagramma di Gantt viene creata utilizzando Microsoft Office Project.
Il processo di pianificazione del lavoro per l'attuazione di un progetto in particolare e la gestione del progetto in generale è associato alla stima del costo e della durata del progetto. Queste informazioni sono fornite nella sezione 5.4. L'SPMP “Assegnazione del budget e delle risorse” e, inoltre, una valutazione preliminare del costo del progetto possono influenzare la versione finale del contratto tra il cliente e l'appaltatore e pertanto devono essere effettuati prima della firma del capitolato d'oneri.

Stima dei costi per la realizzazione di un PS

Il processo di stima dell'intensità del lavoro, di norma, inizia contemporaneamente all'inizio del progetto e continua anche nella fase di scrittura del codice del programma.

Tra i metodi più comuni per valutare l’intensità del lavoro ci sono i seguenti:

• Modellazione algoritmica. Il metodo si basa sull'analisi dei dati statistici su progetti precedentemente completati e viene determinata la dipendenza dell'intensità di lavoro del progetto da alcuni indicatori quantitativi del prodotto software (di solito la dimensione del codice del programma). Questo indicatore viene valutato per un determinato progetto, dopodiché vengono previsti i costi futuri utilizzando il modello.
• Valutazioni di esperti. Viene condotto un sondaggio tra diversi esperti in tecnologia di sviluppo software che conoscono l'ambito di applicazione del prodotto software creato. Ognuno di loro fornisce la propria valutazione dell'intensità di lavoro del progetto. Quindi tutte le stime vengono confrontate e discusse.
• Valutazione per analogia. Questo metodo viene utilizzato se progetti simili sono già stati implementati in un determinato ambito di applicazione del software in fase di creazione. Il metodo si basa sul confronto del progetto pianificato con progetti precedenti che hanno caratteristiche simili. Utilizza dati esperti o dati di progetto memorizzati. Gli esperti calcolano una stima dell'impegno alto, basso e molto probabile in base alle differenze tra il nuovo progetto e i progetti precedenti.

Ciascun metodo di valutazione ha i suoi punti di forza e di debolezza, pertanto attualmente vengono utilizzati approcci che combinano metodi diversi.

La procedura per valutare l'intensità di lavoro dello sviluppo del software consiste nei seguenti passaggi:

1. stimare la dimensione del prodotto in fase di sviluppo;
2. valutazione dell'intensità del lavoro in mesi-uomo o ore-uomo;
3. stima della durata del progetto in mesi solari;
4. stima dei costi del progetto.

Le principali unità di misura della dimensione del software sono:

• numero di righe di codice (LOC – Lines of Code);
• punti funzione (FP – Punti Funzione).

Metodologia per la valutazione della dimensione funzionale

Metodologia per la valutazione della dimensione funzionale (FP – Punti Funzionali) consiste nel misurare uniformemente tutte le capacità di un'applicazione ed esprimere la dimensione dell'applicazione come un unico numero. Questo numero può quindi essere utilizzato per stimare il numero di righe di codice, il costo e la sequenza temporale del progetto.
Per calcolare la dimensione funzionale, vengono determinati il ​​rango e la complessità per ciascuna informazione caratteristica del sistema. L'International Function Point Users Group (IFPUG, www.ifpug.org) ha pubblicato criteri per identificare le caratteristiche delle informazioni, che sono divisi in cinque gruppi:

• – un gruppo riconosciuto dall'utente di dati logicamente correlati che si trova all'interno dell'applicazione e servito tramite input esterni.

• – un gruppo riconoscibile dall'utente di dati logicamente correlati che si trova all'interno e viene gestito da un'altra applicazione. Il file esterno di una determinata applicazione è un file logico interno in un'altra applicazione.

• – un processo elementare che sposta i dati dall’ambiente esterno all’applicazione. I dati possono provenire attraverso canali di comunicazione, dall'utente su una schermata di input o da un'altra applicazione. I dati possono essere utilizzati per aggiornare i file logici interni e possono contenere sia informazioni gestionali che aziendali. I dati di controllo non devono modificare il file logico interno (es. campi di inserimento dati, messaggi di errore, valori calcolati, pulsanti).

• – un processo elementare che sposta i dati calcolati in un'applicazione nell'ambiente esterno. Inoltre, durante questo processo è possibile che i file logici interni vengano aggiornati. I dati creano report o file di output che vengono inviati ad altre applicazioni. Report e file vengono creati in base a file logici interni e file di interfaccia esterni. Inoltre, questo processo può utilizzare dati di input che includono criteri di ricerca e parametri non supportati dai file logici interni. I dati di input provengono dall'esterno, ma sono temporanei e non archiviati in un file logico interno (ad esempio, campi dati nei report, valori calcolati, messaggi di errore).

• – un processo elementare che funziona sia con dati di input che di output, costituito da una combinazione richiesta-risposta, ma non associato al calcolo dei dati derivati ​​o all'aggiornamento dell'ILF. Il risultato sono i dati restituiti da file logici interni e file di interfaccia esterni. La parte di input del processo non modifica i file logici interni e la parte di output non trasporta i dati calcolati dall'applicazione (questa è la differenza tra una richiesta e un output). Ad esempio: elementi di input - campo utilizzato per la ricerca, clic del mouse; elementi visualizzati – campi visualizzati sullo schermo.

GOST R 56376-2015/IEEE C37.92(2005)

STANDARD NAZIONALE DELLA FEDERAZIONE RUSSA

Convertitori di misura elettrici

INGRESSI ANALOGICI DEI RELE' DI PROTEZIONE DA CONVERTITORI ELETTRONICI DI TENSIONE E CORRENTE

Trasduttori elettrici. Ingressi analogici per relè di protezione da trasduttori elettronici di tensione e corrente

OK 17.020

Data di introduzione 2016-01-01

Prefazione

Prefazione

1 PREPARATO dall'impresa unitaria dello Stato federale "Istituto panrusso di ricerca del servizio metrologico" (FSUE "VNIIMS") sulla base della propria traduzione in russo della versione inglese della norma specificata nel paragrafo 4

2 INTRODOTTO dal Comitato Tecnico per la Standardizzazione TC 445 “Metrologia di un’economia efficiente dal punto di vista energetico”

3 APPROVATO ED ENTRATO IN EFFETTO con Ordinanza dell'Agenzia federale per la regolamentazione tecnica e la metrologia del 27 marzo 2015 N 192-st

4 Questo standard è identico allo standard internazionale IEEE Standard C37.92(2005)* “IEEE Standard for analog input to Protective Relays” from Electronic Tension and Current Transducers", IDT).
________________
* L'accesso ai documenti internazionali e stranieri menzionati nel testo può essere ottenuto contattando l'Assistenza Clienti. - Nota del produttore del database.


Il nome di questo standard è stato modificato rispetto al nome dello standard internazionale specificato per renderlo conforme a GOST R 1.5-2012 (clausola 3.5).

Nell'applicazione della presente norma si consiglia di utilizzare, in luogo delle norme internazionali di riferimento, le corrispondenti norme nazionali, le cui informazioni sono riportate nell'appendice aggiuntiva SI

5 INTRODOTTO PER LA PRIMA VOLTA

6 REPUBBLICA. Aprile 2019

Le regole per l'applicazione di tale norma sono stabilite nell'art Articolo 26 della legge federale del 29 giugno 2015 N 162-FZ "Sulla standardizzazione nella Federazione Russa" . Le informazioni sulle modifiche a questo standard sono pubblicate nell'indice informativo annuale (dal 1 gennaio dell'anno corrente) "Norme nazionali" e il testo ufficiale delle modifiche e degli emendamenti è pubblicato nell'indice informativo mensile "Norme nazionali". In caso di revisione (sostituzione) o cancellazione della presente norma, il corrispondente avviso sarà pubblicato nel prossimo numero dell'indice informativo mensile "Norme Nazionali". Informazioni, avvisi e testi pertinenti sono anche pubblicati nel sistema di informazione pubblica - sul sito web ufficiale dell'Agenzia federale per la regolamentazione tecnica e la metrologia su Internet (www.gost.ru)

1 zona di utilizzo

1.1 Disposizioni generali

Questa norma specifica le caratteristiche dell'interfaccia tra sistemi di misurazione della tensione o della corrente, sensori ottici con uscite analogiche e relè di protezione appositamente progettati o altre apparecchiature di misurazione delle sottostazioni. Questi sistemi di misurazione producono forme d'onda proporzionali alle correnti e alle tensioni nella rete elettrica.

Questa norma specifica inoltre i requisiti per ulteriori combinatori intermedi o amplificatori di scala necessari per aggiungere o sottrarre segnali dalle uscite di più di un sensore di misurazione ottico quando si misura con un singolo relè o dispositivo di misurazione.

1.2 Obiettivi

Il segnale di misurazione normalizzato tra il sistema di misurazione e i sistemi di protezione a relè è un segnale elettrico analogico con un'ampiezza massima di ±11,3 V e una potenza massima di 3,2 mW.

Un esempio di sistema di misura con uscita elettronica analogica è un sistema ottico di trasformatori di tensione o corrente con interfaccia ottico-elettronica. La Figura 1 mostra una tipica configurazione degli elementi di un sistema ottico di misurazione della corrente in una sottostazione ad alta tensione. In questa configurazione i sensori ottici dei trasformatori di corrente si trovano sul bus ad alto potenziale. In altri casi, i sensori possono essere montati all'interno di un trasformatore di potenza o di un isolante. I segnali ottici vengono trasmessi attraverso cavi in ​​fibra ottica al potenziale di terra, dove vengono convertiti in segnali elettrici scalati e normalizzati utilizzati dai relè di protezione e da altri dispositivi elettronici intelligenti (IED).

Il modulo di conversione ottico-elettronico è solitamente situato nella sala di controllo generale della sottostazione, ma può anche essere posizionato vicino allo IED nel quadro. Questa norma specifica le caratteristiche dei segnali elettrici tra un modulo di conversione ottico-elettronico e un relè di protezione o altro IED che utilizza questi segnali. L'interfaccia tra i sensori ottici e il modulo di conversione è una soluzione tecnica proprietaria per la realizzazione di un sistema di misura di un produttore specifico, che non è soggetto a standardizzazione. Per una corretta interazione con apparecchiature esterne, è necessario normalizzare le caratteristiche dell'uscita del modulo di conversione, l'ingresso dei terminali di protezione del relè e una serie di altre funzioni di misurazione.

L'area contrassegnata nella Figura 1 mostra la posizione delle interfacce definite da questo standard.

Figura 1 - Sistema di misurazione della corrente ottica con interfaccia analogica standardizzata

2 Riferimenti normativi

Questo standard utilizza riferimenti normativi ai seguenti standard. Per i riferimenti datati vale solo l'edizione citata. Per quelli senza data, l'ultima edizione (compresi tutti gli emendamenti e le modifiche).

IEEE Std 525™, Guida IEEE per la progettazione e l'installazione di sistemi di cavi nelle sottostazioni
_______________
Le pubblicazioni IEEE possono essere acquistate presso l'Institute of Electrical and Electronics Engineers, Inc., 445 Hoes Lane, Piscataway, NJ 08854, USA (http://standards.ieee.org/).


IEEE Std 1050™, Guida IEEE per la messa a terra delle apparecchiature di strumentazione e controllo nelle stazioni di generazione

IEEE Std C37.90™, standard IEEE per relè e sistemi di relè associati ad apparecchi di alimentazione elettrica (relè e sistemi di relè utilizzati per proteggere e controllare dispositivi di alimentazione)

IEEE Std C37.90.1™, test standard IEEE di capacità di resistenza alle sovratensioni (SWC) per relè e sistemi di relè associati ad apparecchi di alimentazione elettrica (test per la resistenza alle sovratensioni di relè e sistemi di relè utilizzati per proteggere e controllare apparecchi di potenza)

IEEE Std C37.90.2™, standard IEEE per la capacità di resistenza dei sistemi relè alle interferenze elettromagnetiche irradiate dai ricetrasmettitori

IEEE Std C57.13™, requisiti standard IEEE per trasformatori di strumenti. Le pubblicazioni IEEE sono disponibili presso l'Institute of Electrical and Electronics Engineers, Inc., 445 Hoes Lane, Piscataway, NJ 08854, USA (http://standards.ieee.org/) (Instrument Transformer Requisiti)

3 Termini e definizioni

Nel presente standard vengono adottati i seguenti termini e definizioni. I termini non presentati in questo standard possono essere trovati nell'autorevole dizionario degli standard IEEE, settima edizione.

3.1 una unità relativa uno per unità (abbreviato: 1 p.u.): il valore di uscita misurato o l'uscita di un sistema di misurazione che corrisponde al valore misurato efficace primario nominale della tensione o della corrente nel circuito di misurazione.

3.2 ingresso relè(ingresso relè): l'ingresso elettronico analogico di qualsiasi terminale relè, contatore, dispositivo di misurazione o controllo o dispositivo elettronico intelligente conforme a questo standard.

3.3 sistema di misurazione(sistema di rilevamento): sensore elettronico, dispositivo, interfaccia ottico-elettronica o sorgente di segnale analogico che genera valori di tensione o corrente misurati in una rete elettrica, la cui uscita è conforme a questo standard.

4 Requisiti generali

4.1 Dispositivi di connessione

L'uscita del sistema di misurazione e l'ingresso del relè devono essere dotati di connettori standard comunemente disponibili in grado di resistere a sovratensioni ad alto potenziale in conformità con i requisiti di 4.4. I connettori devono essere progettati per consentire una facile connessione e terminazione del cavo. I terminali a vite sono la soluzione preferita. Ciascun ingresso o uscita include una coppia di terminali di segnale, etichettati secondo 4.3. Il fornitore dell'apparecchiatura dovrà fornire terminali o mezzi aggiuntivi senza messa a terra per il collegamento degli schermi in conformità alla clausola 7.

4.2 Isolamento galvanico da terra

Entrambi i terminali di uscita del sistema di misurazione e qualsiasi ingresso relè devono essere isolati dalla terra di protezione o dalla terra del telaio quando esposti a segnali CC o a frequenza di alimentazione. La capacità consentita tra qualsiasi terminale e terra non deve superare 0,01 µF.

4.3 Contrassegni di polarità e resistenza alla polarità inversa

Le interfacce devono avere contrassegni di polarità costituiti dai tradizionali "cts" e "vts". Vedere la norma IEEE C57.13.
_______________
Le informazioni sui collegamenti sono fornite nella sezione 2.


Per un'uscita sbilanciata di un sistema di misura, il terminale di uscita del segnale deve essere contrassegnato con l'apposito contrassegno di polarità o come terminale secondario X1 di un trasformatore di misura tradizionale.

Quando la corrente primaria della rete elettrica viene convertita in tensione all'uscita del sistema di misurazione, il valore di tensione positiva sul terminale con il segno di polarità corrispondente deve corrispondere alla direzione della corrente sul terminale primario con la polarità corrispondente cartello.

Ogni sistema di misura e ogni relè deve avere un'etichetta del produttore che attesti che è disponibile solo con polarità non reversibile o che può essere utilizzato con polarità inversa.

La polarità reversibile si riferisce a un ingresso o un'uscita completamente isolati o bilanciati che possono essere collegati in entrambe le polarità come specificato.

La polarità non reversibile si riferisce a un ingresso o un'uscita a filo singolo o sbilanciato (dove un conduttore viene utilizzato per trasportare il segnale e l'altro conduttore funge da conduttore di terra, come un cavo coassiale), che comporta il collegamento del conduttore del segnale solo a il terminale del segnale e il conduttore comune solo al terminale comune.

Tipicamente, un singolo segnale all'uscita di un sistema di misurazione viene ramificato in più relè o dispositivi che utilizzano questo segnale. Quando si effettua questo collegamento è necessario tenere conto di quanto segue:

- se uno o più ingressi di più relè hanno polarità non reversibile, non sempre l'utente sarà in grado di ottenere la polarità richiesta per collegare tutti i dispositivi, anche se la sorgente ha polarità inversa.

Nota - Le impostazioni interne o software di un particolare relè di protezione possono modificare la polarità dell'ingresso;


- se si utilizza la polarità reversibile per ogni ingresso di più relè, allora ogni relè può essere collegato con la polarità desiderata, anche se l'uscita della sorgente non è irreversibile.

Ciò aumenta la flessibilità nell'utilizzo di relè e altri dispositivi con ingressi a polarità inversa utilizzando le uscite analogiche del sistema di misurazione elettronico.

I terminali di uscita simmetrici o reversibili devono essere simmetrici rispetto alla terra.

4.4 Ulteriori risultati dei sistemi di misurazione

4.4.1 Uscita di avviso

Si tratta di un segnale aggiuntivo destinato a segnalare eventuali problemi del sistema di misura, che dovrebbe avvisare di eventuali malfunzionamenti, guasti o degrado delle caratteristiche, ad es. notificare la necessità di manutenzione o riparazione. Un segnale di questo tipo può ad esempio verificarsi in caso di guasto dell'alimentazione elettrica del sistema di misura.

Questa uscita deve essere un contatto di tipo "C", privo di potenziale e specificato dal produttore del sistema di misura. In condizioni di funzionamento normali, l'avvolgimento del relè (bobina) deve essere sempre eccitato per generare un allarme in caso di perdita di alimentazione, nonché in caso di guasto del sistema di misura.

4.4.2 Segnale in uscita della correttezza dei dati trasmessi

Si tratta di un segnale obbligatorio che deve riflettere i risultati di tutti i controlli interni durante l'autodiagnosi dell'elettronica del sistema di misura, la cui presenza significa che c'è un problema con il segnale di uscita analogico e questo può portare ad un funzionamento errato del relè collegati. Viene utilizzato anche per l'indicazione durante l'accensione e/o lo spegnimento, durante i quali il segnale di uscita del sistema di misura presenta grandi errori. I relè collegati potrebbero erroneamente utilizzare questo segnale per inibire l'intervento.

Questo output può assumere una o entrambe le seguenti forme:

- tipo di contatto "A", privo di potenziale e specificato dal produttore del sistema di misura. In condizioni operative normali e corrette, l'avvolgimento del relè (bobina) deve essere sempre eccitato per fornire un segnale o fornire un blocco di sicurezza per un segnale di uscita errato. Il contatto deve essere effettuato in conformità con IEEE Std C37.90. Il ritardo del blocco dell'uscita in caso di effetto trigger (rimbalzo del contatto) non deve superare i 12 ms;

- Il livello logico TTL (da 0 a 5 V) ha una risposta di 1 ms o più veloce (vedere 5.8). In questo caso il livello logico (5 V) indica la correttezza dei dati trasmessi.

4.5 Test di compatibilità elettromagnetica

I seguenti tipi di test vengono utilizzati per verificare le uscite del sistema di misurazione, gli ingressi e le uscite dei relè elettronici analogici compatibili che segnalano un guasto del sistema di misurazione e la correttezza dei dati trasmessi, nonché per verificare gli ingressi dei relè e i dispositivi intermedi descritti in clausola 6. Questo test si aggiunge ad altri test sulla capacità dei relè e dell'elettronica del sistema di misurazione di resistere alle condizioni dell'ambiente elettromagnetico circostante, i cui requisiti sono indicati nelle norme pertinenti.

4.5.1 Prove dielettriche

Queste prove devono essere condotte in conformità con i metodi di prova dielettrica descritti in IEEE Std C37.90. La tensione di prova viene applicata solo in modalità comune tra ciascuna coppia di terminali di ingresso o uscita e la terra di protezione o la terra del telaio. I circuiti di segnale fino a 50 V vengono testati alla tensione di prova dielettrica inferiore secondo IEEE Std C37.90.

5.1.1 Descrizione del segnale per il sistema di misurazione della corrente

Gamma dinamica: da 0,05 a 40 volte nominale;

Livello di uscita nominale (o 1 p.u.): 200 mV (rms);

Valore istantaneo massimo: 0,200x40x1,414 = 11,3 V (picco).

Gli errori di ampiezza e fase rappresentano la deviazione massima dal valore effettivo del segnale primario scalato a 50 o 60 Hz.

Tabella 1 - Descrizione del segnale per il sistema di misura della corrente

Il valore totale del fattore di distorsione non lineare deve essere inferiore o uguale all'errore di ampiezza.

Il rapporto segnale-rumore deve essere maggiore o uguale a 54 dB con un segnale maggiore di 0,1 p.u. La misura deve essere effettuata su un segnale a frequenza industriale e la larghezza di banda della misura del rumore deve essere compresa tra 120 Hz.

Il sistema di misura della corrente può essere dotato di un'uscita aggiuntiva nominalmente 2 Vrms a 1 p.u., con un valore massimo di uscita di 4 p.u. Questa uscita è destinata a quelle applicazioni in cui la precisione di misurazione richiesta è superiore a quella generalmente accettata. Per le applicazioni di misura fiscale, il produttore del sensore deve dimostrare separatamente la conformità con uno standard di precisione appropriato, come IEEE Std C57.13 o parti di esso.

5.1.2 Descrizione del segnale per sistemi di misurazione della tensione

Gamma dinamica da 0,05 a 2,0 volte il valore nominale.

Livello di uscita nominale (o 1 p.u.): 4 V (rms).

Potenza massima: 4,0 x 2,0 x 1,414 = 11,3 V (picco).

Gli errori di ampiezza e fase rappresentano la deviazione massima dal valore del segnale primario effettivamente scalato a 50 o 60 Hz.

Tabella 2 - Descrizione del segnale del sistema di misura della tensione

Il valore totale del fattore di distorsione non lineare deve essere inferiore o uguale al valore dell'errore.

Il rapporto segnale-rumore deve essere maggiore o uguale a 70 dB con un segnale maggiore di 0,85 p.u. Le misurazioni devono essere effettuate utilizzando un segnale a frequenza industriale e una larghezza di banda di misurazione del rumore di almeno 120 Hz.

Ciò si applica ai relè di protezione o alle applicazioni di misurazione per le quali la precisione sopra indicata è accettabile.

Per le applicazioni di misura fiscale, il produttore del sensore deve dimostrare separatamente la conformità agli standard di precisione pertinenti, come IEEE Std C57.13 o parti di essi.

5.2 Correzione di fase

Per ottenere una maggiore precisione, il produttore del sistema di misurazione può specificare un valore di correzione di fase alla frequenza industriale, il cui valore viene inserito come correzione di tutti i valori per ottenere una precisione maggiore rispetto a quella sopra specificata.

NOTA Ciò non elimina la necessità che il sistema di misura rispetti gli errori angolari sopra menzionati.

5.3 Carico nominale

La precisione del sistema di misura deve soddisfare i requisiti di questa norma quando si collega un carico di circa 5 kOhm e un carico capacitivo fino a 5 nF. Un'uscita di un sistema di misura può essere collegata in parallelo a più relè o altri dispositivi di misura. Il relè o altro dispositivo collegato deve avere un'impedenza di ingresso di almeno 50 kOhm, ma non superiore a 200 kOhm.

5.4 Riduzione di modo comune

L'attenuazione di modo comune per gli ingressi e le uscite del circuito di misura deve essere maggiore di 86 dB a 50 o 60 Hz per un segnale di modo comune fino a ±50 V. Questo valore è specificato per disturbi di tensione di 20 V all'ingresso della misura di corrente sistema al quale il valore corrente è 0,5 p.u. e quando il rumore di tipo comune è inferiore al 10% del livello del segnale misurato.

5.5 Deviazione del segnale di uscita dalla zona zero

La deviazione stazionaria del segnale di uscita dalla zona zero (spostamento della componente CC del segnale di uscita) deve essere inferiore a 3 mV. Ciò si riferisce ai requisiti dell'elettronica DC all'uscita dell'amplificatore, ma non si applica al decadimento esponenziale dei segnali di corrente di guasto "DC offset".

La deviazione allo stato stazionario del segnale di uscita dalla zona zero dell'amplificatore deve essere inferiore a 3 mV. Ciò si riferisce alle caratteristiche elettroniche con una componente di corrente continua a lungo termine all'uscita dell'amplificatore, ma non è correlato al decadimento esponenziale del "segnale di offset CC" per i segnali di corrente di cortocircuito.

5.6 Larghezza di banda e risposta ai transitori

Il fornitore del sistema di misura deve specificare la risposta in frequenza. La deviazione della frequenza di rete (frequenza di rete) specificata in 5.1 deve essere compresa tra 45 e 65 Hz. La risposta dovrebbe essere almeno da 0 a -1 dB fino a 3 kHz e da 0 a -3 dB fino a 5 kHz. La frequenza di taglio inferiore (se presente) deve essere impostata in modo tale che il sistema possa soddisfare il seguente requisito per una risposta di offset del segnale costante.

Per compensare completamente la risposta al decadimento esponenziale della corrente primaria ("offset del segnale costante") con un valore di 20 p.u. L'errore istantaneo del fattore di scala non deve superare il 10% per qualsiasi costante di tempo fino a 100 ms.

Per la tensione primaria, la risposta transitoria è determinata dalla risposta ad un impulso a gradino, cioè modificando a zero il valore della forma dell'impulso all'interno dell'intervallo, mentre il segnale all'uscita del sistema di misurazione dovrebbe diminuire ad un livello inferiore al 10% del suo valore iniziale entro un tempo di 4 ms e scendere al di sotto del 10% solo dopo questa volta.

Alcuni clienti potrebbero richiedere il funzionamento del sistema per frequenze nell'intervallo compreso tra 65 e 75 Hz con requisiti di precisione ridotti. Si raccomanda al fornitore del sistema di misurazione di definire i requisiti per le caratteristiche tecniche del suo funzionamento in questo intervallo di frequenza.

5.7 Impostazione del rilevamento del segnale di errore

L'uscita dell'interfaccia del sistema di misurazione deve essere bloccata su zero quando viene rilevato un guasto interno per evitare di causare problemi gravi o falsi allarmi. Ciò è garantito dall'alimentazione di riserva del sistema di misura o dallo spegnimento durante le condizioni transitorie. Il tempo che intercorre tra l'identificazione del problema e la sua risoluzione non dovrebbe essere superiore a 0,2 ms.

Tipicamente, l'identificazione del problema viene effettuata utilizzando lo stesso metodo utilizzato per il rilevamento degli errori, come avviene durante il controllo di correttezza per la trasmissione dei dati dall'output, descritto in 4.4.2.

5.8 Descrizione del segnale per la correttezza dei dati trasmessi

Il segnale opzionale che trasmette le informazioni sulla validità dei dati 4.4.2 deve essere un segnale di livello TTL (0 o 5 V), isolato dalla terra di protezione e destinato ad essere trasmesso utilizzando lo stesso metodo di connessione utilizzato per la trasmissione dei segnali del sistema di misurazione analogico (vedere la sezione 7). Un'unità logica da 3,0 a 5,5 V informa della presenza di dati corretti all'uscita del sistema di misura. Uno zero logico nel campo da 0 a 0,5 V dovrebbe indicare un errore nei dati all'uscita del sistema di misura. L'uscita di questo segnale opzionale deve essere in grado di fornire tensioni entro le specifiche specificate in impedenze di carico di 200 ohm o superiori. Il ritardo dall'evento di attivazione al cambiamento dello stato dell'uscita non deve superare 1 ms.

I circuiti di ingresso nel relè di protezione per ricevere questo segnale devono essere isolati dalla terra di protezione e avere una resistenza di ingresso superiore a 2 kOhm. In questo caso, solo i segnali con un livello superiore a 2,5 V dovrebbero essere percepiti come un'unità logica.

6 Dispositivi intermedi

6.1 Scopo

I dispositivi intermedi possono essere utilizzati per creare la somma o la differenza dei singoli risultati dei sistemi di misurazione. Possono essere utilizzati anche per isolare gli ingressi di diversi tipi di relè o contatori collegati ad un'unica uscita del sistema di misura. I dispositivi intermedi possono avere un guadagno unitario o possono includere la messa in scala dei singoli ingressi per modificare il guadagno del sistema di misurazione.

I dispositivi intermedi possono essere utilizzati anche per abbinare le uscite dei tradizionali trasformatori di misura con le uscite di un sistema elettronico di misura. I requisiti operativi definiti in questa sezione si applicano solo ai dispositivi intermedi con uscite elettroniche analogiche.

6.2 Requisiti prestazionali per i dispositivi intermedi

La precisione, la larghezza di banda e il rapporto segnale-rumore dei dispositivi intermedi devono essere molto migliori rispetto ai sistemi di misurazione stessi. Di seguito sono riportati i requisiti per i dispositivi intermedi.

Tabella 3 – Requisiti prestazionali intermedi del dispositivo

I requisiti prestazionali dell'amplificatore devono essere soddisfatti insieme ai connettori di ingresso e di uscita. I requisiti prestazionali devono essere determinati al guadagno unitario. Il produttore deve specificare le caratteristiche prestazionali con guadagno non unitario.

6.3 Altri requisiti per i dispositivi intermedi

I dispositivi intermedi devono essere conformi a tutti gli altri requisiti delle sezioni 4 e 5, ma non a quelli specificati al punto 6.2. Devono soddisfare i requisiti compresi nell'intervallo di condizioni operative, di trasporto e di stoccaggio specificate in IEEE Std C37.90.

7 Istruzioni per l'installazione dei dispositivi intermedi

Le figure 2, 3 e 4 mostrano esempi di collegamento per sorgenti e carichi singoli e multipli. Vengono presentati per illustrare i collegamenti appropriati per distanze inferiori a 50 m tra il sistema di misurazione e l'ingresso relè più distante. I conduttori intrecciati schermati vengono solitamente installati all'interno del centro di controllo generale della sottostazione, dove la differenza tra i potenziali zero dei sistemi collegati quando si verifica un cortocircuito non supera i 20 V. I conduttori con una sezione trasversale di 24 AWG e maggiore sono abbastanza accettabile per questi scopi. Se più doppini intrecciati sono racchiusi in uno schermo comune, l'influenza reciproca tra i canali durante la connessione differenziale non deve superare il livello di 70 dB.

Dovresti prestare attenzione alle seguenti caratteristiche principali, comuni a tutti i disegni:

- la connessione cablata presuppone che l'apparecchiatura abbia superato il test di reiezione di modo comune specificato nella sezione 4 e che il rapporto di reiezione di modo comune specificato nella sezione 5 sia noto;

- nessuno dei conduttori twistati di segnale è in nessun punto collegato a terra;

- solo un'estremità dello schermo, solitamente il lato relè o l'estremità ricevente della connessione, è direttamente messa a terra. Per sistemi di misurazione multipli e/o installazioni di relè multipli, viene definito un unico punto di messa a terra dello schermo. Questa messa a terra fornisce solo schermatura elettrostatica, non schermatura magnetica alla frequenza di alimentazione. Per fornire un solo punto di messa a terra per più relè, gli schermi possono essere collegati a margherita fornendo allo stesso tempo un singolo punto di messa a terra;

- tenere presente che qualsiasi sistema di misurazione o relè con polarità single-ended o non reversibile che abbia una connessione interna all'uscita comune o non polarizzata dell'interfaccia di terra di sicurezza può causare problemi di segnale o compromettere la sicurezza dell'isolamento di altri dispositivi;

Figura 2 – Un sistema di misurazione e un ingresso relè

Figura 3 – Un sistema di misurazione con più ingressi relè

Figura 4 – Sistemi di misura multipli e dispositivo intermedio

- Per fornire una migliore schermatura elettromagnetica ad alta frequenza, è possibile installare ulteriori condensatori a disco ceramici da 10 nF tra la schermatura e la terra in ciascun punto di connessione della schermatura senza messa a terra. Possono essere installati dall'utente o posizionati all'interno delle apparecchiature dei produttori. Si tenga presente che l'installazione di tali condensatori è generalmente accettabile per cavi di controllo corti, ma costituisce un problema per la schermatura ad alta frequenza di cavi di controllo più lunghi.

Per collegare apparecchiature di commutazione situate in un quadro esterno, dove non esistono condizioni favorevoli per una schermatura elettromagnetica ad alta frequenza di alta qualità, il cliente deve studiare più attentamente gli schemi di schermatura, la messa a terra degli schermi e l'isolamento degli elementi. Vedere lo standard IEEE 525.

In questo caso, è necessario uno schermo esterno affidabile aggiuntivo, collegato a terra su entrambe le estremità, per eliminare l'influenza delle correnti indotte dai campi magnetici ed elettromagnetici di frequenza industriale negli schermi a doppino intrecciato sui segnali di misurazione di basso livello. In questo caso, la sorgente del segnale elettronico dovrà essere isolata dal potenziale di terra.

Appendice A (per riferimento). Utilizzo sicuro

Appendice A
(Informativo)

Esistono differenze significative nel funzionamento tra i moderni sistemi di misura elettronici analogici e i tradizionali sistemi di misura passivi con trasformatori di misura.

Nuove e particolarmente importanti per la loro applicazione sono le caratteristiche nella regione delle basse frequenze, i processi transitori all'accensione e allo spegnimento del sistema, la risposta alle condizioni transitorie della rete elettrica, i ritardi di fase, la risposta alle condizioni transitorie della rete elettrica, i ritardi di fase, l'uscita capacità di carico, anomalie e segnalazioni di emergenza, taratura. Il contrasto tra interfacce analogiche e digitali è in discussione.

A.1 Risposta in ampiezza-frequenza nella regione delle basse frequenze

I tradizionali convertitori con nucleo in ferro rispondono alle basse frequenze finché il dispositivo non viene saturato con corrente alternata oltre un certo limite di volt per hertz. Cioè, solo i livelli di segnale molto bassi vengono riprodotti da tali convertitori senza distorsioni alle basse frequenze. La saturazione avviene improvvisamente durante il mezzo ciclo corrente, con il segnale di uscita che scompare completamente e improvvisamente finché la polarità non viene invertita. I sistemi di misurazione elettronici analogici specificati in questo standard, d'altro canto, possono avere un'attenuazione a bassa frequenza o potrebbero perdere completamente la componente CC del segnale. L'inclusione di un filtro passa-basso può portare a transitori vari e imprevedibili per i quali i relè e altri sistemi di misurazione ad alta velocità non sono progettati. I fenomeni specifici includono: spostamento del punto di riferimento, risposta imprecisa a caratteristiche transitorie che decadono esponenzialmente (comparsa di una tensione di polarizzazione costante) e processo oscillatorio smorzato a bassa frequenza come risposta alle caratteristiche transitorie di ingresso.

I progettisti di relè devono valutare l'effetto dei componenti a bassa frequenza sugli algoritmi di misurazione, e in particolare su quelli specificatamente progettati per il funzionamento con offset CC spesso riscontrati con correnti di guasto. La precisione specificata in 5.6 include i requisiti per il funzionamento con polarizzazione CC.

A.3 Risposta al gradino

La modalità transitoria o la risposta transitoria può variare in modo abbastanza significativo a seconda della larghezza di banda della frequenza, sebbene sia strettamente correlata alle corrispondenti caratteristiche di filtraggio passa-alto nell'elettronica del sistema di misurazione. Cortocircuiti e commutazioni provocano un superamento dell'uscita positiva o negativa e possibilmente oscillazioni ad alta frequenza smorzate.

L'utente dovrebbe verificare la risposta del relè a queste distorsioni. Tenere presente che picchi positivi o negativi possono causare il funzionamento non corretto dei relè ad alta velocità.

È inoltre necessario sapere che nei circuiti differenziali ad alta velocità a banda larga esistono differenze nelle caratteristiche di trasferimento di sistemi di misura di diverse generazioni, di diversi produttori, che possono anche portare a valori di uscita errati e diversi e portare ad una ridotta affidabilità o anche falsi positivi.

Potrebbero non sorgere problemi se la frequenza di taglio del filtro antialiasing (filtro antialiasing - per eliminare gli effetti di aliasing (durante il campionamento) del relè di protezione del microprocessore collegato è tre o più volte inferiore alla larghezza di banda del sistema di misurazione e alle distorsioni di frequenza esistenti .

Va notato che 5.6 include le caratteristiche transitorie del sistema di misurazione, determinate dalla risposta a un impulso a gradino.

A.4 Ritardo di fase

Il ritardo del valore primario misurato nella rete elettrica prima che il sistema di misurazione presenti questo valore ai sistemi di relè collegati può essere breve rispetto all'intervallo di tempo di misurazione e a prima vista insignificante. Tuttavia, questo può rappresentare un problema serio per qualsiasi relè o sistema di misura che confronti due grandezze provenienti da due diversi tipi di sistemi di misura. Il confronto della corrente differenziale è un buon esempio di dove i circuiti ad alta velocità sono sensibili alla differenza nei ritardi di fase tra due sistemi di misurazione. I relè distanziometrici e direzionali, e in particolare i contatori di energia commerciali, possono avere problemi perché devono corrispondere accuratamente alle relazioni tra tensioni e correnti.

I sistemi di misurazione della tensione utilizzano metodi diversi rispetto alla misurazione della corrente senza garantire che i ritardi nella misurazione dei segnali di corrente e tensione primaria siano identici.

La sezione 5.2 descrive un'opzione aggiuntiva per selezionare la correzione di fase fornita dal produttore.

A.5 Capacità di carico

La modalità di uscita in tensione del sistema di misura deve essere in grado di fornire corrente all'intero carico collegato, considerato come un gruppo parallelo di ingressi. L'aumento del carico può portare al deterioramento della precisione di generazione del segnale ed è determinato dall'impedenza della sorgente, ma i segnali di uscita possono comunque essere utilizzati in molte applicazioni. Si può tracciare un parallelo con l'influenza dei carichi sui tradizionali trasformatori di corrente e tensione (TA e TV).

A.6 Guasti e allarmi

I progettisti devono essere in grado di determinare in particolare la modalità di guasto dei componenti elettronici e valutare l'impatto di eventi come danni, rotture o crepe nel cavo in fibra ottica. È impossibile evitare tutti i problemi, ma esistono misure di sicurezza aggiuntive per prevenirne alcuni.

A questo proposito il progettista può aiutare fornendo dati sulle elevate prestazioni dei sistemi di automonitoraggio in grado di rilevare lo smorzamento o la soppressione del segnale di uscita. Si noti che il segnale di uscita smorzato può interferire con il relè di protezione differenziale, provocando un falso intervento a meno che non venga utilizzato un ulteriore segnale di dati non validi per inibire lo scatto. La perdita di tensione sul relè remoto causerà un funzionamento errato o innescherà la perdita di potenziale logica (se utilizzata), che limiterà notevolmente le capacità di protezione.

La capacità di un sistema di misurazione di autodiagnosticare problemi minori e di emettere allarmi non di emergenza, senza soppressione o blocco, offre al personale di manutenzione la prospettiva di risolvere un problema prima che causi conseguenze negative. Una porta di comunicazione dati in grado di segnalare la diagnostica specifica tramite un modem o una porta WAN aumenta la probabilità che i tecnici addetti alle riparazioni arrivino con le parti e le apparecchiature corrette.

A.7 Calibrazione

Il fornitore è tenuto a formare l'utente sulle modalità con le quali viene effettuata e successivamente mantenuta la taratura iniziale del sistema di misura. In particolare, assicurarsi che l'IED fornito abbia le caratteristiche che possono essere richieste per eseguire la procedura di taratura.

Il fornitore del sistema di misurazione deve istruire il cliente su cosa fare con la calibrazione del sistema quando si sostituisce un modulo di conversione elettronico difettoso.

A.8 Interfacce digitali

Questo standard copre solo le interfacce analogiche di basso livello, comprese quelle integrate in sistemi di grandi dimensioni che dispongono di interfacce dati digitali e dove l'interoperabilità per le interfacce analogiche è importante sia per i produttori che per gli utenti.

Le interfacce digitali richiedono la specifica dei processi di campionamento, delle prestazioni e dei livelli del protocollo di comunicazione multistrato per la comunicazione tra il sistema di misurazione e il relè. Le interfacce dati digitali per fornire informazioni sulla rete elettrica sono fornite nelle norme IEC 61850-9-1, IEC 61850-9-2, IEC 60044-7 e IEC 60044-8.

Appendice SI (richiesto). Informazioni sulla conformità delle norme internazionali di riferimento con le norme nazionali

Applicazione SI
(necessario)

Tabella DA.1

Bibliografia

IEEE P1331 Draft 8.3, aprile 1999: standard di prova per ingressi di segnali analogici a bassa energia per relè di protezione

Testo del documento elettronico
preparato da Kodeks JSC e verificato rispetto a:
pubblicazione ufficiale
M.: Standardinform, 2019

Lezione 3

Ciclo di vita del software

Concetti di base coinvolti nella definizione del ciclo di vita

Processo di sviluppo

Processo di sviluppo

10. Analisi dei requisiti di sistema

11. Analisi dei requisiti software

12. Progettazione dell'architettura software

13. Progettazione dettagliata del software (piano di lavoro di sviluppo del software)

14. La codifica e il test del software implicano la risoluzione dei seguenti compiti:

15. Integrazione del sistema

16. Test di qualificazione del software

17. Installazione e accettazione del software

18. Funzionamento del software

19. Manutenzione software (secondo lo standard IEEE – 90)

20. Supportare i processi del ciclo di vita del software

21. Processo di documentazione

22. Gestione della configurazione

23. Processo di garanzia della qualità

24. Verifica

25. Certificazione

26. Processi organizzativi del ciclo di vita del software

27. Gruppi di norme DGUE

28. Elenco dei documenti DGUE

29. Vantaggi derivanti dall'utilizzo degli standard DGUE

30. Svantaggi delle norme DGUE

31. Standard GOST 34.601-90: fasi e fasi della creazione di un sistema automatizzato

32.