Então, hoje discutiremos sobre as estratégias de aceitação e os métodos de estresse de aceitaçãoe como planejamos para o teste de aceitação e quais são os passos importantes envolvidos noo teste de aceitação, quais são as coisas a serem testadas e como planejamos para o seu; nósdiscutirmos sobre esses aspectos na palestra de hoje.
(Consulte O Tempo De Deslizamento: 01:42)
Então, o teste de aceitação é basicamente o teste final em qualificação. Como mencionei isto éseparado da validação como ele é conduzido por stakeholders e não engenheiros do sistemae se este falhar o sistema deve ser alterado. Assim, se o teste de aceitação falhar entãodefinitivamente então esse sistema tem que ser alterado, exceto por algumas exceções; a maioria dosvezes teremos que alterar o sistema, pois isso não é aceitável para o cliente.E o limite de aceitação precisa ser definido no próprio início; portanto, não podemoster um limite identificado após o design do sistema. Assim, quais são os valores de limite paravários design de sistema ou os aspectos do sistema ou o desempenho do sistema precisam serdefinidos bem antes do teste e ou mesmo antes do início do design do sistema, nósprecisamos garantir que os limites sejam definidos.Então, que não há ambiguidade dos limites e não há alterações no limiteapós o sistema ter sido projetado ou baseado no design real do sistema, não podemos alteraro limite; portanto, ele tem que ser predefinido. E o teste de aceitação basicamente se concentrará no usode um sistema por um pequeno grupo de pessoas ou um grupo representativo porque isso não éfeito pelos engenheiros do sistema, precisamos ter um grupo de pessoas que serão os usuáriosJá que não é possível ter um grupo muito grande de pessoas testando o sistema, precisamos identificar um pequeno grupo de pessoas que realmente podem fazer o teste e então descobrirse ele realmente atende a um requisitos.
Então, vários aspectos do sistema usado serão testados por esse conjunto de pessoas e, então, se elecumprir os valores de limite, então ele será aceito. As duas principais perguntas feitas aquié basicamente o que testar, e como testar? Então, quais são as coisas a serem testadas no teste de aceitação do, e como fazer esse teste? Então, estes são os dois aspectos importantes no teste de aceitação.(Consulte o Tempo de Slide: 03:49)
A questão do que testar é a primeira; basicamente a resposta é tudo possível.Então, não há restrições a isso, portanto, quaisquer que sejam as coisas que possamos testar; podemos fazer o testeque é tudo o que é possível pode ser testado. E a questão-chave deve ser feita ouo que deve ser teste? E o que esquecemos de testar? Então, isso também é muito importante o quedevemos testar é um aspecto que devemos cuidar nos testes, mas maisimportante o que nos esquecemos de testar também é importante.Às vezes podemos esquecer de testar alguns parâmetros importantes e que podem levar a uma falha deno sistema. Existem muitos estudos de caso que realmente mostraram que tem algunsdos aspectos foram testados e exatamente esses parâmetros tornaram-se a causa de falha no sistema. Por isso, precisamos ver que não é apenas importante que o que são as coisas que nósestamos testando? Mas quais são as coisas que esquecemos de testar? Também é muito importante.Então, neste caso o teste de aceitação eles substituem os testadores de desenvolvimento pelos usuários. Então,isso eu já mencionei; assim, o desenvolvimento em testadores são diferentes dos usuários e
portanto, e o teste de aceitação precisa ser conduzido apenas pelos usuários, isso não é feitopelos testadores desenvolvimentistas.Então, essa parte precisa ser cuidada e não é possível ter uma repetição exaustivado teste; principalmente porque há muito teste a ser conduzido e há muitos subsistema, componentes e interfaces. Sendo assim, não é possível ter um teste exaustivo do sistemano nível de aceitação. Assim, na maior parte do tempo, teremos que contar com o teste passadotambém. Assim, alguns dos dados do teste passado basicamente no estágio de qualificação e outros estágios de integração de sub-sistema, alguns dos dados do teste serão usados aqui e esse lote dedependência desses dados estará lá durante o teste de aceitação.Então, dependendo do tipo do sistema e dependendo da natureza do requisito do teste, os designers podem realmente decidir; qual o teste importante a serrealizado durante a aceitação? E quais são os dados a serem usados a partir do teste anterior?Então, isso é importante aqui porque há muitas coisas a serem testadas. Então, isso pode nãoser possível sempre durante o teste de aceitação.(Consulte o Tempo de Slide: 06:07)
E os resultados do teste de aceitação; assim, quando faremos um teste de aceitação basicamentea ideia é ver, se ele pode realmente atender a exigência dos stakeholders.Então, que tipo de resultados podemos obter daqui, após o fim das partes interessadas do testepode realmente aceitar o sistema como ele é. Então, essa é uma opção que o sistema pode ser aceito
como está sem nenhuma grande mudança. Assim, a maioria dos parâmetros são testados e elesrealmente atendem o limite de aceitação, os stakeholders podem aceitar o sistema como ele é.Mas então outra opção é que aceite submeter-se a determinadas alterações. Assim, são poucas asmudanças necessárias no sistema com base no teste de aceitação dos testes os stakeholderspodem sugerir algumas alterações e então aceitá-lo com base nessas alterações. Assim, então neste casoo sistema será aceito, mas eles podem solicitar algumas mudanças e os stakeholderspodem começar a usar o sistema, mas mudanças serão implementadas posteriormente com base nos resultados do teste de aceitação; que é uma segunda opção.A terceira opção é que aceita; só depois de alterar isso, o sistema não pode ser aceitono status presente e considerar algumas alterações e o sistema pode ser aceito apenasdepois de fazer as alterações. Assim, neste caso comparado com o anterior aqui o sistemanão será usado pelos stakeholders, eles vão esperar que as alterações sejam feitas e entãosó ele será aceito e a última opção também não é.Então, os stakeholders podem simplesmente dizer que ele não está atendendo os requisitos e, portanto,não podemos aceitar o sistema e ele precisa ser redesenhado. Então, há outra opçãoaqui o sistema precisa ser redesenhado e, em seguida, o teste de aceitação para ser repetido e ouma vez que seja qualificado após o teste de aceitação, então somente ele será aceito pelosstakeholders, portanto, estas são as quatro opções para os stakeholders. Assim, com base na aceitaçãoeles decidirão ou aceitarão o sistema como ele é porque não precisa de maisalterações.Então, neste caso os interessados podem começar a usar o sistema sem nenhuma alteração, mas a segunda opçãoé que eles vão pedir algumas alterações ou eles descobriram que há algumaspequenas alterações a serem feitas tanto na interface ou no desempenho funcional, quesão menores e não afetam realmente o desempenho do sistema.Então, neste caso os stakeholders aceitarão o sistema como está com as pequenas alterações.Então, as pequenas alterações serão ser intimado aos designers e designers fará as modificaçõese adicionará ao sistema existente. Assim, os stakeholders começarão a usar o sistemacom ainda que as pequenas alterações sejam necessárias e essas pequenas alterações; irávir como uma próxima versão ou uma atualizaçao do sistema existente. O terceiro é o sistemaatende a maior parte dos requisitos quase que ele se qualifica na maioria dos casos, mas requer alguns
alterações que são muito importantes e o sistema pode ser aceito somente após estas alteraçõessão feitas.Então, neste caso os interessados não sabem usar o sistema eles vão pedir aos designers quefaçam as alterações e então dê a eles por uso. Então, essa é a terceira opção e aúltima é rejeitar o sistema, por isso não está qualificando qualquer um ou a maioria dos requisitosnão são atendidos pelo sistema. Assim, neste caso rejeitarão o sistema e perguntarão aosdesigners para refazer o sistema ou redesenhar o sistema.E então ele tem que passar pelo estágio de integração e qualificação e o teste de qualificação, bem como o teste de aceitação a ser repetido e então ele será aceito. Então, essessão as várias opções para os stakeholders após o teste de aceitação, mas há algunscasos em que há poucos aceitação, em que o sistema será aceito mesmo se houveralgum problema com o sistema.(Consulte o Tempo de Slide: 10:08)
Então, aqui estes são os casos especiais que os stakeholders aceitam o sistema sem o teste de aceitação positivo completo. Por isso, aqui mesmo que o sistema não esteja satisfazendo completamente os requisitos, os interessados aceitarão o sistema. Isso porque a variante existenteestá causando muitos problemas, portanto, o que quer que eles estejam tendo no presente; está causando tambémmuitos problemas e, portanto, um produto parcialmente melhorado aceito e liberado com uma notapara equipe de engenharia para concluir a tarefa dada rapidamente.
Então, aqui eles vão aceitá-lo porque a versão anterior ou o que for existente empresente está causando excesso de problemas. Então, eles querem ter muitas melhoras sobreque um é aceitável para eles. Então, eles vão começar a usá-la, mas vão dar uma nota para a equipe de designpedir para ele mudar o design ou pedir para melhorá-lo. E o sistema éinaceitável em alguns casos embora esteja atendendo ao máximo da exigência; ele não éaceitável porque causa mais problemas do que o sistema existente.Então nessa situação eles podem não aceitar, embora realmente atenda aos muitos dos requisitos do. Assim, se ele causar mais problema do que o sistema presente então ele não seráaceito e na maior parte desses testes, eles farão duas suposições e depois vão em frentecom os testes. Basicamente um é isso; eles supõem que ele é totalmente aceitável ouinaceitável. Portanto, se isto assumir que é totalmente aceitável então a maior parte do teste seráprojetada de tal forma que para provar que não é aceitável.Então, você assume que é inaceitável e então realizar teste para provar que, ele não éaceitável e se este teste falhar; então é aceitável. Da mesma forma, você assume que ele éinaceitável e, em seguida, realizar o teste para provar que ele é aceitável e se o testetiver sucesso então o sistema será aceito. Assim, desta forma podemos ter dois tipos de premissase teste para realizar o teste de aceitação.(Consulte o Tempo de Slide: 12:04)
O próximo é como testar? Por isso, que existem várias formas de testar e várias coisaspara serem testadas e há diferentes opções para os stakeholders após a prova. Mas como
fazer o teste é novamente um aspecto importante porque há vários aspectos a serem testadose como realizamos esses testes é importante. Então, aqui olhamos um aspecto como a usabilidadedo sistema e depois vemos como fazer o teste de usabilidade.Então, testes de usabilidade são determinar o sucesso em requisitos de atendimento dos stakeholders.Então basicamente os requisitos das partes interessadas; o quanto ele é satisfeito, como é testado a usabilidade deo sistema pelos stakeholders é testado. Há cinco aspectosno teste de usabilidade; basicamente você olha para a aprendizagem do sistema que é hora dedominar um nível de eficiência definido.Então, olhamos para o sistema e depois vemos como primeiro pode ser aprendido pelo ou masterizado por um usuário. Teremos um nível de eficiência predefinido e veremos quanto tempo levapara um usuário atingir esse nível de eficiência; que é o teste de aprendizado. O próximo é a facilidade de uso; agora qual a facilidade para usar o sistema, então aqui o tempo para um usuário frequente completaruma tarefa de definição.Então, você descobre o tempo necessário por um usuário frequente para completar uma tarefa definida. Por isso, lásão usuários com várias capacidades; alguns deles são usuais muito frequentes, alguns delesraramente usam o sistema, alguns dos especialistas no uso do sistema. Então, nós tiramos um usuário de nível médio, um usuário frequente para completar uma tarefa de definição e descobrir quanto tempo ele levapara completar uma determinada tarefa.Então, isso de fato nos dá o uso do sistema e o terceiro é memorabilidade do sistema. Então, tempo para um usuário casual alcançar taxa de produção previamente alcanada. Então,aqui é um usuário casual não é um usuário todo frequente, então ele será solicitado a usar o sistemae para ver quanto tempo leva para atingir uma taxa de produção previamente alcanada.Então, ele pode estar tendo algum nível de produção usando uma versão anterior de um sistema ou um sistema similar. Então, esse usuário será solicitado a usar o sistema e a ver o quão rápido elerealmente atinge a taxa normal de produção e isso realmente nos dá o valor da memorabilidadedo sistema. E a quarta é a taxa de erro, o número de matrizes em umdeterminado período para uma determinada tarefa. Então, dependendo do número de erros podemos descobrirqual é a taxa de erro do sistema? E então por um determinado período, para uma determinada tarefa nós vamostentar descobrir quantos erros estão acontecendo no sistema e isso realmente dá uma taxa de errodo sistema.
Então o nível de satisfação, o nível de satisfação é o de novo é um pouco assunto você,mas depois é o nível de estresse ou de diversão associado ao usuário. Então, basicamente uma pessoa que éusando o sistema; o quanto ele está feliz ou o quanto ele é perturbado ou o quão frustrado eleestá; sobre o uso do sistema. Então, essa é uma medida da satisfação do sistema; assim, a usabilidadedo sistema pode ser testada utilizando-se desta cinco medidas.E a última; que o nível de satisfação pode ser testado somente quando o sistema completo estiverdisponível. Por isso, quando temos o sistema completo; podemos fazer o teste de satisfação, mas ooutro, o teste pode ser concluído mesmo quando o sistema completo não está disponível também. Então,estes são os cinco níveis de testes de usabilidade e podemos realmente pegar esses parâmetros emedir seus valores e ver como o sistema é utilizável e quais são os obstáculosbasicamente lá nos testes de usabilidade.(Consulte o Tempo de Slide: 15:34)
Embora haja fator emitido, há algum problema em realizar o teste de usabilidade. Então, estes são basicamente os primeiros é claro, conseguindo os participantes do teste; quemrepresenta o usuário real? Então, precisamos ter um conjunto de usuários para fazer o teste, mas então elepode não ser sempre fácil de encontrar os usuários ou os usuários de teste o suficiente, número de usuários do testeque podem realmente participar dos testes do sistema. Então, isso de fato dá um problemae precisamos garantir que quem estamos selecionando para o teste do sistema;eles representam os usuários reais ou há uma chance para eles usarem ou há um potencial paraessas pessoas usando o sistema.
Então, então só haverá alguma validade para o teste. Por isso, obter essas pessoas é meiodifícil porque encontrá-las para os testes ou obtê-las para que os testes venham aa instalação de teste e fazer o teste pode não ser sempre possível. Então, esse é um dosproblemas em fazer o teste de usabilidade e, em seguida, obter uma amostra representativa de comoa população irá avaliar o sistema; ou seja, precisamos ter um grupo de pessoas, quemna verdade pode avaliar o sistema usando uma pessoa ou alguns números pode não sersuficiente porque precisamos obter uma amostra representativa de como a população iráavaliar o sistema.Pode haver várias seções de pessoas usando o sistema; pode haver um sistema, podeser usado por adultos ou pode ser filhos ou pessoas fisicamente desafiadas ou aquelas que sãoidosos. Por isso, precisamos obter uma amostra representativa de todas essas pessoas para avaliar o sistemaque também pode ser uma tarefa difícil. Em seguida, selecionar tarefas mais críticas à usabilidadeprecisa, assim como mencionei precisamos ver a tarefa; que são necessárias para serem testadas pelos usuáriosmas então esta selecionando a tarefa mais crítica às necessidades de usabilidade também é importante.Então, os designers precisam analisar toda a tarefa e, em seguida, ver quais são a tarefa mais críticae, consequentemente, precisam fazer o teste. E então escrever os cenários de teste osrepresentam com precisão a situação real. Por isso, os cenários precisam ser devidamente definidos eanotados para que todo o teste possa ser feito com base nesses cenários. Por isso, escrever issocenários também; um grande desafio e prever qual interface do usuário é mais crítico. Entãoisso novamente difícil de prever inicialmente porque dependendo do uso e que dependendodas pessoas que estão usando, portanto, alguns da interface talvez crítica então apenas muitos nãosejam críticos.Então, identificar essa interface crítica também um desafio, então estes são os principais obstáculos emfazer o teste. Então, precisamos garantir que sempre que fizermos um teste de usabilidade; vocêprecisa se certificar de que temos um representante, uma amostra da população que usa o sistemae temos os cenários identificados apropriadamente e temos o usuário críticointerfaces identificadas e escrevemos abaixo os cenários e para testar e quais são astarefas importantes a serem testadas.Então, todas estas precisam ser analisadas e gravadas adequadamente para ter certeza de que fazemos um teste adequado dee que aquelas testings são realmente importantes. E esses valores de teste realmente representama aceitação do sistema pelo usuário. Assim, embora esses desafios na usabilidade
Os testes precisam ser identificados estágios iniciais e medidas a serem tomadas para superar essas dificuldades; portanto, isso é sobre os obstáculos em testes de usabilidade.(Consulte o Tempo de Slide: 19:12)
Então, como mencionei estes são os vários estágios nos testes de aceitação. Por isso, temos queidentificar os cenários de teste, precisamos identificar os cenários de teste assim como precisamosidentificar a tarefa a ser testada e tantos do teste desfalque que testes de usabilidade.Como fazer testes de usabilidade? Por isso, aqui eu vou levar dois estudos de caso para mostrar que comoimportante é o teste de teste e aceitação na qualificação do sistema. Discutimossobre o caso da falha do THERAC 25, mas este era um médico, um dispositivo; um computadormáquina de terapia de radiação controlada e desenvolvido para dar radiação controlada aospacientes e depois no período de 1985 87; 3 pacientes foram mortos por radiaçãooverdoses e embora máquina deveria proteger esses pacientes, eles foram mortospor causa das overdoses em radiação.Então, a razão para isso foram as quatro operadoras diferentes entraram em um aceitável, mas emsequência de comandos utilizada frequentemente. Então, a razão para a overdose foi basicamente o usodo sistema por várias operadoras. Então, quatro operadoras diferentes entraram em uma sequência aceitável,mas em frequentemente usada sequência de comandos e que realmente levaram à overdose eesses erros podem ser rastreados para a análise de requisitos e falhas de design.Então, quando iniciamos o desenho do sistema foi; como mencionei anteriormente precisamosidentificar o requisito adequadamente e depois registrá-los. Então, houve um erro em
identificando a exigência, o requisito adequado não foi identificado. Qual é a condiçãosob a qual esses parâmetros a serem inseridos? E qual é a sequência emque precisa ser digitada? Aquelas coisas não foram devidamente identificadas e o sistema de qualificação projetado corretamentepoderia ter detectado essas falhas.Então, apesar de haver erros no início na etapa de análise ou no estágio de análise do requisito, se tivéssemos um sistema de qualificação adequadamente projetado então esses fluxos poderiamter sido premiados ou pode ser possível ter sido detectado no estágio inicial ou antes deimplementar a máquina ou antes da implementação da máquina, poderíamos teridentificado essas falhas. Então, os testings adequados não foram realizados; onde podemos identificaresses requisitos ou esses cenários.Então, os cenários operacionais como o; no cenário usado com frequência poderiam ter sidosimulados e os testes poderiam ter sido realizados para descobrir o que realmente, o que vaiser a saída e então os erros poderiam ter sido identificados e então poderia ter sidoretificado. Então, esse foi o problema realmente o que realmente causou a morte trágica de muitospacientes por causa de overdose.Então, este foi um caso claro em que toda a sequência de entrada de dados possível deveria ter testado. Por isso,isso realmente mostra a importância dos testes de aceitação. Assim, se toda a sequência de entrada de dados possíveldeveria ter sido testada para se certificar de que não pode haver erro na sequência de entrada de dadose que pode fazer com que o sistema visualize alguns erros. Então, isso realmente mostraa importância do teste de aceitação e identificação de todos os cenários de testes e esteé um estudo de caso que é o outro novamente a partir dos acidentes industriais ou das falhas.
(Consulte O Tempo De Deslizamento: 22:39)
O fracasso ARIANE 5, discutimos sobre isso em uma das palestras. Por isso, ARIANE 5foi o veículo de lançamento desenvolvido pela agência espacial europeia, causando cerca de 500milhões de dólares americanos e 37 seconds em seu voo ARIANE 5 desviou curso edesintegrou-se em breve.Novamente a falha foi rastreada a dois sistemas de referência inercial, um dos quais em hotstandby, emprestamos sobre o sistema de espera que basicamente é um sistema tolerante de queda. Então,havia dois sistemas de referência iniciais; um deles estava em hot standby, portanto, mesmo que umfalhe, o outro pode ser usado para obter a saída do sistema e então pode descobrira localização do sistema o veículo.Ambos SRI ’ s falharam quando seu software converteu 64 bit ponto flutuante em um número inteiro de 16 bitassinado. Então, esta foi a causa básica para a falha houve uma conversão de um número de ponto flutuante de 64bits para um número inteiro de 16 bit bits assinado que não estava planejado no sistemaou eles nunca esperavam esse tipo de conversa. E como foi convertido nestee o sistema não poderia aceitar, a interface não poderia aceitar os dados e, portanto,houve uma falha.Agora, durante o estágio de design sete variáveis foram identificadas que poderiam causar um erro de opere. Por isso, nas etapas iniciais do design; os engenheiros de design identificaram sete variáveisque podem realmente causar esse tipo de problema e identificaram quatro delas. Então, uma decisão deliberada foi tomada para proteger SRIs de quatro essas variáveis; assim,
dos sete, eles identificaram quatro variáveis e fizeram as medidas necessárias paraproteger o sistema ou o SRI ’ s a partir deste problema. E quatro deles foram protegidose os outros três foram assumidos para ter uma grande margem de segurança.Então, novamente eles para tomar decisão aqui dizendo que há uma possibilidade destes três obternisso há resultando em um erro de opere é muito remoto e então eles são decididosnão para protegê-los contra esta três variáveis e nenhum teste foi feito na SRI paraexaminar o cenário operacional associado com a contagem e a trajetória. Então, oSRI ’ s é o basicamente usado durante o estágio inicial do voo. Então, eles não fizeram nenhum teste de aceitaçãopara ver se esse tipo de cenário será gerado ou não.Então, já que eles identificaram três parâmetros ou três variáveis que podem realmentecausar um erro do oponente, eles poderiam ter testado essas condições para garantir que essa vontadenão cause um problema. Mas infelizmente exatamente uma dessas variáveis resultou em um erro de opere dee que realmente causou o problema em todo o lançamento, o veículo foidestruído por aquela simples questão e mais tarde em quando eles alteraram que um e então elesidentificaram a razão da falha, eles poderiam corrigí-lo com muita facilidade e então resolveu o problema.Mas se houve um teste adequado o qual realmente examinou o cenário particular, em queestas três variáveis podem resultar em um erro de opere; então essa falha poderia ter sidoeliminada. Então, isso novamente mostra a importância de um teste de aceitação no sistema eidentificando todos os cenários possíveis de desenvolver um erro. E então certificando-se de queo teste de aceitação realmente garantiu que tais erros não acontecerão e ele realmentese qualifica através deste teste de aceitação. Assim, uma vez que é qualificado então o sistema está pronto para a implementação.
(Consulte O Tempo De Deslizamento: 26:20)
Então, nas últimas três palestras discutimos sobre a integração e a qualificação do sistemae aqui mencionamos isso, temos vários estágios na integração do sistema. Então, nóscomeçamos com os subsistemas e depois componentes e depois subsistema. Em seguida, as interfaces, nóscomeçamos a integrá-las e existem diferentes métodos de integração, o sistema que ébasicamente, a abordagem de baixo para cima, abordagem top down, então big bang approach; assim, nóspodemos usar qualquer um desses métodos para integrar o sistema.similarmente, discutimos sobre as estratégias de qualificação basicamente a validação,verificação e aceitação. Por isso, validação e verificação são basicamente realizadas poros designers do sistema e o teste de aceitação é basicamente realizado pelos usuários com a ajudados designers. Assim, os designers identificarão a tarefa a ser testada e os cenáriosa serem testados e, em seguida, os usuários serão solicitados a testá-los e então com base no; paradeterminado valor de limite, o sistema será aceito.Então, os usuários possuem diferentes opções; após o teste podem realmente aceitar o sistema oupodem aceitá-lo com algumas alterações ou podem rejeitar o sistema. Em alguns casos ealguns casos especiais, os usuários serão forçados a aceitar o sistema mesmo que haja alguns errosporque o sistema existente está dando muitos problemas. Então, eles querem evitar esses problemase então você continua a; eles querem novo sistema, apenas para escapar dos errosdo sistema anterior. Essas são as opções para os usuários e depois discutimos
sobre os procedimentos de teste de aceitação nos procedimentos de testes de usabilidade. E então nósvimos poucos estudos de caso, onde falhas no teste de aceitação causaram a falha do sistema.Então, estes foram os tópicos que discutimos nas três últimas palestras e como mencionei nas palestras anteriores do, portanto, esta é a última etapa do processo de design que as seis funções do processo de design. Então, se completamos esses então realmente para cada ciclo de vida, temos quecompletar essas seis funções do processo de design. Nas próximas palestras, vamosdiscutir sobre poucos tópicos complementares que são realmente úteis no design do sistema. Então,antes de ir para os tópicos complementares; vou levar poucos estudos de caso ou poucos sistemaexemplos de design para mostrá-lo; como realmente utilizamos os princípios, o que aprendemosem um cenário real ou cenário real de design de sistema e como ir em uma forma sistemática deprojetar o sistema.Então, eu vou levar três estudos de caso e explicaremos o procedimento e não estaremos entrando emos detalhes de cada etapa, mas estarei dando uma visão geral de como os princípiospodem ser usados no design do sistema.(Consulte o Tempo do slide: 29:04)
E depois disso, estaremos indo para os outros tópicos complementares, como modelagem gráficae métodos de modelagem, análise de decisão; tomada de decisão e ferramentas de análise de decisão.Então vamos olhar a confiabilidade do sistema; como projetar o sistema para a confiabilidade. Da mesma forma, como evitar as falhas no sistema? Como incorporamos a análise de falhas dono design do sistema? E similarmente olhamos para alguns dos estatísticos
ferramentas que podem ser usadas no design do sistema como design de experimentos e outros métodos.Para iniciar com, iremos para os exemplos de design do sistema; agora vou levar poucos exemplosaqui e então explicar o procedimento de um design de sistema usando o sistema padrãoprincípios de engenharia.(Consulte o Tempo do slide: 29:53)
Então, este é o primeiro exemplo para o design do sistema.(Consulte o Slide Time: 29:57)
Vamos levar o caso de um sistema de link automático, comentei sobre isso em uma das palestras anterioresenquanto explicava uma a decomposição funcional. Explicarei sobre o sistema de link auto, assim vamos analisar o detalhe deste sistema e então como realmentecomeçar com o design do sistema, com os procedimentos ou os métodos que já discutimos.O sistema de link automático é um sistema de informação para os drivers auxiliá-los na navegação esituações de emergência. Então, na verdade estamos tentando projetar um sistema que realmente possa serusado pelos motoristas ou passageiros em um carro ou em qualquer outro veículo em uma situação de emergênciaou para obter algumas outras informações sobre os aspectos de navegação.Então, se alguém está dirigindo em uma rodovia ou viajando em um longo