Ingegneria del software - paniere completo

Il significato dell'acronimo RAD

Nel corso, associamo all'acronimo RAD i seguenti significati:

• Root Assigned Display
• Random Assigned Data
• Requirement Analysis Document
• Rapid Association Device

Attività corretta

Relativamente all'attività di una delle affermazioni che seguono, non è corretta la seguente:

• Il committente e gli utenti mantengono aggiornato il glossario a mano a mano che le specifiche dei requisiti evolvono.
• Gli sviluppatori costruiscono un glossario (data dictionary) che assegna un nome e una descrizione ad ogni oggetto partecipante nei vari casi d'uso.
• L'identificazione dell'analisi degli oggetti partecipanti produce il modello iniziale degli oggetti all'inizio.
• Uno dei primi ostacoli che sviluppatori e utenti incontrano della loro collaborazione è la differente terminologia.

Struttura del Documento di Analisi dei Requisiti (RAD)

Il Documento di Analisi dei Requisiti (RAD) descrive completamente il sistema in...

termini di requisiti funzionali e non-funzionali, e si rivolge ai committenti, agli utenti, al project manager, agli analisti e ai progettisti del sistema. È suddiviso in 4 sezioni: 1) La prima sezione del RAD, Introduzione, si propone di fornire una breve panoramica sulle funzionalità del sistema, le ragioni per il suo sviluppo, la sua area di copertura, i riferimenti al contesto (studi di fattibilità ecc.), gli obiettivi e i criteri per determinare il successo del progetto. 2) La seconda sezione, Analisi dell'esistente, descrive lo stato corrente della problematica. Se il sistema in via di realizzazione sostituirà un sistema esistente, questa sezione descrive le funzionalità e i problemi del vecchio sistema. Altrimenti la sezione descrive come vengono realizzati ora i compiti che il nuovo sistema supporterà. 3) La terza sezione, Il sistema proposto, documenta il modello dell'analisi del nuovo sistema. È qui che vengono descritti i requisiti funzionali e non-funzionali del sistema proposto, le sue caratteristiche principali e le soluzioni proposte per risolvere la problematica. 4) La quarta sezione, Pianificazione, fornisce una stima dei tempi e delle risorse necessarie per lo sviluppo e l'implementazione del sistema proposto. Vengono definiti i milestone, le attività e le responsabilità del team di sviluppo, così come le eventuali dipendenze e i rischi associati al progetto. Questo documento è di fondamentale importanza per garantire una corretta comprensione e pianificazione del progetto, nonché per fornire una base solida per lo sviluppo del sistema.requisiti elicitati earticolata in quattro sottosezioni: - Una Panoramica funzionale del nuovo sistema - I Requisiti funzionali di alto livello - I Requisiti non-funzionali espressi dagli utenti e non direttamente correlati alle funzionalità - descrive gli scenari, i casi d'uso e i modelli, sia degliModelli del sistema oggetti che dinamici, del nuovo sistema. Questala specifica funzionale completa, compresi i prototipi dell'interfacciasotto-sezione contiene utente e i percorsi dinavigazione (sequenze di videate) nei vari vasi d'uso, ai quali gli4) La quarta sezione formata dal Glossario, il quale identifica ogni oggetto partecipantesviluppatori danno un nome ed una descrizione non ambigua per avere una chiara e condivisa terminologia.lOMoARcPSD|8323897Set Domande: INGEGNERIA DEL SOFTWAREINGEGNERIA INFORMATICA E DELL'AUTOMAZIONE (D.M. 270/04)Docente: Sarti LuigiLezione 013modello dinamico1. In merito al definito in fase di analisi dei requisiti,

una delle affermazioni che seguono non è corretta. Quale?

1. Il modello dinamico evidenzia le relazioni di ereditarietà tra le classi.
2. Il modello dinamico contiene diagrammi UML delle macchine a stati.
3. Il modello dinamico contiene diagrammi UML di sequenza.
4. Il modello dinamico si concentra sul comportamento del sistema.

In merito all'analisi una delle affermazioni che seguono non è corretta. Quale?

1. In fase di analisi vengono rimossi errori ed ambiguità ancora presenti nel RAD.
2. In fase di analisi, la specifica dei requisiti prodotta nella fase di elicitazione viene formalizzata; inoltre le condizioni al contorno e i casi eccezionali vengono esaminati in dettaglio.
3. Gli utenti e il committente non partecipano alla fase di analisi: il loro coinvolgimento si esaurisce nella fase di elicitazione dei requisiti.
4. L'analisi produce un modello del sistema corretto, completo, consistente, non ambiguo.

Analisi dei requisiti, è composto da tre modelli individuali. Quale, tra i quattro elementi sotto elencati, non è una componente del modello dell'analisi?

1. Il modello dinamico
2. Il modello degli oggetti dell'analisi
3. Il modello funzionale
4. Il modello costi-benefici

Il modello degli oggetti dell'analisi.

4. In merito al una delle affermazioni che seguono non è corretta. Quale?

1. Il modello degli oggetti dell'analisi definisce l'interfaccia e l'implementazione dei principali metodi del sistema.
2. Il modello degli oggetti dell'analisi cataloga i principali concetti visibili all'utente.
3. Il modello degli oggetti dell'analisi è rappresentato tipicamente da diagrammi delle classi UML.
4. Il modello degli oggetti dell'analisi si concentra sui concetti, le proprietà e le relazioni che il sistema manipola.

Il modello degli oggetti dell'analisi si concentra sui concetti, le proprietà e le relazioni che il sistema manipola.

5. Nel contesto dell'analisi dei requisiti, che cosa sono gli oggetti? Fornisci una definizione ed un esempio.

Gli oggetti sono entità che rappresentano elementi del sistema che possiedono caratteristiche e comportamenti specifici. Ad esempio, in un sistema di gestione di una biblioteca, un oggetto potrebbe essere un libro con attributi come il titolo, l'autore e il numero di pagine, e metodi come il prestito e il ritorno.

Nell'esempio dell'Orologio2B, gli oggetti di tipo Control implementano i casi CambiaData. È un oggetto di tipo control che rappresenta l'attività di cambiare la data premendo una combinazione di bottoni.

Nel contesto dell'analisi dei requisiti, per "Fornisci un esempio" si intende l'attività che identifica concetti più specifici a partire da un concetto di alto livello. La Specializzazione.

Ad esempio: supponiamo di discutere con il committente le funzionalità di un sistema di gestione delle emergenze. Il committente per prima cosa descrive il concetto di Incidente, quindi spiega che ci sono tre tipi di incidente: i Disastri, che richiedono la collaborazione di diverse agenzie; le Emergenze, che richiedono intervento immediato da parte di una singola agenzia; e gli incidenti a Bassa Priorità, che possono non essere gestiti immediatamente se le risorse sono impegnate in eventi più gravi.

boundary?

Nel contesto dell'analisi dei requisiti, gli oggetti rappresentano le entità che compongono il sistema. Essi possono essere di diversi tipi, tra cui boundary, entity e generalizzazione. - Gli oggetti di tipo boundary rappresentano le interazioni tra gli attori e il sistema. Ad esempio, nell'esempio dell'Orologio2B, il Bottone e il Display sono oggetti di tipo boundary. - Gli oggetti di tipo entity rappresentano le informazioni persistenti che il sistema mantiene. Ad esempio, nell'esempio dell'Orologio2B, gli oggetti Anno, Mese e Giorno sono oggetti di tipo entity. - La generalizzazione è l'attività di modellizzazione che identifica concetti astratti partendo da concetti di più basso livello. Ad esempio, in un sistema di gestione delle emergenze, potremmo avere sia incidenti del traffico che incendi come eventi da gestire. Questi due eventi possono essere generalizzati in un concetto più alto livello chiamato "emergenza".alcuni attributi che possono essere condivisi da entrambi gli incidenti del traffico e dagli incendi sono: - La gravità dell'emergenza - La posizione geografica dell'emergenza - Il numero di persone coinvolte - Le risorse necessarie per gestire l'emergenza - Le azioni da intraprendere per risolvere l'emergenza Per quanto riguarda le operazioni comuni, potrebbero includere: - La segnalazione dell'emergenza - La gestione delle risorse - La comunicazione con le autorità competenti - L'evacuazione delle persone coinvolte - L'indagine sull'origine dell'emergenza Queste sono solo alcune delle caratteristiche e operazioni che potrebbero essere condivise tra gli incidenti del traffico e gli incendi.euristiche suggerite nel corso? 1. Identifica i messaggi, le notifiche, gli avvisi che il sistema usa per rispondere all'utente. 2. Identifica gli aspetti visivi dell'interfaccia utente: font, colori, immagini ecc. 3. Identifica le componenti dell'interfaccia utente necessarie per attivare i casi d'uso. 4. Identifica i moduli, i formulari e le schede necessari per l'input dei dati nel sistema.

• Identifica un oggetto control per ogni caso d'uso.
• Identifica un oggetto control per ogni classe.
• Assicurati che le condizioni di ingresso e uscita del caso d'uso siano ben definite.
• Identifica un oggetto control per ogni attore del caso d'uso.
• Diagrammi di sequenza:
1. I diagrammi di sequenza connettono gli scenari ai diagrammi delle macchine a stati.
2. I diagrammi di sequenza sono meno efficaci dei casi d'uso nella comunicazione con gli utenti.
3. I diagrammi di sequenza sono utili agli sviluppatori per chiarire aspetti oscuri dei requisiti.
4. I diagrammi di sequenza evidenziano la distribuzione dei comportamenti tra gli oggetti che partecipano ad un caso d'uso o ad uno scenario.
• Diagrammi di sequenza:
1. Nel corso vengono suggerite alcune euristiche per lo sviluppo, in fase di analisi, dei diagrammi di sequenza.

non è una delle euristiche suggerite nel corso? La prima colonna rappresenta l'attore che inizia il caso d'uso. Altri oggetti control possono essere creati dall'oggetto boundary che ha iniziato il caso d'uso. La seconda colonna è un oggetto boundary che l'attore ha usato per iniziare il caso d'uso. La terza colonna è l'oggetto entity che gestisce il resto del caso d'uso.

LOMoARcPSD|8323897Set Domande: INGEGNERIA DEL SOFTWARE INGEGNERIA INFORMATICA E DELL'AUTOMAZIONE (D.M. 270/04) Docente: Sarti Luigi Lezione 017 di un sotto-sistema?

1. Che cos'è l'interfaccia?
1. È l'insieme dei controlli con cui un operatore può configurare il sotto-sistema.
2. È l'insieme delle operazioni che il sotto-sistema rende disponibili.
3. È lo strato software che incapsula le interazioni tra il sotto-sistema e il sistema operativo ospite.
4. È l'insieme dei messaggi che le classi che costituiscono il sotto-sistema si scambiano tra loro.