Loading

Alison's New App is now available on iOS and Android! Download Now

Study Reminders
Support
Text Version

Set your study reminders

We will email you at these times to remind you to study.
  • Monday

    -

    7am

    +

    Tuesday

    -

    7am

    +

    Wednesday

    -

    7am

    +

    Thursday

    -

    7am

    +

    Friday

    -

    7am

    +

    Saturday

    -

    7am

    +

    Sunday

    -

    7am

    +

Passeremo attraverso i diversipassi uno per uno sulla progettazione dei sistemi di ingegneria.(Fare Slide Time: 00.48)
Come spiegato nelle lezioni precedenti, iniziamo con il processo di progettazione del sistema con l'identificazionedelle esigenze. Quindi, il focus qui è principalmente quello di scoprire le esigenze originali.E poi in base a questa necessità andiamo al concetto operativo requisiti funzionaliarchitettura di sistema e poi assegnato requisito per questi sistemi una volta identifichiamoquesti requisiti per vari sottosistemi poi andiamo per il design dettagliato e poiimplementazione. E infine, andiamo per la prova e la verifica. Quindi, questo è il flusso dipassi coinvolti nel design. Così, iniziamo con l'esigenza di identificazione.
(Riferimento Slide Time: 01.32)
Così, cercheremo di vedere; quali sono le esigenze che stiamo cercando di identificare o quali sono le esigenzestiamo cercando di riempirci di questo design di sistema e cosa c'è di sbagliato con la situazione attualee perché abbiamo bisogno di questa particolare situazione, quindi che ci dica; quali sono leesigenze da affrontare in questo particolare design. E, un'altra parte importante è chese la necessità sia chiaramente articolata o chiaramente compresa chiaramente citata o chiaramenteha registrato i requisiti e le esigenze del cliente.Così, una volta che avremo questo bisogno individuato andremo per il concetto di operazioni per il sistema; dato che si tratta di un nuovo design, dobbiamo individuare una specie di concetto di Frisiache ci aiuti effettivamente a sviluppare il sistema basato su questi concetti. Così, per arrivare afare quello che abbiamo cercato di fare è scoprire; chi sono l'utente destinato a questo sistema: comeusano i prodotti o come usano realmente questi prodotti e come è questo diversodal sistema attuale.Quindi, se conosciamo queste cose sugli utenti e le loro preferenze e ciò che dovrebbe esserediverso dall'esistente possiamo sviluppare un concetto operativo, una volta che avremo questeoperazioni concept andremo al livello successivo dei requisiti funzionali.
(Riferimento Slide Time: 02.40)
Quindi, quale capacità specifica verrà fornita in questo particolare sistema per soddisfare il requisito del clientee a quale livello di dettaglio dobbiamo fornire questi requisitie se tutte le interfacce elemento sono ben definite all'interno dei requisiti. Così, una voltaabbiamo queste risposte a questa domanda in realtà stiamo avendo i nostri requisiti funzionalipronti a partire da quello che andremo per la progettazione dell'architettura di sistema.(Fare Slide Time: 03.06)
Così, qui cercheremo di affrontare qual è il piano complessivo di attacco di quali elementi compongonol'approccio complessivo e sono questi completi logici o coerenti. Quindi, se il tutto
piano di attacco è coerente se effettivamente soddisfa il requisito e se la lorocompleta e logica verrà identificata e verificata nella fase di architettura del sistema. Epoi andiamo per i requisiti assegnati da quando abbiamo molti requisiti e molti sistemi.(Fare Slide Time: 03.34)
Quindi, dobbiamo assegnare questo requisito tra i componenti del sistema. Quindi, proveremoa vedere quali elementi indirizza a quale requisito.Così, facciamo una mappatura dei requisiti con i componenti o la struttura fisica.Così, ci facciamo una mappatura per identificare quali sono gli elementi che affrontiamo realmente unrequisito particolare individuato dal cliente. E poi vediamo se l'assegnazioneè appropriata se l'assegnazione è appropriata o abbiamo fatto una distribuzione su misura oan sotto assegnazione. Quindi, questo verrà analizzato e poi ci saranno requisitiinutili.Quindi, dobbiamo passare attraverso i requisiti e tutti i requisiti sono genuini enon ci sono requisiti inutili che avvertono un'edizione di elementi aggiuntivi inil sistema. Quindi, tutto questo verrà analizzato in questa fase e una volta confortati conquesti requisiti e assegnazione dei requisiti andremo per il design dettagliato.
(Riferimento Slide Time: 04.26)
Che ancora non fa parte dell'ingegneria di sistema che è più di un componentefocus engineering e questo che i dettagli sono corretti soddisfano i requisiti sonole interfacce sono soddisfatte tutte queste sono fatte dagli ingegneri progettisti o dai componentiingegneri e una volta che i componenti sono pronti ed è pronto per l'integrazione, l'ingegnere del sistemala prenderà e poi avvia l'assemblaggio. E poi fare l'implementazioneallora in sostanza faremo una verifica dell'implementazione verrà sperimentatofondamentalmente per capire la soluzione essere soddisfacente in termini di costo e programmazione.E possiamo riutilizzare i pezzi esistenti. Quindi, questo verrà analizzato nell'implementazione della fasee una volta che questo sarà completato andremo a fare un test e verifica.
(Riferimento Slide Time: 05.12)
Fondamentalmente, cerchiamo di capire o identificare qual è la nostra prova di successo e cheil cliente sarà felice di questo particolare sistema o ne avrà bisogno gli utenti; se il tuttole esigenze degli utenti corrispondono. Quindi, faremo un test e verifichiamo la fine del processo di progettazioneper garantire che soddisfi effettivamente i requisiti del cliente. Quindi, questi sonoi vari passaggi coinvolti nella progettazione del sistema.(Fare Slide Time: 05.41)
Così, per ottenere questo risultato abbiamo diviso questo intero processo di progettazione del sistema nel processo di6 o le 6 funzioni del processo di progettazione. Quindi, queste 6 funzioni sono applicabili in tutto
ciclo di vita e il primo si definisce problema di progettazione del livello di sistema. Quindi, qui proviamo acapire tutto il problema dal punto di vista del cliente o del punto di vista delle parti interessate; cercare di sviluppare i concetti per il sistema e cercare di identificare i confini del sistemacercare di identificare i requisiti e quindi preparare un documento di origine.Quindi, lo scopo del primo livello di un processo di progettazione o della prima funzione del processo di progettazioneè sostanzialmente quello di definire il problema di progettazione del livello di sistema, la seconda funzione èfondamentalmente per sviluppare l'architettura funzionale del sistema. Quindi, una volta che abbiamo questi sonoi requisiti identificativi; cerchiamo di identificare le loro funzioni da fornire nel sistema.E poi fornire una struttura gerarchica per le funzioni e identificare tutte le funzionie assicurarsi che queste funzioni siano sufficienti a soddisfare il requisito del cliente ilterzo è quello di sviluppare l'architettura fisica del sistema. Così, una volta che le funzioni sonoidentificate, cerchiamo di identificare i componenti o i sistemi fisici che effettivamente sarannofornire queste funzioni nel sistema questa fase è lo stadio di sviluppo dell'architettura fisicae la quarta è l'architettura di funzionamento del sistema.Così, una volta che abbiamo il sistema il sistema fisico in funzione dobbiamo scoprire come verrà operato il sistemaquali sono i requisiti operativi per il sistema e poisviluppiamo un'architettura di funzionamento che soddisfi i requisiti del cliente allorasviluppiamo un'interfaccia architettura visto che abbiamo molti sottosistemi in atto. Quindi,andiamo per un'architettura di interfaccia che proverà ad identificare sono le interfacce necessarie peril sistema secondario oltre che al sistema esterno, e garantire la compatibilitàcon gli standard. E altri requisiti individuati nel sistema e assicurarsi chenon ci sia perdita di dati o perdita di dati nei sistemi di comunicazione.E infine, una volta che il sistema è pronto sistema di qualificazione developer per il sistemadove garantiamo che il sistema sviluppato sia qualificato per soddisfare i requisiti del cliente. Quindi, in questo processo questo corso quello che cercherà di fare è passare attraverso tutti questipassi nei dettagli cercare di identificare; quali sono le attività coinvolte in ogni fase o la funzione. E poi, infine, svilupperemo il sistema di qualificazione per il sistema principaleche soddisfacendo effettivamente i requisiti di cui ho accennato prima questo è applicabiledurante tutto il ciclo di vita del sistema.
(Riferimento Slide Time: 08.12)
Così, per qualsiasi ciclo di vita del sistema queste 6 funzioni sono applicabili. Quindi, se si prende la fase di sviluppoo la fase di produzione o fase di distribuzione dobbiamo identificareil requisito che dobbiamo definire il problema che dobbiamo definire l'architetturafunzionale dobbiamo definire l'architettura fisica di cui abbiamo bisogno per identificare le interfaccedobbiamo identificare il sistema di qualificazione. Così, attraverso il ciclo di vita questi processi sonoapplicabili. Così, svilupperemo queste 6 funzioni per ogni ciclo di vita separatamente e poiidentifichiamo il requisito per ogni ciclo di vita e la funzione e l'architettura per ogni ciclo di vita.(Fare Slide Time: 08.50)
Quindi, per arrivare al primo processo che è il problema di progettazione del livello di sistema definito che èl'out della funzione 6 questo è il primo; quindi qui in questa fase.Proviamo a sviluppare il concetto di funzionamento per il sistema cerchiamo di identificare i sistemiesterni che sono esterni al sistema sviluppato. E cercheremo di identificare i requisiti originaricerchiamo di identificare quali sono gli obiettivi del sistema e comesviluppiamo la gerarchia degli obiettivi e poi come fare per rendere la documentazioneper i requisiti, e poi come gestire i requisiti. Quindi,questo sono i passi coinvolti nella definizione del problema di progettazione del livello di sistema, andremo
attraverso uno per uno quali sono i passi e come facciamo in realtà tutte queste fasi inraggiungere il problema di progettazione del livello di sistema.(Fare Slide Time: 09.39)
Così, come potete vedere qui il problema di progettazione del livello di sistema il principale input è l'input. Quindi, abbiamo stakeholder che può essere il cliente, può essere l'acquirente o chi èa utilizzarlo. Quindi, qui questo input è il principale input per il problema di progettazione del livello di sistemaessi affermano i requisiti che la loro applicazione prevede dal sistema basato suche l'output arriverà come requisiti originari e concetti operativi.Quindi, l'input maggiore è l'input degli stakeholder e poi la maggiore emissione da questafase particolare sono i requisiti originari che facciamo un documento che si chiamarequisiti originari del documento o ORD. E abbiamo pochi concetti operativiche possono essere sviluppati ulteriormente per soddisfare i requisiti degli stakeholder.
(Riferimento Slide Time: 10.23)
Così, questo grafico spiega in realtà le varie fasi e quali sono gli input e gli output perl'ogni fase della prima funzione. Così, potete vedere qui sviluppare il concetto operativoquesta è la prima fase in cui abbiamo gli stakeholder input come input principale e noiabbiamo un output da questa fase particolare come il concetto operativo. Così, sviluppiamoconcetto operativo molto alto livello operativo molto astratto e senzamolti dettagli. Quindi, questo sarà l'output dalla prima fase di sviluppo del concetto operativoe una volta che abbiamo questo usiamo questo come concetti operativi di input come inpute difendiamo il limite di sistema.Con sistemi esterni da quando ogni sistema interagisce con il sistema esterno abbiamo bisogno diper identificare qual è il nostro focus. Quindi, quale noi cerchiamo di concentrarci qui. Così, che diventail nostro focus principale e che diventa il nostro sistema di interesse e tutto ciò che èche interagisce con il sistema definirà come sistema esterno ci aiutano a fare limiteall'interno del quale dobbiamo progettare il sistema. Quindi, la seconda fase di definizione del limite di sistemaaiuterà il diagramma di sistema esterno, ti aiuta a identificare il limite di sistemagli input e gli output. Quindi, l'output principale da questa particolare fase è la definizione dilimite di sistema gli input al sistema e ciò che gli outputs che vanno fuori dal sistemapoi usiamo il concetto operativo così come gli input di limite di sistema eoutputs e questo concetto di funzionamento e gli input degli stakeholder verranno utilizzati per sviluppare la gerarchia degli obiettivi del sistema. Così, ogni sistema avrà qualche oggetto usato per essere soddisfatto
che viene definito dal cliente qualcosa come il costo operativo o l'efficienzaoperativa.Quindi, queste cose hanno bisogno di una particolare gerarchia. Quindi, non possiamo avere la stessaimportanza per tutti questi obiettivi. Così, in base al concetto operativo e alstakeholder input un oggetto è la gerarchia sarà sviluppata che ci aiuterà ad averequalche scambio in una fase successiva del design. Quindi, l'output da questa fase è l'oggetto è la gerarchiache è l'input per il concetto operativo e l'input degli stakeholder ora utilizzandotutti questi output dai precedenti stagisti sviluppiamo analisi e requisiti raffinati.Quindi, questa è una fase importante in cui dobbiamo sviluppare tutti i requisiti e analizzaree perfezionato il requisito per il cliente ora abbiamo un concetto operativo noiabbiamo l'input degli stakeholder. E abbiamo una gerarchia oggettiva basata su questo noiidentifichiamo tutti i requisiti necessari per il sistema e poi prepariamo i requisiti di sistema originari e. Quindi, ci sono 2 tipi di requisito uno è il requisitooriginario l'altro sono i requisiti di sistema che vedremo quali sono questi requisitiin una fase successiva. Quindi, questa sarà l'uscita da questa particolare fase.Poi andiamo ad analizzare questo requisito per garantire che siano fattibili e soddisfinoi requisiti. Quindi, quella fase è la verifica dei requisiti di fattibilità. Quindi, qui l'input del team di engineering del sistemasarà importante perché gli ingegneri di sistema sanno cosaeffettivamente i requisiti di sistema soddisfano realmente le esigenze del cliente. Così, il sistemaengineering input così come i requisiti originari e quelli di sistema diventanol'input qui e quando fare un'analisi di fattibilità progettale una volta questo soddisfatto ci troviamoulteriore requisito di sistema di qualificazione perché ogni sistema deve essere qualificato asoddisfare il requisito.Così, definiamo i requisiti del sistema di qualificazione e l'output sarà il documento del requisito di sistemae una volta che questo sarà fatto otterremo l'approvazione diquesta documentazione di sistema dagli alti superiori e alla fine di questo otterremola documenti requisiti di origine e di sistema. Quindi, questa funzione di processo del problema di progettazione di livello di sistemainiziamo con gli input degli stakeholder e all'interno dei requisiti di sistema originari e.Quindi, questa è l'output finale di questa particolare fase di sviluppo questo è importanteperché i requisiti devono essere chiaramente definiti e intesi dagli stakeholder
così come lo hanno sviluppato gli ingegneri di sistema qualsiasi requisito di vincolo sarà un problemaall'ultima fase del design. Quindi, dovremmo fare in modo che i requisiti sianoflessibili. Così, che possiamo avere qualche libertà nella fase successiva per fare in modo che quelcorretto commercio di poter essere realizzato e i progettisti di sistema non siano troppo vincolo nello sviluppo didel concetto operativo così come dell'architettura funzionale e fisicadel sistema.(Fare Slide Time: 14.40)
Così, come ho accennato la prima fase è lo sviluppo del concetto operativo. Quindi, nel concetto operativoè una visione per ciò che il sistema è è una dichiarazione dei requisiti di missione edescrizione di come verrà utilizzato il sistema. Quindi, quello è un livello di concettomolto preliminare o molto astratto dove definiamo semplicemente una visione.Per ciò che il sistema è ed è una descrizione molto semplice di come verrà utilizzato il sistemaincluderà le informazioni su come verrà sviluppato il sistema esi ritirano dalla prospettiva del sistema stakeholder e raccolta di scenari einterazione sistemi con altro sistema. Così, al fine di sviluppare un concetto operativo noidobbiamo dover sviluppare analisi preliminari o un concetto preliminare come il sistema saràazionato e utilizzato e cercare di identificare diversi scenari di funzionamento. Quindi, quali sono gli scenariin cui si opererà il sistema? Quindi, che questo ci darà qualche inputsui requisiti diversi vari tipi di requisiti e la loro interazione dei sistemi
con l'altro sistema che è sostanzialmente un diagramma di sistema esterno. Quindi, queste sono lecose da inserire nel concetto operativo.(Fare Slide Time: 15.51)
Ad esempio, se si prende il concetto operativo per atterrare sulla luna è di nuovo ad un concetto di livello superioresi possono avere concetti diversi per farlo.Si può avere un'ascesa diretta dove la visione partirà dalla terra e si andrà suintorno alla terra e poi di nuovo si scatterà sulla Luna direttamente dall'orbita e atterra direttamente sulla Luna e poi si scatta dalla luna e poi di nuovo arrivano direttamente earrivano sulla terra. Così, questo è un modo per farlo è un regista ascente o si può avere unaterra orbite e stampare dove l'orbita terrestre sarà la prima tappa e poi si vadirettamente sulla luna e poi atterra sulla luna.E poi tornare dalla luna decolla direttamente dalla luna, percorrere un rotondointorno alla terra e poi atterrare sulla terra. Così, questa è l'altra possibilità che un altroconcetto che può essere impiegato o l'altro è l'orbita lunare; orbitate attorno all'orbita dove illungo con l'orbita terrestre andrà un giro intorno alla luna e le lune orbitano e poitornano nella terra sulla luna poi si tolgono dalla luna e poi tornano ala terra.Così, questo sono i diversi concetti operativi per atterrare sulla Luna questo è il modo in cui iniziamo con il design del sistema perché non abbiamo alcun concetto da seguirlo
Una missione totalmente nuova la dobbiamo identificare quali sono le possibili opzioni per ipossibili concetti che possiamo dipendente poi prendere uno di questi concetti. E poi, sviluppareil livello successivo cerchiamo di sviluppare gli scenari operativi in base ai quali possiamoidentificare i requisiti da fornire o le funzioni da fornire nel sistema.(Fare Slide Time: 17.23)
Così, al fine di sviluppare scenari operativi cercheremo di identificare variescansioni operative che possiamo pensare ad esempio, se si prende il caso di un ascensoremolto diffuso nella maggior parte dei nostri edifici se si desidera sviluppare un sistemaper un edificio particolare con più elevatori o un singolo ascensorecercheremo di realizzare uno scenario semplice dei concetti, dove diremo che abbiamo 2elevatori in 2 lati dell'edificio o 2 diverse località e poi questo sarà servire 2piani diversi a particolare frequenza
la frequenza è una particolare efficienza o le caratteristichedelle prestazioni.E una volta che avremo questo allora cercheremo di identificare quali sono i diversi scenari sottoche questo ascensore sarà operato. Quindi, cercheremo di definire questo scenario nel dettaglio quanto piùnel dettaglio possibile. Così, che includerà quasi tutti i dettagli quello che dobbiamo saperecirca i requisiti da fornire nel sistema ad esempio, prendiamo lo scenario diun sollevatore di passeggeri per ascensore. Quindi, cerchiamo di definire lo scenario nel dettaglio. Quindi, ci proveremo aspiegarlo che i passeggeri tra cui l'udito di mobilità e la richiesta visivamente contestataup service. Quindi, stiamo cercando di includere anche i disabili o le persone diversamente abili
in questo modo che i requisiti da rispettare in ascensore saranno diversi se non siamoa fornire questo particolare requisito. Quindi, siamo compresi che anche qui siamofornendo ai passeggeri compresi le persone diversamente abili che richiediamo il servizioe il servizio in giù ricevono un feedback che la loro richiesta è stata accolta. Quindi,a meno che non ricevano un feedback non sapranno se l'ascensore funzionao meno.Quindi, è necessario fornire un feedback al passeggero che dice che sì la tua richiesta è stata accettatae daremo un feedback che la richiesta è stata accettata e poi ricevere un inputche l'auto da ascensore si avvicina. Quindi, non solo che la richiesta è stata accettata, anchedarà un input che l'auto dell'ascensore si sta avvicinando e poi che un'opportunità di ingressodisponibile, quindi dovrebbe essere informata ai passeggeri che un'opportunità di ingresso è giàresa disponibile questo è importante soprattutto a causa di persone sfidanti chepotrebbero non sapere che ha raggiunto alla porta è aperta. Quindi, dobbiamo garantireche nelle opportunità di ingresso disponibili e poi il passeggero entrerà nella macchina dell'ascensore epoi ne richiutiamo il pavimento e una volta che le richieste di passeggero per il pavimento dovranno ricevereil feedback che la loro richiesta è stata accettata e poi ricevere feedback che la porta èchiusura ricevono feedback su che piano l'ascensore sta topando riceviamo il feedbackche un.Accent opportunità disponibile e uscita ascensore senza impedimenti fisici. Così, spiega chiaramente l'intero scenario di utilizzo di un ascensore da parte di un passeggero dal momentochiede un servizio all'azione in cui effettivamente esce dall'ascensoresenza alcun impedimento fisico è importante dire tutte queste parole come includere l'udito di mobilitàcontestualizzato così come l'uscita dall'ascensore senza problemi fisicitutto questo definirà i requisiti reali da fornire in ascensore.Così, questo è solo uno scenario ci saranno più scenari come questo che ci aiuteranno aidentificare vari requisiti per esempio.
(Riferimento Slide Time: 20.42)
Possiamo definire scenari diversi come la situazione di emergenza. Quindi, cosa accadrà se ci saràemergenza nell'ascensore che all'interno della porta di sollevamento fuori dall'ascensore? Allora, quali sono le cose aprese cura di questa situazione e che è un incendio nell'edificio. Quindi, se c'è un incendioquale sarà il modo in cui l'ascensore dovrebbe funzionare se deve fornire il servizioo deve fermarsi al punto in cui è punto all'interno dell'ascensore quello che dovrebbe essere l'azioneda intraprendere. Quindi, per questo quali sono gli altri requisiti da soddisfare per quale tipo di sistema di comunicazioneda fornire tra l'ascensore e l'edificio tra l'ascensoree il team di risposta di emergenza.Quindi, tutte quelle cose saranno identificate in questa descrizione dello scenario analogamente auto closeripartizione sovraccarico in tutti questi scenari può essere spiegato chiaramente utilizzando gli scenaripoi possiamo identificare quei requisiti per soddisfare tali requisiti. Così, questogarantirà di prenderci cura di tutti i requisiti tutti gli scenari e di garantireche l'ascensore che è questo progettato soddisfi i requisiti del cliente
soddisfano i vari requisiti in vari scenari operativi.
(Riferimento Slide Time: 21.52)
Quindi, per descrivere lo scenario possiamo effettivamente utilizzare il metodo chiamato trace output trace. Così,qui la traccia di output in ingresso.Basamente dà una foto che rappresenterà gli scenari qui le linee verticalirappresenta l'interagire delle persone il passeggero e l'ascensore o il sistemacomponenti il sistema o il sistema esterno e l'orizzontale rappresenta la comunicazionetra sistema e sistema esterno. Quindi, qui il passeggero è un sistema esternoe il sistema dell'ascensore è il sistema principale che ci interessa. Così,possiamo identificare quali sono la richiesta che passa dal passeggero che tipo di feedback ètornando al passeggero e poi quali informazioni vengono inviate dal passeggeroall'ascensore in base al feedback dato dall'ascensore.Così, tutto questo può essere rappresentato in modo pittorico. Quindi, che è facile capire peraltri soprattutto gli ingegneri del design. Quindi, chiunque attraversi questo capiràche il tipo di interazione che si svolge tra il sistema e il suo sottosistema o i sistemi esterni. Quindi, questa è la traccia di output in ingresso per lo scenario uno che noiabbiamo discusso abbiamo spiegato nella slide precedente.
(Riferimento Slide Time: 23.02)
Quindi, quella era la traccia di output in ingresso per l'identificazione dei requisiti per il concetto operativoe un altro fattore di cui abbiamo bisogno per prenderci cura è il diagramma di sistema esterno. Così, come ho accennato il sistema interagisce con l'ambiente e un altro sistema. Quindi, dobbiamo identificare il limite in cui dobbiamo concentrarei nostri sforzi di progettazione per quel che dobbiamo avere il diagramma dei sistemi esterni che sia il modellodell'interazione del sistema con altri sistemi nel contesto rilevante; quindifornire una definizione del limite dei sistemi in termini di input e output di sistema.Quindi, qui siamo definiti il limite di sistema in termini di input e outputlo scopo di questo è sostanzialmente definire esplicitamente il limite di sistema e le interfaccenecessarie. Quindi, utilizzando questo diagramma di sistema esterno sarà possibile definire il limite ele interfacce definite per