domande sw

7/25/2019 Domande SW

1/4

1. Descrivere limportanza dei modelli di processo nellattuazione egestione del progetto software.

2. Eettuare unanalisi comparativa dei principali modelli diprocesso caratterizzandone vantaggi e svantaggi in relazione

alle diverse tipologie applicative.

Nel 1969 si abbandona il modello casuale(code-fx), e si passa ad un modellowaterall che prevede riide asi da seuire in ordine sen!a possibilit" ditornare indietro# $ vantai sono% defni!ione di concetti utili, punto di parten!a,acilmente applicabile, molto rioroso mentre svantai% intera!ione concliente solo all&ini!io e alla fne, re'uisiti imprecisi e a volte errati scoperti soloalla fne e il sotware risulta installabile solo alla conclusione# er 'uesto si

proposero due varianti% cascata con prototipa!ionereali!!a!ione di unprototipo ini!iale un!ionante e cascata con ritorniaiunta possibilit" ditornare indietro nelle asi per poter apportare delle modifche#n altro modello * 'uello incrementale nel 'uale abbiamo pi+ versionimostrate periodicamente al cliente per poterlo arricchire o correere# $vantai sono% ridu!ione spese per un!ionalit", prova sotware e utili!!o incaso di uren!a mentre svantai sono% documenta!ione non redatta ex-novo

per oni ase e possibilit" di avere una struttura enerale deradata#ncora i modelli evolutivi dove abbiamo un prototipo i vantai sono%valuta!ione re'uisiti di sistema, .$ coinvolendo cliente e orma!ione clientementre svantai sono% mancata documenta!ione opportuna, possibilit" di

perdita di interesse da parte del cliente a uturi aiornamenti e non rispettodella /o0#

odello a spirale e a parte deli evolutivi i vantai sono% esplicita!ione dellaestione rischi, maior possibilit" di individua!ione errori ella ase ini!iali,considera!ione sulla 'ualit" e intera!ione sviluppo e manuten!ione#0vantai% personale in rado di valutare i rischi, problemi nella defni!ione delcontratto e di2colt" nell&adattamento alla realt" a!iendale#$nfne processo unifcato% iterativo orani!!ato in una serie di processi brevi dilunhe!!a fssa## $ vantai sono% estione dei re'uisiti, utili!!o 3, impenocostante dei clienti per ottenere eedbac4 e a5ronto di problematiche maiorinelle itera!ioni ini!iali#

3. Tecniche di analisi dinamica per la verica del software

3e tecniche di analisi dinamica sono 'uelli che ci permettono di capire se ilproramma a 'uello che si * proposto di voler eseuire# 0i dividono in lac4ox 7estin ( testin un!ionale) che * ondato sull&analisi di output eneratidal sistema in risposta ad una serie di input# $n 'uesto caso si sa i" a priori'uali dovrebbero essere li input dato che si conoscono i re'uisiti specifcatidal sistema# 3&altro * il 8hite ox 7estin o 7estin strutturale che testa il

proramma per esaminare come * e si onda sulla defni!ione dei casi di test,deli input associati all&oracolo e sulla base della conoscen!a della struttura delsotware ma pi+ in particolare sulla conoscen!a ( e visione) del codice# 0embranon essere dinamico ma in realt" * ci che prende il nome di debuin#

4. ivelli di test


2/4

-7est di sviluppo% si testano le sinoli componenti del proramma dalla pi+semplice alla pi+ complessa# 0i possono sceliere due approcci per individuarei casi di test, uno che seue l&esperien!a e uno che seue la scelta delle

parti!ioni valutando il sistema prima come blac4 box e poi come white box (

unit")# 0i cercano li errori relative all&utili!!o di interacce che a volte hannocomportamenti anomali ( intera!ione) e infne si testano le un!ioni o5erte da

pi+ componenti interati ( sistema)-7est di reressione% nell&approccio incrementale bisona testare

periodicamente che tutto ci che * stato i" implementato sia privo di errori# :&costoso e alle volte impraticabile-7est di rilascio% si basa sulle un!ionalit" e serve a mostrare la bont" delsotware al cliente-7est sui re'uisiti% dimostra!ione dell&implementa!ione dei re'uisiti stabiliti-7est presta!ione% a sistema ultimato e verifca che sia a2dabile e perormante

5. !aratteristiche fondamentali del test white "o#

E un testing strutturale, poichutilizza la struttura interna del programma per ricavare i dati di

test. Tramite il testing White Box si possono formulare criteri di copertura piprecisi di quelli

formulabili con testing Black Box. Test White Box che hanno successo possono fornire maggiori

indicazioni al debugger sulla posizione dellerrore. Bisogna testare le funzionalitesterne che

sarebbero quelle visibili allutente e definite dai requisiti ma anche le funzionalitinterne che sono

quelle non visibili allutente il tutto partendo dalla definizione delle funzionalitche sono linsieme

dei dati in ingresso, uscita, precondizioni e post condizioni. E necessario definire un oracolo che

conosce il comportamento atteso per ogni caso di test e puessere vario ( umano, automatico, ecc)

e in piogni funzionalitdeve essere eseguita almeno una volta per poi poter giungere allaproduzione di quella che prende il nome di check list.

6. Quality Factors e Variation Factors in foglio metrico

DIT ( profonditdellalbero di ereditariet), NOA ( numero operazioni aggiunte ad una

sottoclasse), MIF ( fattore di ereditarietdei metodi), RFC ( risposte per classe), LCOM

(mancanza di coesione nei metodi), CS (dimensione della classe), WMC (metodi pesati per classe)

e VG (complessitciclomatica). Dallaltra parte abbiamo: coesione interna, profonditdella

gerarchia di classe, complessite generalizzazione di classe e infine complessitdi risposta.

7. Modello FURPS+

F(unzionalit)caratteristiche funzionali, capacite sicurezza;

U(sabilit)fattori umani e documentazione;

R(reliability)gestione errori e crash inclusi precisione e accuratezza;

P(restazioni)tempo di risposta, us delle risorse, throughput;

S(upportability)assistenza, maintenimento e configurabilit;


3/4

+(requisiti di progettazionegestione del sistema, implementazionelimitazione su risorse e

linguaggi, interfacciasistemi esterni, fisici edimensioni hw legalilicenze) utilizzato per

semplificare il processo di identificazione delle misure piidonee per le diverse fasi del ciclo di

vita di un software. Le caratteristiche di qualitsono divise in 27 sotto-caratteristica a cui

associata una o pimisure.

8. UP

UP un processo iterativo molto diffuso per lo sviluppo del software per la costruzione di sistemi

orientati agli oggetti. Dato che al giorno doggi nei progetti software vi sono costanti cambiamenti

si sta affermando sempre pilo sviluppo iterativo dove il risultato di ciascuna iterazione un

sistema eseguibile, testato, integrato ma parziale. Il motivo per cui UP particolarmenteapprezzato proprio per il fatto che iterativo, evolutivo e adattivo e specialmente questultimo

punto va ad influire, nel caso di scelta non adatta, a ridurre la qualito lutilitdel prodotto in s.

Attraverso UP possibile affrontare allinizio le problematiche maggiori e si puavere un costante

feedback dal cliente con cui si in contatto. Luso molto ampio di UML ne permette di gestire pi

facilmente i requisiti e le eventuali richieste di cambiamento e/o configurazioni. Quali sono le fasi

di UP? IDEAZIONE (visione approssimativa, studio economico, stime tempi/costi),

ELABORAZIONE (visione raffinata, implementazione iterativa nucleo e risoluzione rischi

maggiori, stime piaccurate), COSTRUZIONE (implementazione iterativa degli elementi

rimanenti e a rischio minore) e TRANSIZIONE (beta test con rilascio agli utenti).

9. COCOMO II

La stima dei costi e della tempistica del progetto sono due attivitche solitamente vengono

eseguite allunisono. I costi di sviluppo sono i costi dello sforzo richiesto e le stime iniziali sono

importanti al fine di determinare un budget per il progetto e stabilire il prezzo per il cliente. Non

semplice fare una stima accurata dello sforzo richiesto a partire dai primi stadi del progetto, alle

volte quasi impossibile per questo motivo si decide, spesso, di usare il COCOMO che un modello

ben documentato, pubblicamente accessibile e supportato da strumenti pubblici e commerciali con

un solido background. Tuttavia esso rappresenta un modello empirico dato che stato realizzato

partendo da una grande quantitdi dati e trovando delle relazioni. La relazione quella classica:

B x MEffort=A x

con precisi indici per determinare i parametri: -A

fissata a 2,94 in modo empirico -Size

espressa in KSLOC (migliaia di righe di codice) stimate attraverso i punti funzione e dipendenti

dal linguaggio di programmazione; -B

rappresenta laumento del costo allaumentare della dimensione del progetto (tra 1.1 e 1.24)

-M il prodotto di sette indici basati sullaffidabilite complessitdel prodotto, sul riuso richiesto

sulla difficoltdella piattaforma e sulla capacitdel personale :

PERS x RCPX x RUSE x PDIF x PREX x FCIL x SCED

10. Tecniche formali


4/4

Se supponiamo di voler creare un software che controlla il traffico aereo e lo si vuole testare non

avrebbe senso farli partire e accorgersi solamente dopo che vi qualche errore. Per questo motivo

si ricorre a metodi piaffidabili e quindi non basarsi unicamente sul test ma procedere con

simulazioni o con metodi pirigorosi che assicurano lassenza di errori. Questi metodi sono detti

formali e sono utilizzati dai linguaggi formali che sono quei linguaggi la cui sintassi e vocabolario

sono limitati e utilizza delle regole molto rigorose e precise. Spesso vengono utilizzate tecnichematematiche per lanalisi di appositi algoritmi. Nel caso di utilizzo di teorie matematiche la

verifica avviene attraverso lapplicazione di una tecnica manuale o automatica (non sempre

facile automatizzare il processo) che possa aiutare a stabilire se un sistema soddisfa una data

proprieto si comporta in accordo a una specifica data.

11. Model checking

Usa i sistemi a transizioni (LTS) per modellare i sistemi ma fa anche uso della logica temporale

per verificare le propriet. Il problema della verifica viene spesso ridotto a problemi di ricerca su

grafi in pipresenta un grande vantaggio che consiste nel poter essere completamente

automatizzato e abbiamo visto che in alcuni casi, come ad esempio nei metodi formali,

lautomatizzazione impossibile anche a livello teorico. Se la proprietnon verificata viene

generato un controesempio e infine, e soprattutto ciha permesso un suo sviluppo, relativamente

facile da usare.

domande sw

Documents