Wondershare EdrawMind
Galleria mappe mentale Capitolo 4 Mappa mentale dell'ingegneria della progettazione
- 13
Capitolo 4 Mappa mentale dell'ingegneria della progettazione
Capitolo 4 Mappa mentale dell'ingegneria della progettazione Questa mappa mentale include una panoramica dell'ingegneria della progettazione del software, dei principi di progettazione del software, della progettazione dell'architettura del software, della tecnologia di progettazione a livello di componente, delle specifiche di progettazione e della revisione della progettazione.
Modificato alle 2023-11-14 21:39:57
- Microbiologia medica Infezione batterica e immunità
Microbiologia medica, Infezioni batteriche e immunità riassume e organizza i punti di conoscenza per aiutare gli studenti a comprendere e ricordare. Studia in modo più efficiente!
- teoria cinetica dei gas
La teoria cinetica dei gas rivela la natura microscopica dei fenomeni termici macroscopici e le leggi dei gas trovando la relazione tra quantità macroscopiche e quantità microscopiche. Dal punto di vista del movimento molecolare, vengono utilizzati metodi statistici per studiare le proprietà macroscopiche e modificare i modelli di movimento termico delle molecole di gas.
- Breve História do Tempo
Este é um mapa mental sobre uma breve história do tempo. "Uma Breve História do Tempo" é um trabalho científico popular com influência de longo alcance. Ele não apenas introduz os conceitos básicos da cosmologia e da relatividade, mas também discute os buracos negros e a expansão. Do universo. questões científicas de ponta, como inflação e teoria das cordas.
Capitolo 4 Mappa mentale dell'ingegneria della progettazione
- Microbiologia medica Infezione batterica e immunità
Microbiologia medica, Infezioni batteriche e immunità riassume e organizza i punti di conoscenza per aiutare gli studenti a comprendere e ricordare. Studia in modo più efficiente!
- teoria cinetica dei gas
La teoria cinetica dei gas rivela la natura microscopica dei fenomeni termici macroscopici e le leggi dei gas trovando la relazione tra quantità macroscopiche e quantità microscopiche. Dal punto di vista del movimento molecolare, vengono utilizzati metodi statistici per studiare le proprietà macroscopiche e modificare i modelli di movimento termico delle molecole di gas.
- Breve História do Tempo
Este é um mapa mental sobre uma breve história do tempo. "Uma Breve História do Tempo" é um trabalho científico popular com influência de longo alcance. Ele não apenas introduz os conceitos básicos da cosmologia e da relatividade, mas também discute os buracos negros e a expansão. Do universo. questões científicas de ponta, como inflação e teoria das cordas.
- Consigliato per te
- Profilo
Mappa mentale dell'economia dell'ingegneria del software e dell'ingegneria del software
- 11
Analisi dei requisiti, test del software, ingegneria del software, progettazione del software, mappa mentale per lo studio autonomo
- 12
Capitolo 4 Progetto di progettazione
Panoramica sull'ingegneria della progettazione del software
Panoramica sull'ingegneria della progettazione del software
L'analisi dei requisiti software risolve il problema di "cosa fare", mentre il processo di progettazione del software risolve il problema di "come farlo"
La progettazione del software è il processo di trasformazione dei requisiti software nella rappresentazione del software. Consiste principalmente in due fasi: fase di progettazione dell'architettura software e progettazione a livello di componente.
Attività di progettazione del software
Utilizzando un approccio di progettazione, le informazioni sui requisiti software rappresentati da dati, modelli funzionali e comportamentali nel modello di analisi del software vengono passate alla fase di progettazione, risultando nella progettazione di dati/classi, progettazione dell'architettura, progettazione dell'interfaccia, progettazione a livello di componente.
Progettazione di dati/classi: trasforma il modello di classe di analisi nell'implementazione della classe e nelle strutture dati necessarie per l'implementazione del software
Il contenuto dettagliato dei dati descritto nelle classi, negli oggetti dati e nelle relazioni definiti nel CRC e nel dizionario dei dati fornisce la base per le attività di progettazione dei dati.
Il processo di progettazione dei dati comprende i due passaggi seguenti:
In primo luogo, la selezione di una rappresentazione logica per gli oggetti dati determinati nella fase di analisi dei requisiti richiede l'analisi algoritmica di diverse strutture al fine di selezionare la soluzione progettuale più efficace;
Quindi, identificare i moduli del programma che operano sulle strutture logiche dei dati necessarie per limitare o definire l'ambito dell'impatto delle singole decisioni sulla progettazione dei dati.
Progettazione architettonica: la progettazione architettonica definisce la struttura complessiva del software
La progettazione architettonica definisce la struttura complessiva del software, che consiste di componenti software, attributi visibili esternamente e relazioni tra loro.
Le rappresentazioni del progetto architettonico possono essere derivate dalle specifiche del sistema, dal modello di analisi e dall'interazione dei sottosistemi definiti nel modello di analisi.
Progettazione dell'interfaccia: la progettazione dell'interfaccia descrive come comunicare all'interno del software, tra il software e i sistemi collaborativi e tra i colleghi del software.
La progettazione dell'interfaccia comprende principalmente tre aspetti:
Progettare interfacce tra moduli software
Progettare interfacce tra moduli e altri produttori e consumatori di informazioni non umane (come entità esterne)
L'interfaccia tra progettista (utente) e computer
Progettazione a livello di componente: la progettazione a livello di componente trasforma gli elementi strutturali dell'architettura software in una descrizione procedurale dei componenti software.
La progettazione a livello di componente trasforma gli elementi strutturali dell'architettura software in descrizioni procedurali dei componenti software.
Le informazioni ottenute da modelli basati su classi, modelli di flusso e modelli comportamentali costituiscono la base per la progettazione dei componenti.
Obiettivi di progettazione del software
Nel processo di progettazione del software, dobbiamo prestare molta attenzione ai fattori di qualità del software.
Gli obiettivi del processo di progettazione del software McGlanglin sono:
1) Il progetto deve implementare tutti i requisiti espliciti descritti nel modello di analisi e deve soddisfare tutti i requisiti impliciti attesi dall'utente.
2) Il progetto deve essere leggibile e comprensibile, facilitandone la programmazione, il test e la manutenzione futura.
3) La progettazione dovrebbe iniziare dalla prospettiva dell'implementazione e fornire un quadro completo del software relativo a dati, funzioni e comportamenti.
Norme tecniche per la progettazione delle misure
1) La struttura progettata dovrebbe essere una struttura gerarchica per stabilire il controllo tra i componenti software.
2) La progettazione dovrebbe essere modulare, dividendo logicamente il software in componenti che completano funzioni o sottofunzioni specifiche.
3) La progettazione dovrebbe includere sia l'astrazione dei dati che l'astrazione dei processi.
4) La progettazione dovrebbe prevedere moduli con caratteristiche funzionali indipendenti.
5) La progettazione dovrebbe stabilire interfacce che riducano le complesse connessioni tra il modulo e l'ambiente esterno.
6) La progettazione dovrebbe essere in grado di stabilire un metodo guidabile e ripetibile basato sulle informazioni ottenute dall'analisi dei requisiti software.
processo di progettazione del software
1) Sviluppare le specifiche
2) Architettura e design dell'interfaccia
3) Progettazione di dati/classi
4) Progettazione a livello di componente (processo).
5) Scrivere documenti di progettazione
6) Revisione del progetto
principi di progettazione del software
Astrazione e raffinamento graduale
L'astrazione è una strategia di base per controllare la complessità man mano che la scala della progettazione del software aumenta gradualmente.
Il processo di astrazione va dallo specifico al generale. Il concetto di livello superiore è l'astrazione del concetto di livello inferiore, e il concetto di livello inferiore è il perfezionamento e il raffinamento del concetto di livello superiore.
Ogni fase del processo di ingegneria del software è una descrizione concreta dell'interpretazione di un livello di astrazione più elevato.
I principali metodi di astrazione nella progettazione del software sono: astrazione dei processi e astrazione dei dati
L'astrazione del processo (chiamata anche astrazione funzionale) significa che qualsiasi operazione che completa una funzione chiaramente definita può essere trattata dall'utente come un'unica entità, sebbene questa operazione sia in realtà completata da una serie di operazioni di livello inferiore
L'astrazione dei dati si riferisce alla definizione dei tipi di dati e delle operazioni applicate agli oggetti di questo tipo e limita l'intervallo di valori degli oggetti che possono essere modificati e osservati solo tramite queste operazioni.
Cerca gradualmente il raffinamento
Affinamento passo dopo passo, scomposizione del processo di risoluzione del problema in più passaggi o fasi, in cui ogni passaggio è più raffinato e più vicino alla soluzione del problema rispetto al passaggio precedente.
L'astrazione consente ai progettisti di descrivere processi e dati ignorando i dettagli di basso livello, mentre il raffinamento aiuta i progettisti a rivelare i dettagli di basso livello durante il processo di progettazione.
Modulare
La modularizzazione, ovvero la divisione del software in componenti più piccoli, indipendenti ma interconnessi secondo principi prescritti, è in realtà un processo di scomposizione e astrazione del sistema.
Un modulo è una raccolta di oggetti di programma come descrizioni di dati e istruzioni eseguibili. Ha un nome individuale ed è accessibile tramite nome.
Ad esempio, processo. Funzioni, subroutine, macro, ecc.
occultamento delle informazioni
I dettagli di implementazione di ciascun modulo dovrebbero essere nascosti agli altri moduli
Le informazioni (inclusi dati e procedure) contenute nel blocco non possono essere utilizzate da altri moduli che non necessitano di queste informazioni.
Attraverso l'occultamento delle informazioni è possibile definire e applicare restrizioni di accesso ai dettagli del processo e alle strutture dati locali del modulo.
Funzionalmente indipendente
Indipendenza funzionale: l'indipendenza funzionale è il risultato diretto di concetti come modularità, astrazione, occultamento delle informazioni e localizzazione. L'indipendenza funzionale può essere ottenuta sviluppando moduli che siano funzionalmente specifici ed evitino interazioni eccessive con altri moduli.
L'importanza dell'indipendenza funzionale
Le funzionalità sono separate e le interfacce sono semplificate rendendo il software più facile da sviluppare
Poiché gli effetti collaterali causati dalla modifica del progetto o della codifica sono limitati, la diffusione degli errori viene ridotta e diventa possibile il riutilizzo dei moduli, rendendo così più semplice la manutenzione e il test del software.
L’indipendenza funzionale può essere misurata da due indicatori: coesione e accoppiamento
La coesione è una misura di quanto strettamente gli elementi all'interno di un modulo sono integrati tra loro.
Il modulo generale coesione è suddiviso in sette tipologie
1) Coesione coincidente (coesione accidentale): un modulo che separa gli stessi segmenti di codice del programma che non presentano chiaramente funzioni indipendenti in più moduli è chiamato modulo di coesione coincidente.
2) Coesione logica: si riferisce a un modulo che completa una serie di compiti logicamente correlati Quando il modulo viene chiamato, i parametri di controllo passati al modulo determinano quale funzione il modulo deve eseguire.
3) Convergenza temporale: significa che tutte le attività in un modulo devono essere eseguite entro lo stesso periodo di tempo. Ad esempio, modulo di inizializzazione e modulo di terminazione
4) Coesione del processo: si riferisce a un modulo che completa più attività e queste attività devono essere eseguite secondo una procedura specifica (procedurale)
5) Coesione della comunicazione: significa che tutti gli elementi di elaborazione in un modulo sono concentrati in un'area di una determinata struttura dati
6) Coesione sequenziale: si riferisce a un modulo che completa più funzioni e queste funzioni devono essere eseguite in sequenza
7) Coesione funzionale: si riferisce al fatto che tutte le parti di un modulo lavorano insieme per completare una funzione specifica, sono strettamente correlate e sono indivisibili
L'accoppiamento è una misura della relativa indipendenza tra i moduli (quanto strettamente sono collegati tra loro)
In generale, esistono sette tipi di possibili metodi di accoppiamento tra i moduli.
1) Accoppiamento dei contenuti: se un modulo accede direttamente ai dati interni di un altro modulo; o un modulo non va all'altro modulo attraverso l'ingresso normale; o due moduli hanno parte del codice del programma si sovrappone o un modulo ha più ingressi, Quindi avviene l'accoppiamento del contenuto tra i due moduli
2) Accoppiamento pubblico: se un gruppo di moduli accede tutti allo stesso ambiente dati comune, l'accoppiamento tra loro è chiamato accoppiamento pubblico. L'ambiente dati pubblico può essere una struttura dati globale, un'area di comunicazione condivisa, un'area pubblica di copertura della memoria, ecc.
3) Accoppiamento esterno: quando i moduli sono collegati tramite un ambiente esterno al software (come l'accoppiamento I/O del modulo a un dispositivo, formato o protocollo di comunicazione specifico), si parla di accoppiamento esterno.
4) Accoppiamento di controllo: se i parametri trasmessi da un modulo a un altro modulo contengono informazioni di controllo e le informazioni di controllo vengono utilizzate per controllare la logica di esecuzione nel modulo ricevente, si parla di accoppiamento di controllo.
5) Accoppiamento di tag: parte di una struttura dati (come una sottostruttura di una determinata struttura di dati) viene passata tra due moduli attraverso una tabella di parametri, che è l'accoppiamento di tag.
6) Accoppiamento dati: solo i dati semplici vengono trasferiti tra due moduli tramite tabelle di parametri, processo chiamato accoppiamento dati.
7) Accoppiamento indiretto: Se non esiste una relazione diretta tra due moduli, cioè uno dei due non dipende dall'altro e può funzionare in modo indipendente, questo accoppiamento si chiama accoppiamento indiretto.
Quanto più strette sono le connessioni tra i moduli, tanto più numerose sono le connessioni, tanto maggiore è l'accoppiamento e tanto più debole la loro indipendenza funzionale.
Quanto più stretta è la connessione tra i vari elementi all'interno di un modulo, tanto maggiore è la sua coesione.
I moduli con forte indipendenza funzionale dovrebbero essere moduli con elevata coesione e basso accoppiamento.
Progettazione dell'architettura del software
L'architettura software si concentra su una o più strutture di un sistema, inclusi i componenti software, le proprietà visibili esternamente di questi componenti e le relazioni tra loro.
Bass propone tre ragioni chiave per cui l’architettura è importante:
① Facilitare la comunicazione tra le parti interessate
②Favorevole al processo decisionale precoce nella progettazione del sistema
③Astrazione trasmissibile a livello di sistema
processo di sviluppo dell’architettura
Architettura software comune
Struttura a ospite singolo k
Struttura C/S (Client/Server).
Struttura B/S (Browser/Server).
stile dell'architettura del software
La stragrande maggioranza può essere classificata come uno di un numero relativamente piccolo di stili architettonici
Ogni stile descrive una categoria di sistema, che include:
① Alcuni componenti che implementano le funzioni richieste dal sistema (come database, moduli di calcolo)
②Una serie di "connettori" utilizzati per collegare componenti per "comunicazione, coordinamento e cooperazione"
③ Definire i vincoli di sistema sul modo in cui i componenti sono integrati
④ Modello semantico che consente ai progettisti di comprendere le proprietà dell'intero sistema e analizzare proprietà note
architettura incentrata sui dati
Alcuni dati (come un file o un database) vengono archiviati al centro della struttura e vengono frequentemente utilizzati, aggiunti, eliminati o modificati da altri componenti
architettura dello stile del flusso di dati
Questa struttura è adatta affinché i dati di input vengano trasformati in dati di output da una serie di componenti di calcolo o elaborazione.
Architettura in stile chiamata e ritorno
Questo stile consente al progettista di software di progettare un'architettura molto facile da modificare ed estendere.
Contiene: architettura in stile programma principale/sottoprogramma e architettura in stile chiamata di procedura remota
Ci sono alcuni concetti da capire qui:
Profondità della struttura del programma: il numero di livelli della struttura del programma è chiamato profondità della struttura. La profondità della struttura riflette in una certa misura la dimensione e la complessità della struttura del programma.
La larghezza della struttura del programma: il numero massimo di moduli allo stesso livello nella gerarchia è chiamato larghezza della struttura
Fan-in e fan-out dei moduli: Il fan-out rappresenta il numero di altri moduli che un modulo chiama (o controlla) direttamente. Il fan-in è definito come il numero di moduli che chiamano (o controllano) un determinato modulo. Fan-out multipli significano che molti moduli subordinati devono essere controllati e coordinati. I moduli multi-fan-in sono generalmente moduli pubblici.
Architettura in stile orientato agli oggetti
Metodi utilizzati dai componenti del sistema per incapsulare e manipolare i dati
L'interazione e il coordinamento tra i componenti vengono trasmessi tramite messaggi
architettura di stile gerarchico
In questa struttura sono definiti diversi livelli e ciascun livello completa operazioni più vicine alle istruzioni macchina rispetto al livello esterno.
Valutare architetture alternative
Per lo stesso requisito software, verranno derivate diverse strutture software a causa dei diversi principi dei vari metodi di progettazione.
Strutture software diverse per lo stesso problema
ATAM (metodo di analisi del trade-off dell'architettura)
1) Definire scenari applicativi (scenari): esprimere il sistema dal punto di vista dell'utente attraverso diagrammi di casi d'uso
2) Derivare requisiti, vincoli e descrizione dell'ambiente: questo fa parte dell'ingegneria dei requisiti per garantire che tutte le preoccupazioni del cliente siano elencate
3) Descrivere lo stile architettonico in grado di gestire le situazioni e i requisiti di cui sopra
4) Valutare individualmente ciascuna prestazione del sistema. Le prestazioni per la progettazione dell'architettura includono: affidabilità, prestazioni, sicurezza, manutenibilità, flessibilità, testabilità, portabilità, riusabilità e interoperabilità, ecc.
5) Per diverse forme architettoniche, valutare la sensibilità di queste prestazioni menzionate al punto 4. Può essere valutato in questo modo: apportare alcune piccole modifiche all'intera architettura, analizzare e determinare se ci sono cambiamenti sensibili nella performance dell'appello. Quelle prestazioni che risentono fortemente delle modifiche architetturali sono chiamate punti sensibili.
6) Valutare le architetture proposte nello step 3 attraverso l'analisi di sensibilità nello step 5. Il metodo descritto da SEI è il seguente: Quando vengono determinati i punti sensibili di un'architettura, dobbiamo trovare i fattori che richiedono il maggior numero di punti di compromesso nel sistema (trade-off points). Il fattore di compromesso significa che la modifica di questo contenuto nell'architettura causerà cambiamenti sensibili nelle prestazioni del sistema. Ad esempio, le prestazioni di un sistema con una struttura client-server sono strettamente correlate al numero di server nel sistema (ad esempio, aumentando il numero di server miglioreranno le prestazioni del sistema in una certa misura)... In in questo caso, il numero di server è questo punto di equilibrio nell'architettura.
Quando si progetta l'architettura software, è possibile fare riferimento alle seguenti regole:
(1) Migliorare la struttura del software e migliorare l'indipendenza dei moduli
(2) Profondità, larghezza, uscita e apertura del modulo adeguate
(3) L’ambito di giudizio del modulo dovrebbe rientrare nel suo ambito di controllo
(4) Cercare di ridurre la complessità delle interfacce dei moduli
(5) Progettare un modulo con ingresso singolo e uscita singola
(6) La funzionalità del modulo dovrebbe essere prevedibile e la dimensione del modulo dovrebbe essere moderata
(7) In genere è meglio che un modulo contenga dalle 30 alle 50 istruzioni.
(8) Una struttura software ben progettata di solito ha un fan-out più elevato nello strato superiore, un fan-out minore nello strato intermedio e un fan-in elevato nello strato inferiore.
tecnologia di progettazione a livello di componente
Nell'analisi strutturata e nei metodi di progettazione i componenti sono spesso chiamati moduli
Nell'analisi e nella progettazione orientata agli oggetti, i componenti sono chiamati classi. Nei metodi di sviluppo basati sui componenti, i componenti sono chiamati componenti.
Nella fase di progettazione a livello di componente, vengono principalmente completati i seguenti lavori:
Determinare l'algoritmo utilizzato per ciascun componente, selezionare uno strumento appropriato per esprimere il processo dell'algoritmo e scrivere una descrizione procedurale dettagliata del componente
Determinare le strutture dati utilizzate internamente da ciascun componente
Al termine della progettazione a livello di componente, i risultati di cui sopra dovrebbero essere scritti nelle specifiche di progettazione a livello di componente e formati in un documento formale attraverso la revisione, che servirà come base per la fase successiva (fase di codifica).
Metodo di programmazione strutturata
Una definizione più popolare è: "Se i blocchi di codice di un programma sono collegati solo attraverso le tre strutture di controllo di base di sequenza, selezione e ciclo, e ogni blocco di codice ha solo un'entrata e un'uscita, allora si dice che il programma è strutturato . Di"
Con lo sviluppo di nuovi metodi e tecnologie di sviluppo software come l'orientamento agli oggetti e il riutilizzo del software, un approccio di sviluppo più realistico ed efficace può essere una combinazione organica di metodi top-down e bottom-up.
Rappresentazione grafica
Diagramma di flusso del programma
I diagrammi di flusso del programma sono indipendenti da qualsiasi linguaggio di programmazione, relativamente intuitivi, chiari e facili da apprendere e padroneggiare.
Per utilizzare i diagrammi di flusso per descrivere programmi strutturati, è necessario limitare i diagrammi di flusso a sole cinque strutture di controllo di base.
Diagramma NS
Nassi e Shneiderman hanno proposto uno strumento di descrizione grafica conforme ai principi della programmazione strutturata, chiamato diagramma a scatola, chiamato anche diagramma N-S.
Cinque strutture di controllo di base
PAD
PAD è l'abbreviazione di Problem Analysis Diagram, evoluzione del diagramma di flusso del programma.
Cinque strutture di controllo di base
Tabella delle decisioni
Quando l'algoritmo contiene più selezioni di condizioni nidificate, è difficile descriverlo chiaramente utilizzando diagrammi di flusso del programma, diagrammi N-S o PAD.
Tuttavia, le tabelle decisionali possono esprimere chiaramente la corrispondenza tra combinazioni complesse di condizioni e le azioni che dovrebbero essere intraprese.
Il vantaggio della tabella decisionale è che può descrivere tutte le regole di elaborazione in modo conciso e inequivocabile.
Tuttavia, la tabella decisionale rappresenta la logica statica, che è il possibile risultato in una determinata combinazione di valori di condizione. Non può esprimere la sequenza di elaborazione, né può esprimere la struttura del ciclo.
Linguaggio di progettazione PDL
PDL (Program Design Language) è un linguaggio utilizzato per descrivere la progettazione dell'algoritmo e i dettagli di elaborazione dei componenti funzionali, chiamato linguaggio di progettazione
È una specie di pseudocodice. In generale, le regole grammaticali dello pseudocodice si dividono in "grammatica esterna" e "grammatica interna".
La sintassi straniera dovrebbe essere conforme alle regole grammaticali delle istruzioni comunemente usate nei linguaggi di programmazione generali.
La grammatica interna può utilizzare alcune semplici frasi, frasi e simboli matematici comuni in inglese per descrivere le funzioni che un programma dovrebbe eseguire.
Esempi di utilizzo del PDL
Caratteristiche del PDL
1. Esiste una sintassi fissa delle parole chiave esterne che fornisce tutte le strutture di controllo strutturate, le descrizioni dei dati e le funzionalità dei componenti. Le parole chiave appartenenti alla grammatica straniera costituiscono un insieme limitato di vocaboli in grado di segmentare strutturalmente il testo PDL e renderlo di facile comprensione. Per distinguere le parole chiave, si stabilisce che le parole chiave debbano essere in maiuscolo e le altre parole in minuscolo.
2. La grammatica interna utilizza il linguaggio naturale per descrivere le caratteristiche della lavorazione. La sintassi interna è relativamente flessibile, purché sia scritta in modo chiaro, non è necessario preoccuparsi degli errori grammaticali, in modo che le persone possano concentrarsi sulla descrizione della logica dell'algoritmo.
3. Esistono meccanismi di descrizione dei dati, comprese strutture di dati semplici (come scalari e array) e complesse (come elenchi collegati e strutture gerarchiche).
4. Esiste una definizione di subroutine e un meccanismo di chiamata per esprimere le descrizioni dell'interfaccia in vari modi.
Specifiche di progettazione e revisioni del progetto
specifiche di progettazione
revisione del progetto
L’obiettivo finale della progettazione del software è ottenere la soluzione migliore
"Migliore" significa che tra tutte le soluzioni candidate, viene selezionata la soluzione che può raggiungere maggiore produttività, maggiore affidabilità e manutenibilità in base alle condizioni di risparmio sui costi di sviluppo, riduzione del consumo di risorse e riduzione dei tempi di sviluppo.
Contenuto della revisione del progetto
Tracciabilità: ovvero analizzare la struttura del sistema e la struttura del sottosistema del software per confermare se la progettazione del software copre tutti i requisiti software identificati e se ciascun componente del software può essere ricondotto a un determinato requisito.
Interfaccia: analizza la connessione tra le varie parti del software e conferma se l'interfaccia interna e l'interfaccia esterna del software sono state chiaramente definite. Se il componente soddisfa i requisiti di elevata coesione e basso accoppiamento. Se l'ambito del componente rientra nel suo intervallo di controllo.
Rischio: verificare se la progettazione del software può essere implementata in tempo nelle condizioni tecniche esistenti e nel rispetto del budget.
Praticità: verificare se la progettazione del software è pratica per la soluzione delle esigenze
Chiarezza tecnica: Confermare che la progettazione del software sia espressa in una forma che possa essere facilmente tradotta in codice
Manutenibilità: dal punto di vista della manutenzione del software, verificare se la progettazione del software considera la comodità della manutenzione futura.
Qualità: verificare se la progettazione del software presenta caratteristiche di buona qualità
Varie opzioni: vedi se hai considerato altre opzioni e quali sono i criteri per confrontare le varie opzioni?
Limitazioni: valutare se le limitazioni del software sono realistiche e coerenti con i requisiti
Altre domande specifiche: valutazione della documentazione, testabilità, processo di progettazione, ecc.
Esistono due tipi di revisione: revisione formale e revisione informale.
Oltre agli sviluppatori di software, la revisione formale invita a partecipare anche rappresentanti degli utenti ed esperti del settore, di solito sotto forma di difesa.
Le revisioni informali sono più o meno di natura peer-to-peer e non sono limitate al tempo o al formato.