Sicurezza del software

SLE=AV*RM

SLE=AV*EF

x

08. Definire il significato e la formula dell'indice ROA.

08. ROA , Return On attack, misura il guadagno che un attaccante si aspetta da un attacco riuscito rispetto alle perdite che

subisce a causa dell’adozione di misure di sicurezza da parte del suo bersaglio. Infatti il ROA è dato dal rapporto tra il guadagno

dal successo dell’attacco e la somma dei costi per l’attacco e i costi causati dalle contromisure.

Lezione 016

01. I modelli di analisi quantitativa del rischio sono influenzati da tre indicatori. Quale dei seguenti non è un indicatore?

collusione

x fattore di esposizione

rappresaglia

tempo critico

02. Quali sono gli indicatori che influenzano i modelli di analisi quantitativa del rischio?

02. Gli indicatori sono : tempo critico, rappresaglia e collusione. Il tempo critico rappresenta il fatto che l’asset ha valore

diverso nel tempo. La rappresaglia tiene conto del fatto che è possibile prevedere contrattacchi. La collusione tiene conto del

fatto che un attaccante può intervenire su più fronti in maniera coordinata.

Lezione 017

01. Lo Standard for Software Maintenance è:

x IEEE 1219

IEEE 1471

IEEE 1008

IEEE 828

02. L'ingegneria del software è la disciplina tecnologia e manageriale che riguarda

la progettazione e la codifica dei prodotti software

solo il test dei prodotti software

x la produzione sistematica e la manutenzione dei prodotti software

solo la distribuzione dei prodotti software

03. Lo Standard IEEE 610 riguarda:

Software Maintenance

Software and System Test Documentation

x Glossary of Software Engineering Terminology

Software Unit Testing

04. Quale è la differenza tra prodotto software e processo software?

04. Il prodotto software è quell’insieme di tutti gli artefatti che permettono l’utilizzo di un programma da parte di un utente:

codice, documentazione, prodotti intermedi come test, manuali. Il processo software è un insieme organizzato di attività

necessarie alla realizzazione del prodotto software da parte del team di sviluppo nei tempi, costi e con caratteristiche

desiderate di qualità.

Lezione 018

01. L'assenza di un modello del ciclo di vita corrisponde ad una modalità di sviluppo detta

design & fix

build & test

build & fix

x plan & correct

02. L'acronimo SDLC rappresenta:

Software Deployment Life Cycle

System Development Life Cycle

System Deployment Life Cycle

Software Development Life Cycle

x

03. L'ultima fase del ciclo di vita di sviluppo del software è:

la distribuzione

la codifica

la manutenzione

x l'analisi dei requisiti

04. Quali sono le fasi del ciclo di vita di sviluppo del software?

05. Che cosa si intende per modello di ciclo di vita?

04. Il ciclo di vita designa le varie fasi di un software, dalla concezione al ritiro. Questa metodologia (SDLC) è suddivisa in

alcune fasi: analisi dei requisiti, progettazione, implementazione o codifica, test, distribuzione o messa in opera e

manutenzione.

05. Il modello del ciclo di vita del software specifica la serie di fasi attraverso cui il prodotto software progredisce e l’ordine

in cui vanno eseguite, dalla definizione dei requisiti alla dismissione.

Lezione 019

01. L'acronimo SDD rappresenta:

System Design Document

Software Design Document

x Software Development Document

Software Design Data

02. Quale è la fase del SDLC più lunga?

x L'implementazione

L'analisi dei requisiti

La distribuzione

Il test

03. L'acronimo SRS rappresenta:

System Requirement Specification

Software Requirement Specification

x System Requirement Security

Software Requirement Security

04. La prima fase del ciclo di vita di sviluppo del software è:

la manutenzione

la progettazione

il test

x l'analisi dei requisiti

05. La matnutenzione che ha lo scopo di estendere il software per accomodare funzionalità aggiuntive è:

adattiva

perfettiva

x correttiva

preventiva

06. Descrivere le diverse tipologie di manutenzione.

06. Esistono diversi tipi di manutenzione:

• La manutenzione correttiva che consente di risolvere i difetti che possono sorgere.

È praticamente impossibile creare un prodotto perfetto in una volta sola. Alcuni problemi diventano visibili solo quando il

software viene utilizzato da un gran numero di utenti.

• La manutenzione adattiva che consente di adattare il software ad eventuali

cambiamenti

• Manutenzione perfettiva, che ha lo scopo di estendere il software per accomodare

funzionalità aggiuntive;

• Manutenzione preventiva (o software reengineering), che consiste nell'effettuare

modifiche che rendano più semplici le correzioni, gli adattamenti e le migliorie

Lezione 020

01. In quale dei seguenti modelli per ogni singola fase del ciclo di sviluppo, esiste una fase di test direttamente associata?

x a V

RAD

a cascata

iterativo

02. Quale dei seguenti modelli viene definito modello del ciclo di vita sequenziale lineare?

RAD

a V

x a cascata

a spirale

03. Nel modello a V il test di integrazione è la fase di convalida relativa a quale fae di verifica?

analisi dei requisiti aziendali

Progettazione del modulo

Progettazione architettonica

x Progettazione del sistema

04. Quale delle seguenti fasi di convalida è associata alla fase di verifica di analisi dei requisiti aziendali?

Test di integrazione

Test unitario

Test di sistema

Test di accettazione

x

05. Descrivere il modello a V.

06. Descrivere il modello a cascata.

05. IL modello a V è un modello SDLC in cui l’esecuzione dei processi avviene in modo sequenziale in una forma a V. È anche

noto come modello di verifica e convalida. Il V model è un’estensione del modello a cascata e si basa sull’associazione di una

fase di test per ciascuna fase di sviluppo corrispondente. I requisiti sono ben definiti e documentanti, la definizione del

prodotto è stabile.

Le fasi principali sono: Analisi dei requisiti (prima fase in cui viene avviata una comunicazione con il cliente per

comprendere i requisiti e le aspettative), Design del sistema (una volta chiari i requisiti bisogna progettare il sistema. Il

design riguarda la configurazione completa dell’hardware e della comunicazione per il prodotto in fase di sviluppo),

Progettazione architettonica (riguarda le specifiche architettoniche. Il trasferimento dei dati e la comunicazione tra i moduli

interni e con il mondo esterno è compreso in questa fase), Progettazione dei moduli (progetto interno dettagliato per tutti i

moduli del sistema), Fase di codifica (comprende la codifica vera e propria, il linguaggio di programmazione più adatto viene

deciso in base ai requisiti architettonici), fase di convalida che comprende test unitario (sui singoli moduli), test di

integrazione (per testare l’integrazione tra i moduli), test di sistema (controllo dell’intera funzionalità), test di accettazione

(test in ambiente utente).

06. Il modello a cascata è il primo modello di ciclo di vita di sviluppo del software. Viene definito anche come modello del

ciclo di vita sequenziale lineare: ogni fase deve essere completata prima che possa iniziare la fase successiva. In questo caso

i requisiti sono ben documentati, chiari e fissi, la definizione del prodotto è stabile, non ci sono requisiti ambigui, il progetto

deve essere breve.

Le fasi principali sono : Requisiti (raccolta di tutti i possibili requisiti del sistema), Progettazione del sistema (preparazione

del progetto del sistema - requisiti hardware e di sistema), Implementazione (Vengono sviluppati piccoli programmi chiamati

unità e poi successivamente integrati), Testing e Integrazione (integrazione dei moduli e test completo), Distribuzione del

sistema (distribuzione nell’ambiente del cliente), Manutenzione (Problematiche che si verificano nell’ambiente del cliente)

Lezione 021

01. L'acronimo RAD rappresenta:

Risk Application Deployment

x Rapid Application Development

Requirement Application Development

Rapid Application Deployment

02. Modellazione aziendale, Modellazione dei dati, Modellazione dei processi, Generazione di applicazioni e Test e fatturato sono le fasi di quale modello?

a V

iterativo/incrementale

a cascata

RAD

x

03. Descrivere il modello iterativo/incrementale.

04. Descrivere il modello RAD.

03. il modello iterativo non tenta di iniziare con i requisiti completi. Invece lo sviluppo inizia specificando e implementando

solo una parte del software che viene quindi rivista per identificare ulteriori requisiti. questo processo viene quindi

ripetuto producendo una nuova versione del software. Il modello iterativo divide il prodotto in piccoli blocchi.

Nel modello incrementale, l'intero insieme di requisiti è suddiviso in varie build. Durante ogni iterazione, il modulo di

sviluppo passa attraverso le fasi di requisiti, progettazione, implementazione e test. Ogni versione successiva del modulo

aggiunge funzioni alla versione precedente. Il processo continua fino a quando il sistema completo è pronto secondo il

requisito.

I risultati in questo caso si ottengono velocemente e periodicamente, è possibile sviluppare parallelamente, il progresso

può essere misurato, il test è molto più facile, la gestione del rischio è semplice e con ogni incremento viene consegnato il

prodotto operativo. Tuttavia questo modello richiede più attenzione da parte della direzione, possono sorgere problemi

architetturali dato che non tutti i requisiti vengono raccolti all’inizio, non è adatto a progetti troppo piccoli, la complessità

per la gestione è maggiore e la fine del progetto potrebbe non essere nota.

04. Il modello RAD (Rapid Application Development) è un modello che si basa sulla prototipazione e sullo sviluppo iterativo.

Lo sviluppo rapido di applicazioni è una metodologia che utilizza una pianificazione minima a favore della prototipazione

rapida. Un prototipo è un modello funzionante. Nel modello RAD i moduli funzionali vengono sviluppati in parallelo come

prototipi e vengono integrati per realizzare il prodotto completo per una consegna più rapida. Dato che non esiste alcuna

pianificazione è più facile incorporare le modifiche all’interno del processo di sviluppo. I progetti RAD seguono un modello

iterativo e incrementale e dispongono di piccoli team composti da sviluppatori, esperti di dominio, rappresentanti dei

clienti e altre risorse IT che lavorano progressivamente sul loro componente o prototipo.

L'aspetto più importante affinché questo modello abbia successo è assicurarsi che i prototipi

sviluppati siano riutilizzabili.

I