Anteprima
Vedrai una selezione di 1 pagina su 4
Requisiti e Metriche Pag. 1
1 su 4
D/illustrazione/soddisfatti o rimborsati
Disdici quando
vuoi
Acquista con carta
o PayPal
Scarica i documenti
tutte le volte che vuoi
Estratto del documento

Requisiti e Metriche

PLAN: Costruire un piano

● Definire gli obiettivi e determinare le strategie e i mezzi

utili a raggiungere tali obiettivi

DO: Eseguire il piano

● Creare le condizioni, prepararsi sui temi correlati ed

eseguire le azioni necessarie ad eseguire il piano

CHECK: Verificare i risultati

● Verificare se il lavoro procede secondo i piani e se si

ottengono i risultati attesi

ACTION: Eseguire le appropriate e necessarie azioni

se la fase di check rivela che il lavoro non procede secondo

il piano o, in generale, come previsto

Software Development Life Cycle

Analisi dei requisiti e delle specifiche

➤Progettazione

➤Sviluppo

➤ Testing

➤Deploy

➤Manutenzione

I modelli del ciclo di vita

“Waterfall”

Incrementale-iterativo:

■ A spirale

■ RUP

■ Evolutivo

■ Modelli specializzati

■ Agile / Lean

Il costo di correzione di un

errore nei requisiti (stimato)

In fase di raccolta dei requisiti: 10€

■ In fase di analisi: 100€

■ In fase di progettazione: 1.000€

■ In fase di codifica: 10.000€

■ Dopo il rilascio del sistema: 100.000€

■ E’ quindi molto importante tenere sotto

controllo questi costi!

Stakeholders

“insieme dei soggetti che hanno un interesse nei confronti

di un’organizzazione e che con il loro comportamento possono

influenzarne l’attività”

➤ tutte le persone in qualche modo interessate alla messa in

opera del sistema

➤ il cliente e gli utenti finali sono esperti nel loro dominio e

hanno una idea generale (spesso vaga) di cosa il sistema

debba fare, e poca (o nulla) esperienza nello sviluppo del

software

➤ gli sviluppatori hanno esperienza nel produrre sistemi

software, ma hanno una conoscenza limitata del dominio

di applicazione (ambiente degli utenti finali)

Requisiti Funzionali

e Non Funzionali

I Requisiti Funzionali descrivono i servizi, o funzioni,

offerti dal sistema in termini di:

● servizi che il software stesso deve fornire

● risposte che l’utente aspetta dal software in

determinate condizioni

● risultati che il software deve produrre in risposta

a specifici input

➤ I Requisiti Non-Funzionali descrivono vincoli sui

servizi offerti dal sistema, e sullo stesso processo

di sviluppo

Requisiti Funzionali

Descrivono le interazioni tra il sistema e

il suo ambiente indipendentemente dalla sua

implementazione (l’ambiente include l’utente

e ogni altro sistema esterno)

➤ I requisiti funzionali devono essere:

Completi

● Coerenti

Requisiti Non Funzionali

Descrivono gli aspetti del sistema che

non sono direttamente legati al

comportamento (funzionalità) del sistema.

Si riferiscono a diversi aspetti del sistema,

dall’usabilità alle performance

➤ Requisiti di Qualita

➤ Requisiti di Sistema/Ambiente

➤ Requisiti tecnici

Esempi di Requisiti

Non Funzionali

➤Prestazioni/Efficienza (tempi di risposta, consumo

di risorse, capacita)

➤ Usabilita (Appropriatezza/riconoscibilita, Apprendibilita,

Operabilita, Protezione dall’errore

utente, Estetica dell’interfaccia utente, Accessibilita)

➤Affidabilita (Maturita, Disponibilita, Tolleranza

agli errori, Recuperabilita)

➤Sicurezza (Riservatezza, Integrita, Non ripudio,

Responsabilita, Autenticita

Esempi di Requisiti

Non Funzionali

➤Manutenibilita (Modularita, Riusabilita, Analizzabilita,

Modificabilita, Testabilita)

➤ Idoneita funzionale (Copertura, Correttezza,

Adeguatezza)

➤Compatibilita (Coesistenza, Interoperabilita)

➤Portabilita (Adattabilita, Installabilita, Sostituibilita)

➤ Requisiti Tecnici (tecnologie e standard su

DBMS, middleware, networking)

Il modello FURPS

➤Performance

● riguardano attributi quantificabili del sistema

come tempi di risposta, throughput, disponibilita

nel tempo, etc...

➤Supportabilita

● riguardano la semplicita di fare modifiche dopo

il deployment come adattabilita e manutenibilita

Requisiti di dominio

Caratteristiche del sistema che derivano da caratteristiche

generali del dominio applicativo:

● Possono essere requisiti impliciti (il cliente li da

per scontati) o espliciti ma oscuri (il cliente usa

termini o concetti non conosciuti)

➤Vincoli che riguardano caratteristiche di sviluppo

e manutenzione:

● obiettivi temporali del progetto

Dettagli
Publisher
A.A. 2018-2019
4 pagine
SSD Ingegneria industriale e dell'informazione ING-IND/28 Ingegneria e sicurezza degli scavi

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher luca.pitl di informazioni apprese con la frequenza delle lezioni di Requisiti e Metriche e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli Studi di Cagliari o del prof Manca Pier Paolo.