# data[].attributes.body
Esempio di estensione:

# data[].attributes.body
Esempio di inclusione:

# data[].attributes.body
Stakeholders (Portatori di interesse):

Persone o gruppi che influenzano e/o sono influenzati dalle attività di un’organizzazione, dai suoi prodotti o servizi e dai relativi risultati di performance

# data[].attributes.body
Case che eredita le caratteristiche di un altro case: il case figlio eredita il comportamento e il significato dal padre e aggiunge le sue caratteristiche specifiche

# data[].attributes.body
Utilizzato quando abbiamo un case simile ad un altro case, ma con qualche funzionalità in più

# data[].attributes.body
Caso d’uso che utilizza un’altro caso d’uso

# data[].attributes.body
I modelli Top-down e Bottom-up sono strategie di elaborazione dell' informazione e di gestione delle conoscenze riguardanti principalmente il software.
Questi modelli vengono utilizzati per analizzare situazioni problematiche e costruire ipotesi adeguate sulla loro soluzione.
Nel modello Top-down il problema principale viene scomposto in problemi più piccoli, e quindi più facili da risolvere; mentre nella strategia Bottom-up sono i problemi più piccoli a essere aggregati in un unico problema principale

# data[].attributes.body
Diagrammi caso d’uso nella progettazione Top-down:

# data[].attributes.body
Sequenza di transizione in un sistema il cui compito è di conseguire un risultato per un singolo attore del sistema

# data[].attributes.body
Descrive il ruolo assunto da un utente o da un' altra entità che interagisce con il sistema

# data[].attributes.body
Si tratta di un diagramma che esprime un comportamento sulla base dei suoi risultati osservabili

# data[].attributes.body
Dove non è possibile sostituire tutto il software, ma si possono modificare le interfacce utente per renderlo compatibile con nuovi ambienti

# data[].attributes.body
Quando un sistema utilizzato in azienda risulta obsoleto e quindi necessita di una riprogettazione (che può avvenire riprogettando il sistema "da zero" o semplicemente estendere alcune sue funzionalità)

# data[].attributes.body
Dove lo sviluppo parte da zero, nel tentativo di creare un sistema da integrare o sostituire.
Come fonte vengono utilizzati i requisiti del cliente e gli "stakeholders" (persone o gruppi che influenzano e/o sono influenzati dalle attività di un'organizzazione)

# data[].attributes.body
La raccolta di requisiti può essere di 3 tipi:

Greenfield engineering

Re-engineering

Interface engineering

# data[].attributes.body
Sistema è intuitivo e facile da usare
↓
Interfacce utenti, help, manuali…

# data[].attributes.body
il sistema è affidabile?

Fa il lavoro nei tempi stabiliti?

Le risposte sono sempre corrette?

# data[].attributes.body
Requisiti legati al tempo di risposta del sistema:

1. Velocità nel fornire risultati

2. quantità di risorse utilizzate

3. Quantità di info che riesce ad elaborare nell’unità di tempo (Throughput)

# data[].attributes.body
Il sistema è facilmente adattabile a modifiche nel tempo?

# data[].attributes.body
Caratteristiche del programma

Funzionalità, servizi, sicurezza

# data[].attributes.body
1. Functional requirements

Descrivono le funzionalità che il sistema deve avere

Descrivono i servizi offerti dal sistema

Devono essere completi e coerenti → Tutti i servizi e le funzionalità devono essere descritti ma non possono essere in conflitto tra loro

2. Non functional requirements -  requisiti imposti dalle modalità operative o dal rispetto di una normativa

Vincoli che il sistema deve rispettare imposte da fattori esterni [es. regole imposte dal triage del pronto soccorso]

3. Domain requirements - requisiti che dipendono dal dominio di operazione del sistema

Riservatezza dei dati porta ad accedere al sistema con username e password

# data[].attributes.body
1. User Requirements - Requisiti che percepisce il cliente

Descritte  in linguaggio del cliente → Requisiti aperti

2. System requirements - imposti da vincoli già esistenti (Utilizzo di apparecchiature all’interno dell’azienda)

Strutturati e vincolati → Requisiti chiusi

Descritti in linguaggio tecnico

Sconosciuti al cliente

# data[].attributes.body
I requisiti possono essere classificati da 2 punti di vista:

# data[].attributes.body
Per definire gli obiettivi di un sistema software è necessario definire:

1. Prestazioni richieste al sistema in relazione agli obiettivi operativi ed economico-finanziari

2. Requisiti normativi (legislativi) rilevanti (anche quelli di salute e sicurezza)

3. Comunicazione e cooperazione tra attori rilevanti

4. Attività degli utenti (ripartizione compiti), benessere e motivazioni

5. Prestazione dei diversi compiti

6. Progettazione flussi di lavoro e dell’organizzazione

7. Gestione del cambiamento  - attività di addestramento del personale coinvolto

8. Fattibilità delle operazioni (Anche manutenzione)

9. Progettazione posti di lavoro

# data[].attributes.body
I requisiti sono dinamici durante lo sviluppo dell’applicazione.
I requisiti in un processo di progettazione software vengono scritti in rispetto della normativa ISO 13407

↓

“Fondare il progetto sui reali bisogni degli utenti”

# data[].attributes.body
Convalidare le specifiche (Vedere SRSD con il cliente)

Le specifiche precedentemente formalizzate devono essere riviste con l’utente/committente per convalidarle

# data[].attributes.body
Emettere un SRSD (Software Requirement Specification Document)

Raccoglie le specifiche tecniche e funzionali del sistema

# data[].attributes.body
Il programmatore deve definire:

Funzionalità

Operatività

Vincoli

Presentazioni

Altre caratteristiche del sistema che servono per soddisfare le richieste del cliente

# data[].attributes.body
Il programmatore deve procedere con un'analisi del problema/problemi
Deve quindi:

Individuare necessità del cliente

Analizzare la natura dell’ambiente in cui lavorerà il software

Analizzare le condizioni di mercato

Trovare delle condizioni di funzionamento

# data[].attributes.body
La specifica dei requisiti (SRS) deve elencare le funzionalità del software seguendo le esigenze del cliente, facendogli capire quali sono tecnicamente possibili.
Deve inoltre descrivere l'ambiente in cui verrà utilizzato il software in cui il cliente è competente

# data[].attributes.body
Le fasi del modello a cascata sono le seguenti:

Studio di fattibilità:serve per comprendere se il programma è realizzabile o meno. Primo contatto con il cliente;

Analisi funzionale e tecnica:serve per capire quali funzioni dovrà svolgere il programma. Serve per far schiarire le idee al cliente e per fargli capire ciò che effettivamente vuole. Vengono usate le domande WHO(chi lo userà), WHAT(quali scopi avrà), WHEN(per quanto verrà usato), WHERE(in quale ambiente di sviluppo e in quale ambito lavorativo verrà usato) e WHY(perché viene utilizzato). Secondo contatto con il cliente;

Progettazione:si crea una bozza del progetto, definendo in quale sistema operativo e per quale linguaggio verrà usato e le interazioni tra le componenti. Si cerca di stabilire uno sviluppo in parallelo per definire le responsabilità dei programmatori. Si otterrà un documento di progetto;

Sviluppo:si mette in pratica il documento di progetto, scrivendo il codice;

Verifica:si eseguono dei test sul programma cercando di romperlo e si correggono eventuali errori, finita questa fase viene rilasciato il SW. Con il rilascio si ha l'ultimo contatto con il cliente;

Manutenzione:questa è l'unica fase dopo il rilascio del SW, serve a correggere bug ed ad aggiungere nuove funzionalità;

Nel modello a cascata il team di sviluppo non può tornare alle fasi precedenti, per cui, se viene rilevato un errore abbastanza massicico o grave, il team di sviluppo deve ricominciare da capo, perdendo tempo e denaro. Lo sviluppo di software, tramite questo modello, è molto lento e richiede anche molta attenzione e molta esperienza, per evitare di commettere errori. Il modello a cascata è sconsigliato anche per i suoi scarsi rapporti con il cliente.

# data[].attributes.body
Il modello è il progetto iniziale su cui si basa il SW.

Nel 1960 i suoi obbiettivi erano:

1. Identificare gli step da seguire;

2. Adattare gli output ad ogni evenienza;

3. Forzare il passaggio da una fase all'altra;

4. Impedire il rewind(tornare ai passaggi precedenti).

# data[].attributes.body
Il ciclo dello sviluppo agile è composto da diverse fasi.

1. Iteration 0 : Si lancia il progetto, con la partecipazione di tutte le parti coinvolte e si effettua la realizzazione del modello.

2. Sviluppo : Realizzazione del software funzionante, analisi e progettazione del software e si effettuano le prove sul Software ad ogni ciclo di modifica.

3. Rilascio : Fase di rilascio del software finito, si eseguono le ultime prove e si presenta il software prima del rilascio.

4. Produzione : Aggiornamento e mantenimento del Software rilasciato.

# data[].attributes.body
(Diagramma Comportamentale)
Descrive le funzionalità del software in termini di utenti e azioni eseguibili

# data[].attributes.body
(Diagramma Strutturale)
Descrive l'architettura di un software in termini di classi con i relativi attributi e metodi delle relazioni tra esse

# data[].attributes.body
(Diagramma Strutturale)
Rappresenta lo stato completo o parziale di un software in un istante, in termini di oggetti istanziati dalle classi delle loro relazioni e dipendenze

# data[].attributes.body
(Diagramma strutturale)
Documenta l'architettura di un sistema software in termini di componenti e delle loro dipendenze

# data[].attributes.body
(Diagramma di interazione)
Descrive la comunicazione tra le componenti di un sistema di messaggi.

# data[].attributes.body
(Diagramma comportamentale)
Illustra le fasi del flusso di controllo di un sistema software e analizza il processo.

# data[].attributes.body
(Diagramma comportamentale)

# data[].attributes.body
Le caratteristiche del modello a spirale, sono:

1.  Flessibilità.

2. Il lavoro può essere svolto in parallelo da più persone.

3. Si ha la possibilità di correggere gli errori il prima possibile.

4. Maggiore iterazione fornitore-cliente.

# data[].attributes.body
Il ciclo di vita di un SW inizia dalla sua progettazione, per poi passare allo sviluppo, all'evoluzione ed il rilascio.

Dopo il rilascio possono esserci altre evoluzioni, il ciclo di vita prosegue fino al suo ritiro(ultima volta che viene utilizzato)

La progettazione del SW è basata sul modello.

# data[].attributes.body
Ci sono diversi tipologie di modelli agili che hanno in comune le stesse metodologie:

Lightweight

Incrementali

Adattabili

Il processo di sviluppo agile consiste in una consegna rapida e di una maggiore affidabilità. Una caratteristica principale è il fatto di poter ritornare alle fasi precedenti.

# data[].attributes.body
Il modello a spirale è un tipo di modello(incrementale) che raffigura la progettazione di un software dalla sua nascita fino al suo ritiro.
La sua caratteristica principale, è che ad ogni giro vi è un incremento dei costi ma anche delle fasi eseguite.
(modello incrementale)

# data[].attributes.headline
Diagrammi UML (Unified Modelling Language)

# data[].attributes.subject
Diagrammi UML (Unified Modelling Language)

# data[].attributes.body
E' un linguaggio comprensibile a tutti, idealizza una realtà complessa facilitandone la comprensione. L'UML è un linguaggio semi-formale e grafico per vsiualizzare, documentare e costrutire un programma.

# data[].attributes.headline
Raccolta e analisi dei requisiti e Diagrammi casi d'uso

# data[].attributes.subject
Raccolta e analisi dei requisiti e Diagrammi casi d'uso

# data[].attributes.headline
Specifica dei requisiti e Classificazione dei requisiti

# data[].attributes.subject
Specifica dei requisiti e Classificazione dei requisiti

# data[].attributes.headline
Ciclo di vita del SW e Modello a cascata più problematiche

# data[].attributes.subject
Ciclo di vita del SW e Modello a cascata più problematiche