Read Aloud the Text Content

This audio was created by Woord's Text to Speech service by content creators from all around the world.

Text Content or SSML code:

RUP - Processo unificato razionale RUP è un prodotto su un processo, sviluppato da Rational. Si tratta di un processo quadro, adattato e ampliato secondo alla necessità. È abbracciare le 6 migliori pratiche e usi gli strumenti per implementare esso. • Caso di utilizzo guidato: i casi di utilizzo catturano i requisiti funzionali e guidano tutte le fasi dei processi. Sono le basi per identificare le procedure di test. • Architettura- centric: l'architettura è non piatta così che deve essere letta da più vista: Uso cassa vista: contiene caso d'uso e guida tutta la definizione della architettura Vista logica: contiene i requisiti funzionali e l’astrazione del modello Vista implementazione: descrive l’organizzazione del modello software statico Vista processo: descrive l’aspetto concorrente del sistema Vista distribuzione: mostra come gli eseguibili sono distribuiti su piattaforme diverse Il processo ha due dimensioni: • Prima dimensione: dinamica la struttura del processo, che rappresentano il tempo e mostrare aspetti del processo riguardante la sua vita di ciclo • Seconda dimensione: statica la struttura del processo, che rappresentano il flusso di lavoro del processo che gruppo logicamente binded attività. Una cascata approccio nella dinamica struttura della il processo è accettabile se requisito non cambiano. Soluzione: iterare i processi a cascata. Le quattro fasi sono: • Ideazione: determinare gli obiettivi e i limiti del progetto, determinare i criteri di accettazione, il caso d'uso, presentare una prima bozza dell’architettura, stimare costi e tempi e valutare i rischi. Concentrarsi sui requisiti e sulla stima dei costi. • Elaborazione: definire una linea di base dell'architettura e una linea di base per il documento e una strategia di base per la fase di costruzione. Dimostrare che la linea di base dell'architettura supporta precedenti stime di tempi e costi. Concentrarsi sui requisiti e sullo sviluppo del prototipo per testare la soluzione proposta • Costruzione: incentrata sulla progettazione e sull'implementazione del prototipo. Il prototipo viene ampliato, arricchito e completo per completare un primo prodotto • Transizione: concentrarsi sulla realizzazione del progetto e sulla consegna finale. La struttura statica del processo descrive chi (ruoli) fa cosa (documenti), come (attività) e quando (flusso di lavoro). • Ruoli: comportamento e responsabilità di un individuo • Attività: è l’unità del lavoro • Documento: elemento di contenuto informativo Svantaggio: troppo complesso, può ottenere fuori controllo. Vantaggio: feedback regolare, uso efficiente delle risorse, migliore gestione del rischio Cascata Sequenziale, l'uscita di ogni fase è l'ingresso a quella successiva. Testing Il test è il processo di ricerca delle differenze tra il comportamento previsto specificato dai modelli di sistema e il comportamento osservato del sistema implementato. • Il test unitario rileva differenze tra una specifica di un oggetto e la sua realizzazione come componente. • Strutturale test trova le differenze tra il modello di progettazione del sistema e un sottoinsieme di integrati sottosistemi. • Il test funzionale rileva differenze tra il modello del caso d'uso e il sistema. • Il test delle prestazioni rileva differenze tra i requisiti non funzionali e le prestazioni effettive del sistema. Da un punto di vista modellistico, il testing è il tentativo di dimostrare che l’implementazione del sistema non è coerente con i modelli del sistema. Diverse tecniche per aumentare l'affidabilità del software sono: • Evitamento dei guasti • Rilevamento dei guasti • Tolleranza ai guasti Il test è considerato una tecnica di rilevamento dei guasti. Le attività di test sono: • La pianificazione dei test alloca le risorse e pianifica i test. • Il test di usabilità cerca di trovare errori nella progettazione dell'interfaccia utente del sistema. • Unità test cerca di trovare difetti nella partecipazione di oggetti e / o sottosistemi con rispetto all’impiego casi dal modello dei casi d'uso. • Il test di integrazione è l'attività di ricerca di guasti testando i singoli componenti in combinazione. • Il test strutturale è il culmine del test di integrazione che coinvolge tutti i componenti del sistema. • Test sistema test tutti i componenti insieme, visto come un unico sistema per identificare i guasti con rispetto agli scenari del problema economico e le esigenze e obiettivi di progettazione individuati nella analisi e progettazione del sistema, rispettivamente: funzionale test mette alla prova i requisiti della RAD e l'utente manuali. test delle prestazioni verifica i requisiti non funzionali e gli obiettivi di progettazione aggiuntivi dall'SDD (System Design Document). I test funzionali e delle prestazioni vengono eseguiti dagli sviluppatori. Test di accettazione e test di installazione verificano il sistema rispetto all'accordo di progetto e vengono eseguiti dal cliente, se necessario, con l'aiuto degli sviluppatori. Guasto anomalie nel codice sorgente, può o può non produrre il fallimento. Errore azione di sviluppo inappropriata, introdotta da un errore. Causa di una colpa. Errore o comportamento errato / imprevisto o output. Di solito sono classificati. Guasto ➔ Errore ➔ Guasto Un guasto si manifesta come un fallimento se tutto il 3 seguente condizione sono soddisfatte: 1. Esecuzione: viene eseguito il codice pezzo difettoso 2. Infezione: lo stato interno del programma è danneggiato 3. Propagazione: l’errore si propaga a programma di uscita • White box testing: chiamato anche strutturale. Utilizza il codice a scopo di test. Eseguendo il guasto elemento è una necessaria condizione per revealinga guasto. Se si considera il programma di un grafo, siamo in grado di attraversare il grafico con alcuni ingressi e verificare se certo la copertura è garantita. La copertura è espressa come $ C_ {stmt} = \ frac {(numero di istruzioni eseguite)} {numero di istruzioni} $ • Black box testing: utilizza le specifiche del sistema (descrizione del comportamento previsto del programma dato un input) a scopo di test senza considerare la sua implementazione. Verifica ogni categoria e i confini tra le categorie di input. Spesso gli errori tendono a verificarsi presso i confini del dominio di dati → pochi in ingresso vengono selezionati per testare per più categorie. Secondo la Legge di Pareto l’80% dei difetti proviene dal 20% dei moduli.