La specifica dei requisiti software (SRS) si incentra sulla raccolta e
l'organizzazione di tutti i requisiti che circondano il progetto. Se si dispone di un piano di gestione dei requisiti,
consultarlo per determinare la giusta collocazione ed organizzazione dei requisiti. Ad esempio, potrebbe essere utile
disporre di SRS separate per descrivere i requisiti software completi per ciascuna funzione
in un particolare rilascio del prodotto. Ciò può includere diversi casi
d'uso provenienti dal modello di caso d'uso del sistema, per descrivere i requisiti
funzionali di questa funzione, oltre all'insieme pertinente di requisiti dettagliati nelle specifiche supplementari.
Poiché sono a disposizione diversi tool per la raccolta dei requisiti, è importante realizzare che la raccolta di
requisiti si trova in diversi artefatti e tool. Ad esempio, può essere appropriato raccogliere dei requisiti testuali
come i requisiti non funzionali, vincoli di progettazione, ecc, con un tool di documentazione di testo nelle specifiche supplementari. D'altra parte, potrebbe essere utile
raccogliere alcuni (o tutti) dei requisiti funzionali nei casi
d'uso ed utilizzare un tool appropriato alla necessità di definire il modello di caso d'uso.
Non esistono forti motivazioni per focalizzare l'attenzione sulle differenze fra i tool utilizzati. Dopo tutto si
stanno raccogliendo dei requisiti ed il vero punto focale deve essere la raccolta e l'organizzazione efficienti dei
requisiti, a prescindere dai tool a disposizione. Poiché l'attenzione è sui requisiti e non sui tool, si presuppone che
la raccolta di requisiti nella SRS costituisca un pacchetto di informazioni. L'elaborazione dei vari requisiti per il sistema
viene inclusa in un pacchetto che viene denominato specifica dei requisiti software (SRS).
Il pacchetto SRS è ovviamente correlato al documento Visione.
Sicuramente il documento della visione serve da input all'SRS. Ma i due artefatti servono ad esigenze diverse ed in
genere sono scritti da diversi autori. In questa fase del progetto, dal manifesto su larga scala relativo alle esigenze
dell'utente, agli scopi e agli obiettivi, ai mercati di destinazione e alle funzioni del sistema, l'attenzione si
sposta sui dettagli relativi a come verranno implementate le funzioni nella soluzione.
Quello che è necessario conoscere è una raccolta, o pacchetto, di artefatti che descrive il comportamento esterno
completo del sistema - ad esempio, un pacchetto che specifica "Questo è quello che il sistema deve compiere per
distribuire quelle funzioni". Questo è quello che viene definito come pacchetto SRS.
Il pacchetto SRS non è una sezione congelata, prodotta per garantire la conformità ISO 9000 e pertanto seppellito in un
angolo e ignorato quando il progetto continua. Invece è un artefatto attivo. Sicuramente dispone di diversi tipi di
utilizzo, quando gli sviluppatori intraprendono l'impegno lavorativo di implementazione: serve come base per le
comunicazioni fra tutte le parti - ad esempio, fra gli sviluppatori stessi e fra gli sviluppatori ed i gruppi esterni
(gli utenti ed altri stakeholder) con i quali devono comunicare. Formalmente o informalmente, rappresenta un accordo
contrattuale fra le varie parti - se non è incluso nel pacchetto SRS, gli sviluppatori non devono effettuarci delle
attività. Se invece è incluso nel pacchetto SRS, in quel caso sono autorizzati a distribuire quella funzionalità.
L'SRS serve da standard di riferimento per il responsabile di progetto. Il responsabile di progetto difficilmente
ha il tempo, l'energia o gli skill per leggere il codice generato dagli sviluppatori e confrontarlo direttamente con il
documento della visione. Deve utilizzare il pacchetto SRS come riferimento standard
per le discussioni con il team del progetto.
Come già affermato in precedenza, serve da input ai gruppi di progettazione e di implementazione. A seconda di come è
organizzato il progetto, gli implementatori potrebbero essere stati coinvolti in attività iniziali relative alla
risoluzione di problemi e alla definizione di funzioni che da ultimo hanno prodotto il documento Visione. Ma è sul
pacchetto SRS che devono incentrare l'attenzione per poter decidere cosa deve fare il loro codice. Serve da input per
la verifica del software e per i gruppi QA. Anche questi gruppi devono essere stati coinvolti in alcune delle
discussioni iniziali ed è ovviamente utile per loro avere una buona comprensione della "visione" trattata nei documenti
della visione. Ma il loro statuto è di creare degli scenari di test e delle procedure QA per assicurare che il sistema
sviluppato soddisfi davvero i requisiti disposti nel pacchetto SRS. Il pacchetto SRS serve inoltre come riferimento
standard per le loro attività di pianificazione e di verifica.
Consultare Linee guida: Modello di caso d'uso e Linee guida per il
prodotto di lavoro: Caso d'uso per una trattazione completa dell'approccio consigliato per la definizione dei
requisiti funzionali in un modello di caso d'uso e nei casi
d'uso.
I requisiti non funzionali del sistema devono essere documentati nel Prodotto di lavoro: Specifiche supplementari. Di seguito sono
riportate le linee guida da seguire per la definizione dei requisiti.
Quando si raccolgono e si convalidano i requisiti non funzionali, conservare degli elenchi di presupposizioni e
problematiche.
Alcune attività non forniscono delle risposte soddisfacenti. Questo può essere dovuto ad una mancanza di informazioni o
semplicemente perché si considera che la risposta mini alla viabilità della progettazione. E' utile, quindi, creare due
elenchi e gestirli durante lo studio del progetto:
Tutte le presupposizioni effettuate durante il processo dei requisiti e di progettazione, inclusi i processi relativi
al fondamento logico o ai ragionamenti dietro alle presupposizioni. Le presupposizioni possono essere utilizzate per
identificare i progetti secondari o le voci di lavoro correlati che sono al di fuori dell'ambito di questo progetto.
Eventuali importanti problematiche (situazioni significative che potrebbero rivelarsi degli show-stopper)
Queste problematiche devono essere riviste con il cliente al termine di ogni fase. Anche le presupposizioni devono
essere riviste al termine di ogni fase ma il cliente potrebbe non essere sempre la persona giusta per quelle di minore
importanza.
Le presupposizioni e le problematiche riguardano tutti i prodotti di lavoro ma sono comuni particolarmente per i
requisiti non funzionali.
Documenta l'organizzazione geografica dei client.
Documenta le posizioni geografiche della parte di business toccata da questo sistema. La definizione deve includere
anche le sedi non implicate, su cui risiedono i principali programmi di utilità IT. Creare un'annotazione speciale per
le eventuali parti mobili dell'organizzazione. Ad esempio un'unità organizzativa di vendite che si sposta ed utilizza
le workstation. Annotare qualsiasi ubicazione geografica alla quale si potrebbe dover fornire un supporto NLS speciale.
I requisiti specificano l'utilizzo di qualche pacchetto di applicazioni? Un "dato di fatto" molto importante che detta
pesantemente alcune delle decisioni di progettazione del sistema è l'utilizzo di uno specifico pacchetto applicativo
che fornisce una logica software e una organizzazione dei dati già predefinite. Alcuni pacchetti software sono
flessibili e consentono un ampio margine di personalizzazione; altri sono molto rigidi e non lo consentono. I pacchetti
possono dettare i componenti e le decisioni, ad esempio:
-
Tipo di workstation
-
Metodi di connessione
-
Tipo di processore e di DASD (Direct Access Storage Device)
-
Programma di controllo del sistema
-
Organizzazione, collocazione e gestione dei dati
-
Linguaggio di programmazione
-
Interfacce batch
-
Processo e relazioni dei dati
-
Logica di business
-
Progettazione delle schermate ed interfacce utente
-
Caratteristiche delle prestazioni e della disponibilità
-
Eventuale architettura richiesta o esistente per la stampa, come i formati di dati di stampa preferiti (ad esempio
PostScript, PCL, IPDT)
-
NLS (National Language Support)
E' importante capire quale influenza avrà sulla progettazione un determinato pacchetto. Se si dispone di un pacchetto
"fornito", accertarsi di disporre degli skill e della conoscenza giusti relativi al pacchetto. Possono provenire da:
-
Fornitore del pacchetto
-
Consulenti esterni
-
Membri del team di progettazione formati appositamente
Non dare per scontato che questa conoscenza sia prontamente disponibile. Verificare che sia disponibile al momento del
bisogno.
Documentare nei requisiti gli eventuali altri "dati di fatto" che limitano la flessibilità della progettazione.
Ciò è utile per cogliere eventuali requisiti specifici non coperti esplicitamente nelle attività precedenti che
potrebbero limitare la flessibilità della progettazione. Cercare quanto segue:
-
Utilizzo di processori o di immagini di sistemi operativi esistenti
-
Utilizzo di workstation esistenti
-
Utilizzo di una rete esistente
-
Utilizzo di pratiche di gestione sistemi esistenti
-
Utilizzo di un modello specifico, ad esempio: 'è necessario utilizzare un modello di sistema client/server per la
progettazione che mostri chiaramente la logica di presentazione/business/accesso dati e dove ed in che modo si
interfacciano'.
Qualcuno di questi "dati di fatto" influenza il nuovo sistema? Se il nuovo sistema andrà in esecuzione su un
processore, un'immagine di sistema operativo o configurazione di rete esistente, le caratteristiche della piattaforma
esistente e del carico di lavoro influenzeranno il nuovo sistema?
Quanta capacità di connessione e di elaborazione è stata già utilizzata dai carichi di lavoro esistenti?
Quali controlli di sicurezza sono utilizzati dai carichi di lavoro esistenti? Prenderne nota e verificarli rispetto ai
requisiti di sicurezza del nuovo sistema, quando si prende in considerazione quest'ultimo.
Quali sono le caratteristiche di disponibilità del carico di lavoro esistente?
Prender nota di qualsiasi cosa possa influire sulla successiva progettazione della disponibilità per il nuovo sistema.
Ad esempio, il carico di lavoro esistente insiste nello spegnere l'intero processore ogni notte?
I requisiti specificano l'utilizzo di un hardware particolare?
Questo potrebbe essere menzionato in termini generici ("il sistema deve essere supportare un plotter flat-bed ad alta
velocità") o essere più specifici ("verranno supportate le ATM Panda Corp esistenti"). Documentare il più possibile:
-
Qualsiasi prerequisito hardware o software
-
I fornitori e le relative organizzazioni di supporto
-
Considerazioni su NLS (National Language Specification)
-
Strumentazione per la crittografia
I requisiti specificano l'utilizzo di dati esistenti? In tal caso, questo influenzerà la progettazione del sistema.
Documento:
-
Su quale(i) sistema(i) al momento esistono i dati
-
La sua struttura (ad esempio, relazionale o file piatto)
-
La sua dimensione
-
Quali utenti e quali sistemi utilizzano questi dati oggi
-
Considerazioni sulla disponibilità (ad esempio i periodi in cui i dati non sono disponibili a causa di attività
batch o di manutenzione del database)
-
I dati possono essere spostati o copiati?
Il client dispone di un'architettura tecnica e/o di un piano IT strategico (o un insieme equivalente di standard)?
Un'architettura tecnica equivale grossolanamente a quanto segue:
-
Piattaforma tecnica dell'impresa
-
Infrastruttura tecnica dell'impresa
-
Architettura della tecnologia
In un'architettura tecnica potrebbero essere definiti alcuni dei seguenti elementi:
-
Il numero e l'utilizzo dei centri di calcolo
-
La connettività di rete dell'impresa (WAN)
-
La connettività localizzata di determinate sedi (LAN)
-
Servizi di infrastrutture client/server (middleware) con
· Directory e servizi di denominazione che tengono traccia delle risorse di rete e degli attributi
· Servizi di sicurezza che proteggono, mediante la registrazione degli utenti e dei relativi livelli di
autorizzazione, le risorse di rete da un utilizzo non autorizzato
· Servizi di data e ora che regolano la data e l'ora nella rete
· Servizi di gestione delle transazioni che coordinano il recupero delle risorse nei vari sistemi di una rete
-
I metodi di sviluppo che verranno utilizzati per le nuove applicazioni
-
L'insieme accettato di prodotti supportati, ad esempio:
· Hardware
· Il software di controllo del sistema
· Il software applicativo, ad esempio "Office"
· L'utilizzo dell'help desk
· Regole di sicurezza
-
L'architettura del sottosistema di stampa
L'elenco può essere molto esteso e le voci contenute possono essere sorvegliate in modo molto rigido oppure possono non
essere imposte in alcun modo.
Documentare gli eventuali requisiti che richiedono o escludono in modo specifico l'utilizzo di architetture secondarie
come:
-
OSI o SNA
-
UNIX**
-
SAA
-
PS/2* con OS/2* EE.
Architetture particolari che possono essere coinvolte dall'utilizzo di una soluzione applicativa in pacchetto.
Ricordare che alcuni pacchetti applicativi sono delle definizioni strutturali, a loro modo.
Documentare il grado di apertura (cioè l'indipendenza dal fornitore e l'interoperabilità) richiesto dal client. Se
esiste un'architettura tecnica, quasi sicuramente la progettazione dovrà conformarsi ad essa. E' necessario leggerla e
capire le regole che influenzeranno la progettazione del sistema.
Il client possiede un'architettura di rete alla quale il sistema deve conformarsi? Un'architettura di rete è un insieme
di regole comuni per la connettività ad alto livello, con in più un'infrastruttura comune di trasporto. Può essere
compresa la definizione di una rete dorsale (backbone), inclusi i concentratori e le linee. Se è presente questo tipo
di architettura, comprendere le regole essenziali e la topologia e documentare:
Le considerazioni relative alla topologia fisica (vale a dire se la rete è essenzialmente cittadina o di periferia e se
o collegamenti di rete sono densamente popolati piuttosto che scarsamente distribuiti).
Quali funzioni di connessione ad alto livello sono supportate dall'attuale infrastruttura di rete.
Quali sono gli standard di comunicazione utilizzati (ad esempio SNA, OSI, TCP/IP) per supportare queste funzioni di
connessione.
Quali sono le interfacce di programmazione supportate.
Eventuali definizioni di architettura di rete della connettività fra i livelli client/server o i livelli del modello di
sistema di base, come:
-
L'accesso ai dati relazionali fra le workstation client ed i server LAN relazionali deve avvenire tramite i
protocolli di uno specifico prodotto di database relazionale.
-
La logica di presentazione deve essere sempre presente nella workstation e la logica di accesso ai dati deve essere
sempre presente in un sistema host centralizzato.
Il client dispone di criteri per la connessione?
Anche se non si dispone di architetture tecniche o di rete, è possibile disporre di alcuni criteri di connessione.
Documentare qualsiasi criterio che riguarda:
-
L'utilizzo di particolari protocolli o programmi di utilità per la comunicazione (per connessioni all'interno di un
singolo edificio o esterne all'edificio o all'organizzazione).
-
Se sono richiesti implicitamente dei particolari protocolli per supportare la strumentazione o il software
esistente.
-
Se devono essere utilizzate le infrastrutture di connettività fisica già esistenti (cioè, il cablaggio, le unità di
controllo di rete o periferiche, ed infrastrutture comuni del vettore). In caso contrario, potrebbero esistere dei
vincoli sul tipo di infrastrutture fisiche utilizzabili (criteri, regolamentazioni governative, spazio fisico,
proprietà delle sedi, coinvolgimento di terze parti). Documentarle.
-
Se è probabile che venga richiesta l'installazione o la modifica delle infrastrutture fisiche, potrebbe essere
necessario coinvolgere terze parti (ad esempio dei fornitori o dei vettori comuni). Capire le modalità di gestione
del contratto o della responsabilità. Questo è particolarmente importante se le interazioni di business implicano
le connessioni internazionali.
-
Supporto di utenti mobili.
Il client dispone di altri criteri, standard o regole non espressi esplicitamente nei requisiti? Per esempio:
-
Tutte le interfacce del nuovo sistema per gli utenti devono essere progettate per principi orientati sugli oggetti
(object oriented) per consentire le azioni di trascinamento.
-
Tutti i nuovi sistemi devono basarsi sul modello applicativo client/server.
-
Tutti i nuovi sistemi devono essere definiti con degli standard aperti
-
Gli standard ed i criteri per l'NLS (National Language Support), specialmente per cose come l'operazione di testo
da destra a sinistra.
-
Criteri di sicurezza che definiscono la responsabilità di gestione e gli standard per l'autenticazione utente, il
controllo degli accessi e la protezione dei dati.
-
Gli standard di interscambio fra le applicazioni (ad esempio UNEDIFACT o VISA) che possono implicare l'utilizzo di
strumentazione particolare per la connessione o la sicurezza.
Se esistono altri criteri, accertarsi di comprenderli e di disporre dell'autorizzazione all'accesso, in modo da far sì
che la progettazione sia conforme agli standard delle fasi successive del processo di progettazione. L'utilizzo di una
soluzione applicativa in pacchetto potrebbe includere degli standard implicati.
Qual è il criterio che consente agli utenti o ai reparti di aggiungere e/o sviluppare dei propri programmi locali su:
-
Workstation
-
Server (specialmente l'utilizzo di spazio su disco)
Senza i controlli, l'utilizzo locale potrebbe rapidamente usare le risorse necessarie ai sistemi di produzione per i
quali sono stati acquistati originariamente i componenti locali. Si potrebbe rilevare che non è possibile installare il
sistema di produzione quando è pronto per la presentazione.
4.1 "Unità di misura"
Collaborare con il personale di sviluppo applicazioni per dividere i processi di business in unità più granulari, come
dei processi di business più piccoli o delle transazioni.
Il motivo di questa operazione è che nella prossima domanda si dovranno acquisire dei numeri, e si deve decidere cosa
calcolare.
Tenere presente che un processo di business può avviare diverse istanze di transazioni di business più piccole (ad
esempio ordini di più voci per ordine di cliente) e questi moltiplicatori devono essere considerati quando vengono
documentati i numeri. Tuttavia, non ricadere in una descrizione troppo dettagliata, particolarmente in un sistema
complesso.
Un "processo" di business (ad esempio, "gestione degli ordini dei clienti") di solito viene implementato da
un'"applicazione" (un termine IT) o può distribuirsi in più di un'applicazione. In ciascuna applicazione saranno
presenti in genere molte "transazioni" IT, ad esempio, "interroga livello di stoccaggio" o "genera lettera al cliente".
Le diverse comunità utilizzano dei propri nomi per identificare le unità di cui si sta parlando. Ad esempio,
"transazione" potrebbe significare qualcosa per le persone con background di sviluppo applicazioni ed una cosa
completamente diversa per il team delle infrastrutture. E' importante collaborare per correlare i nomi e raccogliere le
informazioni.
4.2 "Volumi di business e dimensioni"
Identificare e documentare le informazioni sui volumi e sulla dimensione di ciascuna unità della sezione 4.1: "Unità di
misura", ad esempio:
-
Quanti utenti si prevede utilizzeranno ciascun processo di business o applicazione in media e nelle ore di punta
-
Quali sono le ore di punta (giornalmente, settimanalmente, mensilmente ecc., a seconda del caso)
-
A che velocità devono essere elaborate le transazioni in media e nei momenti di maggior traffico
-
Il numero di elementi di dati e di istanze in ciascun gruppo di datai e le relative dimensioni.
4.3 "Criteri delle prestazioni del processo di business"
Il client potrebbe avere dei criteri di prestazione specificati per alcuni dei processi di business o per tutti.
Tuttavia, ricordarsi di documentare anche gli obiettivi di prestazione per i processi di supporto del sistema (come i
backup di sistema) ed i processi di sviluppo delle applicazioni, se identificati. Per ogni categoria documentare:
-
I requisiti di risposta/turnaround di ogni categoria
-
Dove devono essere misurati
-
Se sono accettabili dei criteri diversi in orari diversi (ad esempio nelle ore non di punta o di notte)
-
Se i criteri devono essere soddisfatti durante il recupero o la procedura di riserva
-
Se è richiesta una garanzia di prestazioni
-
Qual è l'impatto su ciascuna parte se i requisiti di prestazione non vengono soddisfatti
-
Esprimere le condizioni minime di prestazione richieste perché il processo di business venga considerato
disponibile (vale a dire il punto sotto il quale il sistema viene considerato "non disponibile" invece che
"lento").
-
Se è stata già scelta una soluzione applicativa in pacchetto, verificare di disporre dell'accesso alle sue
caratteristiche di prestazione. Potrebbero non essere necessarie tutte ora ma è importante sapere dove reperirle,
poiché molto probabilmente saranno necessarie per le attività future. Inoltre alle terze parti potrebbe essere
necessario molto tempo per distribuire i valori richiesti, quindi richiederli ora.
L'approccio consigliato per stabilire i requisiti di disponibilità è il seguente:
-
Identificare i veri utenti del sistema, i processi business che eseguono e gli orari in cui li eseguono
-
Analizzare l'impatto della disponibilità del servizio (o la non disponibilità) sulla possibilità per gli utenti di
raggiungere i propri obiettivi di business
-
Specificare dei requisiti di disponibilità che rispecchino direttamente quello di cui necessitano gli utenti per
raggiungere gli obiettivi di business.
-
Se è già stata scelta una soluzione applicativa in pacchetto, la sua struttura e la sua progettazione possono avere
una significativa influenza sulle caratteristiche di disponibilità dell'applicazione così come viene vista dagli
utenti. Un pacchetto che non è stato progettato per funzionare continuamente potrebbe essere molto difficile da
utilizzare in modo continuativo, specialmente per quanto riguarda la manutenzione e le finestre batch.
Prendere in considerazione queste linee guida, quando si devono formare i requisiti della disponibilità:
-
Piuttosto che specificare dei requisiti "globali" per l'intero sistema, specificare i requisiti della disponibilità
ad un livello inferiore di granularità (ad esempio, per singolo processo, gruppo di utenti, gruppo di dati, ecc.).
Questo fornisce al progettista più flessibilità per soddisfare le esigenze degli utenti. Ciò è particolarmente
importante per i sistemi con requisiti di disponibilità continua molto alti.
Alcuni esempi:
-
L'istruzione "Il sistema deve essere attivo 24 ore al giorno per gli utenti di New York e di Hong Kong" lascia al
progettista molto meno flessibilità rispetto all'istruzione "Gli utenti di New York devono essere in grado di
eseguire le transazioni sui LORO dati dalle 7:00 alle 19:00 ora di New York e gli utenti di Hong Kong dalle 7:00
alle 19:00 ora di Hong Kong". In quest'ultimo caso il progettista ha la flessibilità di poter eseguire la
manutenzione sui dati o sui componenti di sistema di una zona di fuso orario mentre nella zona dell'altro fuso
orario sono ancora in piena giornata produttiva.
-
In un'applicazione per bancomat potrebbe essere critico accettare dei depositi e dispensare contanti alle 3 del
mattino del lunedì, mentre è meno critica la possibilità di fornire a quell'ora gli estratti conto aggiornati.
-
Distinguere fra le caratteristiche di disponibilità DESIDERATE e quelle OBBLIGATORIE. Ad esempio, "Il bancomat DEVE
essere in grado di accettare depositi e dispensare contanti 24 ore al giorno. Si DESIDERA che il bancomat sia in
grado di fornire al cliente il saldo esatto del conto 24 ore al giorno; sono tollerate eventuali interruzioni nel
processo di richiesta del saldo, ma DEVONO essere inferiori a 10 minuti come durata e si devono verificare fra le
ore 3:00 e le ore 4:00".
-
Se non è possibile correlare l'impatto di un particolare obiettivo di disponibilità non raggiunto alla capacità
degli utenti di raggiungere i propri obiettivi di business, quell'obiettivo potrebbe non essere adatto ad essere
identificato come requisito di disponibilità per il sistema.
-
I requisiti di disponibilità, che solo indirettamente rispecchiano la disponibilità così come viene percepita
dall'utente (ad esempio "La regione di controllo IMS deve essere attiva"), tendono a non essere utili quanto quelli
che lo fanno (ad esempio, "I cassieri devono essere in grado di eseguire i processi X e Y").
5.2 "Orari pianificati del servizio"
Per ognuno dei processi di business e dei gruppi di utenti che devono eseguirli, identificare gli orari durante i quali
l'utente deve essere in grado di eseguire quel processo. Ricordarsi di effettuare questa operazione anche per i
processi che non sono direttamente associati ai gruppi di utenti.
Se dei gruppi di utenti sono presenti in fusi orari diversi (come nell'esempio precedente di New York/Hong Kong),
considerarli come due gruppi separati di utenti.
Segnalare anche se esistono dei periodi occasionali, ad esempio le feste nazionali, in cui l'applicazione potrebbe non
essere necessaria. (Questo fornisce al progettista la flessibilità di utilizzare quei periodi per una manutenzione
estesa). Quali modifiche sono anticipate negli orari di servizio sulla proiezione del ciclo di vita dell'applicazione?
Gli orari di servizio di questo sistema possono anche essere influenzati da quelli degli altri sistemi con i quali si
interfaccia.
Come si prevede cambino gli orari di servizio pianificati per questo sistema nella proiezione del suo ciclo di vita?
5.3 "Costi dell'interruzione del servizio"
Comprendere l'IMPATTO SUL BUSINESS, i COSTI ed i RISCHI associati alle interruzioni di servizio durante gli orari di
servizio previsti.
Per identificare quali requisiti di disponibilità siano veramente importanti per il sistema, considerare l'insieme dei
processi di business e dei gruppi di utenti ed identificare l'impatto sul business che risulterebbe da:
-
Una breve interruzione o un periodo di tempi di risposta non accettabili durante gli orari pianificati. Definire i
concetti di "breve" e "lento in maniera inaccettabile" in relazione a questa particolare applicazione (vedere
"Criteri per le prestazioni del processo di business")
-
Varie interruzioni di servizio di maggior durata, durante il suddetto orario (un minuto, pochi minuti, 15 minuti,
30 minuti, un'ora, due ore, quattro ore, ecc.)
-
Interruzioni di servizio estese (un turno, un giorno, più giorni, ecc.).
-
Considerare anche tutti i processi che non sono direttamente associati ad un gruppo di utenti (ad esempio, la
ripulitura notturna).
Quando si valuta l'impatto di ogni interruzione di servizio, identificare le procedure di riserva (fallback) e
considerare come possono ridurre il vero impatto sul business dell'interruzione.
Tentare di quantificare l'impatto in termini finanziari (costo della perdita di produttività del personale o delle
attrezzature, valore del business corrente perso, perdita stimata di business futuro a causa dell'insoddisfazione del
cliente, spese di interessi, penalità contrattuali, ecc.).
Fornire tutte le risposte necessarie per rispecchiare le differenze nei costi e nei rischi associati alle interruzioni
di servizio di diversa durata, in ore del giorno differenti, se erano previste o non previste, quali processi di
business o utenti vengono implicati, ecc.
Come si prevede che cambi l'impatto business/finanziario di un'interruzione di servizio, nella proiezione del ciclo di
vita del sistema?
Rivedere ognuno di questi importanti processi di business concordati, per identificare le alternative per consentire
agli elementi più critici dei processi di continuare anche nel caso in cui alcune parti del sistema si rendano
temporaneamente non disponibili. La possibilità di operare temporaneamente con una funzione ridotta di business può
essere un metodo per ridurre l'impatto sulla disponibilità delle interdipendenze nei processi e nei dati critici.
Alcuni esempi:
-
FUNZIONE COMPLETA 1 Leggere ed aggiornare il record di stoccaggio.
-
FUNZIONE RIDOTTA 1 Immettere aggiornamento del record di stoccaggio e mettere in coda per aggiornamento futuro.
-
FUNZIONE COMPLETA 2 Leggere il saldo cliente più recente.
-
FUNZIONE RIDOTTA 2 Leggere il saldo del cliente da una fonte alternativa, che potrebbe non essere altrettanto
aggiornata.
-
FUNZIONE COMPLETA 3 Aggiornare l'agenda del computer.
-
FUNZIONE RIDOTTA 3 Aggiornare la copia su stampa dell'agenda.
Ricordarsi che quando il sistema opera con funzionalità ridotta potrebbe esistere un limite di accettabilità per i
processi di business. Ad esempio, un saldo cliente non aggiornato non deve superare le 24 ore di arretratezza.
Se il servizio viene interrotto durante gli orari pianificato (vedere "Orario pianificato del servizio") l'impatto
dell'interruzione in genere varia in base alla durata dell'interruzione e ad altre condizioni. Alcune interruzioni
potrebbero avere un impatto minimo sulla capacità degli utenti di eseguire i propri processi di business (interruzioni
brevi, quelle che accadono durante i periodi di minor utilizzo nella giornata, quelle che inficiano solo su un
sottoinsieme del gruppo di utenti o quelle per le quali esiste una procedura di riserva accettabile). Altri tipi di
interruzioni, ad esempio quelle più lunghe o che si verificano in un periodo "critico" della giornata, possono avere un
impatto più significativo.
Alcuni esempi:
-
Una breve interruzione dei processi di controllo della linea di produzione potrebbe avere un impatto minimo sulla
produttività, poiché il lavoro può continuare in base agli ordini di lavoro stampati in precedenza e le modifiche
possono esser annotate manualmente per essere poi inserite in un secondo momento. Tuttavia, un'interruzione che si
estende oltre i sessanta minuti potrebbe provocare una chiusura della linea per il resto del turno di lavoro.
-
Una interruzione ad un sistema di transazioni finanziarie con grossi volumi di denaro nell'arco dell'ultima ora di
scambi potrebbe portare a dei costi di interesse significativi o a penalità contrattuali.
-
Le risposte della polizia e dei pompieri ad emergenze con rischio di vita possono continuare mediante l'utilizzo di
procedure manuali di riserva, se il sistema di distribuzione non è disponibile. Tuttavia i tempi di risposta
possono aumentare e potenzialmente implicando il rischio di vita, a causa dell'aumentato carico di lavoro del
programma di distribuzione.
-
Un'interruzione di una linea aerea nei periodo di punta o di un centro di prenotazioni alberghiere non solo
comporta la perdita del business corrente quando il cliente chiama la concorrenza per effettuare le prenotazioni ma
anche del business futuro se il livello di insoddisfazione del cliente è tale da chiamare prima un'altra compagnia
aerea o catena alberghiera, la volta successiva in cui necessita di questi servizi.
5.4 "Criteri di disponibilità e di recupero"
Identificare i CRITERI DI DISPONIBILITA' E DI RECUPERO relativi a delle situazioni "normali".
Escludere situazioni di "disastro", ad esempio una perdita estesa o una chiusura dell'intera infrastruttura di calcolo.
In base ai costi di business/finanziari ed ai rischi identificati in "Costi dell'interruzione del servizio", sviluppare
una specifica dei criteri di disponibilità che devono essere soddisfatti per evitare di inibire in modo significativo i
gruppi di utenti che devono eseguire i processi di business assegnati. I criteri possono essere specificati sotto forma
di:
-
Percentuale di interruzioni recuperate entro un dato numero di minuti/secondi
-
Quantità massima di tempo nell'arco di un(a) determinato(a) settimana/mese/anno durante il quale l'utente non è in
grado di eseguire una particolare funzione
Essere specifici quanto necessario per rispecchiare fattori quali le differenze fra interruzioni pianificate e non
pianificate, l'ora in cui si verifica l'interruzione (ad esempio periodi "critici" rispetto a periodi di scarso
utilizzo), se ne risentono tutti gli utenti o solo alcuni, ecc.
Non specificare, a meno che non sia necessario, dei criteri di disponibilità rigidi, perché potrebbe inficiare
significativamente sul costo dell'implementazione. In generale, se non possono essere identificati dei significativi
costi business/finanziari o rischi con l'insieme di condizioni di interruzione fornito, potrebbe essere un'indicazione
quell'insieme di condizioni non deve essere incluso nei criteri di disponibilità espressi.
Se l'"Orario pianificato del servizio" indicava che le ore di servizio previste sono soggette a cambiamenti e/o i
"Costi di interruzione del servizio" indicavano che i costi di business/finanziari o i rischi associati ad
un'interruzione di servizio sono soggetti a modifica durante la proiezione del ciclo di vita del sistema, effettuare
una stima di come verrebbero modificati i criteri di disponibilità, come conseguenza.
Se deve essere utilizzata la crittografia, devono aver luogo ulteriori considerazioni sul recupero e sulla
disponibilità. Per esempio:
-
La capacità di recuperare informazioni segrete conservate al di fuori del sistema.
-
La necessità di garantire il recupero dei dati protetti da crittografia unitamente al recupero delle appropriate
chiavi di codifica
5.5 "Recupero d'emergenza?"
nell'ambito di questa progettazione è richiesto il recupero d'emergenza (disponibilità in situazioni di "disastro", ad
esempio una perdita estesa o la chiusura dell'intera infrastruttura di calcolo)? In caso affermativo, quali sono i
criteri del recupero?
Probabilmente non tutti i processi di business richiedono l'infrastruttura per il recupero d'emergenza. Selezionare
solo i processi critici e che richiedono il recupero d'emergenza. Anche all'interno di quei processi, non tutte le
funzioni devono essere considerate.
-
In quanto tempo il servizio deve essere ripristinato? Il tempo viene misurato dal momento in cui accade l'emergenza
o da quando viene presa la decisione di passare ad un sito remoto?
-
In base a quali condizioni l'organizzazione decide di recuperare in un sito remoto piuttosto che localmente?
-
Quanto devono essere attuali i dati sul sito remoto perché il business possa continuare ad operare (assolutamente
dati aggiornati al secondo; dati a pochi minuti dall'errore; accettabili dati del giorno precedente)?
-
Quando viene ripristinato il servizio dal sito remoto?
-
In un momento futuro nel tempo?
-
Qual'è sul sito remoto la priorità di recupero di questo insieme di applicazioni in relazione ad altre applicazioni
di business che dipendono dalla stessa infrastruttura di calcolo?
Possono esistere insiemi di criteri diversi per parti differenti del sistema o che dipendono dal tipo di emergenza.
Quali modifiche ai requisiti del recupero di emergenza citati vengono previste durante la proiezione del ciclo di vita
dell'applicazione?
5.6 "Altre considerazioni sulla progettazione della disponibilità"
Per progettare un sistema che recupera il più presto possibile, il progettista deve conoscere la flessibilità
disponibile nell'implementazione dell'applicazione, pur rispettando i requisiti funzionali dell'applicazione. Ecco
alcune domande utili per il progettista:
1. Per inserire delle attività di manutenzione necessarie, il sistema può operare per periodi brevi durante i quali:
a. Esegue le ricerche ma non gli aggiornamenti?
b. Accetta le richieste di aggiornamento dall'utente ma non aggiorna effettivamente il DB finché non sono terminate
le attività della manutenzione?
2. Per un'interruzione che richiede il recupero di dati, è più importante:
c. Ripristinare il servizio il prima possibile, anche se significa utilizzare dati non completamente aggiornati,
oppure:
d. Recuperare tutti i dati allo stato corrente prima di ripristinare il servizio, anche se questo richiede più
tempo?
3. Nel caso una richiesta utente fosse "in corso" al momento dell'errore, si può contare sull'utente per la
reimmissione della richiesta dopo il recupero del servizio?
4. Esistono delle considerazioni non tecniche che potrebbero inficiare sulla disponibilità del sistema (ad esempio dei
criteri di business che affermano che il processo A non deve essere reso disponibile per gli utenti finché non è
disponibile anche il processo B)?
Si prevede che qualcuna delle suddette considerazioni sulla progettazione debba cambiare nel tempo?
Per i processi critici per il business, è utile identificare delle alternative che consentano agli elementi più critici
di quei processi di apparire funzionali anche quando il sistema è temporaneamente non disponibile. La possibilità di
operare temporaneamente con una funzione ridotta di business può essere un metodo per ridurre l'impatto sulla
disponibilità delle interdipendenze nei processi e nei dati critici.
6.1 "Requisiti di sicurezza"
1. Identificare i dati da proteggere
2. Identificare il tipo di rischi a cui è esposto ciascun tipo di dati:
-
Danneggiamento o distruzione accidentali
-
Danneggiamento o distruzione volontari
-
Intelligenza commerciale
-
Frode
-
Intrusione di estranei
-
Virus
1. Identificare i rischi per la sicurezza fisica:
-
Furto di componenti
-
Accesso fisico non autorizzato
-
Sicurezza fisica degli utenti
2. Identificare le persone che potrebbero essere all'origine dei rischi:
-
Personale del centro dati
-
Altro personali IT (ad esempio, dello sviluppo)
-
Personale non IT dell'organizzazione
-
Persone esterne all'organizzazione
3. Identificare gli eventuali requisiti di sicurezza particolari o insoliti, specialmente relativi a:
-
Accesso al sistema
-
Codifica dei dati
-
Verificabilità
4. Esistono dei criteri generali, ad esempio le leggi sulla libertà di informazione, che possono influenzare la
progettazione della sicurezza del sistema?
5. Alcune soluzioni applicative in pacchetto dispongono di propri sottosistemi di sicurezza. Se si dispone di un
pacchetto "fornito" tenere presente le sue infrastrutture per la sicurezza.
Per poter stabilire e classificare i requisiti di sicurezza è possibile utilizzare il seguente approccio:
1. Elencare gli oggetti che richiedono protezione per sicurezza logica o fisica.
2. Identificare l'esposizione pertinente a ciascun oggetto. Categorie tipiche:
-
Accesso alla visualizzazione (violazione di riservatezza), ad esempio informazioni sul conto, elenco dei
client, brevetti.
-
Accesso all'aggiornamento, ad esempio modifica di dati per frode, mascheramenti, deviazione di fondi.
-
Perdita di beni, ad esempio qualcun'altro si impossessa del bene e non è più disponibile per il
proprietario (diverso dalla perdita per disastro). Degli esempi sono: elenchi di clienti e prospetti,
contratti, ecc.
Non tutti gli oggetti sono sensibili a tutte le esposizioni di rischio menzionate.
3. Identificare tutti i rischi pertinenti per il proprio ambiente. Esempi:
-
Dipendenti scontenti
-
Dipendenti non autorizzati
-
Sessioni di terminale aperte in un posto pubblico
-
Hacker
-
Intercettazione della linea
-
Perdita di attrezzature (ad esempio PC portatili)
4. Per ciascun oggetto stabilire a quale rischio è soggetto ed associarlo alla specifica esposizione.
Potrebbe essere necessario rivedere i requisiti di sicurezza relativi all'oggetto sia in una posizione statica (ad
esempio su un disco fisso) che in transito (ad esempio durante la trasmissione).
Poiché la progettazione può estendere la posizione dell'oggetto in aree non sicure, potrebbe essere necessario
riaffrontare questo argomento.
Gli aspetti della sicurezza di alcune progettazioni di sistema possono essere molto esigenti. Possono dominare le
decisioni relative alla progettazione. Potrebbero rendere inaccettabile la selezione di opzioni di strutture e
componenti che altrimenti sarebbero valide. Effettuare quindi ora una scelta definitiva se il sistema da progettare
necessita o meno di requisiti di sicurezza particolarmente esigenti. Per esempio:
-
Un sistema militare sensibile
-
Un sistema di trasferimento di denaro ad alto valore
-
un sistema che gestisce informazioni personali riservate
Se si ritiene che le esigenze di sicurezza siano particolari, individuare un esperto della sicurezza o un assistente
che possa affiancarsi per gli aspetti della progettazione del sistema.
i requisiti di utilizzabilità definiscono quanto deve essere elevata l'utilizzabilità dell'interfaccia utente.
I requisiti di utilizzabilità devono essere impostati sul livello più basso di utilizzabilità che il sistema deve
ottenere per poter essere utilizzato. Non devono essere impostati su quello che si ritiene il sistema possa
raggiungere. In altre parole, i requisiti di utilizzabilità non devono essere considerati un obiettivo, ad esempio un
limite superiore. I requisiti di utilizzabilità devono definire la più bassa utilizzabilità del sistema possibile
accettabile. Una volta soddisfatti i requisiti di utilizzabilità non necessariamente si deve smettere di migliorare
l'utilizzabilità
Quello che deve ottenere il sistema, per poter essere utilizzato, dipende in gran parte da quale sia l'alternativa
all'utilizzo del sistema. E' ragionevole richiedere che il sistema sia più utilizzabile delle alternative in modo
significativo. Le alternative possono essere l'utilizzo di:
-
Procedure manuali esistenti.
-
Sistemi precedenti.
-
Prodotti concorrenti.
-
Versioni precedenti del sistema.
I requisiti di utilizzabilità possono venire anche dalla necessità di giustificare economicamente il nuovo sistema: se
il cliente deve pagare 3 milioni di euro per il nuovo sistema, potrebbe imporre dei requisiti di utilizzabilità che
implicano forse un futuro risparmio di 1 milione di euro all'anno per la diminuzione del carico di lavoro sulle sue
risorse umane.
Quelli che seguono sono degli esempi di alcuni requisiti generali di utilizzabilità:
-
Tempo massimo di esecuzione - quanto tempo impiega un utente esperto per eseguire uno scenario comune.
-
Frequenza massima di errori - quanti errori in media può commettere un utente esperto in uno scenario comune.
Gli unici errori rilevanti per la misurazione sono quelli non recuperabili che hanno effetti negativi
sull'organizzazione, ad esempio perdita del business o danni all'hardware monitorato. Se l'unica conseguenza di un
errore è il tempo necessario per correggerlo, avrà ripercussioni sul tempo di esecuzione misurato.
-
Tempo di apprendimento - quanto tempo ci vuole prima che l'utente possa eseguire uno scenario più rapidamente del
tempo massimo di esecuzione specificato.
Quello che segue è un esempio di alcuni requisiti di utilizzabilità per il caso d'uso "Gestione dei messaggi di posta
in arrivo".
-
L'utente della posta deve essere in grado di organizzare i messaggi di posta con un clic del mouse.
-
L'utente della posta deve essere in grado di scorrere il testo dei messaggi di posta premendo i singoli tasti della
tastiera.
-
L'utente della posta non deve essere disturbato dai messaggi di posta in arrivo mentre sta leggendo dei messaggi
esistenti.
|