hoje analisaremos os aspectos de qualificaçãoexplicamos brevemente sobre a qualificação o que você quer dizer com a qualificação dee quais são os vários estágios na qualificação como validação de verificaçãoe aceitação e discutimos sobre aqueles ciclo de nível superior e o ciclo de nível inferior ou osciclos de nível superior e inferior de qualificação. Hoje, entraremos nos detalhes deste procedimento de qualificaçãoqual tipo de procedimento a ser adotado e quais são os diferentes tiposde testes de aceitação e como realmente garantir que o cliente aceite o sistema equal é o processo pelo qual podemos fazer os testes a fim de garantir que o sistemaexecute conforme os requisitos do cliente.
(Consulte O Tempo De Deslizamento: 02:12)
Então, em primeiro lugar deixe-nos recapitear o procedimento de qualificação e o que é qualificação. Assim, como nósdiscutimos, é o processo de verificar e validar o design do sistema e, em seguida, obteros stakeholders aceitação do design. Então, basicamente precisamos verificar e validar o designe garantir que ele realmente atenda aos requisitos do cliente e ele envolvea validação e aceitação de verificação.Então, como discutimos na verificação de classe anterior é basicamente verificar o sistemadesenvolvido com relação às especificações que identificamos na validação do estágio de design égarantindo que ele atende aos requisitos do cliente em termos dos conceitos e validadeou a validade do design e então a aceitação é basicamente damos ao sistema o sistema completo completo para o usuário e o usuário realiza teste de aceitação e depois aceita o sistema.Então, estes são os 3 estágios através dos quais o processo de qualificação passa e então nósprecisamos projetar o sistema de qualificação à medida que projetamos o sistema de engenharia. Por isso, o coqualificação do sistema de qualificação não pode ser projetado no final do processo embora tenhamos discutidocomo a última etapa o sistema precisa ser projetado no nível básico, quero dizer quando iniciamos o design dedo sistema de engenharia o sistema de qualificação também precisa ser desenvolvido de forma paralela queé quando projetamos um subsistema, precisamos olhar para qual é o requisito para aquele tal sistemae então como testar esse sistema e como validamos esse sistema e entãocomo fazemos um teste de aceitação para aquele sistema específico. Por isso, precisamos desenvolver o procedimento, precisamos identificar os recursos, precisamos identificar os planejamentos.
Em seguida, juntamente com o design do sistema e então esta necessidade de ser usada quando fazemos a validação ou verificação ou aceitação. Por isso, o design do sistema de qualificação precisa serfeito no início do design ou como projetamos o sistema o sistema de qualificação tambémprecisa ser projetado junto com isso e o critério de saída para integração e qualificação éaceitação do projetado pelos stakeholders. Então, esse é o critério de saída. Então, podemos dizerque o design do sistema está completo ou podemos realmente sair daquele processo específico do designapenas quando o interessado aceita o sistema.(Consulte o Tempo de Slide: 04:28)
E este discutirá de fato e novamente na última classe que estes são os vários procedimentos de validaçãoe esta é a verificação e este é o teste de aceitação.Então, fazemos o teste de aceitação neste estágio quando a integração é completa e fazemos o teste de validação deneste estágio e paralelmente desenvolvemos os sistemas de qualificação neste estágio em si desenvolvemos o sistema de qualificação e então a verificação está basicamente verificando os elementoscontra as especificações projetadas e a validade conceitual validadee requisitos de validade e validade do design todos estes precisam ser validados à medida que vamos adiantecom o processo de qualificação.
(Consulte O Tempo De Deslizamento: 05:10)
Então, antes de ir para o processo de qualificação vamos definir poucos termos que serão de interessepara os engenheiros de qualificação ou para aqueles que fazem o teste de qualificação. Então, o objetivo da qualificaçãonão é apenas encontrar falhas e falhas, mas também evitá-las e fornecerdiagnóstico abrangente sobre sua localização e causa.Então, não é só que apenas identificamos as falhas e falhas que precisamos para garantir que nósidentifique a origem dessas falhas, bem como fornecemos algum tipo de entradas para os designerspara garantir que tais falhas ocorram no design. Assim, como fazemos o teste nósgarantimos que podemos identificar as falhas e falhas e podemos identificar a localização das falhastambém podemos realmente sugerir métodos para evitar essas falhas também. Assim, se vocêidentificar o local que podemos realmente ver a partir de se o que é a origem desse erro eentão uma vez que conhecemos a origem do erro podemos fazer um redesenho do sistema. Então, que ostais falhas possam ser eliminadas, os engenheiros de qualificação ou aqueles que estão fazendo a verificação ou validação. Então, eles têm a responsabilidade de identificar as fontes assim como paraajudam os designers.Para evitar tais falhas, apenas recapitaremos o termo normalmente usamos quando discutimos sobre as falhas deque são as falhas no sistema. Então, o fracasso é basicamente um desvio de comportamentoentre o sistema e sua exigência. Então, temos alguns requisitos de comportamento no sistemae quando o sistema não está fornecendo esse comportamento então chamamos de que é um erro de falhaé um subconjunto do estado do sistema que pode levar a uma falha. Então, o sistema de um sistema se ele é
a temperatura a pressão ou o seu tempo de processamento ou a capacidade de processamento qualquer um destesparâmetros que é um subconjunto do estado do sistema. Então, isso pode realmente causar um fracasso. Então,que é um erro e falha são os defeitos no sistema que podem causar um erro.Então, ele é uma basicamente uma falha no sistema causa um erro e este erro conduz uma falha do sistema. Então, para ter um sistema de qualificação de sucesso vários procedimentos complementaresa serem empregados; assim, se você usar 1 ou 2 métodos que sozinhos não irão isso ajudar você a identificar todas asas falhas. Sendo assim, um procedimento pode identificar as falhas nos cenários operacionais umoutro método pode identificar as falhas nos sistemas internos ou nas interfaces. Assim, não hánenhum teste único que possa identificar de fato todas as falhas do sistema e, portanto, precisamosidentificar procedimentos diferentes ou procedimentos de teste ou procedimentos de verificação diferentes quaissão elogiosos. Assim, que a maioria das falhas pode ser identificada. Então, esse é o requisitoaqui precisamos ter muitos testes; assim, muitos procedimentos que são complementares a cadaoutros que podem identificar a maioria das falhas no sistema que podem realmente impedir as falhas dedo sistema.(Consulte o Tempo de Slide: 08:00)
Então, para fazer isso existem muitos métodos empregados por diversos engenheiros do sistema evários métodos de desenvolvimento do sistema, mas é a comunidade de software que realmente colocou osprocedimentos e regras mais abrangentes para testes de sistemas de sistemas de engenhariasistemas, mas algumas dessas regras podem realmente ser implementadas ou podem ser adotadas para o
Os sistemas de engenharia também basicamente existem 3 leis em testes de software ou softwaresprocedimentos de qualificação.Se isso pode realmente ser usado na análise do sistema de engenharia também porque os muitos dos procedimentossão comuns à engenharia de software assim como a engenharia do sistema aprimeira lei é conhecida como paradoxo do pesticida que realmente afirma que todo método que você usa paraprevinem uma falha de bug no caso de sistema de engenharia. Assim, todo método que você usa para prevenirsua falha deixa um resíduo de falhas de subtler; isso significa, sempre que você usa um determinado métodopara evitar uma falha que realmente traz em outra falha no sistema o qual não pode ser identificadousando o método presente. Por isso, sempre que introduzir um novo método para evitar uma falha asfalhas associadas a esse novo método não podem ser identificadas nessa fase. Então, isso é conhecido comoo paradoxo do pesticida. Então, você não pode realmente garantir que por simplesmente.Ao remover um bug você está realmente eliminando um todos os bugs porque isso a falha podevir por causa do novo método também essa é a primeira lei do teste de software de primeira portaque é conhecida como paradoxo pesticida a segunda lei é conhecida como a barreira da complexidade;esta na verdade afirma que a complexidade de bugs ou as falhas cresce até os limites da nossa capacidadede gerenciar essa complexidade. Por isso, como somos mais e mais capazes de resolver uma complexidadeentão a complexidade da falha também vai continuar aumentando. Então, isso é conhecido comoa barreira da complexidade a terceira lei é que o código migra para dados estes realmente afirma queo hardware e as pessoas migram para um software que eventualmente migra para os dados.Então, inicialmente se algo é feito pelo hardware ou algo pelo humano; este realmenteirá lentamente com a migração para o software. Assim, tentaremos substitua-lo por software e, em seguida,o software irá substituirá-lo pelos dados reais. Então, esse é o código migra para dados. Por isso,sempre que será planejado para a qualificação ou teste do sistema de engenharia precisamosgarantir que estes são os fatos que realmente limita nossa capacidade de fazer o teste. Por isso,sempre que tentamos empregar um novo método de evitar falhas que realmente podem trazer outra falhaque não pode ser identificada por esse método. Por isso, precisamos ser cuidadosos enquanto introduzimos um métodopara remover sua falha. Por isso, devemos observar a importância dessa falha é uma frequênciada falha.Então decidimos se introduzimos um outro método para evitar essa falha porque esse novo métodopode trazer outra falha que não pode ser identificada por aquele método específico similarmentea complexidade da falha também continuará aumentando à medida que somos mais capazes de resolver o
problema a complexidade também se mantém em aumentar e então há uma migração de hardwaresoftware extra para dados. Então, nossos algoritmos ou os métodos devem ser capazes de levar isso para a contaquando fazemos o teste dos sistemas de engenharia, então novamente quando fazemos a verificação dodo sistema. Por isso, como sabemos a verificação é um dos estágios mais fáceis da qualificação. Então, temos validação de verificação e aceitação. Sendo assim, a verificação é uma daso método mais fácil ou parte mais fácil do procedimento de qualificação. Por isso, aqui novamente há umapoucas barreiras.Porque a verificação é basicamente nós olhamos para a especificação do design e depois vemosse o sistema real ou o componente real atende a essa especificação quando o problemaaqui é que nunca podemos ter certeza de que as especificações estão corretas. Então, a especificação podeestar errada. Por isso, a especificação qualquer que fizemos a especificação não precisa ser semprecorreta, mas sempre temos que ir assumindo que as verificações estão corretas e fazer o teste de verificação de teste específico, mas eles não estão corretos sempre.(Consulte o Tempo de Slide: 12:07)
E agora sistema de verificação pode verificar cada programa correto. Por isso, não há um sistema de verificaçãoque possa verificar todo programa correto.Você precisa ter procedimentos diferentes ou métodos diferentes para fazer a verificação de um programa completoou um método pode não garantir que ele esteja completamente correto e então podemosnunca ter certeza de que um sistema de verificação está correto. Por isso, novamente não há garantia de que o sistema de verificaçãoesteja sempre correto. Então, essas são as barreiras na verificação que nunca é nós
faça uma verificação na verdade temos algumas suposições e temos algumas limitações. Então, dentro deessa limitação só nós estamos fazendo a verificação. Então, isso mostra que o nível de confiança deo engenheiro de verificação dependendo de que medida podemos assegurar que as especificações sãocorretas para a ação possível e o sistema a maior parte de lá são diferentesmétodos complementares ele usa para garantir que todos os aspectos do sistema sejam testados ouverificados.E similarmente, se o sistema de verificação como o bem é o sistema de verificação. Então,com base neste nível de confiança só podemos dizer que a verificação está completa ou a verificaçãoestá à altura das expectativas dos engenheiros de design. Então, essas são as barreiras na verificação, mas então antes de discutirmos sobre os métodos.(Consulte o Tempo do slide: 13:27)
Precisamos definir alguns termos sobre a categorização de falhas também. Então, existem diferentes tiposde falhas acontecendo no sistema. Por isso, algumas das falhas são muito sever algumas delas não sãomuito sever, mas algumas delas precisa de atenção algumas delas podem ser deixadas como tal porque podenão causar nenhum outro problema no sistema. Assim, a categorização de falhas é o primeiro passo emdefinindo a importância das falhas. Então, se você tem se deseja categorizar a falha no emtermos da importância.Então, o quão importante é essa falha particular é precisamos categorizá-los em várias categoriase essas categorias definiram distinções entre as consequências de falhas. Assim, as categoriaspodem realmente dar a distinção sobre as consequências dessas falhas. Então, alguns dos
categorização ou a taxonomia das falhas aqui; portanto, uma leve falha é algo que poderealmente ser descartado o que realmente diz que realmente não precisamos olhar para aquela falha particularporque é um bem suave como a cor não é adequada ou não há um acabamento uniforme de superfícieou há um pequeno arranhão no sistema. Então, estes são conhecidos como a pequena falha quepodem realmente ser descartados porque são criados qualquer problema adicional no sistema, mas entãotemos uma falha moderada que não está clara ou enganosa ou um menu errado.Então, uma vez que você dê uma entrada ela está dando uma saída diferente que não está relacionada com a entrada que nósestamos dando ou os menus não estão devidamente dados. Assim, um menu não está levando a outro ouo; quaisquer que funções recorrentes não estejam fornecendo no cardápio. Então, estes são conhecidos comofalhas moderadas, isto na verdade pode ser um problema, mas novamente você não precisa investir muitomuito nesse tipo de erros moderados moderados há falhas querealmente dão irritação aos usuários basicamente, ele está procurando por algo alguns dados e ele estárecebendo alguns outros dados ou ele está demorando demais para processar ou esse menu não está devidamente umvindo ou que não é visível corretamente. Então, esses são irritantes tipos de falhas que precisamser evitadas porque os usuários podem não gostar de ter esse tipo de falhas.Mas novamente estes não vão criar nenhum grande problema no desempenho do sistema porqueo sistema pode estar se apresentando, mas ele pode não estar se apresentando como a conveniência do usuário ouo usuário pode não gostar de ter esse tipo de falhas porque isso realmente o irrita e ele éusando o sistema. Então, novamente isso; esta necessidade de ser eliminada o máximo possível o próximo éconhecido como o tipo perturbador de falhas. Então, isso na verdade recusaremos transação legítima.Então, se você tem uma transação legítima você tem uma autoridade adequada para entrar naquele sistemae então realizar alguma transação então sistema não está permitindo que você esteja dando alguns erros.Então, este é um tipo de falha perturbadora que novamente não é aceitável.Próximo nível é grave falhas isto é realmente perde a faixa de saída de entrada. Então, na verdade elenão sabe o que realmente transagiu no sistema. Então, que tipo de insumos foi dado e o que a saídafoi dada e que é algo como em um caixa eletrônico, você depositou algum dinheiro não écontabilizados na sua conta ou não sabe para onde o dinheiro foi embora. Então, esse tipo de situação deé uma falha grave no sistema então novamente o nível seguinte é uma transação muito sériauma falha muito grave que realmente diz que pode haver mistura de entradas e saídas. Por isso,uma pessoa deposita dinheiro em uma conta e que o dinheiro vai para alguma outra conta eo dinheiro é retirado de sua conta por causa de outra pessoa retirar o dinheiro. Então,esse tipo de incompatibilidade de saída de entrada e isso é uma falha muito grave.
Que precisam ser abordados a qualquer custo então novamente existem falhas extremas onde realmente issofalhas muito graves estão acontecendo com frequência que é esse tipo de situação é uma condição extremase freqüentes falhas de categoria muito grave. Então, falhas de categoria gravíssimasestão acontecendo com muita frequência, então é uma situação de falha extrema, então há falhas deintoleráveis o que de fato causa corrupção de dados irrecuperáveis a longo prazo. Então, isso na verdadeintolerável porque na verdade você pode fazer com que todo o sistema em ou um período detempo todo os dados possam estar corrompidos ou eles perderem a pista do que realmente aconteceu. Então,esse tipo de erros de longo prazo não deve estar lá e esse tipo intolerável de falhas.(Consulte o Tempo de Slide: 17:55)
E novamente considerando a seriedade da questão há catastróficas; falhas catastróficasque na verdade o shutdown do sistema causando perda de dados.Então, ele realmente causa uma perda de dados para o sistema completo porque ele vai encerrar o sistema todoe então muitos dados são perdidos sem nenhum traço do que aconteceu. Então, esse tipo de situaçãoé o; uma falha catastrófica e a última é a falha infecciosa de falha infecciosa éque não é apenas o sistema que todo o sistema está associado a esse sistema também está ficandocorrompido. Então, essa é uma situação muito grave suas conhecidas como falhas infecciosas. Então, com base na segurançadessas falhas podemos realmente classificá-las sob várias categorias elas iniciandode leve a situações catastróficas e infecciosas. Então, é dever dos engenheiros da qualificaçãoidentificar essas falhas e categorizá-las que tipo de falha é se ele é ummuito suave ou se é um infectologista.
Então, assim, eles precisam observar a importância dessas falhas e, em seguida, identificar asações necessárias a serem tomadas embora precisem olhar para a origem desses erros e então descobriro ou sugerir aos engenheiros de design os procedimentos ou como realmente um eliminá-los. Por isso,se você puder desenvolver os métodos e procedimentos para identificar todos esses tipos de falhas de mildpara o infeccioso dependendo da gravidade da falha e então tentar eliminá-los que éo trabalho dos engenheiros de qualificação basicamente eles irão aperfeiçoar os engenheiros irão desenvolveros procedimentos para identificar todas essas falhas e categorizá-las e, em seguida, reportá-las aos engenheiros de design. Então, que os engenheiros de design possam de fato olhar para o sistema e depois ir paraum redesenho do sistema.Novamente por olhar para a importância das falhas podemos realmente descobrir a medida deimportância dependendo da frequência da falha acontecendo bem como a gravidade da situaçãoou o ambiente em que essas falhas particulares estão acontecendo. Então, um método de uma medida de quantidadeda importância do tipo de falha é dado aqui,
Ii= ∑j= 1JV j PijCijonde eu tenho a importância do tipo de falha e para a I ésimo defeito no j. º cenário. Então,Pij a probabilidade da falha eu acontecer em um cenário j e Cij é o custo defalha em culpa i no j á cenário em termos de rupees.Então, se você pode realmente converter esse custo dessa falha em particular se for um leve para o custo serámenos, mas se for uma falha muito sever então o custo será muito alto. Então, se podemos realmenteconverter isso em rúpias então podemos dizer que o Cij é o custo de culpa i no j o cenárioe V jé a medida relativa de importância desse cenário.Então, se você tem vários cenários em que a falha está acontecendo. Por isso, podemos realmente dara medida relativa de importância do cenário em alguns cenários pode ser muito importante algunspodem não ser importantes. Então, V j
dá o valor relativo dessa importância. Então, o realmente
importância do tipo de falha pode ser obtida como
∑j= 1JV jPijCijEntão,
Pij é a probabilidade Cij é o custo e V j
é a medida relativa. Então, se você temuma determinada falha acontecendo então vários cenários e se você sabe o custo dessafalha específica assim como a probabilidade da tal falha assim como a medida da importânciadesse cenário podemos descobrir qual é a importância desse tipo de falha e estejuntamente com o imposto para taxonomia discutido anteriormente será capaz de categorizar essas falhas emtermos de se ele é muito severo e então precisamos olhar para procedimentos para eliminá-los oupodemos realmente simplesmente deixá-lo assim porque ele não está causando nenhum problema.Então, este é o modo como as falhas são categorizadas e então como fazemos a análise das falhas decom base na probabilidade de falha assim como o custo da falha e a importância dos cenáriosagora nos deixe analisar os métodos e procedimentos para fazer o planejamento da qualificação.(Consulte o Tempo do slide: 21:59)
Então, como mencionei a estratégia de qualificação precisa ser planejada durante o próprio estágio de design.Então, há 4 grandes níveis de planejamento de qualificação um é o processo de qualificação você planejao plano de qualificação planeja as abordagens de qualificação e você planeja as atividades de qualificaçãoe então planejar teste específico.Então, estas são as 4 atividades a serem realizadas no planejamento de qualificação como se sabe oprimeiro é o processo de qualificação este é o primeiro nível de design da qualificaçãoplanejando onde.
(Consulte O Tempo De Deslizamento: 22:32)
Nós olhamos para os vários aspectos da qualificação basicamente precisamos fazer o teste de aceitaçãoteste de validação e teste de verificação e todos estes 4 estágios olhamos para os estes 3 testes a seremrealizados na qualificação e planejamos para estes 3 testes em todos os 4 estágios o que nósdiscutiamos. Então, esse é o planejamento do processo de qualificação no planejamento do processo de qualificação, olhamos para os objetivos do sistema identificamos quais são os requisitos identificados emos objetivos do sistema que é uma das palestras anteriores discutimos como identificar os objetivos do sistemae então utilizar esses objetivos para definir os requisitos do sistema também nósolhamos para a hierarquia dos objetivos.Então, no planejamento de qualificação também precisamos começar com os objetivos do sistema. Então, o quena verdade o sistema deveria alcançar e baseado nisso só nós vamos olhar para os objetivospara sermos um necessário e então esses objetivos se tornam novamente uma linha base para o processo de qualificaçãotambém. Então, olhamos para os objetivos do sistema e então identificamos a qualificaçãosistema objetivo do sistema mais parecido com um objetivo de desempenho. Assim, com base no objetivo de desempenhoolhamos para o objetivo do sistema de qualificação.Então, eles estarão diretamente relacionados porque o sistema de qualificação deve realmente garantir queos objetivos de desempenho sejam atendidos e, portanto, os objetivos de qualificação precisam serdesenvolvidos a partir dos objetivos do sistema, então precisamos olhar para o limite de falhas de passagem para cada testeporque precisamos realizar muitos testes como teste de validação de teste de aceitação e teste de verificaçãoe precisamos observar o que são o limite de falhas de passagem para estes testes. Então, nós
não pode ter um valor muito baixo para o limite. Então, se você colocar um valor muito baixo para os limitesentão esse teste se torna não realmente útil, mas se você colocar um limite muito alto entãoo que acontece é que você pode achar que a maioria dos testes o sistema não conseguirá passaro teste também.Então, um dos principais requisitos aqui é observar os objetivos os objetivos do sistema e os objetivos de qualificaçãoe então decidir sobre um valor para este limite o limite de fail passpara cada um e então baseado em que vamos para a qualificaçãorequisitos que é como qualquer outro processo de design de sistema observamos os requisitos da qualificaçãoe depois a arquitetura funcional para a qualificação quais são as funçõesprecisam ser fornecidas quais são as funções de nível superior e quais funções subdural são necessáriasentão vamos para o desenvolvimento de arquitetura física e depois identificamos riscos e mitigaçõesestratégias. Então, quais são os riscos envolvidos nesses processos e como na verdadesuperamos esses riscos e então criamos um plano de qualificação de mestrado.Então, ao final do processo de planejamento de qualificação estaremos obtendo um plano de qualificaçãoque pode realmente ser empregado para o todo o design. Assim, inicialmente olhando para os objetivos do sistemavamos desenvolver os objetivos de qualificação e depois com base nos objetivos de qualificação.Nós decidimos sobre os valores de limite para diferentes teste e então identificamos os requisitos de qualificaçãoe a partir daí olhamos para a arquitetura funcional e física e finalmente,estaremos obtendo o plano de qualificação que é um documento de plano de qualificação principal e este documentoserá o documento principal para todos os tipos de atividades de qualificação. Então, essa é a primeira funçãono plano de planejamento de qualificação o processo de qualificação.
(Consulte O Tempo De Deslizamento: 25:59)
O próximo está planejando as abordagens de qualificação e novamente isso foi feito para todos os tipos de3 tipos de uma validação e verificação de aceitação de teste. Por isso, aqui nessa abordagem vamos tentaridentificar os recursos e as organizações.Então o atribuir as atividades de qualificação às organizações atribuem atividades de qualificação arecursos e desenvolverá programações de qualificação coerentes com os planejamentos de desenvolvimento. Então,este é o planejamento da abordagem de qualificação. Por isso, aqui tentamos identificar todos os recursosnecessários para a qualificação. Por isso, precisamos realizar vários testes e para isso vários testes nósprecisamos ter vários recursos e precisar identificar a infraestrutura disponível e as pessoasque são capazes de fazer esses testes se o teste pode ser feito em house podemos realmente identificarse alguns equipamentos a serem adquiridos que estão planejados ou existem algumas instalações padrão de testesdisponíveis se o teste pode ser realizado. Então, isso também precisa ser planejado.Então, essa é a primeira etapa que você identifica as organizações e atividades e atribui essas atividadesa diversos recursos e, em seguida, desenvolve os planejamentos consistentes com o cronograma de desenvolvimento. Por isso, aqui vai ter vários horários para a atividade de design como nósum planejado para o design temos o design de nível de componente e depois algum design de nível de sistemae. Então, junto com isso em consonância com aqueles planejamentos precisamos ter o cronograma de qualificaçãotambém; por exemplo, se você quiser verificar os componentes. Assim, quando umcomponente em particular é disponibilado conforme o planejamento então o cronograma de qualificaçãotambém deve combinar com esse componente de forma semelhante quando esse componente está indo para um
a integração a verificação desse subsistema integrado precisa ser realizada e o subsistemaestá pronto.Então, o planejamento seja o que desenvolvemos para a qualificação deve inconsistente com as atividades do designe isso deve ser garantido na evolução da abordagem de qualificação ou no planejamento da abordagem de qualificação. Então, essas são as diversas atividades realizadas na abordagemde qualificação.(Consulte o Tempo do slide: 27:59)
O próximo está planejando as atividades na verdade. Então, como de fato realizamos realizar essas atividades. Assim, desenvolver requisitos de qualificação detalhados e derivados escrevem ativamente os planos de qualificaçãoe atribuem responsabilidades de qualificação. Então, estes estão realmente planejandoas atividades reais. Então, nós encontramos os requisitos de qualificação detalhada e derivada. Então,há talvez diferentes requisitos a partir do requisito principal pode haver alguns requisitosderivados.Então, entramos nos detalhes. Por isso, no terceiro nível entramos nos detalhes se observamos ositens de configuração de itens individuais e componentes e, em seguida, identificamos os planos detalhados paracada componente. Assim, se você tem um componente em particular identificado no design você tem queolhar para o que é aquele componente em particular e que tipo de requisitos existem para este componentese precisamos ter alguma fixação específica ou especializada para montá-lo eentão fazer o teste ou quaisquer recursos especializados são necessários ou instalações especializadas são necessáriaspara aquele componente específico. Então, esse tipo de planejamento detalhado será feito no terceiro
função que são as atividades de qualificação. Assim, para cada componente e subsistema, olhamospara os detalhes.(Consulte o Tempo de Slide: 29:07)
E então desenvolver as atividades de qualificação e a quarta é basicamente o teste específico.