In questa classe cercheremo l'integrazione e la qualificazione dei sistemi di ingegneria. Come ho accennato nelle precedenti lezioni questa è una delle fasifinali nella progettazione di sistemi di ingegneria dove cerchiamo di integrare diversi componenti, diversi sottosistemi che abbiamo già progettato e quindi qualificare il sistemaper assicurarsi che soddisfi i requisiti del sistema o che soddisfi le esigenze dellestakeholder. I due punti importanti qui sono l'integrazione e la qualificazione, sostanzialmente l'integrazione è l'assemblaggio di componenti e sottosistemi per renderetutto il sistema e la qualificazione è in sostanza la validazione e la verifica del sistemaper garantire che soddisfi i requisiti di progettazione.Così, passeremo attraverso questi due passi sostanzialmente l'integrazione e la qualificazione epoi vedere quali sono i passi importanti in possesso di un'integrazione e qualificazione, così comequali sono le procedure da seguire per assicurarsi che il sistema sia integratoe il le prestazioni sono assicurate attraverso fasi di validazione e verifica.(Fare Slide Time: 01.28)
Così, andiamo alle fasi di progettazione che abbiamo già discusso che ci sono 6 funzioni del processo di progettazionee questo è l'ultimo che è il sistema di qualificazione definito peril sistema fondamentalmente guardiamo l'integrazione e la qualificazione.Così, stiamo attraversando queste fasi che è il problema di progettazione del livello di sistema, sistemaarchitettura funzionale, architettura fisica, architettura operativa e interfacciaarchitettura. Così, completiamo tutte queste fasi e l'ultima la sesta funzione èfondamentalmente il sistema di qualificazione in cui guardiamo l'integrazione e la qualificazioneaspetti del sistema ingegneristica.(Fare Slide Time: 02.03)
Se si guarda al diagramma di sistema v che abbiamo discusso in una delle classi quandoha discusso il processo di progettazione del sistema è possibile vedere che il design del sistema può essere effettivamenteessere classificato in una fase di decomposizione oltre ad una fase di integrazione. Quindi, la fase di decomposizione diè in sostanza cerchiamo di decomporre il problema in piccoli modulie poi di provare a sviluppare questi moduli e poi iniziamo il processo di integrazione.Quindi, qui il colpo di demone del v sarà decomponendo il problema fondamentalmente noianalizzeremo gli item di configurazione e poi li faremo progettare a specifiche e poipiani di verifica. E questa è la parte del lavoro degli ingegneri di sistema e poi questa è la fase di progettazionedove gli specialisti del design o la progettazione meccanica o elettronica qualunquela specializzazione necessitava di fare il palco del design qui e poi una volta che gli elementisaranno costruiti e andremo per la fase di integrazione e qualificazione.
.Quindi, questa è la fase in cui ci stiamo ora cercando di integrare gli articoli che cosa sono il designe poi si farà il processo di verifica e validazione che conosci aqualificare il sistema per rendere i requisiti del cliente.(Fare Slide Time: 03.15)
Così, l'integrazione sostanzialmente può essere un definito come il processo di assemblaggio del sistemadai suoi componenti che deve essere assemblato da lì Cè. Quindi, è un processo diassemblare i componenti o gli elementi di configurazione e renderli sub assemblatie quindi fare assemblaggio e infine, ottenere tutto il sistema pronto. Quindi, questo è il processo di integrazione.
(Riferimento Slide Time: 03.38)
Qualifica d'altra parte è sostanzialmente garantire che il sistema soddisfi effettivamente i requisiti del cliente. Ecco, qui è il processo di verifica e convalida del sistemadel sistema e poi l'ottenimento degli stakeholder che accettano il design. Così, qui questo è unodelle tappe cruciali perché questi sono questi stage otteniamo l'accettazione dalla partecipazionetitolare.Così, una volta che il titolare della partecipazione dice che è accettabile per loro allora solo noi possiamo effettivamenteassicurare o possiamo dire effettivamente che il design del sistema è completo. Così, in questa fase proviamoa guardare al cliente quali sono i requisiti che il cliente ha specificato e sestiamo effettivamente soddisfacendo questi requisiti. Quindi, passeremo attraverso la fase di validazione everifica e poi assicureremo che siano i requisiti di sistema ad essere soddisfatti i requisiti distakeholder sono soddisfatti dal sistema e i clienti e gli stakeholderaccettano il sistema. Quindi, che l'accettazione è la fase finale di un design di sistema. Quindi, la qualificaè la fase in cui garantiamo che il cliente sia felice con il prodotto oil sistema e accetta qualunque sia le funzioni che forniamo e che sia sufficiente asoddisfare il requisito del cliente.Così, potete vedere che ci sono due stadi uno è la verifica in realtà possiamo vedere laverifica e validazione del sistema. Quindi, dobbiamo verificare e validare il sistema.Quindi, qual è la differenza tra questa verifica e la validazione? Sostanzialmente un sistema di qualificazionedeve essere progettato contemporaneamente. Quindi, prima di andare alla differenza
tra la validazione della verifica solo io darò alcuni punti importanti come il sistema di qualificazionedeve essere progettato contemporaneamente con i sistemi operativi. Così,quando stiamo definendo il sistema di qualificazione che è ancora prima di arrivare sul palco diqualificare il sistema dobbiamo avere il sistema di qualificazione progettato.Quindi, dobbiamo assicurarci di avere una procedura particolare per assicurarsi che i requisiti di sistemasiano soddisfatti e la qualifica come facciamo realmente il processo di validazione, quali sono i documenti necessari, tutti quelli che sembrano decidere in questa faselo sviluppo del sistema di qualificazione. E questo deve essere fatto insieme allo sviluppo del sistema operativoperché nel sistema operativo sappiamo come funzionerà il sistema. Così, quando sviluppiamo il sistema operativo garantiamo chesviluppiamo un sistema di qualificazione anche che in realtà dettagli la procedura daseguito nel garantire la qualità del sistema o in verifica e validazione del sistema.Il criterio di uscita per l'integrazione e la qualificazione è l'accettazione del progetto da parte distakeholder. Quindi, questo è il criterio di uscita. Una volta accettato il sistema allora la procedura di qualificazione dell'integrazioneè finita, fino a quando il titolare della partecipazione accetta il prodotto o il sistema. Quindi, non saremo in grado di uscire dal processo di progettazione. Quindi, ora, al criterio di uscitaecco l'accettazione del sistema da parte degli stakeholder.(Fare Slide Time: 06.23)
Come ho accennato che la verifica e la validazione e l'accettazione sono le tre procedurenel processo di qualificazione. Così, come potete vedere qui la verifica è la determinazioneche il sistema ci farà bene. Quindi, qui garantiamo che il sistema ci faccia a destrala verifica è sostanzialmente garantire che il sistema costruito sia giusto o il sistema quello che siamoedificio è quello giusto quello che in realtà abbiamo voluto decidere e la validazione determinache è stato costruito il sistema giusto. Quindi, cioè la differenza tra verifica evalidazione, la validazione determina che il sistema giusto è stato costruito. Quindi, abbiamo alcuni requisitida parte del cliente e i clienti hanno specificato che il sistema deve soddisfarequesti requisiti e progettiamo un sistema.Quindi, per prima cosa c'è praticamente bisogno di garantire che qualunque sia il sistema che siamoprogettare sia effettivamente soddisfare il requisito o il design è il sistema giusto èprogettato per quel determinato lavoro. Quindi, questa è la convalida. In convalida garantiamo chequalunque cosa stiamo costruendo possa effettivamente soddisfare i requisiti del cliente e la fase di verificagarantiamo che qualunque cosa abbiamo voluto progettare lo stesso design è statocostruito per il sistema. Questo è il fatto che il sistema costruito a noi proprio in verifica garantiamoche il sistema costruito a noi a destra e validazione garantiamo che il sistema giusto sia stato costruitoper la particolare applicazione. Quindi, questa è la differenza di base tra verifica evalidazione.Come potete vedere qui in validazione ci sono diversi tipi di validità che è una è la validità dell'operazione, altra è la validità concettuale e la terza è la validitàe la validità progettuale. Quindi, al fine di garantire che il processo di validazione siacompleto dobbiamo garantire che tutte queste validità che siano validità operativa,validità concettuale, validità requisiti e validità del design siano soddisfatte. Questi sonofondamentalmente utilizzati per garantire che il sistema giusto sia stato costruito per soddisfare i requisiti del cliente. Come potete vedere qui in questo V diagramma dobbiamo avere diverse convalidenonché le procedure di verifica. Vi mostrerò una foto migliore qui potete vederei diversi tipi di validita '. Quindi, questo è il requisito degli stakeholder e questo è il diagramma dicomplessivo per questo è il design di sistema. Quindi, se guardate potete vedere i diversiprocessi coinvolti nella progettazione del sistema. Ecco, queste sono le attività di ingegneria del sistemae qui è l'attività di progettazione ingegneristica.Ora, qui se si guarda alle valige la prima è la validità concettuale. Quindi, la validitàè sostanzialmente quella di garantire che il sistema giusto sia stato costruito abbiamo alcune esigenze del titolare
già identificato in questa fase iniziale e poi basato su questi stakeholder ha bisogno di noisviluppare un concetto operativo. Quindi, la validità concettuale è fondamentalmente quella di assicurare che ogarantire che il concetto operativo qualunque cosa sviluppiamo realmente ha bisogno delleesigenze interessate. Quindi, sostanzialmente si tratta di uno ad una corrispondenza o considerandose effettivamente corrisponde alle esigenze degli stakeholder e la validità concettuale guardiamo alil concetto operativo e le esigenze degli stakeholder e garantiscono che questo particolare concetto di operazionepossa soddisfare le esigenze degli stakeholder che sia la validità concettuale. Noidobbiamo garantire questa validità concettuale prima di partire per qualsiasi altro processo. Quindi, la validità concettualeè importante perché se si fa errore nella validità concettualepotremmo rendere un sistema e anche il processo di verifica che soddisfa non sarebbeessere in grado di soddisfare le esigenze degli stakeholder perché il sistema costruito non era corretto.Così, la validità concettuale garantisce che il concetto operativo quello che abbiamo scelto per gli stakeholderdeve soddisfare le esigenze degli stakeholder è quello giusto e il suo è valido perquel particolare bisogno del cliente. Questa è la validità concettuale. Poi abbiamo i requisiti operativi. Quindi, abbiamo molti requisiti dal concetto operativoe da altre fonti è stato discusso nelle fasi iniziali i documenti di richiesta originari disaranno sviluppati. Questo requisito originario ei requisiti individuati in requisiti originari e il concetto operativo e sescopriamo che c'è una corrispondenza tra questi due allora è la validità dei requisiti.Requisiti di validità garantiscono sostanzialmente che i requisiti originari sianosufficienti e il concetto operativo per questo concetto operativo abbiamo identificato tutto il requisito di origine. Gli altri requisiti sono stati identificati o dobbiamoaggiungere pochi requisiti in più o ci sono requisiti che non sono necessari. Quindi, queltipo di analisi è in realtà la validazione dei requisiti. In questa richiesta di convalidaanalizziamo tutti i requisiti individuati per questo concetto operativo oltre che per soddisfarele esigenze del cliente e se soddisfano allora stiamo ottenendo i requisitivalidità.Poi abbiamo basato su questo requisito originato poi i requisiti di sistema iniziamosviluppando l'architettura funzionale poi l'architettura fisica e poi la specificaper i componenti per o il sistema. Così, questo in realtà garantisce la validità del design. Quindi, se il componente qualunque sia necessario progettare o il sottosistema qualunque noiprogettiamo se questo può soddisfare i requisiti originari e questo è la validità progettativa e.
Così, nella validazione del design si guardano i componenti e la specifica e poi si garantisceche questi possono soddisfare i requisiti già identificati. Quindi, cioèla validazione del design. Così, in questa fase, abbiamo questa tre validazione sostanzialmente la validità concettuale, la validità dei requisiti e la validità progettuale e l'ultima cosa quella chedobbiamo garantire è la validità operativa.Così, la validità operativa può essere assicurata solo quando abbiamo il sistema completosviluppato. Una volta che hai integrato tutti questi elementi per poi ottenere il sistema completoallora guardiamo al sistema e al suo funzionamento e vediamo se il concetto operativoqualunque cosa abbiamo proposto per questo cliente dove questo è corrispondente al sistemaquello che abbiamo sviluppato. Questo è un convalidato, possiamo garantire che il concetto operativoqualunque cosa abbiamo voluto sviluppare sia effettivamente sviluppato nel sistema originale e chegarantisca la validità operativa del sistema. Così, questi quattro processi di validazione la validazione concettuale, la validazione dei requisiti, la validazione del design e la validazione operativaassicura il processo di validazione del sistema.Quindi, questo è il primo in qualifica, quindi il requisito di base o l'idea di base dellavalidazione è garantire che costruiamo il sistema giusto e che il sistema possa effettivamente soddisfarei requisiti del cliente e questo è assicurato attraverso i quattro processi divalidazione concettuale, validazione dei requisiti, validazione del design e validazioneoperativa.E l'altro uno è la verifica. Quindi, abbiamo la validazione e la verifica.Verification è sostanzialmente garantire che qualunque sia il sistema che abbiamo progettato e qualunque cosa noisviluppiamo siano effettivamente corrispondenti tra loro o il requisito o il designrequisiti o il design qualunque cosa abbiamo proposto qui è effettivamente realizzato nel designeffettivo.Così, cioè la verifica del sistema. Così, mentre sviluppiamo il sistema verifichiamo che il sistemagli elementi che abbiamo sviluppato o il sottosistema che abbiamo sviluppato incontrino effettivamente i requisitidel sistema già progettato. Quindi, questa è la verifica. Quindi, assicurateviche il sistema ci porterà a destra per questo, qualunque cosa abbiamo individuato e qualunque cosa noiconsegnate siano effettivamente corrispondenti. Ecco, questa è la verifica dello sviluppo. Quindi, una voltaabbiamo questa validazione e verifica questo in realtà garantisce che qualunque cosa abbiamo voluto
si sviluppa che si ottiene in termini di validazione così come la verifica e poi l'ultimaè sostanzialmente l'accettabilità del sistema.Quindi, l'accettabilità è sostanzialmente il processo con cui il cliente o l'stakeholder accettanoil sistema ciò che abbiamo progettato. Quindi, una volta che avrete queste validazioni e la verificaassicura che il tutto ciò che volevamo sviluppare come ingegneri progettisti abbiamosviluppato in base al concetto operativo e poi ad altri requisiti e il sistemaviene consegnato in forma hardware o software. E poi facciamo test di accettabilità con il clienteo con gli stakeholder e una volta che i requisiti degli stakeholder sono soddisfatti eaccetteranno il sistema e che effettivamente completano il ciclo di v cycle o iniziamocon le esigenze degli stakeholder e con soddisfazione ha bisogno attraverso un processo di progettazioneV dove passiamo attraverso il processo di progettazione e poi passiamo attraverso le fasi di integrazione e qualificazionee infine, consegniamo il sistema come per i clientirequisito. Quindi, questo è il processo di verifica della convalida e accettazione del sistema.(Fare Slide Time: 14.55)
Qui potete vedere in questa accettazione la convalida e la verifica ci sono due catenecome potete vedere c'è una catena di alto livello e una catena di basso livello. Nella catena di alto livelloguardiamo alla validità dell'operazione di validità concettuale e alla prova di accettazione. Quindi, ildi alto livello questo al livello superiore avrà la validità concettuale che in realtàgarantisce che il concetto operativo possa soddisfare le esigenze degli stakeholder e l'operatività
validità il funzionamento del sistema è come per il concetto operativo quello che abbiamo propostoe il collaudo di accettazione è sostanzialmente il cliente accetta il sistema in cosa siamo progettiamo.Così, questa è la catena di alto livello che in realtà come parte del processo di qualificazione.E nel livello più basso una catena abbiamo la validità del requisito, la validitàvalidità, poi abbiamo la validità di verifica e funzionamento come parte dell'operazionevalidità che sta arrivando anche sotto la catena di basso livello in cui guardiamo i componenti o i sottosistemie che la loro validità operativa. Ecco perché abbiamo una sovrapposizione della validità operativanella catena di alto livello e nella catena di livello inferiore.La catena di livello inferiore potremmo sviluppare alcuni componenti o sottosistemi e poista verificando se effettivamente questo soddisfa il requisito che è la validità operativa ale fasi iniziali. E poi le fasi finali, una volta che si ha l'assemblaggio di tutto il sistemail sistema completo è sviluppato poi abbiamo la validità operativa alla catenadi alto livello. Quindi, questa è la catena di alto livello e la catena di livello di qualificazione di livello inferioreche assicura che il sistema legato sia stato costruito e il sistema costruito fosse giusto. Quindi, questoè il processo di qualificazione di un sistema di ingegneria. Penso che questo sia lo stesso un diagrammache studiano più chiarezza.(Fare Slide Time: 16.36)
Quindi, passiamo attraverso i dettagli della verifica e quali sono le tappe importanti per essereimpiegati per la verifica come abbiamo visto che la validazione ci sono diversi tipi divalidazione. In verifica anche noi dobbiamo percorrere pochi passi per assicurarcelo
soddisfa il requisito di sistema. Quindi, sostanzialmente la verifica è la corrispondenza della configurazioneitem, componenti o sottosistemi e il sistema ai loro corrispondenti requisiti aassicurarsi che ogni sistema sia stato costruito a destra.Quindi, in fase di verifica analizziamo gli elementi di configurazione o il livello più piccolo dei componentie poi i sottosistemi dei componenti e il sistema ai relativirequisiti per garantire che ogni sistema sia stato costruito a destra. Quindi, questa è la fase di verifica. Garantiamo che ogni sistema sia stato costruito a destra per soddisfare i requisiti del clienteo i requisiti di progettazione. E per la verifica per avere successo i requisiti originari e derivatidevono essere testati che sono i requisiti devono essere singole istruzioni che sianoinequivocabili, comprensibili e verificabili.Quindi, si tratta di una dichiarazione importante per quando iniziamo per la verifica o il processo di qualificazione del sistemadobbiamo garantire di avere tutti i requisiti specificati inmaniera univoca. Così, quando abbiamo discusso dei requisiti originarisviluppo abbiamo dichiarato che ci sono alcune cose specifiche da curare mentre noisviluppiamo i requisiti, uno dei punti importanti è che il requisito debba esseremolto chiaro e inequivocabile che sia dovremmo indicare chiaramente qual è effettivamente il requisitoda ogni singolo componente o luogo e poi solo possiamo verificare se èsoddisfa il requisito o meno.Quando iniziamo lo sviluppo del sistema che è l'importanza dell'analisi dei requisitie la documentazione dei requisiti perché che verrà utilizzato come comunicato per la verificadel sistema che è il motivo per cui dobbiamo scriverlo chiaramente senza ambiguitàperché chi sta facendo il processo di verifica potrebbe non essere la stessa persona cheha effettivamente scritto i requisiti. Quindi, non va interpretata in modo diverso che siaperché tutta la documentazione dei requisiti soprattutto il requisito da diversicomponenti e sistemi i requisiti interpretati tutte quelle cose dovrebbero essere chiaramenteenunciati e i requisiti di verifica devono essere chiaramente indicati, in modo che questo possaeffettivamente ogni componente possa essere verificato contro quei requisitiindividuati. Ecco, questa è l'importanza di mettere in scena i requisiti in modo chiaro.Così, per avere successo tutto dovrebbe essere solo dichiarazioni che siano inequivocabilmentecomprensibili e verificabili. Quindi, questo gioca un ruolo importante nella verifica. Quindi, identificando
i requisiti e poi la scrittura dei requisiti sono molto importanti quandoarriva alla verifica dei requisiti o alla verifica del sistema.(Fare Slide Time: 19.25)
Così, potete vedere qui il diagramma IDEF0 per l'integrazione delle qualifiche. Quindi, è possibile vederequeste sono alcune delle funzioni nelle funzioni di primo livello nella qualifica di sistema.(Fare Slide Time: 19.31)
Quindi, il design di sistema che questa è eseguire le attività di integrazione delle qualifiche è una delle funzioni secondarienel processo di progettazione.
(Riferimento Slide Time: 19.39)
E questo può essere effettivamente diviso nelle sue funzioni secondarie come contattare la validazione anticipata. Quindi, laearly validation è sostanzialmente e prima di iniziare effettivamente il design del sistema andiamoper la validazione anticipata come la validità dell'operazione per garantire che il concetto operativoqualunque cosa abbiamo sviluppato soddisfi effettivamente i requisiti e poi andiamo per l'integrazione e la verifica. Così, una volta che avremo gli altri componenti dei sottosistemiprogettati allora avremo la fase di integrazione e l'integrazione e la verificaverrà effettuata e poi faremo la convalida. La validazione finale doveanalizziamo la validità operativa e la validità della pressione dei componenti così come la validazioneper la validazione della concezione e la validazione del requisito sarà effettuata epoi andremo al test di accettazione. Ecco, queste sono le varie fasi coinvolte inintegrazione e qualificazione di quel sistema.Così, questa validazione chiaramente garantisce che il sistema o il concetto operativoqualunque sia sviluppato è sufficiente per rendere i requisiti del cliente e poi daquesta fase andremo per il design. Possiamo avviare la loro progettazione il sistema in termini dile sue funzioni architettura fisica di architettura e l'architettura di funzionamentoe sviluppiamo le specifiche di item di configurazione e utilizzando quelle specifiche verràeffettuerà l'integrazione e la verifica del sistema per garantire che il sistema ci faràdiritto e poi il sistema giusto è stato costruito per cercare nuovamente una convalida.
Così, riceveremo il documento di convalida che utilizzerà il documento di convalida afare questo e i dati di verifica saranno utilizzati come meno il prototipo e altri dati sarannoutilizzati per scopi di validazione. E uno, utilizzando i dati di validazione e il documento di validazionee altri dettagli dall'ORD, i documenti dei requisiti originari da noieffettueranno una verifica di accettazione che garantirà che il sistema progettato siaaccettato dal cliente o che soddisfi effettivamente un requisito del cliente.(Fare Slide Time: 21.38)
E una volta che questo incontro il requisito allora stiamo ottenendo un sistema operativo soddisfai requisiti del cliente e riceveremo il documento di accettazione e verificaanche come parte dell'output. E l'output finale da questa fase sarà sostanzialmenteuna documentazione di integrazione e la documentazione di collaudo di accettazione e riceverete ancheil sistema di funzionamento. E ogni qualvolta ci sono cambiamenti di design che saranno ancheportati in queste fasi. Quindi, che tutte le modifiche di progettazione sono incorporate nelle fasi di convalida e verificae che inoltre si avrà come output da questa fasedi un processo di progettazione.Sono i vari passaggi coinvolti nella verifica e nella validazione nella qualifica un sistema.
(Riferimento Slide Time: 22.34)
A meno che non abbia accennato di considerare la verifica e la validazione del sistema e abbiamo bisogno diper verificare l'integrazione del sistema o come fare in realtà l'integrazione dei componentinel sistema. Quindi, ci sono modi diversi di farlo, soprattutto quando si tratta didi hardware o software che i metodi utilizzati sono diversi se confrontati con i sistemi hardware. Quindi, dobbiamo vedere quali sono le diverse procedure disponibilidifferenti metodi adottati da varie industrie e varie organizzazioni e vari settoridi organizzazione nello sviluppo, nell'integrazione del sistema.L'integrazione Basicamente è quella di ottenere l'assemblaggio di tutti i componenti e garantire chein realtà sia il momento in cui si assemblano i componenti di configurazione dei componenti e il sottosistemae ottenere il sistema completo con le prestazioni è garantito per soddisfare i requisiti del cliente. Quindi, qui e l'integrazione facciamo l'integrazione dei componenti e la verifica, faremo l'integrazione dei componenti e poi verifichiamo se questo soddisfai requisiti di progettazione e poi eseguiamo l'integrazione del sottosistema e poi fare nuovamente la verificaper garantire che soddisfi il requisito e poi eseguiamo l'integrazione e la verifica del sistema. Ecco, queste sono le tre tappe normalmente seguite nello scopo di integrazione.Prima andiamo per l'integrazione dei componenti e poi andiamo per l'integrazione del sistema sub epoi vanno per l'integrazione di sistema. Quindi, praticamente questo è più simile ad un approccio bottom updove iniziamo con la voce più piccola dei componenti poi vai al sistema secondario e fai
l'integrazione del sistema. E ogni tappa, andremo per la verifica. Quindi,ogni qualvolta abbiamo un'integrazione di componenti andiamo per una fase di verifica per garantire chequesto abbia bisogno dei requisiti di progettazione e poi andiamo per l'integrazione del sistema sub e poi andareper una verifica di nuovo garantendo che soddisfi i requisiti e poi esegua l'integrazione del sistemache sia l'integrazione del sistema finale e poi effettui una verifica per garantireche soddisfi il requisito specificato. Quindi, questi sono i passi coinvolti nel processo di integrazione.(Fare Slide Time: 24:44)
E ci sono diversi processi seguiti poi l'integrazione è uno è l'approccio bottom up. Come ho accennato nell'approccio bottom up cominciamo con gli item di configurazionee dopo che ogni articolo di configurazione è collaudato i componenti che comprendono più elementi di configurazionesono sottoposti a test e il processo è continuato fino a quando l'intero sistema èassemblato e collaudato. Quindi, questo è l'approccio bottom up.Si inizia con gli elementi di configurazione e dopo ogni item di configurazione viene sperimentato. Quindi, noifacciamo la verifica degli elementi di configurazione inizialmente ogni CI è testato i componenticomprendente più IC sono testati. Quindi, facciamo i singoli test e poi facciamo ulterioricomponenti con più CI e siamo sottoposti a test e poi viene continuato fino a quando tutto il sistemaviene assemblato e collaudata. Quindi, ne andrà uno per uno iniziano con il più piccolo l'articolo di configurazione CItest ogni articolo di configurazione e poi assembla la configurazioneitem ai componenti poi effettua la verifica e poi assembla i soli componenti fino al
intero sistema viene assemblato e poi fare i test. Ecco, questo è il più comune bottomup approccio in integrazione.I vantaggi di questo metodo sono fondamentalmente più facili da rilevare difetti in pezzi più piccoli del sistema. Dal momento che stiamo iniziando con gli item di configurazione o i pezzi più alti del sistemae stiamo facendo i test è facile per noi scoprire gli errori in qualsiasi piccoloitem piccoli pezzi del sistema. Ecco, questo è uno dei vantaggi di utilizzare l'approccio bottom up. E poi le condizioni di prova sono facili da creare perché stanno mettendo alla prova i singoli CIs dio i piccoli articoli molto facili da sviluppare le condizioni di prova, diversamente dai testtutto il sistema effettuerà la verifica individuale del sistema, così possiamo scriveredown le procedure molto facilmente visto che sono semplici prodotti semplici o noncosì componenti complessi.Il problema principale è che i principali errori non vengono catturati fino alla fine perchéla maggior parte dei tempi ci saranno errori nell'integrazione e questi errori non vengono trovati fino agli ultimi istanti. I singoli elementi possono essere perfetti, quindi possiamo effettivamente identificare i difettinei singoli articoli, ma i principali errori di integrazione non verranno catturati fino afine o verso la fine del processo di progettazione poi solo sarà possibile catturare i principalierrori. Ecco, questo è uno dei problemi con l'approccio bottom up.La maggior parte del design di sistema segue l'approccio bottom up a causa di questi vantaggiche possiamo testare piccole parti. Ed è facile sviluppare la condizione di prova per le piccole parti,ma il problema maggiore è che c'è questo che non si ottiene l'errore maggiore è fino ala fine del design di sistema o verso la o la fine del processo di integrazione dei processi di progettazioneallora solo si otterrà i maggiori errori e risolvi quei principali errori all'che lo stage forse e potrebbe essere difficile anche.