Ciclo di vita dei sistemi software. Processi del ciclo di vita del software Istruzioni per l'installazione del dispositivo intermedio

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.

Scopi e obiettivi della metodologia di progettazioneDI. Principali aree di progettazioneDI. Fasi della creazioneDI.

Software (Software) è un prodotto intelligente, indipendente dal supporto su cui è registrato, inclusi programmi, regole e dati associati, che, quando caricato nell'area di esecuzione di un programma per computer, ne garantisce il funzionamento.

Software (Prodotto software) - un insieme di programmi informatici, procedure ed eventualmente documentazione e dati associati.

Software (Prodotto software) - qualsiasi insieme di programmi informatici, procedure, documentazione e dati associati ottenuti come risultato dello sviluppo del software e destinati ad essere consegnati all'utente [ISO/IEC 12207]. Nota. I prodotti includono prodotti intermedi e prodotti destinati a utenti quali sviluppatori e personale di manutenzione.

Sviluppo software L'ingegneria del software è una forma di sviluppo che applica i principi dell'informatica, della tecnologia dell'informazione, della matematica e della scienza applicativa per ottenere soluzioni economicamente vantaggiose a problemi pratici attraverso il software.

Progettazione del software è il processo di creazione di applicazioni di dimensioni reali e rilevanza pratica che soddisfano specifici requisiti di funzionalità e prestazioni.

Programmazione - è una delle attività comprese nel ciclo di sviluppo del software.

Fasi della creazione del software

1. Comprendere la natura e la portata del prodotto proposto.

2. Selezionare un processo di sviluppo e creare un piano.

3. Raccogliere i requisiti.

4. Progettare e assemblare il prodotto.

5. Eseguire il test del prodotto.

6. Rilasciare il prodotto e fornire il suo supporto.

Per ciclo di vita di un programma intendiamo un insieme di fasi:

Analisi dell'area tematica e creazione di specifiche tecniche (interazione con il cliente)

Progettare la struttura del programma

Codifica (insieme di codici di programma secondo la documentazione del progetto)

Test e debug

Attuazione del programma

Supporto al programma

Disposizione

Il concetto di ciclo di vita del software (LC). Definizione del ciclo di vita secondo lo standard internazionale ISO/IEC 12207:1995. Processi di base del ciclo di vita del software.

Il ciclo di vita del software è un processo continuo che inizia dal momento in cui viene presa la decisione sulla necessità di crearlo e termina quando viene completamente rimosso dal servizio.

Il ciclo di vita (LC) del software è definito come un periodo di tempo che inizia dal momento in cui viene presa la decisione sulla necessità di creare software e termina nel momento in cui viene completamente rimosso dal servizio.

Il principale documento normativo che regola la composizione dei processi del ciclo di vita del software è lo standard internazionale ISO/IEC 12207: 1995 “Information Technology - Software Life Cycle Processes” (ISO - International Organization for Standardization, IEC - International Electrotechnical Commission - International Commission for Standardization) Ingegneria elettrica Definisce la struttura del ciclo di vita contenente i processi, le azioni e i compiti che devono essere eseguiti durante la creazione del software.

In questa norma Software (o prodotto software)è definito come un insieme di programmi informatici, procedure ed eventualmente documentazione e dati associati.

Processiè definito come un insieme di azioni interconnesse (un insieme di lavori interconnessi) che trasformano alcuni dati iniziali (dati di input) in output (risultati). Ogni processo è caratterizzato da determinati compiti e metodi per risolverli, dati di input ottenuti da altri processi e risultati.

Ogni processi suddiviso in una serie di azioni, ciascuna azione– per set compiti. Ogni processo, azione o attività viene avviato ed eseguito da un altro processo secondo necessità e non esistono sequenze di esecuzione predeterminate (ovviamente mantenendo le connessioni tra i dati di input).

Processi fondamentali del ciclo di vita :

Ordine (acquisto);

Azione: avvio dell'acquisizione

Azione – preparazione delle proposte di offerta

Azione - preparazione e adeguamento del contratto

Azione - supervisione delle attività dei fornitori

In corso accettazione vengono preparati ed eseguiti i test necessari. Completamento del lavoro previsto dal contratto viene eseguito se tutte le condizioni di accettazione sono soddisfatte

Fornitura;

Inizio della consegna

Pianificazione

Sviluppo;

Il processo di sviluppo coinvolge le attività e i compiti svolti dallo sviluppatore e include quanto segue:

Lavoro preparatorio

Analisi dei requisiti di sistema

Progettazione dell'architettura del sistema ad alto livello consiste nell'identificare i componenti del suo hardware, software e le operazioni eseguite dal personale che utilizza il sistema. L'architettura del sistema deve essere conforme ai requisiti di sistema e agli standard e alle pratiche di progettazione accettati.

Analisi dei requisiti software

Progettazione dell'architettura del software

Codificazione e test del software

Integrazione del software

Test di qualificazione del software

Integrazione del sistema

Installazione software

Accettazione del software

Sfruttamento; copre le azioni e i compiti dell'operatore - l'organizzazione che gestisce il sistema e comprende le azioni:

Lavoro preparatorio comprende l'operatore che svolge le seguenti attività:

pianificare le attività e il lavoro svolto durante il funzionamento e definire gli standard operativi;

determinazione delle procedure per localizzare e risolvere i problemi che insorgono durante il funzionamento.

Test delle prestazioni viene effettuato per ogni edizione successiva del prodotto software, dopodiché viene messo in funzione.

Operazione di sistema

Supporto utente

Processiscorta prevede le azioni e i compiti svolti dal servizio di supporto. In conformità con lo standard IEEE-90 sotto accompagnamento si riferisce ad apportare modifiche al software per correggere errori, migliorare le prestazioni o adattarsi a condizioni o requisiti operativi mutevoli.

Lavoro preparatorio i servizi di supporto comprendono le seguenti attività:

pianificare le azioni e il lavoro svolto durante il processo di supporto;

determinazione delle procedure per localizzare e risolvere i problemi che insorgono durante il processo di manutenzione.

Analisi delle problematiche e richieste di modifiche software

Modifica del software

Ispezione e accettazione

Dismissione del software effettuato a discrezione del cliente con la partecipazione dell'organizzazione operativa, del servizio di supporto e degli utenti. In questo caso i prodotti software e la relativa documentazione sono soggetti ad archiviazione conformemente all'accordo.

Il concetto di ciclo di vita del software (LC). Definizione del ciclo di vita secondo lo standard internazionale ISO/IEC 12207:1995. Processi ausiliari del ciclo di vita del software.

Vedi punto 2

Processi ausiliari del ciclo di vita :

Documentazione; una descrizione formalizzata delle informazioni create durante il ciclo di vita del software.

Il processo di documentazione comprende i seguenti passaggi:

lavoro preparatorio;

Design e sviluppo;

rilascio della documentazione;

accompagnamento

Gestione della configurazione a lei; 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 la completezza, compatibilità e correttezza del software, gestire l'archiviazione e la consegna del software. Secondo lo standard IEEE-90 configurazione Per software si intende l'insieme delle sue caratteristiche funzionali e fisiche stabilite nella documentazione tecnica e implementate nel software.

lavoro preparatorio

identificazione della configurazione stabilisce regole che possono essere utilizzate per identificare e distinguere chiaramente i componenti software e le loro versioni

controllo della configurazione è inteso per una valutazione sistematica delle modifiche software proposte e della loro implementazione coordinata, tenendo conto dell'efficacia di ciascuna modifica e dei costi della sua implementazione

contabilità dello stato della configurazione (rappresenta la registrazione dello stato dei componenti software, la preparazione di rapporti su tutte le modifiche implementate e rifiutate delle versioni dei componenti software). + cronologia delle modifiche

valutazione della configurazione (consiste nel valutare la completezza funzionale dei componenti del software, nonché la rispondenza del loro stato fisico alla presente descrizione tecnica);

gestione dei rilasci e fornitura (copre la produzione di copie di riferimento di programmi e documentazione, la loro archiviazione e consegna agli utenti secondo la procedura adottata nell'organizzazione).

Garanzia di qualità;

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

Il processo di assicurazione della qualità comprende le seguenti attività:

lavoro preparatorio

assicurare la qualità del prodotto garantendo la piena conformità dei prodotti software e della loro documentazione ai requisiti del cliente stipulati nel contratto;

garantire la qualità del processo di conformità dei processi del ciclo di vita del software, dei metodi di sviluppo, dell'ambiente di sviluppo e delle qualifiche del personale con i termini del contratto stabilito garantire altri indicatori di qualità del sistema

Verifica; consiste nel constatare che i prodotti software soddisfano pienamente i requisiti o le condizioni determinate dalle azioni precedenti (verifica in senso stretto significa prova formale della correttezza del software).

lavoro preparatorio;

verifica;

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 selezionati con i termini del contratto;

adeguatezza degli standard, delle procedure e dell'ambiente di sviluppo per il processo del ciclo di vita del software;

conformità delle specifiche di progettazione del software con i requisiti specificati;

correttezza della descrizione nelle specifiche di progettazione dei dati di input e output, sequenza di eventi, interfacce, logica;

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.

Certificazione;

implica determinare la completezza della conformità dei requisiti specificati e del sistema o prodotto software creato con il loro scopo funzionale finale. La certificazione solitamente significa conferma e valutazione dell'affidabilità dei test eseguiti. Si raccomanda di effettuare la certificazione effettuando test in tutte le situazioni possibili e utilizzando specialisti indipendenti.

Valutazione partecipativa(Analisi Partecipativa); per valutare lo stato dei lavori sul progetto e sul software.

La valutazione viene applicata sia a livello di gestione del progetto che a livello di attuazione 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.

Il processo di valutazione partecipativa prevede le seguenti attività:

lavoro preparatorio;

valutazione (analisi) della gestione di progetti;

valutazione tecnica.

Controllo;

determinare il rispetto dei requisiti, dei piani e dei termini del contratto. Un audit può essere eseguito da due parti qualsiasi coinvolte nel contratto, con una parte che controlla l'altra. Un audit è un audit (verifica) effettuato da un'autorità competente (persona) al fine di fornire una valutazione indipendente del grado di conformità del software o dei processi ai requisiti stabiliti.

Autorizzazione(Soluzione) i problemi.

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.

Il concetto di ciclo di vita del software (LC). Definizione del ciclo di vita secondo lo standard internazionale ISO/IEC 12207:1995. Processi organizzativi del ciclo di vita del software. Relazione tra i processi del ciclo di vita del software.

Vedi punto 2

Processi del ciclo di vita organizzativo :

Controllo;

è costituito dalle attività (attività generali) e dai compiti che possono essere svolti da qualsiasi soggetto che gestisce le proprie risorse. 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. Ad esempio, un amministratore è responsabile della gestione del progetto, della consegna, dello sviluppo, del funzionamento, della manutenzione, ecc.

Il processo di gestione prevede le seguenti azioni:

predisposizione e definizione dell'area gestionale . Il dirigente deve garantire che le risorse necessarie alla gestione (personale, attrezzature e tecnologie) siano a sua disposizione in quantità sufficienti;

pianificazione comporta lo svolgimento almeno delle seguenti attività:

elaborazione degli orari di lavoro;

stima dei costi;

allocazione delle risorse necessarie;

distribuzione delle responsabilità;

valutare i rischi associati a compiti specifici;

creazione di infrastrutture gestionali.

esecuzione e controllo;

verifica e valutazione;

completamento.

Creazione di infrastrutture;

copre la selezione e il supporto (supporto tecnologico), gli standard e gli 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.

Miglioramento;

prevede la valutazione, la misurazione, il controllo e il miglioramento dei processi del ciclo di vita del software.

Formazione scolastica.

copre la formazione iniziale e il successivo sviluppo continuo del personale.

Relazione tra i processi del ciclo di vita del software

I processi del ciclo di vita del software, regolati dallo standard ISO/IEC 12207, possono essere utilizzati da diverse organizzazioni in progetti specifici in vari modi. Tuttavia, lo standard offre una serie di relazioni di base tra i processi da vari punti di vista (Fig. 1). Questi aspetti sono:

aspetto contrattuale;

aspetto gestionale;

aspetto operativo;

aspetto ingegneristico;

aspetto di supporto.

IN aspetto contrattuale Il cliente e il fornitore stipulano un rapporto contrattuale e implementano di conseguenza i processi di approvvigionamento e consegna. IN aspetto gestionale il cliente, il fornitore, lo sviluppatore, l'operatore, il servizio di supporto e le altre parti coinvolte nel ciclo di vita del software gestiscono l'esecuzione dei propri processi. IN aspetto operativo l'operatore che gestisce il sistema fornisce i servizi necessari agli utenti. IN aspetto ingegneristico uno sviluppatore o un servizio di supporto risolve problemi tecnici rilevanti sviluppando o modificando prodotti software. IN aspetto di supporto i servizi che implementano i processi ausiliari forniscono i servizi necessari a tutti gli altri partecipanti al lavoro.

Le relazioni tra i processi descritti nello standard sono carattere statico . Più importante connessioni dinamiche tra i processi e i soggetti che li implementano sono stabiliti in progetti reali.

Il concetto di modello e fase del ciclo di vita del software. Caratteristiche delle fasi di creazione del software.

1) Norma internazionale ISO/ CEI 12207: 1995 Ecco come lo definisce il modello del ciclo di vita:

Il modello del ciclo di vita del software è inteso come una struttura che definisce la sequenza di esecuzione e le relazioni di processi, azioni e compiti durante tutto il ciclo di vita. Il modello del ciclo di vita dipende dalle specificità, dalla scala e dalla complessità del progetto e dalle condizioni specifiche in cui il sistema viene creato e opera.

2) GOST R ISO/IEC 12207-99 Ecco come lo definisce il modello del ciclo di vita:

Un modello del ciclo di vita è una struttura costituita da processi, lavori e compiti, compreso lo sviluppo, il funzionamento e la manutenzione di un prodotto software, che copre la vita di un sistema dalla definizione dei requisiti fino alla fine del suo utilizzo.

Sotto palcoscenico Per creazione del software si intende una parte del processo di creazione del software, limitato da un certo periodo di tempo e che termina con il rilascio di un prodotto specifico (modelli software, componenti software, documentazione), determinato dai requisiti specificati per questa fase. Le fasi della creazione del software si distinguono per ragioni di pianificazione razionale e di organizzazione del lavoro che si conclude con risultati specifici.

Il ciclo di vita del software solitamente comprende le seguenti stazioni:

Formazione dei requisiti software.

Progetto.

Implementazione.

Test.

La messa in produzione.

Funzionamento e manutenzione.

Disattivazione.

Il concetto di modello del ciclo di vita del software. Modello a cascata (cascata) del ciclo di vita del software.

Vedi punto 5

Nell'originale IS omogeneo, ogni applicazione era un tutt'uno. Per sviluppare questo tipo di applicazione è stato utilizzato il metodo a cascata. La sua caratteristica principale è la divisione dell'intero sviluppo in fasi, e il passaggio da una fase a quella successiva avviene solo dopo che i lavori su quello attuale sono completamente completati (Fig. 2). Ogni fase si conclude con il rilascio di una documentazione completa, sufficiente affinché lo sviluppo possa essere proseguito da un team di specialisti nella fase successiva.

Vantaggi dell'utilizzo del metodo a cascata :

in ogni fase viene generato un set completo di documentazione progettuale che soddisfa i requisiti di completezza e coerenza;

le fasi di lavoro eseguite in sequenza logica consentono di pianificare i tempi di completamento di tutti i lavori e i relativi costi.

L'approccio a cascata si è dimostrato efficace nella costruzione di sistemi informativi, per i quali, all'inizio dello sviluppo, tutti i requisiti possono essere formulati in modo abbastanza accurato e completo, al fine di fornire agli sviluppatori la libertà di implementarli tecnicamente nel miglior modo possibile .

Allo stesso tempo, questo approccio presenta una serie di svantaggi, causati principalmente dal fatto che l’effettivo processo di creazione del software non rientra mai completamente in uno schema così rigido. Il processo di creazione del software è solitamente natura iterativa : i risultati della fase successiva spesso causano cambiamenti nelle soluzioni progettuali sviluppate nelle fasi precedenti. Pertanto, vi è una costante necessità di tornare alle fasi precedenti e chiarire o rivedere le decisioni prese in precedenza. Di conseguenza, il vero processo di creazione del software assume una forma diversa (Fig. 2).

Ritardo significativo nell'ottenimento dei risultati. Il coordinamento dei risultati con gli utenti viene effettuato solo nei punti pianificati dopo il completamento di ciascuna fase di lavoro, i requisiti per l'IS sono “congelati” sotto forma di specifiche tecniche per tutto il tempo della sua creazione. Pertanto, gli utenti possono esprimere i loro commenti solo dopo che il lavoro sul sistema è stato completamente completato. Se i requisiti vengono indicati in modo impreciso o cambiano nel corso di un lungo periodo di sviluppo del software, gli utenti si ritrovano con un sistema che non soddisfa le loro esigenze. I modelli (sia funzionali che informativi) dell'oggetto automatizzato potrebbero diventare obsoleti contemporaneamente alla loro approvazione.

Il concetto di modello del ciclo di vita del software.Modello di sviluppo rapido delle applicazioni. Vedi paragrafo 5

Uno dei possibili approcci allo sviluppo di software applicativo nell'ambito del modello del ciclo di vita a spirale è il metodo ampiamente utilizzato del cosiddetto sviluppo rapido di applicazioni, o RAD (Rapid Application Development). RAD ha tre componenti:

piccoli gruppi di sviluppatori (3-7 persone) che eseguono lavori sulla progettazione di singoli sottosistemi software. Ciò è dovuto al requisito della massima controllabilità della squadra;

programma di produzione breve ma attentamente elaborato (fino a 3 mesi);

un ciclo iterativo in cui gli sviluppatori, man mano che l'applicazione inizia a prendere forma, richiedono e implementano nel prodotto i requisiti ottenuti attraverso l'interazione con il cliente.

Il team di sviluppo dovrebbe essere un gruppo di professionisti con esperienza nella progettazione, programmazione e test del software, in grado di interagire bene con l'utente finale e trasformare le loro proposte in prototipi funzionanti.

Si distinguono: fasi del processo di sviluppo RAD :

Modellazione aziendale . I flussi di informazioni tra le funzioni aziendali sono modellati.

Modellazione dei dati . Un flusso di informazioni viene mappato su un insieme di oggetti dati.

Simulazione della lavorazione . Le trasformazioni degli oggetti dati sono definite per garantire l'implementazione delle funzioni aziendali.

Generazione di applicazioni . Per costruire l'utilità di automazione vengono utilizzati linguaggi di programmazione di quarta generazione e componenti già pronti.

Test e fusione . L'uso di componenti riutilizzabili riduce i tempi di test.

Ciascuna funzione principale viene sviluppata da un gruppo separato di sviluppatori in parallelo per non più di 3 mesi, quindi viene integrata nell'intero sistema.

Svantaggi d'uso RAD :

I grandi progetti richiedono notevoli risorse umane per creare team.

Il modello è applicabile solo per quei sistemi che possono essere scomposti in moduli separati e in cui le prestazioni non rappresentano un valore critico.

Non applicabile in condizioni di rischi tecnici elevati, ad es. quando si utilizza la nuova tecnologia.

Il concetto di modello del ciclo di vita del software. Modello del ciclo di vita del software a forma di V.

Il modello del ciclo di vita a forma di V è stato creato per aiutare il team di progetto nella pianificazione per garantire ulteriori test del sistema. Tale modello pone particolare enfasi sulle attività volte alla verifica e validazione del prodotto. Dimostra che il test del prodotto viene discusso, progettato e pianificato nelle prime fasi del ciclo di vita dello sviluppo.

Un piano di test di accettazione del cliente viene sviluppato durante la fase di pianificazione e un piano di test del layout del sistema viene sviluppato durante le fasi di analisi, sviluppo della progettazione, ecc. Questo processo di sviluppo dei piani di prova è indicato dalla linea tratteggiata tra i rettangoli del modello a forma di V.

Il modello a V è stato sviluppato come variante del modello a cascata, e ne ha quindi ereditato la stessa struttura sequenziale. Ogni fase successiva inizia una volta ottenuti i risultati della fase precedente.

Il modello dimostra un approccio integrato alla definizione delle fasi del processo di sviluppo del software. Evidenzia le relazioni che esistono tra le fasi analitiche e di progettazione che precedono la codifica, seguita dalle fasi di test. Le linee tratteggiate indicano che queste fasi devono essere considerate in parallelo.

Riso. . Modello del ciclo di vita V

Di seguito è riportata una breve descrizione di ciascuna fase del modello V, dalla pianificazione del progetto e dei requisiti fino ai test di accettazione:

pianificazione del progetto e dei requisiti – vengono determinati i requisiti di sistema e il modo in cui le risorse dell’organizzazione verranno allocate per soddisfare i requisiti (se necessario, in questa fase vengono determinate le funzioni per hardware e software);

analisi dei requisiti e delle specifiche del prodotto – l’analisi del problema software attualmente esistente termina con una specificazione completa del comportamento esterno previsto del sistema software creato;

architettura o design al massimo livello – determina come le funzioni del software dovrebbero essere utilizzate nell'implementazione del progetto;

sviluppo dettagliato del progetto – definisce e documenta gli algoritmi per ciascun componente che è stato definito in fase di architettura. Questi algoritmi verranno successivamente convertiti in codice;

sviluppo del codice del programma – gli algoritmi definiti in fase di progettazione dettagliata vengono convertiti in software finito;

test unitari – ogni modulo codificato viene controllato per eventuali errori;

integrazione e test – stabilire relazioni tra gruppi di moduli precedentemente testati elemento per elemento al fine di confermare che questi gruppi funzionano allo stesso modo dei moduli testati indipendentemente gli uni dagli altri nella fase di test elemento per elemento;

sistema e test di accettazione – viene verificato il funzionamento del sistema software nel suo insieme (sistema completamente integrato), dopo essere stato inserito nel suo ambiente hardware in conformità con la specifica dei requisiti software;

produzione, funzionamento e supporto – il software viene messo in produzione. Questa fase prevede anche ammodernamenti e modifiche;

prove di accettazione (non mostrato in figura) – consente all'utente di testare la funzionalità del sistema per verificarne la conformità con i requisiti iniziali. Dopo il test finale, il software e l'hardware circostante diventano operativi. Successivamente viene fornita la manutenzione del sistema.

vantaggi:

Il modello pone particolare enfasi sulla pianificazione volta a verificare e certificare il prodotto in sviluppo nelle prime fasi del suo sviluppo. La fase di test unitario convalida la progettazione dettagliata. Le fasi di integrazione e test implementano la progettazione architettonica o il design al massimo livello. La fase di testing del sistema conferma che la fase dei requisiti del prodotto e delle sue specifiche è stata completata correttamente;

il modello prevede la certificazione e la verifica di tutti i dati esterni ed interni ricevuti, e non solo del prodotto software stesso;

nel modello V, la definizione dei requisiti viene eseguita prima della progettazione del sistema e la progettazione del software prima dello sviluppo dei componenti;

il modello definisce i prodotti che dovrebbero essere ottenuti come risultato del processo di sviluppo e ogni dato ottenuto deve essere testato;

grazie al modello, i project manager possono monitorare lo stato di avanzamento del processo di sviluppo, poiché in questo caso è del tutto possibile utilizzare una sequenza temporale e il completamento di ogni fase è una pietra miliare;

Il modello è di facile utilizzo (rispetto al progetto per il quale è adatto).

screpolatura:

con il suo aiuto non è facile far fronte ad eventi paralleli;

non tiene conto delle iterazioni tra le fasi;

il modello non prevede l'introduzione di requisiti per cambiamenti dinamici nelle diverse fasi del ciclo di vita;

la verifica dei requisiti nel ciclo di vita avviene troppo tardi, per cui è impossibile apportare modifiche senza influire sulla pianificazione del progetto;

Il modello non prevede azioni finalizzate all'analisi del rischio.

Per superare queste carenze, il modello a V può essere modificato per includere cicli iterativi progettati per risolvere i cambiamenti nei requisiti al di fuori della fase di analisi.

Come il suo predecessore, il modello a cascata, il modello a V funziona meglio quando tutte le informazioni sui requisiti sono disponibili in anticipo. Una modifica comune al modello V per superare le sue carenze prevede l’introduzione di cicli iterativi per risolvere i cambiamenti nei requisiti al di fuori della fase di analisi.

L'uso del modello è efficace quando sono disponibili informazioni sul metodo di implementazione della soluzione e della tecnologia e il personale ha le competenze e l'esperienza necessarie per lavorare con questa tecnologia.

Il modello a V è una scelta eccellente per i sistemi che richiedono elevata affidabilità, come applicazioni di monitoraggio clinico dei pazienti e software integrato per i controlli degli airbag automobilistici.

Il concetto di modello del ciclo di vita del software. Il modello a spirale di Boehm del ciclo di vita del software.

Modello a spirale - un classico esempio di applicazione di una strategia di progettazione evolutiva. Il modello a spirale (di Barry Boehm, 1988) si basa sulle migliori proprietà del ciclo di vita classico e della prototipazione, a cui viene aggiunto un nuovo elemento: l'analisi del rischio, che prima mancava.

Come mostrato nella Fig. 3, il modello definisce quattro azioni, rappresentate dai quattro quadranti dell'elica:

Pianificazione: definizione di obiettivi, opzioni e vincoli.

Analisi del rischio: analisi delle opzioni e riconoscimento/selezione del rischio.

Design: sviluppo di un prodotto di livello successivo.

Valutazione: la valutazione da parte del cliente dei risultati attuali della progettazione.

L'aspetto integrativo del modello a spirale è evidente quando si tiene conto della dimensione radiale della spirale. Ad ogni iterazione a spirale (spostandosi dal centro alla periferia), vengono costruite versioni sempre più complete del software.

Standard internazionale IEEE Std 830-1993. Linee guida per lo sviluppo delle specifiche dei requisiti software.

Approvato il 2 dicembre 1993 dall'IEEE Standards Committee

Riepilogo: vengono descritti il ​​contenuto e la qualità di una buona specifica dei requisiti software (SRS) e vengono presentati diversi progetti SRS di esempio. Queste linee guida mirano non solo a definire i requisiti per il software in fase di sviluppo, ma possono essere applicate anche alla selezione dei prodotti software interni e commerciali esistenti.

Parole chiave: contratto, cliente, prototipazione, specifica dei requisiti software, fornitore, specifica dei requisiti di sistema

introduzione

(L'Introduzione non fa parte delle Linee guida IEEE Std 830-1993 per lo sviluppo delle specifiche dei requisiti software.) Questo documento descrive gli approcci consigliati per la creazione di una specifica dei requisiti software. Si basa su un modello in cui l'output del processo di specifica dei requisiti software è un documento di specifica inequivocabile e completo. Questo dovrebbe aiutare

a) Descrivere ai clienti del software esattamente cosa desiderano ricevere

b) I fornitori di software capiscono esattamente cosa vuole il cliente

c) Gli individui completano i seguenti obiettivi:

1) Sviluppare un quadro di specifica dei requisiti software standard per le proprie organizzazioni

2) Definire il formato e il contenuto delle specifiche dei requisiti software

3) Includere elementi di requisiti aggiuntivi, come una lista di controllo della qualità o un manuale dello scrittore.

Buone specifiche dovrebbero fornire diversi vantaggi distinti a clienti, fornitori e altri, come ad esempio:

a) Stabilire le basi per l'accordo tra clienti e fornitori su cosa dovrebbe fare il software. Una descrizione completa delle funzioni che verranno eseguite dal software specificato nell'SRS aiuterà il potenziale utente a determinare se il software soddisfa le sue esigenze o come il software deve essere modificato per soddisfare le sue esigenze.

b) Ridurre gli sforzi di sviluppo. La preparazione di un SRS obbliga i vari gruppi di stakeholder dell'organizzazione cliente a considerare rigorosamente tutti i requisiti prima che inizi lo sviluppo del progetto e riduce la quantità di lavoro di riprogettazione, ricodifica e nuovo test in seguito. Un'attenta revisione dei requisiti dell'SRS può rivelare omissioni, incomprensioni e incoerenze nelle prime fasi dello sviluppo, quando questi problemi possono essere corretti più facilmente.

c) Fornire una base per le stime e la pianificazione dei costi. La descrizione del prodotto da sviluppare come definito nell'SRS fornisce una base realistica per la stima dei costi del progetto e può essere utilizzata per negoziare proposte o stimare i costi.

d) Fornire una base per test e verifiche. Le organizzazioni possono sviluppare i propri piani di test e ispezione in modo molto più produttivo con un buon SRS in atto. Come parte del contratto di sviluppo, l’SRS fornisce un quadro rispetto al quale è possibile misurare la conformità.

e) Facilitare il trasferimento. Gli STP semplificano il trasferimento di un prodotto software a nuovi utenti o l'installazione su nuove macchine. Ciò rende più semplice per i clienti trasferire il software ad altre parti della propria organizzazione ed è più semplice per i fornitori trasferire il software a nuovi clienti.

f) Fornire una base per il miglioramento. Poiché l'SRS descrive il prodotto, ma non il progetto che si sta sviluppando, l'SRS può servire come base per un ulteriore miglioramento del prodotto finito. L'SRS può essere soggetto a modifiche, ma fornisce le basi per una valutazione continua della produzione.

1. Panoramica

Lo standard descrive gli approcci alla creazione delle specifiche dei requisiti software. La sezione ha cinque punti.

Il punto 1 spiega le funzionalità di questo standard.

La clausola 3 contiene le definizioni utilizzate.

Il punto 4 fornisce la base informativa per lo sviluppo dell’SRS.

Il paragrafo 5 esamina ciascuna delle parti essenziali dell'SRS.

Lo standard dispone anche di appendici che forniscono modelli alternativi per i formati SRS.

1.1 Funzionalità (ambito)

Fornisce indicazioni sulla creazione delle specifiche dei requisiti software. Descrive il contenuto e gli attributi di una buona specifica dei requisiti software (SRS) e presenta diversi progetti SRS di esempio.

Queste linee guida hanno lo scopo di definire i requisiti del software in corso di realizzazione. Può essere utilizzato anche per assistere nella selezione di prodotti software interni e commerciali. Tuttavia, applicare queste linee guida a software già creato potrebbe essere controproducente.

Quando il software viene incorporato in un sistema di grandi dimensioni, come un dispositivo medico, possono verificarsi problemi che esulano dall'ambito di applicazione di questo standard.

Lo standard descrive il processo di creazione di un prodotto e il contenuto del prodotto. Prodotto: specifica dei requisiti software. Uno standard può essere utilizzato per creare direttamente una specifica dei requisiti software o può essere utilizzato come modello per definire uno standard più specifico.

Lo standard non definisce metodi speciali, terminologia (nomenclatura) o strumenti per la preparazione di STS.

2 Riferimenti

ASTM 1340-90, Guida standard per la prototipazione rapida di sistemi computerizzati

IEEE Std 610.12-1990, Glossario standard IEEE della terminologia dell'ingegneria del software (ANSI).

IEEE Std 730-1989, standard IEEE per i piani di garanzia della qualità del software (ANSI).

IEEE Std 828-1990, standard IEEE per i piani di gestione della configurazione software (ANSI).

IEEE Std 982.1-1988, Dizionario standard delle misure IEEE per produrre software affidabile (ANSI).

IEEE Std 982.2-1988, Guida IEEE per l'uso del dizionario di misure standard IEEE per produrre software affidabile (ANSI).

IEEE Std 983-1986, Guida IEEE alla pianificazione della garanzia della qualità del software.

IEEE Std 1002-1987, tassonomia standard IEEE per gli standard di ingegneria del software (ANSI).

IEEE Std 1012-1986, standard IEEE per i piani di verifica e convalida del software (ANSI).

IEEE Std 1016-1987, pratica raccomandata IEEE per le descrizioni della progettazione del software (ANSI).

IEEE Std 1028-1988, standard IEEE per le revisioni e gli audit del software (ANSI).

IEEE Std 1042-1987, Guida IEEE alla gestione della configurazione software (ANSI).

IEEE Std 1058.1-1987, standard IEEE per i piani di gestione dei progetti (ANSI).

IEEE Std 1074-1991, standard IEEE per lo sviluppo di processi del ciclo di vita del software (ANSI).

3 Definizioni

In generale, le definizioni dei termini utilizzati in questo documento sono conformi alle definizioni stabilite in IEEE Std 610.12-1990.5. I termini chiave sono definiti di seguito così come vengono utilizzati nel presente documento.

3.1 Contratto.

Un documento giuridicamente vincolante concordato dal cliente e dal fornitore. Include requisiti tecnici e organizzativi, costi e tempistica per il prodotto. Il contratto può contenere anche informazioni informali ma utili come obblighi o aspettative delle parti coinvolte.

3.2 Cliente.

La persona o le persone che pagano per il prodotto e solitamente (ma non necessariamente) ne definiscono i requisiti. Ai fini del presente documento, il cliente e il fornitore possono essere membri della stessa organizzazione.

3.3 Fornitore.

La persona o le persone che producono un prodotto per un cliente. Ai fini del presente documento, possono essere membri della stessa organizzazione.

3.4 Utente

La persona o le persone che lavorano o interagiscono direttamente con il prodotto. Gli utenti e i clienti spesso non sono le stesse persone.

4 Considerazioni per produrre un buon SRS

Questo paragrafo fornisce la base informativa per lo sviluppo dell'SRS. Include quanto segue:

a) L'essenza dell'SST

b) Contesto STS

c) Caratteristiche di buoni SST

d) Formazione congiunta degli SST

e) Processo per la modifica dell'SRS

f) Prototipazione

g) Inserimento del progetto nel STS

h) Incorporazione dei requisiti di progettazione nell'SRS

4.1 Natura dell'SRS

STP: specifiche tecniche per un prodotto software, un programma o una serie di programmi separati che eseguono attività specifiche in un ambiente specifico. L'SRS può essere creato da uno o più rappresentanti dei fornitori, da uno o più rappresentanti dei clienti o da entrambi. Il punto 4.4 raccomanda lo sviluppo con la partecipazione di rappresentanti del fornitore e del cliente.

Le principali questioni che lo sviluppatore SSS dovrebbe considerare sono:

a) Funzionalità. Cosa dovrebbe fare il programma?

b) Interfacce esterne. In che modo il software interagisce con le persone, l'hardware di sistema, altro hardware e altro software?

c) Produttività. Qual è la velocità, la disponibilità, il tempo di risposta, il tempo di ripristino delle varie funzioni software, ecc.?

d) Attributi. Qual è la portabilità, la correttezza, la manutenibilità, la sicurezza, ecc.?

e) Vincoli di progettazione imposti all'implementazione. Eventuali requisiti standard esistenti, linguaggio di runtime, policy di integrità del database, limitazioni delle risorse, ambienti operativi di runtime, ecc.?

Gli sviluppatori SRS dovrebbero evitare di inserire requisiti di sviluppo o di progetto nell'SRS.

4.2 Contesto della SRS

È importante considerare il ruolo che l'SST svolge nel piano complessivo del progetto, come definito dall'IEEE Std 610.12-1990. Il software può contenere sostanzialmente tutte le funzionalità di un progetto o può far parte di un sistema più ampio. In quest'ultimo caso, solitamente esiste un SRS che definisce le interfacce tra il sistema e il software e contiene i requisiti per le caratteristiche e la funzionalità di quel software. Naturalmente l'SST in questo caso deve essere coordinato e ampliato con requisiti a livello di sistema.

IEEE Std 1074-1991 descrive le fasi del ciclo di vita del software e gli input corrispondenti per ciascuna fase. Altri standard, come quelli elencati nella Sezione 2, si riferiscono ad altre fasi del ciclo di vita del software e possono anche integrare i requisiti del software.

Poiché gli SSP svolgono un ruolo speciale nel processo di sviluppo del software, gli autori degli SSP devono fare attenzione a non oltrepassare i limiti di tale ruolo. Ciò significa che STPO

a) Deve identificare correttamente tutti i requisiti software. I requisiti software sono determinati dalla natura del problema da risolvere o da una caratteristica speciale del progetto.

b) Non deve descrivere alcun dettaglio di progettazione o esecuzione. Dovrebbero essere descritti nella fase di sviluppo del progetto.

c) Non deve imporre ulteriori restrizioni al software. È corretto se sono definiti in altri documenti come il piano di garanzia della qualità. Pertanto, è corretto se gli SST creati limitano l'ambito della progettazione, ma non definiscono alcun dettaglio della progettazione.

4.3 Caratteristiche di un buon SRS

L'STP deve avere le seguenti caratteristiche

d) Corretto

e) Inequivocabile

g) Seriale

h) Valutato per importanza e/o stabilità

i) Verificabile

j) Modificabile

k) Tracciabile

4.3.1 Corretto

Gli SRS sono corretti se e solo se ogni requisito in essi indicato deve essere soddisfatto nel software. Non esiste uno strumento o una procedura che ne determini la correttezza. L'SRS dovrebbe essere confrontato con tutte le specifiche di livello superiore pertinenti, come le specifiche dei requisiti di sistema, altri documenti di progettazione e altri standard pertinenti per garantire la conformità. Inoltre, il cliente o l'utente può determinare se l'SRS riflette accuratamente le esigenze reali. La tracciabilità rende questa procedura più semplice e meno soggetta a errori (vedere 4.3.8).

4.3.2 Inequivocabile

Gli SRS sono coerenti se e solo se ciascuna affermazione dichiarata ha una sola interpretazione. Come minimo, ciascuna caratteristica del prodotto finale deve essere descritta utilizzando un unico termine univoco. Nei casi in cui un termine utilizzato in un particolare contesto possa avere molteplici significati, dovrebbe essere incluso in un glossario in cui il suo significato sia reso più specifico.

Gli SST rappresentano una parte importante del ciclo di vita del software e vengono utilizzati nella progettazione, implementazione, controllo del progetto, verifica, test e formazione come descritto in IEEE Std 1074-1991. L'SRS deve essere interpretato in modo inequivocabile, sia da coloro che lo creano sia da coloro che lo utilizzano. Tuttavia, questi gruppi spesso non hanno la stessa formazione e quindi tendono a interpretare i requisiti software in modi diversi. Rappresentazioni che migliorano la specifica dei requisiti per lo sviluppatore possono essere controproducenti nella comprensione dell'utente e viceversa.

4.3.2.1 Insidie ​​del linguaggio naturale

I requisiti sono spesso scritti in linguaggio naturale (come l'inglese). Il linguaggio naturale è intrinsecamente ambiguo. Per identificare l'uso ambiguo del linguaggio naturale, l'SRS deve essere rivisto da un soggetto indipendente in modo che eventuali ambiguità identificate vengano corrette.

4.3.2.2 Linguaggi di specifica dei requisiti

Un modo per evitare l'ambiguità inerente al linguaggio naturale è scrivere l'SRS in un linguaggio di specifica dei requisiti speciale. I processori linguistici rilevano automaticamente molti errori lessicali, sintattici e semantici.

Tali lingue presentano degli svantaggi. Richiedono tempo per essere padroneggiati e molti utenti li trovano confusi. Inoltre, questi linguaggi sono più adatti ad esprimere determinati requisiti e riferirsi a determinati tipi di sistemi. Pertanto, potrebbero avere un’influenza indiretta sui requisiti.

4.3.2.3 Strumenti di rappresentazione.

In generale, i metodi per creare requisiti, linguaggi e strumenti che li supportano rientrano in tre categorie generali: oggetti, processi, comportamento. Gli approcci orientati agli oggetti sono organizzati in termini di oggetti reali, i loro attributi e i servizi forniti da tali oggetti. Gli approcci basati sui processi organizzano i requisiti in una gerarchia di funzioni collegate tramite flussi di dati. Gli approcci comportamentali descrivono il comportamento esterno di un sistema in termini di concetti astratti (come un predicato numerabile), funzioni matematiche o una macchina a stati.

La misura in cui tali strumenti e tecniche sono utili nella creazione di un STS dipende dalle dimensioni e dalla complessità del programma. Non viene fatto alcun tentativo di descrivere o raccomandare alcuno strumento specifico.

Quando si utilizza uno di questi approcci, è meglio mantenere le descrizioni in linguaggio naturale. Allo stesso tempo, quei clienti che non hanno familiarità con la notazione del linguaggio capiranno STPO.

4.3.3 Completato

Gli SRS sono completi se e solo se includono i seguenti elementi:

a) Tutti i requisiti essenziali riguardanti funzionalità, prestazioni, vincoli di progettazione, prestazioni o interfacce esterne. In particolare, eventuali requisiti esterni imposti dalle specifiche del sistema devono essere identificati e considerati.

b) Tutte le reazioni del software a tutti i possibili tipi di dati di input in tutte le possibili situazioni. È importante definire le reazioni ai valori dei dati validi e non validi.

4.3.3.1 Utilizzo di TBD

Eventuali STR che utilizzano la frase "da determinare" (TBD) non sono complete, tuttavia a volte sono necessarie e dovrebbero essere accompagnate da quanto segue

a) Una descrizione delle condizioni che danno origine alla frase “da determinare” (ad esempio, perché non si conosce la risposta) affinché la situazione possa essere risolta.

b) Una descrizione di cosa deve essere fatto per eliminare la frase “da determinare”, chi è responsabile dell'eliminazione, quando deve essere effettuata l'eliminazione.

4.3.4 Coerente

L’integrità si riferisce all’integrità interna. Se l'SRS contraddice documenti di livello superiore, come le specifiche dei requisiti di sistema, allora ciò non è corretto (vedere 4.3.1).

4.3.4.1 Coerenza interna

Gli SRS sono internamente coerenti se e solo se non vi sono sottoinsiemi di requisiti individuali descritti negli SRS che siano in conflitto tra loro. Esistono tre tipi di potenziali conflitti nel STS:

a) Le caratteristiche specificate degli oggetti potrebbero essere in conflitto. Per esempio,

1) Il report di output può essere descritto in un requisito come tabellare e in un altro come testo.

2) Un requisito può stabilire che tutti gli indicatori devono essere verdi e un altro requisito che tutti gli indicatori devono essere blu.

b) Potrebbe esserci un conflitto logico o temporale tra le due azioni specificate. Per esempio.

1) Un requisito può specificare che il programma aggiungerà due quantità di input, un altro può specificare che le moltiplicherà.

2) Un requisito prevede che l'evento “A” debba sempre seguire l'evento “B”, mentre un altro requisito prevede che gli eventi “A” e “B” si verifichino contemporaneamente.

3) Due o più requisiti possono descrivere lo stesso oggetto, ma utilizzare termini diversi per quell'oggetto. Ad esempio, la richiesta di input dell'utente da parte di un programma può essere chiamata "prompt" in una richiesta e "cue" in un'altra. L'utilizzo di terminologia e definizioni standard migliora la coerenza.

4.3.5 Classificato per importanza e/o stabilità

Un SRS è classificato in base all'importanza e/o alla stabilità se ciascun requisito ha un identificatore che identifica l'importanza e/o la stabilità di quel requisito.

In genere, non tutti i requisiti software sono ugualmente importanti. Alcuni requisiti potrebbero essere obbligatori, soprattutto per le applicazioni critiche, mentre altri potrebbero essere solo auspicabili.

Ogni requisito della SRS deve essere valutato per rendere queste distinzioni chiare ed esplicite. L’identificazione dei requisiti aiuta:

UN. Fornire ai consumatori un’interpretazione più precisa di ciascun requisito, che spesso rivela presupposti impliciti

B. Gli sviluppatori prendono le giuste decisioni di progettazione e prestano la necessaria attenzione alle diverse parti del prodotto software.

4.3.5.1 Grado di stabilità

Un metodo per identificare i requisiti utilizza una misura di stabilità. La stabilità può essere espressa come il numero di modifiche previste a qualsiasi requisito sulla base dell'esperienza e della conoscenza dei probabili eventi che influenzano l'organizzazione, le funzioni e il personale supportato dal software.

4.3.5.2 Grado di necessità

Un altro modo per valutare i requisiti è distinguere le classi di requisiti in obbligatori, condizionali e facoltativi.

a) Obbligatorio. Implica che il software non sarà accettabile a meno che questi requisiti non siano inclusi e concordati.

b) Condizionale. Implica che questi requisiti miglioreranno il prodotto software, ma che il prodotto software sarà accettabile senza di essi.

c) Facoltativo. Si riferisce a una classe di funzioni che possono o meno essere degne di attenzione. Ciò offre al fornitore l'opportunità di offrire alcune funzionalità che vanno oltre l'ambito dell'STS.

4.3.6 Verificabile

Una SRS è verificabile se e solo se ogni requisito in essa definito è verificabile. Un requisito è verificabile se e solo se esiste un processo finito ed economicamente vantaggioso mediante il quale una persona o una macchina può verificare che il software soddisfi il requisito. Qualsiasi requisito ambiguo non è verificabile.

I requisiti non verificabili includono affermazioni come "funziona bene", "buona interfaccia umana", "accadrà comunemente". Queste affermazioni non sono verificabili perché è impossibile definire i termini "buono", "bene" o "solitamente". L'affermazione "un programma non dovrebbe mai entrare in una ricorsione infinita" non è verificabile perché testare questa qualità è teoricamente impossibile.

Esempio di un'affermazione verificabile

Il programma deve essere terminato entro 20 s nel 60% dei casi ed entro 30 s nel 100% dei casi

Questa affermazione è verificabile perché utilizza termini specifici e quantificabili.

Se non è possibile sviluppare un processo per determinare se un dato requisito è soddisfatto nel software, allora il requisito deve essere rimosso o rivisto.

4.3.7 Modificabile

Un SRS è modificabile se e solo se ha una struttura e uno stile tali che qualsiasi modifica ai requisiti possa essere apportata facilmente, completamente, coerentemente e mantenendo la struttura. In generale, la mutevolezza è richiesta in STPO

a) Avere una struttura coerente e di facile utilizzo con un sommario, un indice e riferimenti incrociati espliciti

b) Non essere ridondante; ovvero, lo stesso requisito non dovrebbe apparire in più di un punto dell'SRS

c) Esprimere ciascun requisito separatamente anziché mescolarlo con altri requisiti

La ridondanza in sé non è un bug, ma può facilmente portare a errori. La ridondanza a volte può aiutare a rendere leggibile l'SRS, ma possono sorgere problemi quando il documento viene modificato. Ad esempio, se un requisito è stato modificato solo in uno dei punti in cui appare, l'SRS diventa ambiguo. Laddove sia necessaria la ridondanza, l'SRS dovrebbe includere riferimenti incrociati espliciti.

4.3.8 Tracciabile

Un SRS è tracciabile se l'origine di ciascun requisito è chiara e se l'SRS fornisce un facile accesso a ciascun requisito dalla documentazione prodotta durante lo sviluppo successivo o dalla documentazione che estende l'SRS. Si consigliano due tipi di tracciabilità.

a) Tracciabilità a ritroso (vale a dire alle fasi precedenti di sviluppo). Ciò dipende dal fatto che ciascun requisito citi esplicitamente una fonte nei documenti precedenti.

b) Tracciabilità inoltrata (ovvero a tutti i documenti generati dal SRS). Ciò dipende dal fatto che ciascun requisito dell'SRS abbia un nome o un numero di riferimento univoco.

La tracciabilità futura del software è particolarmente importante quando il software entra nella fase operativa e di supporto. Man mano che i codici e i documenti di progettazione cambiano, è necessario essere in grado di identificare l’insieme completo di requisiti che potrebbero essere interessati da tali cambiamenti.

4.4 Preparazione congiunta dell'SRS

Il processo di sviluppo del software deve iniziare con un accordo tra il fornitore e il cliente su cosa dovrebbe fare il software finito. Questo accordo sotto forma di SRS deve essere preparato congiuntamente. Questo è importante perché di solito né il cliente né il fornitore sono abbastanza esperti per sviluppare individualmente un buon documento.

c) I clienti solitamente non comprendono il processo di creazione e sviluppo del software abbastanza bene da poter creare software utilizzabile.

d) I fornitori solitamente non comprendono l'ambito del cliente abbastanza bene da determinare i requisiti per un sistema soddisfacente.

Pertanto, il cliente e il fornitore devono lavorare insieme per produrre un SRS ben scritto e pienamente comprensibile.

Esiste una situazione in cui un sistema e il suo software vengono sviluppati simultaneamente. Quindi la funzionalità, le interfacce, le prestazioni e altre caratteristiche e limitazioni del software non sono predeterminate, ma vengono definite congiuntamente in modo più preciso durante il processo di sviluppo e sono soggette a negoziazione e modifica. Questo è più difficile, ma non meno importante, poiché è necessario raggiungere le caratteristiche indicate al punto 4.3. In particolare, gli SRS che non sono conformi ai requisiti delle specifiche del sistema genitore non sono corretti.

Non si discute qui di stile, uso del linguaggio o tecniche di buon linguaggio. Questo è molto importante perché gli STPO devono avere un buon linguaggio. I manuali per la creazione di libri tecnici possono essere utilizzati come guida.

4.5 Sviluppo dell'evoluzione SRS

Gli STP possono evolversi man mano che i prodotti software vengono migliorati. Potrebbe non essere sempre possibile determinare alcuni dettagli prima dell'inizio del progetto. Ad esempio, potrebbe non essere possibile definire tutti i formati dello schermo per un programma interattivo durante la fase di sviluppo dei requisiti. Ulteriori modifiche potrebbero verificarsi qualora si riscontrassero parti mancanti, carenze ed errori nell'SRS.

In questo processo è necessario tenere conto dei seguenti due punti principali:

a) I requisiti devono essere specificati nel modo più completo ed esauriente possibile attualmente, anche se si possono prevedere cambiamenti evolutivi come inevitabili. Il fatto che i requisiti siano incompleti dovrebbe riflettersi nelle note.

b) È necessario avviare un processo di cambiamento formale per identificare, gestire, tracciare e segnalare i cambiamenti. Le modifiche approvate ai requisiti devono essere incluse nell'SRS in modo che

1) Garantire un controllo accurato e completo delle modifiche.

2) Consentire la visualizzazione delle parti attuali e modificate dell'SRS

4.6 Prototipazione

La prototipazione viene spesso utilizzata durante la fase di sviluppo dei requisiti di un progetto. Esistono molti strumenti che consentono di ottenere rapidamente e facilmente prototipi di sistemi da un modello impostando i parametri. Vedi anche ASTM Std 1340-90.

I prototipi sono utili per tre ragioni:

a) È molto probabile che il cliente vorrà guardare il prototipo e reagire ad esso, piuttosto che leggere l'SRS e reagire ad esso. Pertanto, il prototipo fornisce un feedback rapido.

b) Il prototipo mostra aspetti inaspettati del comportamento del sistema. Pertanto, non solo risponde alle domande che sono sorte, ma ne pone anche di nuove. Ciò aiuta a raggiungere il completamento dello sviluppo STS.

c) Gli SRS basati su prototipi tendono a subire meno modifiche durante lo sviluppo, riducendo così i tempi di sviluppo.

Un prototipo dovrebbe essere utilizzato come modo per identificare i requisiti software. Alcune caratteristiche, come la tipologia delle schermate o i formati dei messaggi, possono essere ricavate direttamente dal prototipo. Altri requisiti potranno essere ottenuti sperimentando il prototipo.

4.7 Incorporare la progettazione nell'SRS

Un requisito definisce una funzione o caratteristica visibile esternamente di un sistema. Un progetto descrive un singolo sottocomponente di un sistema e/o si interfaccia con altri sottocomponenti. I creatori dell'SRS devono distinguere chiaramente tra l'identificazione dei vincoli di progettazione richiesti e la progettazione di un progetto specifico. Si noti che ciascun requisito della SRS limita le alternative di progettazione. Ciò non significa che ogni requisito sia un progetto.

Gli SST devono determinare quali funzioni devono essere svolte, quali dati produrre, quale risultato si ottiene, dove si trovano, per chi. Gli STP dovrebbero concentrarsi sui servizi che verranno forniti. L'SRS normalmente non dovrebbe definire elementi del progetto come i seguenti:

a) Dividere il software in moduli

b) Distribuzione delle funzioni tra i moduli

c) Descrizione del flusso di informazioni o dell'interazione tra i moduli

d) Selezione delle strutture dati

4.7.1 Requisiti di progettazione necessari

In casi particolari, alcuni requisiti possono limitare rigorosamente il progetto. Ad esempio, i requisiti di privacy o sicurezza possono riflettersi direttamente nella progettazione. Questi sono requisiti come

a) Mantenere alcune funzioni in moduli separati

b) Consentire una comunicazione limitata tra determinate aree del programma

c) Controllare l'integrità dei dati per le variabili critiche

Esempi di vincoli di progettazione accettabili sono i requisiti fisici, i requisiti prestazionali, i requisiti per supportare gli standard di sviluppo del software, gli standard di qualità del software.

Pertanto, i requisiti devono essere formulati da un punto di vista puramente esterno. Quando i modelli vengono utilizzati per illustrare i requisiti, ricordare che il modello indica solo il comportamento esterno e non definisce la progettazione.

4.8 Integrazione dei requisiti del progetto nell'SRS

Gli SSP dovrebbero definire il prodotto software, non il processo di creazione.

I requisiti di progettazione forniscono un'intesa tra cliente e fornitore riguardo alle questioni contrattuali rilevanti per la produzione del software e quindi non dovrebbero essere inclusi nell'SRS. Di solito questi sono punti come questo

un costo

b) Tempi di consegna

c) Attività di reporting

d) Metodi di sviluppo del software

e) Garanzia di qualità

f) Prove e criteri di ispezione

g) Procedure di accettazione

I requisiti del progetto sono definiti in altri documenti, solitamente un piano di sviluppo software, un piano di test del software o un documento di accettazione del lavoro.

5 sezioni di SRS (le parti di un SRS)

Questa sezione illustra ciascuna delle parti richieste di un PTSS. Le sezioni situate nello schema mostrato in Fig. 1 può servire da modello per lo sviluppo dell’SST.

1. Introduzione

1.2 Limiti di applicazione

1.3 Termini, acronimi, abbreviazioni

1.5 Breve panoramica

2. Descrizione generale

2.1 Prospettive del prodotto

2.2 Funzioni del prodotto

2.3 Caratteristiche dell'utente

2.4 Limitazioni

2.5 Presupposti e dipendenze

3. Requisiti dettagliati (vedere 5.3.1-5.3.8 per spiegazioni sui possibili requisiti dettagliati. Vedere anche l'Appendice A per le diverse strutture di questa sezione dell'SRS)

Applicazioni

Indici

Figura 1 Esempio di diagramma STP

Sebbene un SRS non debba necessariamente seguire lo schema o utilizzare questi titoli di sezione, un SRS corretto dovrebbe includere tutte le informazioni discusse qui.

5.1 Introduzione (Sezione 1 STP)

L'introduzione dell'SRS dovrebbe fornire una breve panoramica dell'intero SRS. Dovrebbe contenere le seguenti sottosezioni:

b) Limiti di applicazione

c) Definizioni, acronimi (abbreviazioni) e abbreviazioni

d) Breve panoramica

5.1.1 Scopo (1.1 da SRS)

Questa sottosezione dovrebbe fare quanto segue:

a) Descrivere lo scopo della SRS dettagliata

b) Determinare il pubblico a cui è destinato l'STS

5.1.2 Ambito (1.2 da SRS)

Questa sottosezione dovrebbe

c) Identificare il/i prodotto/i software che verrà prodotto/i, nome (ad esempio, “Server DBMS”, “Generatore di report”, ecc.)

d) Spiegare cosa faranno gli elementi software e, se necessario, non faranno

e) Descrivere le applicazioni del software in via di definizione, compresi importanti vantaggi, oggetti e scopi.

f) Coerente con affermazioni simili nelle specifiche di livello superiore (ad esempio specifiche dei requisiti di sistema), se esistenti

5.1.3 Termini, acronimi e abbreviazioni (1.3 da STPO)

Questa sottosezione dovrebbe fornire le definizioni di tutti i termini, acronimi e abbreviazioni necessari per interpretare correttamente la SRS. Tali informazioni possono essere fornite facendo riferimento a una o più appendici dell'SRS o facendo riferimento ad altri documenti.

Questa sottosezione dovrebbe

a) Fornire un elenco completo di tutti i documenti menzionati ovunque nell'SRS

b) Identificare ciascun documento per nome, numero (se periodico), data, ente editoriale.

Tali informazioni possono essere fornite facendo riferimento a una o più appendici dell'SRS o facendo riferimento ad altri documenti.

5.1.5 Panoramica (1.5 da STPO)

Questa sottosezione dovrebbe

a) Descrivere cosa contiene il resto dell'SRS

b) Spiegare come è strutturato il STS

5.2 Descrizione generale (Sezione 2 di STP

Questa sezione dell'SRS dovrebbe descrivere i fattori generali che influenzano il prodotto e i requisiti. Questa sezione non definisce requisiti specifici. Fornisce invece la base per la loro definizione dettagliata nella Sezione 3 e li rende più facili da comprendere.

Questa sezione è generalmente composta dalle seguenti sei sottosezioni:

a) Descrizione del prodotto

b) Funzioni del prodotto

c) Caratteristiche dell'utente

d) Limitazioni

e) Presupposti e dipendenze

f) Sottoinsiemi di requisiti

5.2.1 Prospettiva del prodotto (2.1 da SPTO)

In questa sottosezione delle STS, questo prodotto deve essere considerato dal punto di vista dei prodotti correlati. Se il prodotto è indipendente e completamente autonomo, ciò deve essere indicato qui. Se l'SRS specifica un prodotto che è un componente di un sistema più ampio, come spesso accade, allora questo sottopunto deve mettere in relazione i requisiti di quel sistema più ampio con la funzionalità di quel prodotto e deve identificare le interfacce tra quel sistema e il prodotto.

Potrebbe essere utile un diagramma che mostri i componenti principali del sistema più ampio, le loro interazioni e le interfacce esterne.

Questa sottosezione dovrebbe inoltre descrivere in che modo il software è conforme a varie restrizioni interne. Ad esempio, potrebbe includere:

a) Interfacce di sistema

b) Interfacce utente

c) Interfacce hardware del computer

d) Interfacce software

e) Interfacce di comunicazione

f) Limitazioni di memoria

g) Operazioni

h) Requisiti per l'allestimento delle postazioni di lavoro

5.2.1.1 Interfacce di sistema

Per garantire i requisiti di sistema, le descrizioni delle interfacce e la conformità del sistema, è necessario elencare ciascuna interfaccia di sistema e identificare la funzionalità del relativo software.

5.2.1.2 Interfacce utente

È necessario determinare:

a) Le caratteristiche logiche di ciascuna interfaccia tra il prodotto software e gli utenti. È necessario includere le funzionalità di configurazione (ad esempio, formati dello schermo richiesti, layout di pagine o finestre, contenuto di eventuali messaggi o menu, disponibilità di tasti funzione programmabili) necessarie per soddisfare i requisiti del software.

b) Tutti gli aspetti di ottimizzazione dell'interfaccia tra il prodotto software e gli utenti che utilizzano il prodotto. Ciò può includere semplicemente un elenco di ciò che il sistema dovrebbe e non dovrebbe fare dal punto di vista dell'utente. Un esempio è la richiesta di scegliere tra messaggi di errore lunghi o brevi. Analogamente ad altri requisiti, questi requisiti dovrebbero essere verificabili, ad esempio, "un dattilografo di 4a elementare può eseguire la funzione X in Z minuti dopo 1 ora di formazione" è preferibile a "un dattilografo può eseguire la funzione X" (questo può anche essere specificato in le specifiche del sistema software nella sezione intitolata “Facilità d'uso”).

5.2.1.3 Interfacce hardware del computer

Qui è necessario determinare le caratteristiche logiche di ciascuna interazione (fattura) tra il prodotto software e i componenti hardware del sistema informatico. Ciò include le caratteristiche di configurazione (numeri di porta, set di istruzioni, ecc.), copre questioni come un elenco di dispositivi supportati, metodi di supporto, protocolli. Ad esempio, è possibile specificare che un terminale supporti lo schermo intero o, in alternativa, supporti una riga.

5.2.1.4 Interfacce software

Qui è necessario determinare l'utilizzo di altri prodotti software richiesti (ad esempio un sistema di gestione dei dati, un sistema operativo o un pacchetto matematico) e le interfacce con altri sistemi applicativi (ad esempio il collegamento tra il sistema di contabilità clienti e il sistema di contabilità generale) . Per ciascun prodotto software richiesto è necessario fornire quanto segue:

un nome

b) Nome mnemonico

c) Numero di specifica

d) Numero di versione

e) Sorgente Per ciascuna interfaccia dovrà essere indicato:

a) Discussione dello scopo dei programmi interagenti in relazione a un dato prodotto.

b) Definizione dell'interfaccia in termini di contenuto e formato del messaggio. Le interfacce correttamente registrate non richiedono una descrizione dettagliata, ma è richiesto un collegamento a un documento che descriva l'interfaccia.

5.2.1.5 Interfacce di comunicazione

Qui è necessario definire diverse interfacce di comunicazione come protocolli di rete locale, ecc.

5.2.1.6 Vincoli di memoria

Qui è necessario definire eventuali caratteristiche applicabili e il loro significato per RAM e ROM.

5.2.1.7 Operazioni

Qui è necessario definire le azioni normali e speciali richieste dagli utenti, come ad esempio

a) Diversi modi di fare le cose nell'organizzazione dell'utente; ad esempio le operazioni avviate dall'utente

b) Periodi di azioni di dialogo e periodi di azioni senza risposta

c) Funzioni di supporto al trattamento dei dati

d) Azioni di backup e ripristino

NOTA – Questo elemento è talvolta definito come parte della sezione delle interfacce utente.

5.2.1.8 Requisiti di adattamento del sito

Qui è necessario

a) Definire i requisiti per qualsiasi dato o sequenza di inizializzazione definita per un determinato luogo di lavoro, attività o modalità operativa, come valori di rete, limiti di sicurezza, ecc.

b) Identificare le caratteristiche del lavoro o dell'attività eseguita che devono essere modificate per configurare il software per una configurazione specifica.

5.2.2 Funzioni del prodotto (2.2 da SRS)

Questa sottosezione dell'SRS dovrebbe contenere un riepilogo delle principali funzioni eseguite dal software. Ad esempio, un STP per un programma di contabilità potrebbe utilizzare questa sottosezione per definire le funzioni di gestione del conto cliente, richiesta cliente e preparazione delle fatture senza menzionare la grande quantità di dettagli che ciascuna di queste funzioni richiede.

A volte il riepilogo delle funzioni necessario per questa parte può essere derivato direttamente dalle sezioni delle specifiche di livello superiore (se presenti) che assegnano funzioni specifiche al prodotto software. Si prega di notare che per motivi di chiarezza:

a) Le funzioni dovrebbero essere organizzate in gruppi che rendano l'elenco delle funzioni comprensibile al cliente o a chiunque legga il documento per la prima volta.

b) È possibile utilizzare metodi testuali o grafici per mostrare le varie funzioni e le loro relazioni. Tali diagrammi non hanno lo scopo di mostrare il design di un prodotto, ma mostrano semplicemente le relazioni logiche tra le variabili.

5.2.3 Caratteristiche utente (2.3 da SRS)

Questa sottosezione dell'SRS dovrebbe descrivere le caratteristiche generali degli utenti a cui sono destinati i prodotti, inclusi livello di istruzione, esperienza e qualifiche tecniche. Questa sezione non deve essere utilizzata per Pagina 22

Standard esterni

Norma IEEE 830-1993

Per formulare requisiti dettagliati è piuttosto necessario spiegare le ragioni per cui tali requisiti appariranno più avanti nella sezione 3 dell'SRS.

5.2.4 Vincoli (2.4 da SRS)

Questa sottosezione dell'SRS dovrebbe fornire una descrizione generale di eventuali altri fattori che limitano le scelte dello sviluppatore. Questi includono:

a) Politica di regolamentazione

b) Limitazioni hardware del computer (ad esempio requisiti temporali di selezione)

c) Interfacce con altre applicazioni

d) Funzionamento in parallelo

e) Funzioni di registrazione

f) Funzioni di controllo

g) Requisiti per i linguaggi di alto livello

h) Protocolli di interfaccia di temporizzazione del segnale (ad esempio XON-XOFF, ACK-NACK)

i) Requisiti di affidabilità

j) Criticità applicativa

k) Considerazioni sulla sicurezza e sulla privacy

5.2.5 Presupposti e dipendenze (2.5 da SRS)

Questa sottosezione dell'SRS definisce un elenco di fattori che influenzano i requisiti definiti nell'SRS. Questi fattori non rappresentano restrizioni sul software di progetto, ma qualsiasi modifica ad essi potrebbe influenzare i requisiti dell'SRS. Ad esempio, si può presupporre che un particolare sistema operativo sarà disponibile sull'hardware del computer destinato a un prodotto software. Se, infatti, il sistema operativo non fosse disponibile, l'SRS dovrebbe cambiare.

5.2.6 Ripartizione dei requisiti (2.6 da SRS)

Questa sottosezione dell'SRS dovrebbe definire i requisiti che potrebbero essere rinviati alle versioni future del sistema.

5.3 Requisiti specifici (Sezione 3 del STP)

Questa sezione dell'SRS dovrebbe contenere tutti i requisiti software in modo sufficientemente dettagliato da consentire agli sviluppatori di progettare e ai tester di verificare un sistema che soddisfi tali requisiti. In questa sezione, ogni requisito deve fornire l'interoperabilità con utenti, operatori o altri sistemi esterni. Questi requisiti devono includere, come minimo, una descrizione di tutti gli input del sistema, di tutti gli output del sistema e di tutte le funzioni che il sistema esegue in risposta agli input o per produrre output.

Poiché questa è spesso la parte più ampia e importante dell’SRS, devono essere applicati i seguenti principi:

a) I requisiti dettagliati devono essere stabiliti in conformità con le regole descritte al punto 4.3 della presente norma.

b) I requisiti dettagliati dovrebbero contenere riferimenti incrociati ai documenti precedenti a cui si riferiscono.

c) Tutti i requisiti devono essere identificati in modo univoco.

d) Per migliorare la leggibilità, particolare attenzione dovrebbe essere prestata alla strutturazione dei requisiti.

Prima di esplorare modalità specifiche per strutturare i requisiti, è utile esaminare le diverse sezioni dei requisiti presentate di seguito.

5.3.1 Interfacce esterne

Dovrebbe esserci una descrizione dettagliata di tutti gli input e output del sistema software. Questa sottosezione è in aggiunta alla descrizione dell'interfaccia nella sezione 5.2. Non deve ripetere le informazioni contenute nella sezione 5.2.

a) Nome dell'articolo

b) Descrizione dello scopo

c) Fonte dell'input o destinazione dell'output

d) Intervallo, precisione e/o tolleranze accettabili

e) Unità di misura

f) Caratteristiche temporali

g) Relazioni con altri input/output

h) Formati/organizzazione dello schermo

i) Formati/organizzazione delle finestre

j) Formati dei dati

k) Formati dei comandi

l) Fine dei messaggi

5.3.2 Funzioni

I requisiti funzionali definiscono le azioni fondamentali che devono avvenire nel software durante la ricezione e l'elaborazione dei dati di input e durante la generazione dei dati di output. Di solito sono elencati come "dovrebbero" all'inizio della definizione dei requisiti funzionali. “Il sistema deve...”

La descrizione include:

a) Validazione dei dati di input

b) Sequenza esatta di azioni

c) Azioni in caso di situazioni eccezionali, inclusi

1) Traboccamento

2) Strutture di comunicazione

3) Gestione e ripristino degli errori

d) Influenza dei parametri

e) Relazioni tra input e output, inclusi

1) Sequenze di ingresso/uscita

2) Formule per convertire i dati di input in dati di output

È possibile definire la suddivisione dei requisiti funzionali in sottofunzioni o sottoprocessi. Ciò non implica che il software in fase di sviluppo avrà la stessa divisione.

5.3.3 Requisiti prestazionali

Questa sottosezione specifica i requisiti per le caratteristiche numeriche statiche e dinamiche. Questi requisiti possono includere:

a) Numero di terminali da supportare

b) Numero di utenti simultanei che devono essere supportati

c) Quantità e tipologia dei dati da trattare

I requisiti per le caratteristiche numeriche statiche sono talvolta separati in una sezione separata denominata Carico di sistema.

I requisiti per le caratteristiche numeriche dinamiche possono includere, ad esempio, il numero di transazioni e attività, la quantità di dati che verranno elaborati entro determinati intervalli di tempo per condizioni di carico di lavoro normali e di punta.

Tutti questi requisiti devono essere espressi in termini di unità di misura.

Ad esempio, il 95% delle transazioni dovrebbe essere elaborato in meno di 1 s invece che l’operatore debba attendere per completare la transazione.

NOTA: le limitazioni numeriche che si applicano a una funzione specifica sono generalmente specificate come parte di un sottoparagrafo nella descrizione del funzionamento di quella funzione.

5.3.4 Requisiti del database logico

È qui che vengono definiti i requisiti logici per qualsiasi informazione che deve essere inserita nel database. Può includere:

d) Tipologie di informazioni utilizzate dalle diverse funzioni

e) Frequenza di utilizzo

f) Modalità di accesso.

g) Entità dei dati e loro relazioni

h) Vincoli di integrità

i) Requisiti di conservazione dei dati

5.3.5 Vincoli di progettazione

Ciò definisce i vincoli di progettazione che possono essere imposti da altri standard, limitazioni dell'hardware del computer, ecc.

5.3.5.1 Conformità agli standard

Questa sottosezione dovrebbe definire i requisiti che derivano da norme o regolamenti esistenti. Può includere:

a) Formato del messaggio

b) Denominazione dei dati

c) Procedure contabili

d) Tracciabilità dell'audit

Ad esempio, è possibile definire un requisito per il software per registrare il processo di elaborazione. Tale protocollo è necessario affinché alcune applicazioni soddisfino i requisiti minimi degli standard normativi o finanziari. Un requisito di registrazione potrebbe, ad esempio, specificare che tutte le modifiche al database dei salari debbano essere registrate in un file di registro con i valori prima e dopo le modifiche.

5.3.6 Attributi del sistema software

Esistono molte caratteristiche del software che possono fungere da requisiti. È importante che questi requisiti siano definiti in modo tale da poter essere verificati in modo oggettivo. I paragrafi seguenti forniscono esempi di alcune caratteristiche.

5.3.6.1 Affidabilità

Ciò definisce i fattori necessari per stabilire l'affidabilità richiesta del software di sistema al momento della consegna.

5.3.6.2 Disponibilità

Ciò definisce i fattori necessari per garantire un certo livello di disponibilità dell'intero sistema, come punti di interruzione, ripristino e riavvio.

5.3.6.3 Sicurezza

Definisce i fattori che dovrebbero garantire che il software sia protetto da accesso, utilizzo, modifica, distruzione o divulgazione accidentali o dannosi. I requisiti specifici in questo settore potrebbero includere quanto segue:

a) Utilizzare alcuni metodi di crittografia

c) Assegnare alcune funzioni a diversi moduli

d) Limitare le connessioni tra alcune aree del programma

e) Controllare l'integrità dei dati per le variabili critiche

5.3.6.4 Manutenibilità

Qui vengono definiti i parametri del software che si riferiscono direttamente alla facilità di manutenzione del software. Potrebbero esserci alcuni requisiti per definire modularità, interfacce, complessità, ecc. I requisiti non dovrebbero essere pubblicati qui semplicemente perché si ritiene che costituiscano una buona pratica di progettazione.

5.3.6.5 Portabilità

Ciò definisce i parametri del software che riguardano la facilità di portabilità del software su altre macchine e/o sistemi operativi. Può includere:

f) Percentuale di componenti con codice dipendente dalla macchina

g) Percentuale di codice che dipende dalla macchina

h) Utilizzo di un linguaggio portabile e comprovato

i) Utilizzo di un compilatore specifico o di un sottoinsieme di linguaggi

j) Utilizzo di un sistema operativo specifico

5.3.7 Organizzazione dei requisiti specifici

Per i sistemi non banali, i requisiti dettagliati possono essere estesi. Per questo motivo si consiglia di strutturarli in modo da renderli facilmente comprensibili. Non esiste una struttura ottimale per tutti i sistemi. Vari modi di strutturare i requisiti per le diverse classi di sistemi sono forniti nella Sezione 3 dell'SRS. Alcune strutture sono descritte nelle sottosezioni seguenti.

5.3.7.1 Modalità sistema

Alcuni sistemi si comportano in modo molto diverso a seconda della modalità operativa. Ad esempio, un sistema di controllo può avere diversi insiemi di funzioni a seconda dell'utilizzo: formazione, normale o emergenza. Nell'organizzare la suddivisione in modalità, utilizzare gli schemi riportati nelle sezioni 1 o 2 dell'Appendice A. La scelta è determinata dalla dipendenza delle interfacce e dell'esecuzione del programma dalla modalità operativa.

5.3.7.2 Classi utente

Alcuni sistemi forniscono diversi set di funzioni per diverse classi di utenti. Ad esempio, un sistema di controllo di un ascensore presenta diverse opzioni ai passeggeri, agli addetti alla manutenzione e ai vigili del fuoco. Utilizzare lo schema mostrato nella Sezione 3 dell'Appendice A per organizzare questa sezione.

5.3.7.3 Oggetti

Gli oggetti sono entità reali che hanno un duplicato all'interno del sistema. Ad esempio, in un sistema di monitoraggio dei pazienti, gli oggetti sono pazienti, sensori, infermieri, stanze, medici, farmaci, ecc. Ogni oggetto è associato ad un insieme di attributi (di quell'oggetto) e funzioni (eseguite da quell'oggetto). Queste funzioni chiamano anche servizi, metodi o processi. Quando organizzi questa sezione, usa lo schema

mostrato nella Sezione 4 dell'Appendice A. Si noti che gli insiemi di oggetti possono essere separati da attributi e servizi. Sono raggruppati come classi.

5.3.7.4 Caratteristiche

Una caratteristica è un servizio desiderato esternamente fornito da un sistema che può richiedere una sequenza di input per produrre l'output desiderato. Ad esempio, in un sistema telefonico, le funzionalità includono chiamate intraurbane, chiamate rapide e chiamate in conferenza. Ciascuna caratteristica è generalmente descritta in una sequenza di coppie di reazione all'impatto. Nell'organizzare questa sezione, utilizzare lo schema mostrato nella Sezione 5 dell'Appendice A.

5.3.7.5 Stimolo

Alcuni sistemi potrebbero essere meglio organizzati se le loro funzioni fossero descritte in termini di impatto. Ad esempio, le funzioni del sistema di atterraggio automatico di un aeromobile possono essere organizzate in sezioni per i seguenti effetti: perdita di potenza, raffica di vento, cambio improvviso di virata, eccessiva velocità verticale, ecc. Nell'organizzare questa sezione, utilizzare lo schema mostrato nella Sezione 6 dell'Appendice A.

5.3.7.6 Risposta

Alcuni sistemi potrebbero essere organizzati meglio se le loro funzioni fossero descritte in termini di generazione di reazioni. Ad esempio, le funzioni di un sistema di contabilità del personale possono essere organizzate in sezioni corrispondenti a tutte le funzioni associate alla creazione di un libro paga, corrispondenti a tutte le funzioni associate alla creazione di un elenco attuale dei dipendenti, ecc. Utilizzare la Sezione 6 dell'Appendice A (sostituire tutte le occorrenze delle parole “impatto” con “reazione”).

5.3.7.7 Gerarchia funzionale

Quando nessuno degli organigrammi di cui sopra è adatto, la funzionalità completa può essere organizzata in una gerarchia di funzioni organizzate da input comuni, output comuni o accesso comune ai dati interni. I diagrammi di flusso dei dati e i dizionari dei dati possono essere utilizzati per mostrare le relazioni tra funzioni e dati. Utilizzare il diagramma 7 nell'appendice A per organizzare questa sezione.

5.3.8 Commenti aggiuntivi

Quando viene definito un nuovo requisito, può seguire diversi metodi di strutturazione descritti in 5.3.7.7. In tali casi, strutturare i requisiti dettagliati in più gerarchie adattate alle esigenze speciali del sistema da specificare. Ad esempio, vedere 8 nell'Appendice A per l'organizzazione che combina classe utente e funzionalità. Eventuali requisiti aggiuntivi possono essere inseriti in una sezione separata alla fine dell'SRS.

Sono disponibili numerose descrizioni, metodi e strumenti di supporto automatizzati per assistere nella documentazione dei requisiti. Principalmente, il loro valore è una funzione della strutturazione. Ad esempio, quando si organizza per modalità, possono essere utili macchine a stati o diagrammi di stato; quando si struttura per oggetti, l'analisi orientata agli oggetti può essere utile; quando si struttura per caratteristiche, le sequenze “esposizione-risposta” possono essere utili; A

Quando si struttura in base alla gerarchia funzionale, possono essere utili i diagrammi di flusso dei dati e i dizionari dei dati.

In uno qualsiasi dei diagrammi forniti in 1-8, le sezioni denominate "Requisiti funzionali" possono essere scritte nella lingua madre (ad esempio inglese), in pseudocodice, in un linguaggio di descrizione del sistema o come quattro sottosezioni: Introduzione, Input, elaborazione, output.

5.4 Informazioni di supporto

Il supporto informativo facilita l'uso del software. Include

b) Indici

c) Applicazioni

5.5 Appendici

Le applicazioni non sono sempre considerate parte delle specifiche dei requisiti effettivi e non sono sempre necessarie. Questi possono includere

a) Esempi di formati di input/output, descrizioni dell'analisi dei costi di formazione o risultati del sondaggio tra gli utenti

b) Informazioni di supporto o preparatorie che possano aiutare i lettori dell'SRS

c) Descrizione dei problemi che verranno risolti utilizzando il software

d) Istruzioni speciali sull'imballaggio per il codice e le informazioni necessarie per requisiti di sicurezza, esportazione, avvio o altri requisiti

Se sono presenti allegati, il SRS deve dichiarare esplicitamente se gli allegati sono considerati o meno parte dei requisiti.

6 Appendice A (Informativa)

6.1 Modello sezione 3 delle STS organizzato per modalità: Versione 1
3 Requisiti dettagliati
3.1 Requisiti per le interfacce esterne



3.1.4 Interfacce di comunicazione

3.2.1 Modalità 1

3.2.2 Modalità 2
3.2.m. modalità m
3. 2. m.1 Requisito funzionale m.
3. 2. m.n Requisito funzionale m.n
3.3 Requisiti prestazionali
3.4 Limitazioni del progetto

3.6 Altri requisiti
6.2 Modello per la sezione 3 del STS organizzato per modalità: Versione 2
3. Requisiti dettagliati
3.1. Richieste funzionali
3.1.1 Modalità 1
3.1.1.1 Interfacce esterne
3.1.1.1.1 Interfacce utente
3.1.1.1.2 Interfacce hardware del computer
3.1.1.1.3 Interfacce software
3.1.1.1.4 Interfacce di comunicazione
3.1.1.2 Requisiti funzionali
3.1.1.2.1 Requisito funzionale 1
3.1.1.2.n Requisito funzionale n
3.1.1.3 Requisiti prestazionali
3.1.2 Modalità 2
3,1 m. Modalità m.
3.2 Limitazioni del progetto
3.3 Caratteristiche del software di sistema
3.4 Altri requisiti
6.3 Modello sezione 3 del SRS organizzato per classe di utenza
3 Requisiti dettagliati

3.1.1 Interfacce utente
3.1.2 Interfacce hardware del computer
3.1.3 Interfacce software
3.1.4 Interfacce di comunicazione
3.2 Requisiti funzionali
3.2.1 Classe utente 1
3.2.1.1 Requisito funzionale 1.1
3.2.1.n Requisito funzionale 1.n
3.2.2 Classe utente 2
3,2 m. Classe utente m.


3.3 Requisiti prestazionali
3.4 Limitazioni del progetto
3.5 Caratteristiche del software di sistema
3.6 Altri requisiti
6.4 Modello di sezione 3 del STS organizzato per oggetto
3 Requisiti dettagliati
3.1 Requisiti delle interfacce esterne
3.1.1 Interfacce utente
3.1.2 Interfacce hardware del computer
3.1.3 Interfacce software
3.1.4 Interfacce di comunicazione
3.2 Classi/oggetti
3.2.1 Classe/oggetto 1
3.2.1.1 Attributi (propri o ereditati)
3.2.1.1.1 Attributo 1
3.2.1.1.n Attributo n
3.2.1.2 Funzioni (metodi. Nativi o ereditari)
3.2.1.2.1 Requisito funzionale 1.
3.2.1.2.m Requisito funzionale m
3.2.1.3 Messaggi (ricevuti o inviati)
3.2.2 Classe/oggetto 2
3.2.p Classe/oggetto p
3.3 Requisiti prestazionali
3.4 Limitazioni del progetto
3.5 Caratteristiche del software di sistema
3.6 Altri requisiti
6.5 Modello per la sezione 3 del STS organizzato per caratteristiche
3 Requisiti dettagliati
3.1 Requisiti delle interfacce esterne
3.1.1 Interfacce utente
3.1.2 Interfacce hardware del computer
3.1.3 Interfacce software
3.1.4 Interfacce di comunicazione
3.2 Caratteristiche del sistema
3.2.1 Funzionalità del sistema 1
3.2.1.1 Introduzione/Scopo
3.2.1.2 Sequenza impatto/reazione
3.2.1.3 Requisiti funzionali associati
3.2.1.3.1 Requisito funzionale 1
3.2.1.2.n Requisito funzionale n
3.2.2 Funzionalità del sistema 2
3.2.m Caratteristica del sistema m.
3.3 Requisiti prestazionali
3.4 Limitazioni del progetto
3.5 Caratteristiche del software di sistema
3.6 Altri requisiti
6.6 Modello per la sezione 3 dell'SRS organizzato per impatto
3 Requisiti dettagliati
3.1 Requisiti delle interfacce esterne
3.1.1 Interfacce utente
3.1.2 Interfacce hardware del computer
3.1.3 Interfacce software
3.1.4 Interfacce di comunicazione
3.2 Requisiti funzionali
3.2.1 Impatto 1
3.2.1.1 Requisito funzionale 1.1
3.2.1.n Requisito funzionale l.n
3.2.2 Impatto 2
3,2 m Impatto m
3.2.m.1 Requisito funzionale m.1
3.2.m.n Requisiti funzionali m.n
3.3 Requisiti prestazionali
3.4 Limitazioni del progetto
3.5 Caratteristiche del software di sistema
3.6 Altri requisiti
6.7 Modello per la sezione 3 dell'SRS organizzato per gerarchia funzionale
3 Requisiti dettagliati
3.1 Requisiti delle interfacce esterne
3.1.1 Interfacce utente
3.1.2 Interfacce hardware del computer
3.1.3 Interfacce software
3.1.4 Interfacce di comunicazione
3.2 Requisiti funzionali
3.2.1 Flussi informativi
3.2.1.1 Diagramma del flusso di dati 1
3.2.1.1.1 Entità dati
3.2.1.1.2 Processi pertinenti
3.2.1.1.3 Topologia
3.2.1.2 Diagramma del flusso di dati 2
3.2.1.2.1 Entità dati
3.2.1.2.2 Processi pertinenti
3.2.1.2.3 Topologia
3.2.1.n Diagramma del flusso dei dati n
3.2.1.n.1 Entità dei dati
3.2.1.n.2 Processi pertinenti
3.2.1.n.3 Topologia
3.2.2 Descrizione dei processi
3.2.2.1 Processo 1
3.2.2.1.1 Entità di dati di input
3.2.2.1.2 Algoritmo o formula del processo
3.2.2.1.3 Entità dei dati interessate
3.2.2.2 Processo 2
3.2.2.2.1 Entità di dati di input
3.2.2.2.2 Algoritmo o formula del processo
3.2.2.2.3 Entità dei dati interessate
3.2.2.m Processo m
3.2.2.m.1 Entità di dati di input
3.2.2.m.2 Algoritmo o formula del processo
3.2.2.m.3 Entità dei dati interessate
3.2.3 Specifiche della struttura dei dati
3.2.3.1 Struttura 1
3.2.3.1.1 Tipo di record
3.2.3.1.2 Campi elementari
3.2.3.2 Struttura 2
3.2.3.2.1 Tipo di record
3.2.3.2.2 Campi elementari
3.2.3.p Struttura pag
3.2.4 Dizionario dei dati
3.2.4.1 Dato 1
3.2.4.1.1 Nome
3.2.4.1.2 Presentazione
3.2.4.1.3 Unità/formato
3.2.4.1.4 Precisione/Accuratezza
3.2.4.1.5 Intervallo di valori
3.2.4.2 Dato 2
3.2.4.2.1 Nome
3.2.4.2.2 Presentazione
3.2.4.2.3 Unità/formato
3.2.4.2.4 Precisione/Accuratezza
3.2.4.2.5 Intervallo di valori
3.2.4.1.q Dato q
3.2.4.q.1 Nome
3.2.4.q.2 Presentazione
3.2.4.q.3 Unità/formato
3.2.4.q.4 Precisione/Accuratezza
3.2.4.q.5 Portata
3.3 Requisiti prestazionali
3.4 Limitazioni del progetto
3.5 Caratteristiche del software di sistema
3.6 Altri requisiti
6.8 Modello per la sezione 3 delle STS che mostra più organizzazioni
3 Requisiti dettagliati
3.1 Requisiti delle interfacce esterne
3.1.1 Interfacce utente
3.1.2 Interfacce hardware del computer
3.1.3 Interfacce software
3.1.4 Interfacce di comunicazione
3.2 Requisiti funzionali
3.2.1 Classe utente 1
3.2.1.1 Caratteristica 1.1
3.2.1.1.1 Introduzione/Scopo
3.2.1.1.2 Sequenza impatto/reazione
3.2.1.1.3 Requisiti funzionali associati
3.2.1.2 Caratteristica 1.2
3.2.1.2.1 Introduzione/Scopo
3.2.1.2.2 Sequenza stimolo/risposta
3.2.1.2.3 Requisiti funzionali associati
3.2.1.m. Caratteristica 1.m
3.2.1.m.1 Introduzione/Scopo.
3.2.1.m.2 Sequenza impatto/reazione
3.2.1.m.3 Requisiti funzionali associati
3.2.2 Classe utente 2
3.2.n Classe utente n
3.3 Requisiti prestazionali
3.4 Limitazioni del progetto
3.5 Caratteristiche del software di sistema
3.6 Altri requisiti

• In contatto con

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

Standard	Nome	Descrizione	All'uscita
12207 IEEE, ISO/IEC, GOST R ISO/IEC	Processi del ciclo di vita del software	La presente norma internazionale stabilisce, utilizzando una terminologia chiaramente definita, un quadro generale per i processi del ciclo di vita del software che può essere utilizzato per guidare l'industria del software.	1) Estratti dai rapporti degli utenti sui difetti identificati e sugli aggiustamenti proposti (p. 5.5.2.1 GOST R ISO/IEC 12207) 2) Proposte di aggiustamento (pag.5.5.2.3 #M12291 1200009075 GOST R ISO/IEC 12207#S ) 3) Notifica agli utenti del rilascio di una nuova versione dell'AS (clausola.5.5.2.5 #M12291 1200009075 GOST R ISO/IEC 12207#S ) 4) Piano di trasferimento oggetto (p.5.5.5.2 #M12291 1200009075 GOST R ISO/IEC 12207)
14764 ISO/IEC GOST RISOIEC	Supporto software (Normativa per l’Ingegneria del Software – Manutenzione del Software)	Questo standard descrive in dettaglio il processo di manutenzione stabilito nel 12207 ( ISO/IEC #M12291 1200009075 GOST R ISO/IEC)
9126 ISO/IEC GOST R ISO/IEC	Tecnologie dell'informazione. Valutazione di prodotti software. Caratteristiche di qualità e linee guida per il loro utilizzo	I manutentori devono disporre di un programma di garanzia della qualità del software che copra sei caratteristiche di qualità, installato in #M12291 1200009076 GOST R ISO/IEC 9126#S. Durante la manutenzione di uno strumento software, deve essere implementato un processo appropriato per identificare, descrivere, selezionare, applicare e migliorare i metodi per valutare (misurare) le caratteristiche di questo strumento	Caratteristiche di qualità: 1) Funzionalità 2) Affidabilità 3) Praticità 4) Efficienza 5) Manutenibilità 6) Mobilità
GOST 34.603-92	Tipologie di test dei sistemi automatizzati	La norma stabilisce le tipologie di test AS e i requisiti generali per la loro conduzione. I test della centrale nucleare vengono eseguiti nella fase di “Commissioning” in conformità con GOST 34.601 al fine di verificare la conformità della centrale nucleare creata con i requisiti delle specifiche tecniche (TOR)	Per pianificare tutti i tipi di test, viene sviluppato un documento "Programma e metodologia di test." Il programma di test autonomo indica: 1) elenco (funzioni da testare; 2) descrizione delle relazioni tra l'oggetto del test e altre parti del software; 3) condizioni, procedura e metodi di test ed elaborazione dei risultati; 4) criteri per l'accettazione delle parti in base ai risultati dei test. Durante il funzionamento di prova della sottostazione viene effettuato registro di lavoro, che contiene informazioni sulla durata di funzionamento dell'AS, guasti, malfunzionamenti, emergenze, modifiche dei parametri dell'oggetto di automazione, adeguamenti continui della documentazione e del software e adeguamento delle apparecchiature tecniche.
IEEE 1219-1998	Standard IEEE per la manutenzione del software (Norma per la manutenzione del software)	Questo standard descrive un processo iterativo per la gestione e l'esecuzione delle attività di manutenzione del software. L'uso di questo standard non è limitato dalle dimensioni, dalla complessità, dalla criticità o dall'applicazione del prodotto software.

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

Dati in ingresso	Fase di manutenzione	Produzione	Uscita al paragrafo
Versione base dell'altoparlante, messaggi di errore da parte degli utenti	Analisi dei difetti e delle modifiche	Conferma (non conferma) di un errore o difetto, esempio di modifica	Estratti dai rapporti degli utenti sui difetti identificati e suggerimenti per la correzione.
Proposte di modifica accettate documentate nel registro dei difetti	Attuazione della modifica	Modifiche implementate e documentate	Determinazione di cosa è soggetto a modifica (analisi del registro dei difetti identificati e proposte di correzione).
Modifiche effettuate, documentate nel registro degli adeguamenti predisposti e approvati	Valutazione e accettazione dei risultati del supporto	Approvazione del completamento soddisfacente della modifica come definito nel contratto di manutenzione	Avviso preparato agli utenti sul rilascio di una nuova versione del sistema di altoparlanti
Piano di migrazione	Trasferimento su un'altra piattaforma (in un altro ambiente)	Piano di migrazione completato, notifica agli utenti della migrazione	Descrizione del piano di migrazione. Notificare all'utente i piani e le azioni di trasferimento.

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

GOST 34.603-92 Tipi di test di sistemi automatizzati

IEEE 1219-1998 Standard IEEE per la manutenzione del software

Manutenzione Software (Manutenzione Software tramite SWEBOK) // ‒ Modalità di accesso:

Rivista “Rete” n. 2.2001 Articolo “Ciclo di vita dei sistemi informativi” // ‒ Modalità di accesso: http://www.setevoi.ru/cgi-bin/text.pl/magazines/2001/2/44

Metodologia e tecnologia per lo sviluppo di sistemi informativi. Profili dei sistemi informativi aperti // ‒ Modalità di accesso: http://gendocs.ru/v7394/lectures_on_theory_of_information_processes_and_systems?page=9

Numero di visualizzazioni della pubblicazione: attendere prego

Baryshnikova Marina Yurievna
MSTU im. NE Bauman
Caf. IU-7

Lezione 3

Ciclo di vita del software
disposizione

Ciclo di vita del software

è un periodo di tempo che inizia con
momento del processo decisionale
la necessità di creare software
disposizione e termina in questo momento
la sua completa cessazione dal servizio
(IEEE Std. 610.12 – Glossario standard del software 19990
Terminologia ingegneristica)

Concetti di base coinvolti nella definizione del ciclo di vita

Gli artefatti sono informazioni create dall'uomo
entità - documenti, in un senso abbastanza generale
partecipanti come dati di input e risultanti
qualità dei risultati delle varie attività.
Il ruolo è un gruppo astratto di persone interessate,
coinvolti nella creazione e nel funzionamento di
sistemi che risolvono gli stessi problemi o hanno gli stessi
e gli stessi interessi in relazione a lei
Prodotto software: un insieme di programmi per computer,
procedure ed eventuale documentazione associata e
dati
Un processo è un insieme di azioni correlate,
trasformare alcuni dati in input in output

Ciclo di vita del software secondo lo standard ISO/IEC 12207:1995
"Tecnologia internazionale - Processi del ciclo di vita del software"
(GOST ISO IEC 12207-99 Tecnologie dell'informazione.
Ciclo di vita del software)
Ciclo vitale
Organizzativo
processi
Controllo
progetto
Creazione
infrastruttura
Valutazione e miglioramento
ciclo vitale
Formazione scolastica
Di base
processi
Acquisizione
Ausiliario
processi
Documentazione
Fornitura
Controllo
configurazione
Sviluppo
Sicurezza
qualità
Sfruttamento
Verifica
Scorta
Certificazione
Giunto
grado
Controllo
Autorizzazione
i problemi

Processo di acquisizione del software
Determina le azioni del cliente che acquista il software
software o servizi relativi al software basati su contratto
relazioni
Durante questo processo, il cliente esegue quanto segue:
Azioni:
consapevolezza delle vostre esigenze nel sistema software e
prendere decisioni riguardanti l'acquisto, lo sviluppo personalizzato
o miglioramenti a un sistema esistente;
preparazione di proposte di offerta contenenti i requisiti per
sistema, le sue condizioni operative e tecniche
restrizioni e altre clausole contrattuali
L’acquisizione è il processo per ottenere un sistema,
prodotto software o servizio software

Processo di consegna
Determina le azioni dell'organizzazione fornitrice in merito
in relazione alle proposte di offerta del cliente
Il processo include:
considerazione delle proposte di offerta del cliente e inserimento nelle stesse
le tue modifiche (se necessarie);
predisposizione di un accordo con il cliente;
pianificare l’esecuzione del lavoro (in questo caso il lavoro può
effettuato in proprio o con il coinvolgimento di un subappaltatore);
sviluppo della struttura organizzativa del progetto, tecnica
requisiti per l'ambiente e le risorse di sviluppo, misure per
gestione del progetto, ecc.
Il processo di consegna è responsabile dell'esecuzione dei processi
sviluppo, funzionamento e (o) manutenzione

Processo di sviluppo

Definisce le azioni eseguite dallo sviluppatore in
il processo di creazione del software e i suoi
componenti secondo i requisiti specificati
Questo processo include, ma non è limitato a:
registrazione della progettazione e operativa
documentazione;
preparazione dei materiali necessari per la verifica
operabilità del prodotto software e dei suoi
rispetto degli standard di qualità;
sviluppo di materiali (metodologici e didattici),
necessari per la formazione e l'istruzione del personale e
eccetera.

Processo di sviluppo

Scelta di un modello di ciclo di vita
Analisi dei requisiti di sistema
Progettazione dell'architettura del sistema
Analisi dei requisiti software
Progettazione dettagliata del software
Codificazione e test del software
Integrazione del software
Test di qualificazione del software
Integrazione del sistema
Test di qualificazione del sistema
Installazione software
Accettazione del software

10. Analisi dei requisiti di sistema

In questa fase viene considerato l’ambito di applicazione del sistema.
L'elenco dei requisiti per il sistema in fase di sviluppo dovrebbe includere:
insieme di condizioni in cui è destinato a funzionare
sistema futuro (risorse hardware e software,
forniti al sistema; condizioni esterne del suo funzionamento;
composizione delle persone e delle opere ad essa legate);
descrizione delle funzioni svolte dal sistema;
restrizioni nel processo di sviluppo (scadenze della direttiva per il completamento).
singole fasi, risorse disponibili, modalità organizzative
e misure per garantire la protezione delle informazioni, ecc.)
I requisiti di sistema vengono valutati in base ai criteri
fattibilità e verificabilità durante i test

11. Analisi dei requisiti software

Implica determinare quanto segue
caratteristiche per ciascun componente software:
funzionalità, incluso
caratteristiche prestazionali e ambientali
funzionamento dei componenti
interfacce esterne
specifiche di affidabilità e sicurezza;
requisiti ergonomici
requisiti per i dati utilizzati
requisiti di installazione e accettazione
requisiti di documentazione per l'utente
requisiti per il funzionamento e la manutenzione

12. Progettazione dell'architettura software

Architettura del software
è una descrizione di sottosistemi e componenti software
sistemi e le connessioni tra di essi
Nell’ambito della progettazione di un’architettura per tutti
Il componente software esegue le seguenti attività:
definire una struttura ad alto livello di astrazione
software e la composizione dei suoi componenti
sviluppo e documentazione di software
interfacce software e database
sviluppo di una versione preliminare di una consuetudine
documentazione
sviluppo e documentazione dei preliminari
requisiti di test e piano di integrazione del software

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

Include le seguenti attività:
descrizione dei componenti software e delle interfacce tra
loro in una quantità sufficiente per loro
successiva codifica indipendente e
test
sviluppo e documentazione dettagliata
progetto di banca dati
aggiornamento della documentazione utente
sviluppo e documentazione dei requisiti per
test e piano di test dei componenti software

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

sviluppo (codifica) e documentazione
ogni componente software e database, nonché
insieme di procedure di test e dati per
test
testare ogni componente software e database
dati per il rispetto dei requisiti ad essi relativi
requisiti
aggiornando (se necessario) l'utente
documentazione
aggiornamento del piano di integrazione software

15. Integrazione del sistema

consiste nell'assemblare il tutto
componenti, inclusi software e
attrezzature e test
componenti aggregati
Il processo di integrazione produce anche
registrazione e verifica del set completo
documentazione del sistema

16. Test di qualificazione del software

effettuato dallo sviluppatore in presenza
cliente per dimostrare che il software
soddisfa le sue specifiche e
pronto per l'uso in condizioni
operazione
Ciò controlla anche la completezza
documentazione tecnica e d'uso e
la sua adeguatezza ai componenti software

17. Installazione e accettazione del software

L'installazione del software viene eseguita dallo sviluppatore in
secondo il piano in quell'ambiente e su quello
attrezzature previste dal contratto. IN
Durante il processo di installazione viene verificata la funzionalità
Software e banche dati
L'accettazione del software implica la valutazione dei risultati
test di qualificazione del sistema e
documentazione dei risultati della valutazione, che
prodotto dal cliente con l'aiuto dello sviluppatore.
Lo sviluppatore esegue il trasferimento finale del software
al cliente in conformità al contratto, garantendo
con la formazione e il supporto necessari

18. Funzionamento del software

Il sistema è gestito in
ambiente destinato a questo scopo
secondo la consuetudine
documentazione
Include l'installazione
standard operativi e
svolgimento operativo
test

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

apportare modifiche al software per correggere
bug, miglioramenti delle prestazioni o
adattamento alle mutate condizioni di lavoro
o requisiti
Funzioni del servizio di supporto:
analisi delle problematiche e richieste di modifiche software
modifica di un prodotto software
la sua verifica ed accettazione
trasferire il software in un altro ambiente
smantellamento del software

20. Supportare i processi del ciclo di vita del software

Documentazione
Gestione della configurazione
Garanzia di qualità
Verifica
Certificazione
Valutazione partecipativa
Controllo
Risoluzione del problema

21. Processo di documentazione

Documentazione - descrizione formalizzata
informazioni create ovunque
ciclo di vita del software
Questo è un insieme di azioni attraverso le quali
pianificare, progettare, sviluppare,
produrre, modificare, distribuire e
accompagnare i documenti necessari per tutti
stakeholder coinvolti nello sviluppo
Software, così come per gli utenti del sistema

22. Gestione della configurazione

La configurazione del software è
la totalità delle sue funzioni funzionali e fisiche
caratteristiche stabilite nella scheda tecnica
documentazione e implementati nei programmi
Il processo consente di organizzare, in modo sistematico
prendere in considerazione e controllare le modifiche
Software in tutte le fasi del ciclo di vita
Vengono riflessi i principi generali e le raccomandazioni per la gestione della configurazione
nello standard ISO/IEC CD 12207 – 2:1995 “Tecnologia dell'informazione – Software”
Processi del ciclo. Parte 2. Gestione della configurazione per il software”

23. Processo di garanzia della qualità

Fornisce la garanzia che il prodotto software e
i suoi processi del ciclo di vita corrispondono a quanto specificato
requisiti, nonché sviluppati e approvati
piani di lavoro
La qualità è un insieme di proprietà che caratterizzano
capacità del software di soddisfare
dati i requisiti e le esigenze di tutti gli interessati
partiti
Il processo è progettato per garantire la conformità
processi del ciclo di vita, ambiente di sviluppo e
qualificazione del personale secondo i termini del contratto stabilito
norme e procedure. Per questo deve esserci
la qualità del prodotto, la qualità del processo e altri sono garantiti
indicatori di qualità del sistema

24. Verifica

Questo è il processo per determinare se lo stato attuale di sviluppo è conforme
raggiunti in questa fase, i requisiti di questa fase. In corso
la verifica verifica le seguenti condizioni:
coerenza dei requisiti di sistema e grado di considerazione delle esigenze
utente
capacità del fornitore di soddisfare i requisiti specificati
conformità dei processi del ciclo di vita selezionati con i termini del contratto
adeguatezza degli standard, delle procedure e dell'ambiente di sviluppo ai processi del ciclo di vita del software
conformità delle specifiche di progettazione ai requisiti specificati
correttezza della descrizione nelle specifiche di progettazione degli input e degli output
dati, sequenza di eventi, logica, ecc.
conformità del codice alle specifiche e ai requisiti di progettazione
testabilità e correttezza del codice, sua conformità agli standard accettati
codifica
corretta integrazione dei componenti software nel sistema
adeguatezza, completezza e coerenza della documentazione
La verifica è un insieme di azioni confrontate
il risultato del ciclo di vita ottenuto con le caratteristiche richieste
per questo risultato, che è considerato una prova formale
correttezza del software

25. Certificazione

prevede la determinazione della completezza
conformità ai requisiti specificati e
sistema o software creato
prodotto alle loro specifiche
scopo funzionale
Verifica e certificazione: due visioni della qualità:
se la verifica valuta il software in termini di come è stato creato,
quindi la certificazione considera il sistema software dal punto di vista
cosa fa (vale a dire viene valutata la capacità del sistema software
soddisfare le esigenze funzionali degli utenti)

26. Processi organizzativi del ciclo di vita del software

Controllo
Creazione di infrastrutture (infrastruttura
il progetto software include tecnologie e
standard, nonché una serie di hardware,
software e strumenti per
sviluppo, funzionamento o manutenzione di software)
Miglioramento
Formazione (formazione iniziale e
successivo aumento permanente
qualifiche del personale, compreso lo sviluppo
materiale didattico)

27. Gruppi di norme DGUE

Codice del gruppo
0
1
2
3
4
5
6
7
8
9
Nome del gruppo
Disposizioni generali
Standard fondamentali
Regole per l'esecuzione della documentazione di sviluppo
Regole per il completamento della documentazione di produzione
Regole per l'esecuzione della documentazione di supporto
Regole per l'implementazione della documentazione operativa
Regole per la circolazione della documentazione software
Prenota gruppi
Altri standard
La designazione della norma DGUE è composta da:
numero 19 (assegnato alla classe delle norme DGUE);
una cifra (dopo il punto) che indica il codice del gruppo di classificazione delle norme,
indicato in tabella;
un numero di due cifre (dopo un trattino) che indica l'anno di registrazione della norma

28. Elenco dei documenti DGUE

GOST 19.001-77 DGUE. Disposizioni generali
GOST 19.101-77 DGUE. Tipi di programmi e documenti di programma
GOST 19.102-77 DGUE. Fasi di sviluppo
GOST 19.103-77 DGUE. Designazione di programmi e documenti di programma
GOST 19.104-78 DGUE. Iscrizioni di base
GOST 19.105-78 DGUE. Requisiti generali per i documenti di programma
GOST 19.106-78 DGUE. Requisiti per i documenti di programma stampati
GOST 19.201-78 DGUE. Compito tecnico. Requisiti di contenuto e design
GOST 19.202-78 DGUE. Specifica. Requisiti di contenuto e design
GOST 19.301-79 DGUE. Procedura e metodologia di prova
GOST 19.401-78 DGUE. Testo del programma. Requisiti di contenuto e design
GOST 19.402-78 DGUE. Descrizione del programma
GOST 19.404-79 DGUE. Nota esplicativa. Requisiti di contenuto e design
GOST 19.501-78 DGUE. Modulo. Requisiti di contenuto e design
GOST 19.502-78 DGUE. Descrizione dell'applicazione. Requisiti di contenuto e design
GOST 19.503-79 DGUE. Guida per il programmatore di sistema. Requisiti di contenuto e
registrazione
GOST 19.504-79 DGUE. Guida del programmatore
GOST 19.505-79 DGUE. Manuale dell'operatore
GOST 19.506-79 DGUE. Descrizione del linguaggio
GOST 19.508-79 DGUE. Manuale di manutenzione. Requisiti di contenuto e
registrazione
GOST 19.604-78 DGUE. Regole per apportare modifiche ai documenti di programma eseguiti
in forma stampata
GOST 19.701-90 DGUE. Schemi di algoritmi, programmi, dati e sistemi. Convenzioni e
regole di esecuzione
GOST 19.781-90. Fornitura di sistemi di elaborazione delle informazioni

29. Vantaggi derivanti dall'utilizzo degli standard DGUE

Le norme DGUE introducono un elemento di ordinamento
processo di documentazione del software
(PS);
nonostante i requisiti per il kit
documentazione del software prevista dalle norme
ESPD, ti consentono di aggiungere ulteriori tipi
documenti;
Gli standard ESPD ti consentono di cambiare cellulare
strutture e contenuti di specie stabilite
documenti di programma in base ai requisiti
cliente e utente

30. Svantaggi delle norme DGUE

orientamento verso un unico modello di vita “a cascata”.
ciclo del software;
mancanza di linee guida chiare sulla documentazione
caratteristiche di qualità del software;
mancanza di collegamento sistemico con altri esistenti
sistemi nazionali di norme sul ciclo di vita e
documentazione di prodotti in generale, ad esempio ESKD;
approccio poco chiaro alla documentazione del software
prodotti commerciali;
mancanza di raccomandazioni per l'autodocumentazione del software,
ad esempio, sotto forma di menu su schermo e strumenti di guida in linea
utente (“aiuta”);
mancanza di raccomandazioni su composizione, contenuto e design
documenti per il software concordato con
raccomandazioni di standard internazionali e regionali

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

1.
Formazione dei requisiti per gli oratori
2.
Sviluppo del concetto di AC
3.
Studiare l'oggetto
Svolgere il lavoro di ricerca necessario
Sviluppo di opzioni per il concetto AC e selezione di un'opzione per il concetto AC,
soddisfare i requisiti degli utenti
Redazione di una relazione sul lavoro svolto
Compito tecnico
4.
Ispezione dell'impianto e giustificazione della necessità di creare una centrale nucleare
Formazione dei requisiti utente per i relatori
Preparazione di una relazione sul completamento dei lavori e una domanda per lo sviluppo di una centrale nucleare
Sviluppo e approvazione delle specifiche tecniche per la realizzazione di centrali nucleari
Progetto preliminare
Sviluppo di soluzioni progettuali preliminari del sistema e delle sue parti

32.

Standard GOST 34.601-90: stadi e fasi
realizzazione di un sistema automatizzato
5.
Progetto tecnico
6.
Documentazione di lavoro
7.
Sviluppo della documentazione di lavoro per la centrale nucleare e le sue parti
Sviluppo e adattamento dei programmi
La messa in produzione
8.
Sviluppo di soluzioni progettuali per il sistema e le sue parti
Sviluppo della documentazione per il sistema di altoparlanti e le sue parti
Sviluppo ed esecuzione della documentazione per la fornitura di componenti
Sviluppo di attività di progettazione in parti adiacenti del progetto
Preparazione di un oggetto di automazione
Formazione del personale
Set completo di altoparlanti con prodotti in dotazione (software e hardware,
sistemi software e hardware, prodotti informatici)
Lavori di costruzione e installazione
Lavori di messa in servizio
Esecuzione di prove preliminari
Conduzione dell'operazione di prova
Esecuzione di test di accettazione
Supporto CA
Esecuzione dei lavori in conformità agli obblighi di garanzia
Servizio post-garanzia