Font size
Worksheetsdomande multiple create da me parte 1 is
Total questions: 120
Worksheet time: 3600secs
Che cosa è l'ingegneria del software secondo Bruegge e si può definire mediante 4 attività fondamentali. Elencarne almeno 3.
Modellazione, problem solving, acquisizione della conoscenza, fondamenti logici come guida.
Testing, progettazione, deployment
Revisione del codice, documentazione, manutenzione
Deployment, integrazione continua, release management
Le seguenti categorie di requisiti estendono il modello FURPS di base:
Affidabilità, usabilità, performance
Interfaccia, packaging, legali, operazione
Scalabilità, sicurezza, manutenibilità
Portabilità, interoperabilità, accessibilità
Un work product è:
Una specifica del cliente
Un artefatto prodotto durante l'attività di sviluppo
Un requisito funzionale
Un documento di gestione del progetto
In un diagramma di stato (state chart) un'attività è:
Un evento che cambia lo stato dell'oggetto
Un comportamento che è eseguito quando un oggetto risiede in uno stato
Un'azione di transizione tra stati
Una condizione di guardia per una transizione
Un caso d'uso specifica:
I requisiti hardware del sistema
Tutti i possibili scenari per una data funzionalità del sistema
Il budget e il tempo stimato per il progetto
La struttura di dati utilizzata nel sistema
Indicare i tre tipi di comunicazione pianificata e esprimere brevemente lo scopo di ognuna:
Presentazione del problema: viene spiegato il problem statement, Revisione del codice: esamina il codice per errori, Testing: verifica il funzionamento del software
Presentazione del problema: viene spiegato il problem statement, Riesame tra pari: vi sono due tipi, informale (walkthrough) e formale (ispezione), Brainstorming: si cercano tutte le soluzioni possibili ad un problema
Presentazione del problema: viene spiegato il problem statement, Documentazione: creazione di documenti per il progetto, Manutenzione: correzione di bug e miglioramenti
Pianificazione del progetto: definizione dei compiti e delle scadenze, Sviluppo del codice: scrittura del codice sorgente, Distribuzione: rilascio del software agli utenti
Indicare cosa rappresentano i seguenti oggetti:
Entity object: rappresenta un'entità fisica, Boundary object: rappresenta un confine geografico, Control object: rappresenta un controllo fisico
Entity object: rappresenta un documento di progetto, Boundary object: rappresenta un'interfaccia utente, Control object: rappresenta un controllo di sicurezza
Entity object: rappresenta l'informazione persistente all'interno del sistema, Boundary object: rappresenta l'oggetto di comunicazione tra l'utente e il sistema, Control object: rappresenta l'oggetto che si occupa del controllo del flusso degli eventi (la logica del sistema)
Entity object: rappresenta un database, Boundary object: rappresenta un firewall, Control object: rappresenta un controllo di accesso
Le schede CRC servono per definire:
I requisiti del progetto
I casi d'uso del sistema
Struttura e relazioni delle classi del sistema
Il budget e il piano di progetto
L'attività che identifica concetti più specifici a partire da concetti di più alto livello viene detta:
Generalizzazione
Astrazione
Specializzazione
Normalizzazione
Fornire la definizione di coesione ed accoppiamento:
L'accoppiamento è l'insieme delle dipendenze tra sottosistemi, mentre la coesione è l'insieme delle dipendenze interne ai sottosistemi. L'accoppiamento deve essere debole, mentre la coesione alta.
La coesione è l'insieme delle dipendenze tra sottosistemi, mentre l'accoppiamento è l'insieme delle dipendenze interne ai sottosistemi. La coesione deve essere debole, mentre l'accoppiamento alto.
L'accoppiamento è l'insieme delle dipendenze tra sottosistemi, mentre la coesione è l'insieme delle dipendenze interne ai sottosistemi. L'accoppiamento deve essere alto, mentre la coesione debole.
La coesione è l'insieme delle dipe
Quale tra le seguenti affermazioni è falsa? Un modello è utile per:
Visualizzare il sistema
Comunicare con gli stakeholder
Documentare le decisioni di progetto
Considerare i dettagli del sistema
La specifica delle seguenti informazioni "nome task, ruolo assegnato, descrizione task, input, output" qualifica:
Un requisito non funzionale
Un caso d'uso
Un task
Un diagramma di stato
La domanda "quanti task può eseguire il sistema in un certo periodo di tempo?" fa riferimento al criterio di disegno di:
Scalabilità
Throughput
Affidabilità
Usabilità
Fanno parte della fase di "start" del processo di project management le seguenti attività:
Sviluppo del codice, testing
Team formation, project kickoff
Manutenzione del sistema, documentazione
Rilascio del prodotto, supporto tecnico
Fanno parte del "client sign-off":
Schedule, RAD, un processo di revisione
Progettazione, sviluppo, testing
Deployment, manutenzione, supporto
Documentazione, formazione, rilascio
Un test stub:
Simula un componente chiamato da un altro sottotest
È un caso di test automatizzato
È una versione preliminare del software
È un documento di specifica dei requisiti
Una versione che viene resa disponibile a altri sviluppatori durante un progetto viene detta:
Release
Promotion
Deployment
Hotfix
Elencare le attività del system design:
Decomposizione del sistema in sottosistemi, mapping hw/sw, polizza di controllo degli accessi, scelta dell'architettura software, flusso di controllo globale, gestione dei dati persistenti, gestione delle condizioni limite
Progettazione dell'interfaccia utente, testing, documentazione, manutenzione del sistema, analisi dei requisiti, sviluppo del codice
Rilascio del software, supporto tecnico, formazione, testing, gestione dei dati, documentazione
Identificazione degli stakeholder, analisi dei requisiti, sviluppo del codice, testing, deployment, supporto tecnico
Definire la nozione di "work product"
Un documento di progetto che descrive le funzionalità del sistema
Un artefatto prodotto durante la realizzazione di un task o di un'attività. Il work product può essere interno (promotion) se è rivolto agli sviluppatori, deliverable se è da consegnare all'utente.
Una riunione tra sviluppatori per discutere dei progressi del progetto
Un diagramma di flusso che mostra il processo di sviluppo del software
Durante l'analisi gli sviluppatori mirano a produrre un modello del sistema che è:
Parziale, vago, ambiguo
Completo, consistente, non ambiguo
Flessibile, aperto, iterativo
Dettagliato, complesso, statico
Elencare i nomi delle sezioni che compongono un caso d'uso in forma testuale
Nome del caso d'uso, Attori partecipanti, Modello dei dati, Diagramma delle classi
Nome del caso d'uso, Attori partecipanti, Requisiti hardware, Condizioni di entrata
Nome del caso d'uso, Attori partecipanti, Condizioni d'entrata, Flusso di eventi, Condizioni di uscita, Requisiti di qualità
Nome del caso d'uso, Attori partecipanti, Codice sorgente, Requisiti di manutenzione
Il processo teso a ricercare un certo numero di soluzioni a un problema per poi valutarle viene detto:
Revisione tra pari
Prototipazione
Il processo teso a ricercare un certo numero di soluzioni a un problema per poi valutarle viene detto:
Revisione tra pari
Prototipazione
Brainstorming
Testing
Estendono il modello FURPS al modello FURPS+:
Requisiti di performance, requisiti di usabilità
Requisiti di sicurezza, requisiti di scalabilità
Requisiti di implementazione, requisiti legali
Requisiti di manutenibilità, requisiti di portabilità
Un diagramma di sequenza contiene le stesse informazioni di un:
Diagramma delle classi
Diagramma dei componenti
Diagramma di attività
Diagramma dei casi d'uso
Elencare almeno cinque attività che vengono svolte durante l'analisi dei requisiti
Sviluppo del codice, testing, deployment, manutenzione, documentazione
Identificare oggetti boundary, entity, control, attributi, aggregazioni, associazioni
Creazione dell'interfaccia utente, testing, revisione del codice, rilascio, supporto tecnico
Definizione del budget, pianificazione delle risorse, gestione dei rischi, monitoraggio del progetto, valutazione delle prestazioni
Nei diagrammi di attività le swimlane servono a:
Separare i diversi stati di un oggetto
Raggruppare le azioni svolte dai ruoli
Indicare le transizioni tra gli stati
Rappresentare i flussi di dati tra i processi
Possono estendere i diagrammi già presenti in UML:
Classi, oggetti
Stereotipi, vincoli
Interfacce, package
Diagrammi, casi d'uso
L'acquisizione della conoscenza è:
Un processo non lineare
Un processo lineare
Un processo sequenziale
Un processo ciclico
I diagrammi delle classi rappresentano:
Il flusso dei dati nel sistema
La struttura del sistema
I requisiti funzionali del sistema
La sequenza delle operazioni del sistema
Tra una classe e una sua istanza esiste una relazione di:
Associazione
Aggregazione
Generalizzazione
Composizione
Uno schedule costituisce:
Un elenco di attività
Una descrizione delle risorse necessarie
Il mapping di un task sull'asse dei tempi
Una lista di requisiti
Quale tra i seguenti requisiti è verificabile?
Il sistema sarà facile da usare
Il sistema sarà sicuro
Il sistema sarà flessibile
Il sistema fornirà risposte in meno di un secondo
In UML un'associazione tra due classi è:
Una relazione gerarchica
La rappresentazione di un insieme di collegamenti tra oggetti
Una relazione di aggregazione
Una relazione di composizione
Una richiesta di chiarimenti costituisce un evento di comunicazione:
Asincrono e pianificato
Sincrono e pianificato
Asincrono e non pianificato
Sincrono e non pianificato
In UML un diagramma state chart è una notazione per:
Descrivere la struttura del sistema
Descrivere la sequenza di stati di un oggetto
Descrivere il flusso dei dati nel sistema
Descrivere i casi d'uso del sistema
Nei diagrammi di sequenza quale delle seguenti euristiche è inadatta?
Oggetti boundary accedono a oggetti di controllo
Oggetti boundary accedono a oggetti entity
Oggetti entità accedono a oggetti di controllo
Oggetti di controllo accedono a oggetti entity
Lo scopo dell'analisi è quello di:
Progettare l'architettura del sistema
Testare il software
Strutturare e formalizzare i requisiti utente
Manutenere il sistema
L'identificazione degli obiettivi di design (design goal):
Descrive le funzionalità del sistema
Permette di stabilire le necessità hw/sw
Definisce i requisiti di usabilità
Stabilisce il budget del progetto
Una classe C1 nel package P1 usa una classe C2 nel package P2. La relazione tra P1 e P2 è:
Aggregazione
Composizione
Dipendenza
Generalizzazione
Nei diagrammi di stato un'azione è definita come:
Un comportamento atomico eseguito nella macchina a stati
Una transizione tra stati
Un evento che attiva una transiz
Nei diagrammi di stato un'azione è definita come:
Un comportamento atomico eseguito nella macchina a stati
Una transizione tra stati
Un evento che attiva una transizione
Una condizione di guardia
La comunicazione pianificata include:
Status meeting, peer review
Brainstorming, discussioni informali
Email, telefonate
Test, rilascio del software
Definire la nozione di metodo:
Una tecnica di debugging
Una funzione di un programma
Un procedimento generale per risolvere uno specifico problema
Una libreria di codice
In Java i contratti per la specifica delle interfacce possono essere implementati con il meccanismo di:
Meccanismo delle eccezioni
Overloading dei metodi
Ereditarietà
Polimorfismo
Il pilot testing:
Viene effettuato dall'intero team di sviluppo
È effettuato da un selezionato numero di utenti
Viene effettuato solo dal project manager
È effettuato dopo il rilascio del prodotto
Quali di queste attività fanno tutte parte dell'ispezione dei componenti?
Codifica, testing, deployment
Design, implementazione, manutenzione
Overview, preparation, follow-up
Pianificazione, sviluppo, rilascio
Nel contesto del configuration management, una versione di un configuration item che è stata formalmente riesaminata e poi approvata che può cambiare solo mediante una change request viene detta:
Release
Baseline
Hotfix
Patch
Definire il concetto di baseline nel contesto del configuration management:
Una versione preliminare del software
Una lista di bug noti
Una versione non approvata di un configuration item
È una versione di un configuration item che è stata formalmente riesaminata e successivamente approvata, che può essere cambiata solo dopo una richiesta di cambiamento.
Un work product è un artefatto prodotto durante lo sviluppo software e si distingue in "interno" destinato a usi propri del team di sviluppo e "deliverable" da consegnare invece al cliente. Associare a ogni artefatto il tipo appropriato:
Manuale d'uso: deliverable
Manuale dei test: interno
Diagramma delle classi: interno
Specifiche software: deliverable
Fornire la definizione di metodo:
Una tecnica di progettazione
Un insieme di regole per la programmazione
Un procedimento generale per risolvere uno specifico problema
Un approccio per la gestione del team
Il dominio applicativo riguarda tutti gli aspetti del problema dell'utente. Il dominio applicativo include:
Modelli di dati, protocolli di rete, librerie software
Ambiente fisico, utenti, processi
Requisiti hardware, specifiche tecniche, costi
Architettura del sistema, linguaggi di programmazione, tool di sviluppo
I diagrammi dei casi d'uso possono includere i seguenti tipi di relazione:
Aggregazione, composizione, generalizzazione
Comunicazione, estensione, generalizzazione
Associazione, dipendenza, implementazione
Ereditarietà, dipendenza, composizione
Un task è definito come l'unità di lavoro assegnabile a:
Un progetto
Un sistema
Un ruolo
Un'azienda
Lo scopo del project review è fornire informazioni:
Al cliente per approvare il progetto
Al project manager per stimare stato del progetto; ai team per esaminare interfacce
Agli sviluppatori per migliorare il codice
Al team marketing per preparare il lancio del prodotto
L'ingegneria delle interfacce riguarda:
La progettazione di database
La manutenzione del codice sorgente
Il ridisegno di interfacce utente in un sistema pre-esistente
L'ottimizzazione delle performance del sistema
Elencare i tre modelli che compongono il modello d'analisi:
Modello di dati, modello di processo, modello di interfaccia
Modello di dominio, modello di implementazione, modello di test
Modello funzionale, modello a oggetti, modello dinamico
Modello di rete, modello di sicurezza, modello di de
Fanno parte del "client sign-off":
Schedule, RAD, un processo di revisione
Testing, debugging, deployment
Pianificazione, sviluppo, manutenzione
Analisi, design, implementazione
Quando è possibile progettare test ripetibili per dimostrare che il sistema soddisfa la specifica, si dice che:
La specifica dei requisiti è completa
La specifica dei requisiti è coerente
La specifica dei requisiti è comprensibile
La specifica dei requisiti è verificabile
"System", "model", "document" sono sottoclassi dirette della classe:
Artefatto
Task
Work product
Processo
Un "ruolo" è definito come:
Un insieme di responsabilità assegnate a un individuo
Una posizione all'interno dell'organizzazione
Un compito specifico assegnato a un membro del team
Un insieme di task di tipo manageriale e tecnico che sono assegnati ad un singolo o ad un team
Il dominio delle soluzioni rappresenta:
Lo spazio di modellazione di tutti i possibili sistemi
I requisiti funzionali del sistema
L'ambiente fisico di sviluppo
Le specifiche hardware del sistema
In un diagramma delle classi un'associazione molti a molti rappresenta:
Una molteplicità 1..1 su entrambi i lati
Una molteplicità 0..1 su un lato e 1..n sull'altro
Una molteplicità 1..n su un lato e 0..n sull'altro
Una molteplicità 0..n oppure 1..n su entrambi i lati
Una specifica dei requisiti che non contraddice se stessa viene detta:
Verificabile
Completa
Comprensibile
Consistente
Descrivere (scopi e partecipanti) la comunicazione pianificata "problem inspection":
Un processo di revisione del codice tra il cliente e il project manager
L'ispezione è un tipo di comunicazione pianificata detta "riesame tra pari" che avviene tra sviluppatori. Durante questo tipo di comunicazione viene sottoposto il codice sorgente ad una serie di criteri per verificare se li rispetta.
Un incontro tra gli sviluppatori e gli stakeholder per discutere i requisiti
Una revisione delle specifiche di progetto tra il team di sviluppo e il team di testing
Sia W l'insieme dei work product e D l'insieme dei deliverable di un progetto software. Qual è la relazione tra W e D?
Deliverable è sottoinsieme di work product
Work product è sottoinsieme di deliverable
Work product e deliverable sono equivalenti
Deliverable è indipendente da work product
Quale tra le seguenti affermazioni è falsa? Un modello è utile per:
Studiare la proprietà emergente del sistema
Studiare la complessità del codice sorgente
Comunicare tra membri del team
Progettare l'architettura del sistema
Un tipo di dato astratto è specificato in:
Un linguaggio a oggetti
Un linguaggio di markup
Un linguaggio di scripting
Un linguaggio di programmazione funzionale
I diagrammi dei casi d'uso descrivono il comportamento di un sistema come percepito da:
Utenti del sistema
Sviluppatori del sistema
Tester del sistema
Clienti del sistema
In UML un link rappresenta:
Una connessione tra oggetti
Un'associazione tra classi
Una relazione di ereditarietà
Un flusso di dati
La specifica delle seguenti informazioni "nome task, ruolo assegnato, descrizione task, input, output" qualifica:
Un processo
Un progetto
Un task
Un deliverable
Il V-Model si occupa della pianificazione di attività di testing ed esecuzione dei test case relativamente a:
Solo alla fase di sviluppo
Solo alla fase di progettazione
Tutte le fasi del ciclo di sviluppo
Solo alla fase di test
Sono esclusivamente di pianificazione i seguenti insiemi di documenti:
Test report, test case
Test design, test case
Test plan, test schedule
Test script, test s
Sono esclusivamente di pianificazione i seguenti insiemi di documenti:
Test report, test case
Test design, test case
Test plan, test schedule
Test script, test summary
Le seguenti attività gestionali "configuration item identification, release management, variant management" fanno parte del:
Project management
Change management
Risk management
Quality management
Quale tra le seguenti caratteristiche è estranea alla definizione di progetto?
Serve a creare un prodotto o un servizio
Ha un inizio e una fine
È sempre di breve durata
Utilizza risorse limitate
I seguenti elementi fanno parte della specifica di un work package:
Nome task, descrizione task, costi
Nome task, descrizione task, dipendenze sugli input
Nome task, ruoli assegnati, output
Descrizione task, tempi stimati, output
Un vincolo è una regola collegata a un elemento di modellazione UML che:
Definisce l'interfaccia dell'elemento
Restringe la semantica dell'elemento modellato
Determina la visibilità dell'elemento
Stabilisce le dipendenze tra elementi
Gli scopi del client review:
Confermare i cambi ai requisiti del sistema
Rivedere il codice sorgente
Pianificare le attività future
Validare le specifiche di test
Quale tra le seguenti attività non fa parte della requirement elicitation?
Identificare i dati persistenti
Raccogliere requisiti funzionali
Condurre interviste con gli utenti
Analizzare i requisiti esistenti
Una baseline è definita come una versione di un work product che è:
Una versione temporanea
Una versione di work item formalmente riesaminata e approvata
Una versione di lavoro
Una versione preliminare
Il testing di un insieme comune di funzionalità presso un ristretto e selezionato gruppo di utenti viene detto:
User acceptance testing
Pilot testing
Regression testing
Integration testing
Nell'ambito della specifica delle interfacce un contratto è interpretabile come un accordo tra:
L'utente finale e il fornitore
L'utente della classe e l'implementatore della classe
Gli sviluppatori e i tester
Il project manager e il cliente
Quale delle seguenti tecniche è rivolta esclusivamente a scoprire staticamente gli errori (senza l'esecuzione del programma o dei modelli che lo rappresentano)?
Fault tolerance
Fault avoidance
Fault injection
Fault detection
Un processo aziendale di change management può essere modellato mediante:
Class diagram
Use case diagram
Activity diagram
Sequence diagram
Quale tra le seguenti attività è estranea al project management?
Pianificazione del progetto
Gestione qualità del software
Monitoraggio dello stato del progetto
Assegnazione delle risorse
Fornire una definizione di metodologia:
Una metodologia è un insieme di metodi che servono per risolvere classi di problemi
Una metodologia è un processo casuale di lavoro
Una metodologia è un insieme di strumenti software
Una metodologia è un approccio unico per ogni progetto
Quale domanda non è attinente al requisito di supportability?
Quanti utenti concorrenti deve supportare il sistema?
Qual è il costo del supporto tecnico?
Quali sistemi operativi deve supportare il sistema?
Quali protocolli di rete devono essere supportati?
Il modello dell'analisi deve essere:
Completo, consistente, non ambiguo
Solo funzionale e non ambiguo
Incompleto ma consistente
Solo tecnico e completo
Qual è lo scopo dei diagrammi di deployment?
Mostrare le relazioni logiche tra i componenti
Mostrare le relazioni fisiche tra i componenti hw e sw
Visualizzare i flussi di dati nel sistema
Descrivere i requisiti funzionali
Gli strumenti software definite "same time, different place groupware" consentono di:
Collaborare in modo asincrono
Collaborare tra utenti in rete in modalità sincrona
L
Gli strumenti software definite "same time, different place groupware" consentono di:
Collaborare in modo asincrono
Collaborare tra utenti in rete in modalità sincrona
Lavorare offline
Gestire progetti in modo centralizzato
Il documento che contiene: inputs, drivers, stubs, e risultati attesi dei test viene chiamato:
Test plan
Test case specification
Test report
Test strategy
Giustificare l'uso di uno strumento software per la gestione delle configurazioni:
Rende il lavoro più lento
Facilita la tracciabilità e il controllo delle versioni dei componenti
Aumenta la complessità del processo
Non è necessario in progetti piccoli
Fornire una definizione di work package:
È la specifica di come deve essere realizzato il work product. Al suo interno sono indicati nome del task, input, output, schedule.
È un documento di revisione
È una descrizione di un obiettivo del progetto
È un piano di test
Quale domanda tra le seguenti è inadatta a individuare gli attori di un sistema?
Quali sono i requisiti del sistema?
Chi paga per la realizzazione del sistema?
Chi utilizzerà il sistema?
Chi gestirà il sistema?
Un diagramma state chart è una notazione per:
Descrivere la sequenza di stati di un oggetto
Visualizzare le classi del sistema
Rappresentare le relazioni tra oggetti
Pianificare le attività di testing
Quali concetti non sono propri della fase di system design?
Architettura del sistema
Generalizzazione e specializzazione
Specifica dei requisiti
Componenti del sistema
La "differenza tra quanto specificato e comportamento osservato" fa riferimento al criterio di:
Usabilità
Affidabilità
Funzionalità
Manutenibilità
Il testing funzionale, di usabilità e di prestazioni eseguito dal cliente nell'ambiente di sviluppo viene definito:
Regression testing
Acceptance testing
Unit testing
Integration testing
La comunicazione pianificata include:
Problem presentation, project review, peer review
Solo problem presentation e project review
Problem presentation, project review, peer review
Solo peer review
Una versione di un configuration item che è stata formalmente riesaminata e che può essere cambiata solamente tramite una richiesta di cambiamento viene chiamata:
Work item
Baseline
Versione preliminare
Release candidate
Giustificare l'uso del linguaggio OCL:
OCL è utilizzato solo per la programmazione
L'OCL è un linguaggio che consente l'uso dei vincoli per specificare formalmente gli elementi in un singolo modello. Un vincolo è espresso con un'espressione booleana che restituisce true/false.
OCL è un linguaggio di markup
OCL è usato per la creazione di report
Un dominio applicativo:
Rappresenta tutti gli aspetti del problema utente
Rappresenta solo le soluzioni tecniche
È limitato agli utenti finali
Riguarda solo le tecnologie utilizzate
Un link rappresenta:
Una relazione tra classi
Una connessione tra oggetti
Un tipo di dato
Un metodo di accesso ai dati
Uno schedule costituisce:
La pianificazione delle attività di testing
Il mapping di un task sull'asse dei tempi
Un elenco di requisiti
La gestione delle risorse umane
Nei diagrammi statechart uno stato rappresenta:
Un'azione eseguita dall'oggetto
Una condizione soddisfatta da un insieme di attributi di un oggetto
Un evento che causa una transizione
Una classe di oggetti
In UML un'associazione tra due classi è:
La rappresentazione di un'entità
La rappresentazione di un insieme di collegamenti tra oggetti
Un tipo di relazione
Un metodo di interazione
La comunicazione non pianificata include:
Solo le riunioni programmate
Request for change, request for clarification, issue resolution
Solo le email di aggiornamento
Le comunicazioni formali tra i team
Quale attività non fa parte delle attività di requirements elicitation?
Interviste con gli utenti
Identificare gli oggetti boundary
Workshop di gruppo
Questionari agli stakeholder
Qual è l'esempio corretto di bilanciamento (trade-off) tra obiettivi di progetto?
Tempo di consegna vs qualità
Budget vs funzionalità
Manutenzione vs usabilità
Rischio vs risorse
L'attività di specifica delle interfacce include:
Identificare i requisiti di sicurezza
Specificare i contratti, identificare le boundary conditions
Analizzare i dati di input
Sviluppare piani di testing
Fornire una definizione di test case:
È un documento che riporta il codice sorgente
È un insieme di input e risultati aspettati che esercita un componente di test con lo scopo di causare fallimenti e rilevare errori.
È un piano per l'esecuzione di test automatizzati
È un report dei risultati del testing
Il path testing costituisce una tecnica di:
Blackbox testing
Whitebox testing
Regression testing
Integration testing
I cambi a un configuration item associati con una singola revisione di una configurazione vengono chiamati:
Change request
Change set
Version control
Release notes
Il lavoro di un team cross-funzionale:
Si concentra su un solo sottosistema
Ha impatto sullo sviluppo di molti sottosistemi
È limitato alla fase di testing
Non coinvolge diversi dipartimenti
Quali delle seguenti affermazioni è falsa. Il riesame del cliente (client review) è usato per:
Ispezionare il codice sorgente
Valutare i requisiti
Confermare le modifiche ai requisiti
Discutere il progresso del progetto
Quale di queste affermazioni è falsa? Un project review è condotto:
Durante il test di accettazione del cliente
Durante la pianificazione del progetto
Durante il test di accettazione del cliente
Durante la fase di chiusura del progetto
Quale tra i seguenti concetti non è collegato al pattern Facade?
Pattern proxy
Pattern decorator
Pattern singleton
Pattern adapter
Le boundary condition:
Definiscono il comportamento in condizioni estreme
De
