Appunti corso completi per superare esame di Ingegneria del Software

IMPORTANTI NOVITA’ DEL MODELLO:

- I PROCESSI SONO CHIAMATI “DISCIPLINES” e si dividono in 4 fasi:

1) INCEPTION (AVVIO)

2) ELABORATION (ELABORAZIONE)

3) CONSTRUCTION (COSTRUZIONE)

4) TRANSITION ( TRANSIZIONE )

- L’approccio IID si concretizza attraverso CICLI e ITERAZIONI (che si sviluppano nelle singole

fasi)

a) OGNI CICLO PRODUCE UNA NUOVA RELEASE

b) Ogni fase consente di ottenere dei MILESTONES

c) Ogni ITERAZIONE che si sviluppa nella singola fase , corrisponde ad UN PRODOTTO FINITO

Le DISCIPLINES (sarebbero i processi nel nostro caso) sono attive in tutte e 3 le fasi dello schema

soprastante , con INTENSITA’ E VOLUME VARIABILE



- INCEPTION si ha un picco di PROCESSI DI REQUIREMENTS



- ELABORATION si ha un picco di PROCESSI DI DESIGN



- CONSTRUCTION si ha un picco di PROCESSI DI TESTING ED IMPLEMENTAZIONE



- TRANSITION si ha un picco degli OPERATION PROCESSES



N.B. Un’ITERAZIONE attraversa tutte le DISCIPLINE



N.B. Il Prodotto FINITO di un’ITERAZIONE in una FASE passa alla FASE SUCCESSIVA

Esiste una nuova versione del Modello analizzato , con due nuove fasi ( Production e Retirement ) + una

nuova DISCIPLINE ( Processo di operazione e supporto)



MODELLI CON RIUSO O PER IL RIUSO Poiché il RIUSO è di fondamentale importanza nei CVS , sono

state apportate VARIANTI ai CICLI PROPOSTI allo scopo di facilitarne il RIUSO

- VARIANTE ALLA SPIRALE DI BOEHM adattata AL RIUSO



- VARIANTE AL COMPONENT-BASED adattata AL RIUSO in questa variante il RIUSO

COMINCIA A VALLE di PROGETTAZIONE 

- VARIANTE AL COMPONENT-BASED adattata AL RIUSO in questa variante il RIUSO

COMINCIA A LIVELLO DI REQUISITI

IL MODELLO del RIUSO DI “BASILI”

5) MODELLI DI SVILUPPO AGILE

- Sono modelli ovviamente FONDARI SUI METODI AGILI nati per esigenze affermatesi col

diffondersi di Applicazioni sul WEB

- I MODELLI AGILI devono fronteggiare i FREQUENTI CAMBIAMENTI dal punto di vista dei

REQUIREMENTS richiesti dal CUSTOMER

- Sono “AGILI” in quanto devono possedere la proprietà di “FLESSIBILITA’” e adattarsi ai

cambiamenti quanto meglio e più velocemente possibile.

ESISTE UN MANIFESTO PUBBLICATO DA 16 PROPONENTI nell’anno 2001 chiamato “MANIFESTO FOR

AGILE SOFTWARE DEVELOPMENT” Semplice manifesto “pubblicitario” con il nome dei 16 PROPONENTI

Il Manifesto elenca 12 REGOLE:

1) La prima cosa da fare è soddisfare il CLIENTE con SW di qualità

2) Bisogna saper gestire i CAMBIAMENTI in qualsiasi fase di sviluppo

3) La consegna del SW al cliente viene fatta con tempistiche di consegna tra 2 SETTIMANE a 2

MESI

4) Cliente / Sviluppatore devono comunicare per sistemare sempre le cose (anche

quotidianamente)

5) I Progetti sono affidati ad individui MOTIVATI e quindi che possano fare un buon lavoro

6) I Vari Team devono COMUNICARE di persona per prendere decisioni in comune e avanzare nel

lavoro

7) Il NOSTRO PROGRESSO è misurato sulla base del SW FUNZIONANTE e di QUALITA’ consegnato

8) I PROCESSI AGILI promuovono lo SVILUPPO SOSTENIBILE

9) Bisogna essere attenti all’eccellenza TECNICA per promuovere l’agilità

10) SEMPLICITA’ e ESSENZIALITA’ sono importantissime in ambito lavorativo

11) I Team che si auto-organizzano portano a termine i migliori progetti

12) Il Team deve migliorarsi con il passare del tempo ( prendendo decisioni comuni internamente)

 LA PIRAMIDE DELLO SVILUPPO AGILE:

1) VALORI

2) PRINCIPI

3) CICLI



SCRUM è un FRAMEWORK AGILE per la GESTIONE del CVS ( di tipo iterativo/Incrementale) concepito

per gestire PROGETTI E PRODOTTI SW o anche APPLICAZIONI DI SVILUPPO

Esso prende in considerazione: 

a) UN PRODUCT OWNER Il Proprietario del Prodotto



b) UN TEAM DI SVILUPPO DELEGATO “SCRUM DEVELOPMENT TEAM”



c) UN FACILITATORE DI RAPPORTI facilita i RAPPORTI tra le due parti sopra indicate

(CHIAMATO ANCHE SCRUM MASTER)

IL LAVORO SI ARTICOLA IN UNA SEQUENZA DI “SPRINTS” ( sono delle parti che del lavoro da consegnare a

tempo una dopo l’altra fino a quando non si arriverà all’ultima)

- ALCUNI ARTEFATTI SCRUM



a) I PRODUCT BACKLOG è una LISTA ORDINATA dei REQUISITI (per priorità)



b) SPRINT BACKLOG è una LISTA ORDINATA dei LAVORI ( sequenziale)

Esistono 4 occasioni formali in cui le parti interessate si incontrano per fissare o pianificare dei compiti:



- SPRINT PLANNING dura mediamente 8 ore



- DAILY SCRUM MEETING 15 minuti



- SPRINT REVIEW 4 ore



- SPRINT RETROSPECTIVE 3 ore



XP PROGRAMMAZIONE ESTREMA:

è una metodologia di sviluppo del software che enfatizza la scrittura di codice di qualità e la rapidità di

risposta ai cambiamenti di requisiti. Appartiene alla famiglia delle metodologie agili, e come tale prescrive

lo sviluppo iterativo e incrementale strutturato in brevi cicli di sviluppo.  SCHEMA GENERALE XP

SOFTWARE REQUIREMENTS

Dei Processi che abbiamo descritto 3 servono per i Requisiti:

1) 2 di essi agiscono nel “CONTESTO”

2) 1 di essi agisce nell’AMBIENTE DI PRODUZIONE

GRAFICO:

 I REQUISITI sono una parte ESSENZIALE nello sviluppo di un PRODOTTO SW : devono essere ben

definiti per contrastare potenziali SW FAILURES e per concorrere all’ottimizzazione della

Conformity ( proprietà del SW)

DEFINIZIONE DI REQUISITO(GENERALE): è una CARATTERISTICA che il SISTEMA SW deve AVERE o un

VINCOLO che il SISTEMA SW deve SODDISFARE in base alle direttive del CUSTOMER ( DESCRIVE IL COSA e

non IL COME!)

UNA DEFINIZIONE DI IEEE :

Un REQUISITO è 3 COSE:

1) Una condizione o una capacità richiesta dal CUSTOMER per RISOLVERE UN PROBLEMA o

RAGGIUNGERE UN OBIETTIVO

2) Una condizione o una capacità richiesta che il SISTEMA DEVE SODDISFARE in base alle direttive

imposte da un CONTRATTO o comunque da un DOCUMENTO

3) Una documentazione di una condizione o di una capacità



Schema dei REQUISITI deriva dal fatto che il SISTEMA SW è fatto di COMPONENTI

 Un Requisito deve essere VERIFICABILE

 I REQUISITI devono essere CLASSIFICABILI IN BASE A PRIORITA’

Una CLASSIFICAZIONE PER PRIORITA’ può essere fatta con l’ausilio di un’apposita SCALA chiamata:

SCALA MOSCOW: (Classificazione a 4 livelli di priorità)



1) M di MUST REQUISITI CHE RISPONDONO al “DEVE AVERE”… sono quindi OBBLIGATORI



2) S di SHOULD REQUISITI IMPORTANTI MA NON OBBLIGATORI



3) C di COULD REQUISITI di SCARSA IMPORTANZA



4) W di WAN’T REQUISITI che NON HANNO MINIMA INFLUENZA SUL SUCCESSO DEL SISTEMA

* N.B. il 4) Wan’t sta per “Non voluti nell’attuale RELEASE “

Esistono 2 tipi di REQUISITO SOFTWARE:

- DI PRODOTTOO ( una funzionalità che il SW deve implementare)

- DI PROCESSO (l’obbligo di adottare delle METRICHE OBBLIGATORIE ( esempio : “per il CVS

adottare obbligatoriamente il RUP”)

Un secondo tipo di Classificazione in base alla caratteristica che descrivono ( DI SWEBOK ):

Un Requisito può essere :

a) FUNZIONALE: descrive una funzionalità che il sistema deve avere

b) NON FUNZIONALE : descrive un vincolo che deve essere rispettato (performances , efficienza ,

tempo ecc…)

c) REQUISITO legato a PROPRIETA’ ARCHITETTURALI DEL SISTEMA [NON ADOTTATO

COMUNEMENTE]

I 5 REQUISITI non FUNZIONALI ( RACCOMANDATI DA SWEBOK):

1) PERFORMANCE

2) MANUTENIBILITA’

3) SAFETY ( SICUREZZA) riguardano la sicurezza del SISTEMA stesso ( dati salvaguardati ecc..)



4) SECURITY (PROTEZIONE) riguardano la protezione del SISTEMA da accessi indesiderati



5) INTEROPERABILITY capacità da parte di un sistema ( o sottosistema) di interagire a livello

operativo con altri prodotti o sistemi

I REQUISITI per la QUALITA’ di “FURPS”:

1) Functionality = Funzionalità (Capacità di fornire le funzioni richieste)

2) Usability = Usabilità (Facilità d'uso dell'utenza finale)

3) Reliability = Attendibilità (Gestione degli errori e dei crash)

4) Performance = Prestazioni

5) Supportability = Supportabilità (Capacità di garantire assistenza e mantenimento)

- All'acronimo si può aggiungere anche un "+" finale, (FURPS+) che indica i requisiti secondari e/o

complementari come il linguaggio informatico da usare, o le questioni legali da affrontare..

RISOLVERE I CONFLITTI TRA I REQUISITI:

- INDIVIDUATI I REQUISITI IN CONFLITTO SE NE ELIMINA UNO (SE POSSIBILE ) oppure SE NE

TRASFORMA UNO DEI DUE (SE POSSIBILE) oppure SI TRASFORMANO ENTRAMBI!

- L’ELIMINAZIONE DI UN REQUISITO non può essere presa in considerazione se I REQUISITI IN

CONFLITTO SONO FUNZIONALI CON EGUALE PRIORITA’

- Per fare ciò occorre necessariamente PRENDERE ACCORDI COL CUSTOMER

L’assenza di CONFLITTI è sinonimo di REQUIREMENTS QUALITY:

ci si trova nello stato di REQUIREMENTS QUALITY se sono rispettate le seguenti proprietà:



1) CONSISTENZA assenza di contraddizione tra i requisiti



2) VERIFICABILITA’ se sono verificabili i requisiti

 

3) TRACCIABILITA’ collegamento dei Requisiti sono pertanto TRACCIABILI

ESISTE UN MODELLO GENERALE da ADOTTARE per la REQUIREMENTS QUALITY;

esso è definito da 6 proprietà:

1) CONSISTENZA 2) VERIFICABILITA’ 3) TRACCIABILITA’



4) COMPLETEZZA capacità da parte di TUTTI I REQUISITI di rappresentare in maniera completa il

funzionamento del sistema



5) NON AMBIGUITA’ TUTTI I REQUISITI devono essere BEN ESPRESSI ( da un punto di vista

SEMANTICO) 

6) CORRETTEZZA TUTTI I REQUISITI devono rappresentare in MANIERA CORRETTA le funzionalità

del SISTEMA

DEFINIZIONE DEI REQUISITI 

IL PROCESSO DI “DEFINIZIONE GENERALE DEI REQUISITI” è parte dell’ISO 12207 “STAKEHOLDER



REQUIREMENTS DEFINITION PROCESS” Permette di DEFINIRE GLI STAKEHOLDERS coinvolti nel



SISTEMA, descrivendone DESIDERI E BISOGNI DEFINISCE ANCHE LE INTERAZIONI CHE IL SISTEMA

DOVRA’ AVERE CON L’AMBIENTE OPERATIVO

Esiste una SPECIALIZZAZIONE di tale processo nell’ O.O. Software Engineering chiamata “ELICITAZIONE DEI

REQUISITI” (IL VERO CUORE DEL PROCESSO, che permette l’IDENTIFICAZIONE dei REQUIREMENTS)

Il Processo di STAKEHOLDER REQUIREMENTS DEFINITION PROCESS comprende 5 STEPS:1)

1) Identificazione degli STAKEHOLDERS 

2) Identificazione dei REQUISITI “ELICITAZIONE DEI REQUISITI” CUORE DEL PROCESSO



3) Valutazione dei REQUISITI Si valutano le PRIORITA’ dei vari REQUIREMENTS