Sala de Estudos Karinoya

Qualificações · Laboratório de aprovação no IT Passport

Tecnologia de desenvolvimento

Você pode ler as perguntas e explicações em português. As aulas (artigos explicativos) estão disponíveis apenas em japonês.

Ver a versão em japonês (com aulas) →

Questão 1 | Definição de requisitos

Qual das alternativas a seguir é uma atividade realizada na definição de requisitos do desenvolvimento de sistemas?

  1. Decidir a estrutura interna de módulos e os procedimentos de processamento dos programas
  2. Corrigir falhas que ocorrem depois que o sistema entra em operação e melhorar suas funções
  3. Estudar as operações de negócio dos usuários e esclarecer as funções e o desempenho que o sistema deve oferecer
  4. Verificar cada programa concluído, um por um, para confirmar que funciona conforme os documentos de projeto
RespostaC. Estudar as operações de negócio dos usuários e esclarecer as funções e o desempenho que o sistema deve oferecer

A definição de requisitos (要件定義) é a primeira fase do desenvolvimento: organiza as solicitações dos usuários e esclarece as funções e o desempenho que o sistema deve oferecer. A alternativa A é o projeto interno (内部設計), a alternativa D é o teste unitário (単体テスト) e a alternativa B é a manutenção (保守), todas fases posteriores à definição de requisitos.

Questão 2 | Projeto externo

Qual das alternativas a seguir é o item mais adequado a ser decidido no projeto externo, também chamado de projeto básico?

  1. Procedimentos para preparar os dados de teste usados no teste de integração
  2. Padronização dos nomes de variáveis e funções de acordo com as convenções de codificação
  3. Os procedimentos internos de processamento e os algoritmos de cada módulo
  4. Os layouts das telas que os usuários operam e dos relatórios a serem impressos
RespostaD. Os layouts das telas que os usuários operam e dos relatórios a serem impressos

O projeto externo (外部設計) é a fase que decide as partes visíveis aos usuários, como telas, formulários de relatório (帳票) e troca de dados; por isso a alternativa D está correta. A alternativa C pertence ao projeto interno, a alternativa B à programação e a alternativa A à fase de testes; nenhuma delas é decidida no projeto externo.

Questão 3 | Fases de projeto

Qual das alternativas a seguir explica adequadamente a relação entre o projeto externo e o projeto interno?

  1. As especificações visíveis ao usuário decididas no projeto externo são transformadas em estruturas de programa no projeto interno
  2. O projeto externo é realizado depois de concluído o projeto interno, com base em seus resultados
  3. Tanto o projeto externo quanto o interno são fases que decidem os layouts de telas e relatórios a serem acordados com os usuários
  4. O projeto externo é conduzido principalmente pelos programadores, e o projeto interno principalmente pelos usuários
RespostaA. As especificações visíveis ao usuário decididas no projeto externo são transformadas em estruturas de programa no projeto interno

O desenvolvimento avança do projeto externo (外部設計) para o projeto interno (内部設計), transformando as especificações visíveis externamente em estruturas de módulos e procedimentos de processamento concretos. A alternativa B inverte a ordem, a alternativa C está errada porque o projeto interno não é uma fase para decidir especificações voltadas ao usuário, e a alternativa D inverte os responsáveis.

Questão 4 | Ordem das fases

Qual das alternativas a seguir é a ordem adequada em que as fases do desenvolvimento de sistemas são realizadas?

  1. Definição de requisitos, depois testes, depois projeto do sistema, depois programação
  2. Projeto do sistema, depois definição de requisitos, depois testes, depois programação
  3. Definição de requisitos, depois programação, depois projeto do sistema, depois testes
  4. Definição de requisitos, depois projeto do sistema, depois programação, depois testes
RespostaD. Definição de requisitos, depois projeto do sistema, depois programação, depois testes

O desenvolvimento avança decidindo o que construir na definição de requisitos (要件定義), decidindo como realizá-lo no projeto do sistema (システム設計), construindo na programação e verificando nos testes. Em cada uma das outras três alternativas, o projeto ou os testes aparecem antes do que deveriam, gerando sequências impossíveis, como inspecionar algo antes de construí-lo.

Questão 5 | Divisão em módulos

Qual é o principal objetivo de projetar um programa dividindo-o em vários módulos?

  1. Aumentar a independência de cada componente, facilitando a modificação, os testes e a reutilização
  2. Reduzir o número de servidores usados no ambiente de produção e diminuir os custos
  3. Reduzir o número de itens que os usuários precisam digitar e facilitar a operação
  4. Garantir a redução do número total de linhas de código-fonte do programa
RespostaA. Aumentar a independência de cada componente, facilitando a modificação, os testes e a reutilização

A divisão em módulos (モジュール分割) transforma cada função em um componente com alta independência, restringindo o impacto das alterações e facilitando os testes e a reutilização. Dividir um programa não reduz necessariamente o número total de linhas, então a alternativa D está errada; a alternativa C trata do projeto de telas e a alternativa B da configuração da infraestrutura, portanto seus objetivos são diferentes.

Questão 6 | Usabilidade

Qual das alternativas a seguir é o exemplo mais adequado de projeto de tela que melhora a usabilidade?

  1. Avisar os usuários sobre erros de entrada no mesmo instante e mostrar concretamente o que está errado e como corrigir
  2. Usar muitos termos técnicos para que apenas usuários com conhecimento consigam operar a tela
  3. Não mostrar instruções de operação na tela e explicá-las apenas em um manual separado
  4. Concentrar todos os itens de entrada em uma única tela, sem exibir nenhum título ou explicação complementar
RespostaA. Avisar os usuários sobre erros de entrada no mesmo instante e mostrar concretamente o que está errado e como corrigir

Usabilidade (ユーザビリティ) é a facilidade com que os usuários atingem seus objetivos de forma eficiente, sem se perder, e informar os erros de modo claro e imediato a melhora. As alternativas B, D e C aumentam o esforço de compreensão e operação dos usuários, reduzindo a facilidade de uso.

Questão 7 | Aceitação

Qual das alternativas a seguir descreve adequadamente a aceitação de software?

  1. Melhorar o software depois que ele entra em operação, de acordo com mudanças no negócio e solicitações dos usuários
  2. Os desenvolvedores testarem os programas que escreveram, módulo por módulo ou programa por programa
  3. O contratante confirmar o software entregue por meio de testes operacionais e similares e aceitá-lo se ele atender aos requisitos
  4. Os desenvolvedores construírem a estrutura interna e os procedimentos de processamento dos programas de acordo com os documentos de projeto
RespostaC. O contratante confirmar o software entregue por meio de testes operacionais e similares e aceitá-lo se ele atender aos requisitos

A aceitação de software (ソフトウェア受入れ) é a fase em que o contratante confirma, por meio de testes operacionais e verificações similares, que os entregáveis atendem aos requisitos antes de recebê-los; também é chamada de inspeção de aceitação (検収). A alternativa B é o teste unitário, a alternativa D é a programação e a alternativa A é a manutenção, todas fases diferentes da aceitação.

Questão 8 | Teste unitário

Qual das alternativas a seguir descreve adequadamente o teste unitário?

  1. Fazer os usuários operarem o sistema seguindo seus procedimentos reais de trabalho para verificar se ele atende aos requisitos
  2. Verificar, para cada módulo ou programa individual, se o processamento interno funciona corretamente
  3. Verificar o sistema inteiro, incluindo desempenho e tolerância à carga, em um ambiente próximo ao de produção
  4. Combinar vários módulos e verificar se os dados são transmitidos corretamente entre eles
RespostaB. Verificar, para cada módulo ou programa individual, se o processamento interno funciona corretamente

O teste unitário (単体テスト) é a primeira etapa dos testes, realizada módulo por módulo. A alternativa D descreve o teste de integração (結合テスト), a alternativa C o teste de sistema (システムテスト) e a alternativa A o teste operacional (運用テスト), que funciona como teste de aceitação; todos são realizados em etapas posteriores ao teste unitário.

Questão 9 | Teste de integração

O que é verificado principalmente no teste de integração?

  1. Se a troca de dados e a coordenação entre os módulos combinados estão corretas
  2. Se os usuários conseguem executar seu fluxo real de trabalho sem problemas
  3. Se todas as instruções e ramificações dentro de um único módulo foram executadas
  4. Se os custos de desenvolvimento permanecem dentro do orçamento original
RespostaA. Se a troca de dados e a coordenação entre os módulos combinados estão corretas

O teste de integração (結合テスト) conecta módulos que passaram no teste unitário e verifica se as interfaces (インタフェース), ou seja, a troca de dados entre eles, estão corretas. A alternativa C é o teste de caixa branca realizado durante o teste unitário, a alternativa B é o objetivo do teste operacional e a alternativa D trata do gerenciamento de custos do projeto, não de testes.

Questão 10 | Teste de sistema

Qual das alternativas a seguir descreve de forma mais adequada o que é feito no teste de sistema, também chamado de teste geral?

  1. Verificar o sistema inteiro em um ambiente próximo ao de produção, conferindo desempenho e tolerância à carga, além das funções
  2. Corrigir a indentação e as irregularidades de formatação do código-fonte com um formatador automático
  3. Adicionar como novas funções os recursos solicitados pelos usuários após a entrega
  4. Os membros lerem juntos, no papel, os módulos em desenvolvimento, um por um, para encontrar erros de escrita
RespostaA. Verificar o sistema inteiro em um ambiente próximo ao de produção, conferindo desempenho e tolerância à carga, além das funções

O teste de sistema (システムテスト) é a etapa final de testes realizada pelo lado do desenvolvimento, confirmando que o sistema inteiro funciona conforme exigido em termos de funções, desempenho, carga etc. A alternativa D é trabalho de revisão ou de teste unitário, a alternativa B é trabalho de codificação e a alternativa C é a adição de funções durante a manutenção; nenhuma se aplica.

Questão 11 | Teste operacional

Qual das alternativas a seguir descreve adequadamente o teste operacional, também chamado de teste de aceitação?

  1. Os desenvolvedores lerem os programas no papel e apontarem erros
  2. Os desenvolvedores se concentrarem na estrutura interna dos programas e verificarem exaustivamente instruções e ramificações
  3. Os desenvolvedores verificarem a coordenação entre os módulos integrados
  4. Os usuários operarem o sistema seguindo seu fluxo real de trabalho para verificar se ele atende aos requisitos
RespostaD. Os usuários operarem o sistema seguindo seu fluxo real de trabalho para verificar se ele atende aos requisitos

O teste operacional (運用テスト) é o teste final conduzido pelos usuários, ou seja, pelo contratante, para confirmar que o sistema pode ser usado nos procedimentos reais de trabalho. A alternativa B é o teste de caixa branca, a alternativa C é o teste de integração e a alternativa A é a revisão de código; todas são atividades realizadas pelos desenvolvedores, portanto tanto o responsável quanto o objetivo são diferentes.

Questão 12 | Modelo em V

No modelo em V, qual fase de teste corresponde ao projeto externo, também chamado de projeto básico?

  1. Teste unitário
  2. Teste de integração
  3. Teste de sistema
  4. Teste operacional
RespostaC. Teste de sistema

No modelo em V (V字モデル), a definição de requisitos forma par com o teste operacional, o projeto externo com o teste de sistema, o projeto interno com o teste de integração e a programação com o teste unitário. Portanto, a fase que corresponde ao projeto externo é o teste de sistema; o teste unitário corresponde à programação, o teste de integração ao projeto interno e o teste operacional à definição de requisitos.

Questão 13 | Caixa branca

Qual das alternativas a seguir descreve adequadamente o teste de caixa branca?

  1. Processar o mesmo volume de dados da produção e medir se o tempo de processamento fica dentro do padrão
  2. Teste que ignora a estrutura interna do programa e se concentra apenas na relação entre entradas e saídas mostrada nas especificações
  3. Teste que se concentra na estrutura interna do programa e cobre os caminhos de execução para que instruções e ramificações sejam executadas
  4. Fazer os usuários operarem um protótipo e incorporar suas opiniões aos requisitos
RespostaC. Teste que se concentra na estrutura interna do programa e cobre os caminhos de execução para que instruções e ramificações sejam executadas

O teste de caixa branca (ホワイトボックステスト) olha para o interior do programa, sua estrutura de controle, e elabora casos de teste que cobrem instruções e ramificações; é usado principalmente no teste unitário. A alternativa B descreve o teste de caixa preta (ブラックボックステスト), a alternativa D a prototipação e a alternativa A o teste de desempenho.

Questão 14 | Caixa preta

Qual das alternativas a seguir é uma forma adequada de criar casos de teste no teste de caixa preta?

  1. Atribuir mecanicamente um número de casos de teste proporcional ao número de linhas de código-fonte
  2. Escolher caminhos de execução de modo que cada ramificação seja executada pelo menos uma vez
  3. Verificar linha por linha se os comentários escritos pelos desenvolvedores estão corretos
  4. Dividir as condições de entrada das especificações em grupos com significado e escolher valores representativos e valores-limite de cada um
RespostaD. Dividir as condições de entrada das especificações em grupos com significado e escolher valores representativos e valores-limite de cada um

O teste de caixa preta (ブラックボックステスト) baseia-se nas especificações sem olhar para a estrutura interna, escolhendo valores representativos e valores-limite das entradas por meio do particionamento de equivalência (同値分割) e da análise de valor limite (境界値分析). A alternativa B é o teste de caixa branca, que se concentra na estrutura interna; na alternativa A, o número de linhas não serve de base para casos de teste; e a alternativa C é trabalho de revisão de código.

Questão 15 | Teste de regressão

Qual é o objetivo de realizar o teste de regressão?

  1. Confirmar que a modificação do programa não introduziu defeitos em partes que funcionavam corretamente antes da modificação
  2. Confirmar que os usuários treinados aprenderam corretamente os novos procedimentos de operação após a mudança
  3. Confirmar que o sistema tem desempenho de processamento suficiente para suportar o uso em produção
  4. Verificar apenas a parte recém-adicionada, conferindo somente se a função adicionada funciona conforme especificado
RespostaA. Confirmar que a modificação do programa não introduziu defeitos em partes que funcionavam corretamente antes da modificação

O teste de regressão (回帰テスト) verifica se funções existentes que funcionavam corretamente não foram danificadas por modificações ou recursos adicionados. A alternativa D é o teste da própria função adicionada, a alternativa C é o teste de desempenho e a alternativa B é a verificação de educação e treinamento; nenhuma delas é o objetivo do teste de regressão.

Questão 16 | Técnicas de revisão

Entre as técnicas de revisão de software, qual das alternativas a seguir descreve adequadamente uma inspeção?

  1. Uma revisão formal conduzida por um moderador, com papéis e procedimentos dos participantes definidos antecipadamente, para detectar defeitos nos entregáveis
  2. Executar de fato o programa para verificar se as saídas para determinadas entradas correspondem às especificações
  3. Duas pessoas compartilhando um terminal e se revezando para escrever o programa
  4. Uma sessão conduzida pelo autor, que apresenta o entregável aos participantes em ordem enquanto eles apontam informalmente, na hora, erros e dúvidas
RespostaA. Uma revisão formal conduzida por um moderador, com papéis e procedimentos dos participantes definidos antecipadamente, para detectar defeitos nos entregáveis

A inspeção (インスペクション) é uma revisão formal conduzida por um moderador (モデレータ), com papéis e procedimentos definidos e com registros mantidos. A alternativa D é o walkthrough (ウォークスルー), que é informal; a alternativa B é um teste que executa de fato o programa; e a alternativa C é a programação em par do XP; nenhuma delas é uma inspeção.

Questão 17 | Modelo em cascata

Qual das alternativas a seguir é uma característica adequada do modelo em cascata?

  1. Construir protótipos e consolidar os requisitos enquanto se recebem as avaliações dos usuários
  2. Avançar pelas fases em ordem e, em princípio, desenvolver sem voltar às fases anteriores
  3. Repetir iterações curtas e entregar software funcionando em cada iteração
  4. As equipes de desenvolvimento e de operações trabalharem como uma só e lançarem versões com frequência por meio da automação
RespostaB. Avançar pelas fases em ordem e, em princípio, desenvolver sem voltar às fases anteriores

O modelo em cascata (ウォーターフォールモデル) avança pelas fases em ordem, das iniciais às finais, aprovando os entregáveis de cada fase com a premissa de não voltar às fases anteriores. A alternativa C descreve o desenvolvimento ágil, a alternativa A o modelo de prototipação e a alternativa D o DevOps; cada uma é uma abordagem diferente.

Questão 18 | Prototipação

Qual é a principal vantagem de adotar o modelo de prototipação?

  1. O protótipo substitui os documentos de projeto, por isso nenhum trabalho de documentação é necessário
  2. Fazer os usuários verificarem um protótipo em uma etapa inicial reduz o retrabalho causado por divergências nos requisitos e mal-entendidos
  3. Como os usuários verificaram o protótipo, é possível garantir que nenhuma mudança de especificação ocorrerá depois que o sistema entrar em operação
  4. Construir um protótipo sempre reduz o esforço total de desenvolvimento e corta os custos pela metade
RespostaB. Fazer os usuários verificarem um protótipo em uma etapa inicial reduz o retrabalho causado por divergências nos requisitos e mal-entendidos

A prototipação (プロトタイピング) é uma técnica que evita grandes retrabalhos (手戻り) causados por requisitos mal compreendidos, fazendo os usuários avaliarem um protótipo cedo. Os documentos de projeto continuam necessários mesmo com um protótipo, por isso a alternativa A está errada; não há garantia de que o esforço sempre caia pela metade nem de que mudanças nunca ocorram, então as alternativas D e C também estão erradas.

Questão 19 | Modelo em espiral

Qual das alternativas a seguir descreve adequadamente o modelo em espiral?

  1. Concluir todas as funções em uma única passagem das fases iniciais às finais, sem nenhum retorno às fases anteriores nem revisões no meio do caminho
  2. Pular a fase de definição de requisitos, construir primeiro algo que funcione e documentar as especificações depois
  3. Terceirizar todas as fases de desenvolvimento e gerenciar o progresso apenas por meio de relatórios mensais
  4. Dividir o sistema em partes e aumentar seu grau de acabamento em espiral, repetindo um ciclo de projeto, desenvolvimento e avaliação
RespostaD. Dividir o sistema em partes e aumentar seu grau de acabamento em espiral, repetindo um ciclo de projeto, desenvolvimento e avaliação

O modelo em espiral (スパイラルモデル) divide o sistema em partes e repete um ciclo que vai do projeto à avaliação, reduzindo riscos enquanto aumenta o grau de acabamento. A alternativa A é o modo de pensar do modelo em cascata, e as alternativas B e C não têm relação com a definição do modelo em espiral.

Questão 20 | Ágil

Qual das alternativas a seguir descreve de forma mais adequada a abordagem do desenvolvimento ágil?

  1. Os usuários participarem apenas na definição de requisitos e na aceitação, sem envolvimento durante o desenvolvimento
  2. Definir todas as especificações no início e, em princípio, não permitir mudanças posteriores
  3. Construir software funcionando em iterações curtas e responder às mudanças incorporando as opiniões dos usuários
  4. Priorizar documentos de projeto detalhados e perfeitamente acabados em vez de mostrar rapidamente software funcionando
RespostaC. Construir software funcionando em iterações curtas e responder às mudanças incorporando as opiniões dos usuários

O desenvolvimento ágil (アジャイル開発) repete iterações curtas, valorizando o software funcionando e a capacidade de responder a mudanças, em colaboração com os usuários. As alternativas B, D e A são características do estilo de desenvolvimento em cascata e são o oposto da abordagem ágil.

Questão 21 | Escolha do modelo

Os requisitos ainda não estão definidos, e o plano é adicionar funções em ciclos curtos enquanto se observa a reação dos usuários. Qual das alternativas a seguir é a diretriz de desenvolvimento mais adequada para este sistema?

  1. Realizar todos os testes juntos no final e não fazer nenhuma verificação de funcionamento até lá
  2. Não iniciar o desenvolvimento até que o documento de requisitos seja aprovado e não aceitar nenhuma mudança após a aprovação
  3. Lançar funções funcionando a cada iteração curta e refletir as avaliações dos usuários na iteração seguinte
  4. Definir as especificações de todas as funções, desenvolver tudo de uma vez e mostrar aos usuários somente na conclusão
RespostaC. Lançar funções funcionando a cada iteração curta e refletir as avaliações dos usuários na iteração seguinte

Em projetos cujos requisitos mudam com facilidade, é adequado um estilo ágil (アジャイル型), que entrega algo funcionando a cada iteração e incorpora as avaliações. As alternativas D e B seguem o estilo em cascata e são frágeis diante de mudanças, e a alternativa A atrasa a descoberta de defeitos e aumenta o retrabalho, portanto nenhuma se adapta a esta situação.

Questão 22 | RAD

Qual das alternativas a seguir descreve adequadamente o RAD, Rapid Application Development (desenvolvimento rápido de aplicações)?

  1. Uma abordagem em que as equipes de desenvolvimento e de operações cooperam estreitamente e buscam a melhoria contínua por meio da automação
  2. Uma técnica para desenvolver um sistema em pouco tempo usando uma equipe pequena e ferramentas de apoio ao desenvolvimento
  3. Uma técnica para criar um novo serviço combinando vários serviços disponibilizados publicamente
  4. Uma técnica para analisar programas existentes e extrair suas especificações e informações de projeto
RespostaB. Uma técnica para desenvolver um sistema em pouco tempo usando uma equipe pequena e ferramentas de apoio ao desenvolvimento

O RAD é uma técnica que encurta o período de desenvolvimento usando uma equipe pequena e ferramentas de apoio ao desenvolvimento (開発支援ツール). A alternativa D descreve a engenharia reversa (リバースエンジニアリング), a alternativa A o DevOps e a alternativa C um mashup (マッシュアップ); cada um é um termo diferente do RAD.

Questão 23 | Programação em par

Qual das alternativas a seguir descreve adequadamente a programação em par?

  1. Duas equipes desenvolverem a mesma função separadamente e adotarem o melhor resultado após a conclusão
  2. Duas pessoas compartilharem um terminal, uma escrevendo o código enquanto a outra revisa e orienta durante o desenvolvimento
  3. Fazer dois usuários operarem a mesma tela e comparar a facilidade de uso
  4. Realizar dois tipos de teste ao mesmo tempo para encontrar defeitos mais cedo
RespostaB. Duas pessoas compartilharem um terminal, uma escrevendo o código enquanto a outra revisa e orienta durante o desenvolvimento

A programação em par (ペアプログラミング) é uma prática representativa do XP em que duas pessoas escrevem um mesmo código, elevando a qualidade com revisão feita na hora. A alternativa A é uma forma competitiva de desenvolver, a alternativa D é uma forma de realizar testes e a alternativa C é uma avaliação de usabilidade; nenhuma se aplica.

Questão 24 | TDD

Qual das alternativas a seguir é a forma adequada de avançar no desenvolvimento orientado a testes, TDD?

  1. Escrever primeiro o código de teste e depois implementar o programa de modo que os testes passem
  2. Planejar os testes pela primeira vez somente depois que toda a implementação estiver concluída
  3. Deixar os testes inteiramente a cargo de especialistas externos, sem que os desenvolvedores façam nenhum teste
  4. Criar testes pela primeira vez somente depois que os usuários relatarem falhas após a entrada em produção
RespostaA. Escrever primeiro o código de teste e depois implementar o programa de modo que os testes passem

O desenvolvimento orientado a testes (テスト駆動開発) escreve os testes primeiro, implementa o mínimo necessário para passar neles e repete as melhorias. Nas alternativas B, C e D, os testes vêm depois da implementação ou da entrada em operação, o que contraria a ideia do TDD de que os testes guiam o desenvolvimento.

Questão 25 | Refatoração

Qual das alternativas a seguir descreve adequadamente a refatoração?

  1. Reorganizar a estrutura interna de um programa para torná-la mais clara sem alterar seu comportamento visível externamente
  2. Transferir um sistema em operação para outro data center
  3. Adicionar novas funções a um programa existente em resposta a solicitações dos usuários
  4. Aumentar o número de servidores ou a quantidade de memória para elevar a velocidade de processamento
RespostaA. Reorganizar a estrutura interna de um programa para torná-la mais clara sem alterar seu comportamento visível externamente

A refatoração (リファクタリング) é o trabalho de organizar a estrutura interna do código preservando seu comportamento visível externamente, facilitando modificações futuras. A alternativa C é a adição de funções, a alternativa D é o reforço de hardware e a alternativa B é a transferência de instalações; nenhuma delas é uma melhoria da estrutura interna.

Questão 26 | Product Owner

Qual é o papel do Product Owner no Scrum?

  1. Ser responsável pelo conteúdo e pela prioridade do backlog do produto e maximizar o valor do produto
  2. Fazer a avaliação de desempenho dos membros da equipe e atribuir tarefas a cada pessoa
  3. Registrar o progresso diário e relatar à alta direção os estouros de orçamento
  4. Ajudar a garantir que as regras do Scrum sejam seguidas corretamente e remover problemas que atrapalham o desenvolvimento
RespostaA. Ser responsável pelo conteúdo e pela prioridade do backlog do produto e maximizar o valor do produto

O Product Owner (プロダクトオーナー) é o papel responsável por priorizar o que será construído. A alternativa D é o papel do Scrum Master; a alternativa B não está definida no Scrum, em que a equipe de desenvolvimento decide sua própria divisão de trabalho; e a alternativa C também não é um papel definido.

Questão 27 | Scrum Master

Qual das alternativas a seguir descreve adequadamente o papel do Scrum Master no Scrum?

  1. Ajudar a equipe a praticar o Scrum corretamente e remover problemas que atrapalham a equipe
  2. Negociar preços com os clientes e decidir as condições do contrato
  3. Dar ordens de trabalho a cada membro da equipe de desenvolvimento e gerenciá-los repreendendo quem fica para trás
  4. Decidir a prioridade dos requisitos e definir as funções a serem lançadas
RespostaA. Ajudar a equipe a praticar o Scrum corretamente e remover problemas que atrapalham a equipe

O Scrum Master (スクラムマスター) apoia a equipe na prática do Scrum e remove impedimentos. O comando e controle da alternativa C não faz parte do papel, a alternativa B é trabalho da área de vendas ou administrativa e a alternativa D é o papel do Product Owner; nenhuma delas é atribuição do Scrum Master.

Questão 28 | Termos do Scrum

Qual das alternativas a seguir descreve adequadamente a Daily Scrum no Scrum?

  1. A equipe de desenvolvimento se reúne brevemente todos os dias para compartilhar o progresso e os problemas e confirmar o trabalho do dia
  2. No final de uma sprint, os entregáveis concluídos nela são mostrados às partes interessadas para avaliação e feedback
  3. Os requisitos a serem realizados são organizados em uma lista priorizada
  4. A equipe reflete sobre sua forma de trabalhar e decide melhorias para o futuro
RespostaA. A equipe de desenvolvimento se reúne brevemente todos os dias para compartilhar o progresso e os problemas e confirmar o trabalho do dia

A Daily Scrum (デイリースクラム) é uma reunião curta de cerca de 15 minutos realizada todos os dias, com o objetivo de compartilhar o progresso e detectar impedimentos cedo. A alternativa B descreve a revisão da sprint (スプリントレビュー), a alternativa C o backlog do produto (プロダクトバックログ) e a alternativa D a retrospectiva da sprint (スプリントレトロスペクティブ); seus momentos e objetivos são diferentes.

Questão 29 | CI/CD

Qual das alternativas a seguir descreve adequadamente o CI/CD, integração contínua e entrega contínua?

  1. A equipe de operações copiar manualmente arquivos para o ambiente de produção e aplicar as mudanças uma por uma
  2. Juntar todas as mudanças em um único lote pouco antes do lançamento e executar todos os testes juntos, uma única vez, somente nesse momento
  3. Suspender novos desenvolvimentos e trabalhar apenas na manutenção da documentação dos sistemas existentes
  4. Integrar com frequência o código-fonte alterado, executar automaticamente builds e testes e automatizar o fluxo até o lançamento
RespostaD. Integrar com frequência o código-fonte alterado, executar automaticamente builds e testes e automatizar o fluxo até o lançamento

O CI/CD (継続的インテグレーション/継続的デリバリ) é uma prática que integra pequenas mudanças com frequência e automatiza build, testes e lançamento, elevando a qualidade e a velocidade de entrega. A alternativa B é a integração tradicional em bloco (big bang), que atrasa a descoberta de problemas; a alternativa A não é automatizada; e a alternativa C interrompe a própria atividade de desenvolvimento; por isso todas estão erradas.

Questão 30 | Engenharia reversa

Qual das alternativas a seguir corresponde à engenharia reversa?

  1. Usar um ambiente de desenvolvimento que permite criar aplicativos apenas posicionando componentes na tela
  2. Criar um programa com base nos documentos de projeto
  3. Criar um novo serviço combinando vários serviços disponibilizados publicamente
  4. Analisar um programa existente para extrair suas especificações e informações de projeto
RespostaD. Analisar um programa existente para extrair suas especificações e informações de projeto

A engenharia reversa (リバースエンジニアリング) consiste em analisar um software existente para extrair suas especificações e informações de projeto. A alternativa B é o desenvolvimento comum, no sentido direto, do projeto à implementação; a alternativa C é um mashup (マッシュアップ); e a alternativa A descreve o desenvolvimento no-code ou low-code (ノーコード/ローコード).

Prática: responda às perguntas desta página

Esta é uma ferramenta de prática com perguntas em ordem aleatória (funciona quando o JavaScript está ativado). Mesmo sem ela, você pode ler todas as perguntas e explicações acima.

* As explicações são informações para fins de estudo. O conteúdo e o sistema dos exames mudam de ano para ano, por isso confira sempre os comunicados oficiais da entidade organizadora.

Esta página é uma tradução do texto original em japonês. Em caso de diferença entre a tradução e o original, prevalece a versão em japonês. Esta tradução foi feita com IA e pode conter erros. Informar um erro de tradução Ver o original em japonês