Wondershare EdrawMind
Galleria mappe mentale Analisi dei requisiti, test del software, ingegneria del software, progettazione del software, mappa mentale per lo studio autonomo
- 13
Analisi dei requisiti, test del software, ingegneria del software, progettazione del software, mappa mentale per lo studio autonomo
Analisi dei requisiti, test del software, ingegneria del software, mappa mentale per lo studio autonomo della progettazione del software, che organizza il contenuto dell'analisi dei requisiti, progettazione del software, test del software, manutenzione del software, riutilizzo del software e ambiente di sviluppo del software. Spero che questa mappa mentale sia utile a te.
Modificato alle 2023-02-23 22:55:01
Analisi dei requisiti, test del software, ingegneria del software, progettazione del software, mappa mentale per lo studio autonomo
- Consigliato per te
- Profilo
Mappa mentale dell'economia dell'ingegneria del software e dell'ingegneria del software
- 12
Analisi dei requisiti, test del software, ingegneria del software, progettazione del software, mappa mentale per lo studio autonomo
analisi della domanda
Classificazione dei requisiti
Requisiti funzionali (cosa fa il software, cosa deve realizzare il sistema e le qualità che ha), requisiti prestazionali (affidabilità, tolleranza agli errori, prestazioni, tempo di risposta), vincoli di progettazione (i vincoli specificano restrizioni, come specificare database, sistemi operativi, sviluppo utensili )
Esigenze aziendali (il direttore generale ha detto voglio sviluppare un... sistema per realizzare... affari), esigenze degli utenti (il direttore generale ha detto... servono funzioni e prestazioni), esigenze del sistema (sviluppo e utilizzo di)
Bisogni di base (requisiti chiaramente indicati dagli utenti), bisogni attesi (cose che gli utenti non hanno dichiarato esplicitamente ma che pensano dovrebbero essere ovvie), bisogni interessanti (superare le aspettative degli utenti, funzioni aggiuntive che gli utenti non si aspettano e che non devono essere eseguite)
Requisiti Ingegneria
Sviluppo dei requisiti (determinazione di funzioni, prestazioni, dati e interfacce, comprese quattro fasi di acquisizione dei requisiti, analisi, scrittura delle specifiche e verifica dei requisiti)
Gestione della domanda
Sviluppare un piano di gestione dei requisiti, definire le linee di base dei requisiti, ottenere comprensione e impegno nei confronti dei requisiti, gestire le modifiche ai requisiti, mantenere il monitoraggio bidirezionale dei requisiti e identificare le incoerenze tra il lavoro del progetto e i requisiti
Tracciamento bidirezionale dei requisiti: nel tracciamento in avanti, in quale caso d'uso viene realizzato il requisito originale, se tutti i requisiti originali sono realizzati, nel tracciamento inverso, se un caso d'uso non realizza alcun requisito originale, è un'esigenza interessante.
Acquisizione dei requisiti
informazioni da acquisire (cosa)
Informazioni relative al dominio del problema, informazioni relative al problema da risolvere, aspettative e vincoli dell'utente
Fonte delle informazioni (dove)
Stakeholder, sistemi legacy, concorrenti, esperti di dominio
Requisiti tecniche di acquisizione (come)
Riunioni sui requisiti di discussione congiunta (discussione multipartitica), interviste agli utenti (gli utenti chiave preparano le domande), sondaggi scritti (quando sono presenti molte persone), osservazioni sul posto, lettura di documenti storici e partecipazione a pratiche commerciali
Strumenti grafici: diagramma a blocchi gerarchico, diagramma dei casi d'uso, diagramma IPO, diagramma di Warnier
Strategie di acquisizione dei requisiti
Lo sviluppo dei requisiti è un processo evolutivo iterativo e non a cascata che scompone il problema dall'alto verso il basso, strato dopo strato, e fornisce una visione logica e una visione fisica del sistema.
analisi della domanda
Compito
Disegnare un diagramma di ambito della relazione tra il sistema e le entità esterne, creare un prototipo di interfaccia utente, analizzare la fattibilità dei requisiti, determinare la priorità dei requisiti, stabilire un modello di analisi dei requisiti (modello dei casi d'uso, diagramma ER, diagramma del flusso di dati) , creare un dizionario dati e utilizzare le funzioni di qualità allocate
metodo
metodi di analisi strutturati
Un metodo di modellazione che si basa sulla scomposizione passo-passo dall'alto verso il basso dei diagrammi di flusso dei dati per esprimere graficamente il processo di trasformazione e trasferimento delle informazioni nel sistema.
analisi dei processi aziendali
Indagare e cogliere la situazione di base, descrivere, confermare e analizzare i processi aziendali esistenti, scoprire problemi, proporre soluzioni e proporre processi aziendali ottimizzati
Disegna il diagramma del flusso di dati DFD
Il diagramma di livello superiore chiarisce con quali entità esterne il sistema ha una relazione e quali dati devono essere trasmessi. Il diagramma di livello superiore è scomposto strato per strato dall'alto verso il basso e dettaglia i componenti.
Incluso flusso di dati (dati con nome e direzione del flusso), elaborazione (trasformazione del flusso di dati), archiviazione di dati (informazioni archiviate accessibili), entità esterne (origine dati e destinazione dati)
Dizionario dei dati
Fornire definizioni logiche a tutti gli elementi di dati che compaiono nel diagramma di flusso dei dati
Incluso linguaggio strutturato, albero decisionale, tabella decisionale
Metodo di analisi orientato agli oggetti
Metodo di analisi del dominio del problema dell'area
Scrivere le specifiche dei requisiti software
Metodi (utilizzare una buona struttura e un linguaggio naturale per scrivere documenti di testo, costruire modelli grafici e scrivere specifiche formali)
Requisiti (completezza, coerenza, modificabilità, tracciabilità)
Verifica dei requisiti
Revisione della richiesta: la partecipazione del cliente alla conferma della firma è uno dei criteri di accettazione. Verificare se la richiesta viene eseguita secondo il processo e se il risultato della richiesta è obiettivo, giusto e ragionevole.
Test dei requisiti
progettazione del software
Il principio fondamentale
Occultamento delle informazioni (i dati e i metodi tra i moduli non possono essere utilizzati da moduli non correlati), astrazione, top-down, perfezionamento strato per strato, indipendenza del modulo (alta coesione e basso accoppiamento)
fare un passo
Progetto di architettura
Vista logica (soddisfazione dei requisiti funzionali), vista del processo (problemi di concorrenza), vista dei componenti (problemi di implementazione), vista della distribuzione (problemi di distribuzione)
Progettazione del contorno
Convertire i requisiti software in strutture di dati e strutture di sistemi software, completando principalmente la progettazione complessiva, inclusa la divisione delle funzioni in moduli, la determinazione delle funzioni dei moduli e le relazioni di chiamata e composizione tra i moduli
design dettagliato
Top-down, perfezionamento graduale, occultamento delle informazioni (interfaccia operativa), moduli indipendenti (alta coesione, basso accoppiamento)
Progettare la struttura dei dati e l'algoritmo per ciascun modulo, prestazioni, tempi di consegna, tempi di risposta, produttività, precisione, ecc.
Scrivere documenti di progettazione
revisione del progetto
metodo di progettazione
Moduli nel diagramma della struttura del sistema
Modulo in entrata, modulo in uscita, modulo di trasformazione, modulo di coordinamento
Diagramma della struttura del sistema comune
Trasformazione, Transazione, Misto
interfaccia utente
Usabilità, flessibilità, complessità, affidabilità
revisione del progetto
Responsabile della progettazione, personale dirigente, revisori principali, team di revisione
prova del software
Principi di prova
Testare il prima possibile e in modo continuo. I programmatori dovrebbero evitare di testare i programmi che hanno progettato. Dovrebbero scegliere dati validi e ragionevoli così come dati non validi e irragionevoli. Dopo la modifica, eseguire test di regressione uguale al numero di errori rilevati dal programma proporzionale all'errore
Progettare casi di test inclusi input, condizioni di esecuzione e output previsto
Metodi di prova
test della scatola nera
Progetta casi di test in base alle specifiche funzionali e verifica se le funzioni soddisfano i requisiti, indipendentemente dalla struttura e dall'elaborazione del programma.
Divisione delle classi di equivalenza
Dividere le classi di equivalenza. Testare i valori rappresentativi della classe di equivalenza equivale a testare altri valori di questo tipo. Ogni classe di equivalenza viene testata in due casi: valido e non valido.
analisi dei valori limite
Progettare casi di test sui confini di input e output. I valori limite sono i più soggetti a errori (assumere un valore che sia esattamente uguale, appena maggiore o appena inferiore al confine).
errore di ipotesi
Possibili errori nella speculazione basati sull'esperienza e sull'intuizione
diagramma di causa ed effetto
Analizzare le specifiche dei requisiti per scoprire vari input e output (cause e risultati), scoprire la corrispondenza tra varie combinazioni di condizioni di input e output e disegnare un diagramma causa-effetto una tabella decisionale. Ogni colonna della tabella decisionale è un caso di test.
test della scatola bianca
Testare il contenuto
Progettare casi di test per la logica interna del programma per verificare se i percorsi logici funzionano secondo i requisiti predeterminati, che è più completo e dettagliato rispetto ai test della scatola nera
Testare tutti i percorsi del modulo di programma almeno una volta, testare tutti i giudizi logici, vero e falso, almeno una volta, testare i confini del ciclo e i limiti di funzionamento e testare la validità delle strutture dati interne
Metodi di prova
Copertura della dichiarazione, copertura della decisione, copertura della condizione, copertura della condizione della decisione, copertura della combinazione di condizioni, copertura del percorso
Test della scatola grigia
Combina i test della scatola nera e della scatola bianca
fase di test
prova unitaria
Condotti durante la fase di codifica, test generali white-box, come test del funzionamento dell'interfaccia del modulo, test della struttura dei dati locali, test del percorso, test della gestione degli errori e test delle condizioni al contorno
Test d'integrazione
Vengono scoperti gli errori in fase di progettazione Dopo che i moduli sono stati assemblati, vengono testate l'interfaccia e la comunicazione tra i moduli, solitamente un test della scatola nera.
Prova di conferma
Controllare se le funzioni e le prestazioni del software sono coerenti con le esigenze dell'utente, in base alle specifiche della domanda, ai test di validità, alla revisione della configurazione del software e ai test di accettazione (rapporto di analisi, manuale utente, rapporto di riepilogo dello sviluppo) in un ambiente simulato
Prova del sistema
Test dell'ambiente di produzione, test della scatola nera basati sulle specifiche dei requisiti, che coprono tutti i componenti comuni e valutano la qualità dei prodotti software
Compresi software, hardware, periferiche, dati, software di supporto, ecc., in particolare test di ripristino, test di sicurezza, test di resistenza, test di prestazioni, test di affidabilità e test di installazione
test
Per il software di tipo prodotto, lo sviluppatore @ è presente e il cliente implementa il test, mentre lo sviluppatore b non è presente.
Tipo di prova
test di funzionalita
Test delle prestazioni
Scopo (valutare le capacità del sistema, identificare i punti deboli, mettere a punto il sistema, verificare stabilità e affidabilità), tipo (test di carico, test di resistenza, test di capacità)
Test d'ingresso
Analisi dei requisiti software, preparazione del piano di test di accettazione e dei criteri di accettazione del progetto, progettazione del test e progettazione del caso di test, costruzione dell'ambiente di test, implementazione del test, analisi dei risultati, rapporto di test
test di terze parti
Intermediario: Centro di valutazione software di Pechino
Test di regressione (verificare che i difetti verificatisi in precedenza ma che sono stati riparati non si ripresentino), test di ripristino, test di affidabilità, test di avvio/arresto, test di configurazione, test di sicurezza, test di usabilità, test di installazione, test di processo, test di compatibilità sessuale
Test orientato agli oggetti
Test di analisi orientato agli oggetti, test di progettazione orientato agli oggetti, test di programmazione orientato agli oggetti (test unitario orientato agli oggetti, test di integrazione orientato agli oggetti, test di sistema orientato agli oggetti)
strumenti di prova
Non richiede validazione periodica, calibrazione, verifica o gestione della configurazione per mantenere l'idoneità.
gestione delle prove
È difficile gestire il team di test perché gli indicatori di prestazione dei tester non sono facili da contare. C'è un grande divario nel numero di bug nei programmi scritti da esperti e principianti. Come determinare la capacità dei tester di trovare i bug?
Gestione del tracciamento degli errori (difetti).
Manutenzione del software
La manutenzione del software è parte integrante del ciclo di vita. Fornisce tutte le attività che richiedono il supporto del software. Il software è comprensibile, testabile, modificabile e manutenibile.
Manutenibilità del software
L'ingegneria del software migliora la manutenibilità
Analisi dei requisiti: vengono spiegati i possibili miglioramenti e modifiche
Fase di progettazione: soluzione facile da espandere, portatile, riutilizzabile, orientata agli oggetti
Fase di codifica: annotazione, qualità, orientamento agli oggetti
Fase di test: se il test è buono, allora sono disponibili tutti i documenti relativi al test;
Fase di manutenzione: buona gestione della configurazione e documenti sincronizzati
Documentazione del sistema (requisiti di manutenzione, codice sorgente, documenti di progettazione, documenti di test)
Documentazione per l'utente (Manuale dell'utente, Documentazione di installazione, Manuale di riferimento, Guida dell'amministratore)
metriche di manutenibilità
Numero di loop (complessità del codice sorgente), dimensione del software, altri fattori
Classificazione della manutenzione del software
Correzione (il processo di diagnosi e correzione degli errori)
Tipo adattivo (il processo di adattamento ai cambiamenti nel nuovo software e hardware dell'ambiente esterno, nel database dell'ambiente dati, nel formato dei dati e nei supporti di memorizzazione per modificare il software, come l'aggiornamento del sistema operativo e la modifica del software)
Di tipo preventivo (il processo di modifica del software per migliorare la manutenibilità e l'affidabilità del software e gettare le basi per futuri miglioramenti al software. Non è un errore ora ma lo diventerà nel tempo, come il problema del Millennium Bug risolto nel 1999)
Tipo di perfezione (il processo di modifica del software o di riqualificazione del software per soddisfare nuove funzioni e prestazioni)
Implementazione della manutenzione del software
Stabilire l'organizzazione della manutenzione, proporre i requisiti di manutenzione, implementare le operazioni di manutenzione, registrare gli elementi di manutenzione e valutare le attività di manutenzione
La manutenzione pre-consegna include piani operativi e piani di manutenzione post-consegna, mentre la manutenzione post-consegna include modifiche al software, formazione, materiali di supporto, ecc.
Riutilizzo del software
L'utilizzo di varie conoscenze rilevanti del software esistente per costruire nuovo software per ridurre i costi di sviluppo e manutenzione del software è una tecnologia importante per migliorare la produttività e la qualità del software.
Riutilizzo del codice, riutilizzo della progettazione, riutilizzo dell'analisi, riutilizzo dei test case
Un componente è un corpo di programma con determinate funzioni che può funzionare in modo indipendente o essere assemblato e coordinato con altri componenti. Per essere pratici e riutilizzabili in modo più efficace, i componenti dovrebbero avere variabilità e flessibilità per migliorare la versatilità.
ambiente di sviluppo software
Una raccolta di strumenti software correlati, ambiente di sviluppo integrato (integrazione dei dati, integrazione del controllo, integrazione dell'interfaccia)