Questões de Engenharia de Software - Ciclo de Vida de Software

III é base para o requisito não funcional: enviar e-mail para Deputados da Mesa Diretora conforme critérios preestabelecidos.

I é base para a regra de negócio: validação da identificação da pessoa que registra uma reclamação junto à Ouvidoria.

II é base para o requisito funcional: tempo limite para retorno do processamento de buscas.

I é base para o requisito não funcional: validação da identificação da pessoa que registra uma reclamação junto à Ouvidoria.

todas são base para a criação de regras de negócio, que são fontes para requisitos funcionais e não funcionais.

todos os pares trazem nas figuras da esquerda modelos de interface incorretos ou a serem evitados e nas figuras da
direita sua correspondente correção ou melhoria.

todos os pares trazem nas figuras da esquerda modelos de interface corretos ou mais adequados e nas figuras da direita o
modelo correspondente com algum erro ou algo a ser evitado.

todos os pares trazem modelos de interface alternativos que são adequados para representar uma mesma ideia ou
comunicação com o usuário.

no Exemplo 1, a figura da esquerda traz o modelo de interface menos indicado e a da direita seu correspondente
adequado; no Exemplo 2, a figura da esquerda traz o modelo de interface mais indicado e a da direita seu correspondente
inadequado.

no Exemplo 1, a figura da esquerda traz o modelo de interface mais indicado e a da direita seu correspondente adequado;
os Exemplos 2 e 3 trazem na esquerda o modelo incorreto ou inadequado e na direita o correspondente melhor ou mais
adequado.

generator, quando tiver a intenção de criar um ambiente que suporte a geração de um conjunto de testes depois que uma
seção do software tenha sido modificada, podendo também selecionar um subconjunto de testes de acordo com a
alteração feita.

regression, quando tiver como objetivo automatizar a reexecução de casos de teste. A reexecução pode ser aleatória,
baseada em caminho, baseada em modelo ou uma mistura destes.

harness, quando tiver como objetivo obter um ambiente controlado em que são utilizados drivers e stubs, que são
pequenos programas que interagem com o software sendo testado, fornecendo informações que o software necessita e
também recebendo informações por ele enviadas.

coverage analyzer, quando tiver como objetivo realizar a análise de resultados de testes por meio de recursos de
visualização gráfica, a fim de avaliar medidas relacionadas à confiabilidade de acordo com modelos selecionados.

reliability evaluation, quando tiver a intenção de avaliar quais e quantas entidades do gráfico de fluxo do software foram
exercitadas entre todas as exigidas pelo critério de cobertura do teste sendo realizado. A análise é realizada com base em
instrumentadores do programa que inserem sondas de gravação no código.

corretiva, evolutiva e preventiva.

adaptativa, evolutiva e corretiva.

evolutiva, adaptativa e preventiva.

adaptativa, preventiva e corretiva.

corretiva, preventiva e adaptativa.

em todas as tarefas as linguagens são interpretadas ou passam por uma fase de interpretação.

na tarefa II a linguagem é orientada a objetos e na tarefa I a linguagem não permite acesso a banco de dados.

em duas das tarefas as linguagens são normalmente interpretadas, em uma tarefa a linguagem é compilada e em uma
tarefa a linguagem baseia-se em um modelo híbrido.

na tarefa IV a linguagem é orientada a objetos e a tarefa III utiliza linguagem compilada.

em duas das tarefas as linguagens são normalmente interpretadas, em uma tarefa a linguagem baseia-se em um modelo
híbrido e em uma tarefa utiliza-se uma linguagem de marcação.