Banco público de questões

Questões para Concursos

Pesquise questões reais por disciplina, assunto, tópico, banca, órgão, cargo, ano e modalidade.

Questões por banca

29 bancas disponíveis. Clique para visualizar todas.

Acesse diretamente as bancas disponíveis na QuestLab. As quantidades abaixo consideram as questões ativas do banco.

CEBRASPE 51.363 questões FGV 25.316 questões FCC 24.632 questões AOCP 23.456 questões IBFC 11.190 questões VUNESP 10.983 questões Instituto Quadrix 9.793 questões FUNDATEC 9.088 questões IBADE 7.820 questões CESGRANRIO 6.013 questões OBJETIVA 4.740 questões CONSULPLAN 4.174 questões FEPESE 3.585 questões IADES 3.439 questões IESES 2.627 questões SELECON 2.377 questões IDECAN 1.907 questões MS CONCURSOS 1.485 questões Instituto Legalle 1.281 questões FAFIPA 1.161 questões FUMARC 842 questões ACAFE 551 questões INSTITUTO AOCP 430 questões NUCEPE 378 questões FUNIVERSA 348 questões FAURGS 203 questões FIOCRUZ 48 questões MACKENZIE 48 questões CETRO 17 questões

Encontre as questões que procura

Palavra-chave

Disciplina

Assunto

Tópico

Banca

Órgão

Ano

Cargo

Modalidade

Limpar filtros

204 questões encontradas

ID 168754 Tecnologia da Informação Engenharia de Software FCC 2016

Considere:

I. Uma Especificação de Requisitos que reflete todas as decisões que foram tomadas e não contém cláusulas de pendências. Desta forma, contém todos os requisitos significativos relativos a funcionalidade, desempenho, restrições de desenho, atributos e interfaces externas, além de definir as respostas do software para todas as entradas possíveis, válidas e inválidas, em todas as situações possíveis.

II. Uma Especificação de Requisitos em que todo requisito presente possui apenas uma única interpretação, aceita tanto pelos desenvolvedores quanto pelos usuários chaves. Em particular, ela é compreensível para todo o seu público alvo e é suficiente para a especificação dos testes de aceitação do produto.

Os itens I e II descrevem especificações cujos requisitos contemplam, respectivamente, as qualidades

A rastreabilidade e consistência.

B completeza e precisão.

C correção e completeza.

D consistência e priorização.

E verificabilidade e precisão.

ID 168749 Tecnologia da Informação Engenharia de Software FCC 2016

Considere a figura abaixo.
Pelas características apresentadas na figura, este processo de software

A é uma metodologia ágil para grandes equipes que desenvolvem software baseado em requisitos precisos, que pouco se
modificam, e na qual o cliente não atua diretamente.

B é adequado para projetos nos quais as versões devem ser entregues a cada mês, ou no máximo a cada seis meses,
aumentando a possibilidade de feedback rápido do cliente.

C mantém as funcionalidades a serem implementadas em uma lista denominada Product Backlog ou Pacote de Trabalho. Na
reunião de planejamento o Product Owner prioriza os itens dos Pacotes de Trabalho.

D mantém as funcionalidades a serem implementadas em uma lista denominada Product Backlog ou Pacote de Trabalho. Na
reunião de planejamento o Product Owner prioriza os itens dos Pacotes de Trabalho.

E é conhecido como TDD − Test Driven Development e sua principal característica é que o código é comunitário, não
pertencendo a um único desenvolvedor.

ID 168734 Tecnologia da Informação Engenharia de Software FCC 2016

Existem no SVN três diretórios especiais com funções bem definidas. O primeiro deles é o trunk, que armazena a versão
funcional mais recente de desenvolvimento. Os outros são:

I. armazena versões de desenvolvimento paralelo oriundas do trunk, porém isoladas deste. Deve ser utilizado quando uma
implementação oferecer risco de afetar a integridade do trunk.

II. armazena rótulos para facilitar a localização de revisões. Cada rótulo possui um nome único que a identifica, sendo criada
como um diretório, sempre através do trunk.

Os diretórios I e II são, correta e respectivamente,

A working_copy − labels.

B heads − labels.

C repository − branches.

D repository − working_copy.

E branches − tags.

ID 168497 Tecnologia da Informação Engenharia de Software FCC 2016

Atualmente os softwares podem ser desenvolvidos utilizando-se métodos ágeis ou métodos tradicionais. A escolha da metodologia
mais adequada vai depender de vários fatores, como por exemplo, a característica de projeto, da empresa ou da gestão.
Para fazer a escolha correta, é necessário ainda conhecer as características dos principais métodos e modelos de processo de
desenvolvimento de software. Sobre estes métodos e modelos de processo é correto afirmar:

A As metodologias ágeis são indicadas principalmente em casos em que os requisitos são bem compreendidos e provavelmente
não sofrerão grandes alterações durante o desenvolvimento do sistema.

B Os diagramas de Caso de Uso da UML são utilizados intensamente na fase de Elaboração do Rational Unified Process −
RUP para criar um modelo de requisitos para o sistema.

C Nos modelos em cascata os testes são desenvolvidos paralelamente aos requisitos, antes de iniciar o desenvolvimento,
ajudando testadores e desenvolvedores a compreenderem os requisitos.

D No Rational Unified Process − RUP o cliente participa do processo de desenvolvimento discutindo cenários com a equipe
para gerar os cartões de estórias, que englobam as necessidades do cliente.

E Sprinter e programação em pares são práticas descritas e amplamente utilizadas na eXtreme Programming − XP para
agilizar o processo de desenvolvimento e reduzir a possibilidade de erros.

ID 168096 Tecnologia da Informação Engenharia de Software FCC 2016

Considere que um Analista de Sistemas sugeriu a implementação de um novo projeto com base em um processo de software
que organiza suas iterações em quatro fases principais:

[1] Concepção: levantar, de forma genérica e pouco precisa, o escopo do projeto. O objetivo é ter uma visão inicial do
problema, estimar esforço e prazos e determinar se o projeto é viável e merece uma análise mais profunda.

[2] Elaboração: levantar todos, ou a maior parte dos requisitos. Em uma primeira iteração alguns requisitos, de maior risco e
valor arquitetural, são especificados em detalhes, implementados e servem como base de avaliação junto ao usuário e
desenvolvedores para o planejamento da próxima iteração. Ao fim da fase, 90% dos requisitos devem ter sido levantados
em detalhes, o núcleo do sistema deve ter sido implementado com alta qualidade, os principais riscos devem ter sido
tratados, podendo-se fazer estimativas mais realistas.

[3] Construção: implementar, de forma iterativa, os elementos restantes de menor risco e mais fáceis e preparação para a
implantação.

[4] Transição: realizar testes finais e implantação.

O processo de software indicado pelo Analista é o

A Baseado em Componentes.

B Desenvolvimento Concorrente.

C Rapid Application Development − RAD.

D Processo Unificado.

E Espiral.

ID 167687 Tecnologia da Informação Engenharia de Software FCC 2016

Considere o diagrama a seguir:
Trata-se de um

A processo modelado por meio da BPMN.

B modelo de atividade usando o Diagrama de Sequência da UML.

C processo de negócio modelado por meio de um fluxograma.

D Diagrama de Atividade da BPMN.

E Diagrama de Processo de Negócio d a UML.

ID 167520 Tecnologia da Informação Engenharia de Software FCC 2016

A Engenharia de Requisitos utiliza algumas técnicas que apoiam as atividades de levantamento de requisitos, sendo a entrevista
uma das mais utilizadas. Uma entrevista pode ser estruturada de formas diferentes, como na estrutura em

A diamante, que envolve sessões de workshop com os usuários os quais assumem papéis de documentadores, escrevendo
os requisitos em flipcharts.

B brainstorming, em que inicia-se com perguntas mais genéricas sobre o sistema e finaliza-se com perguntas mais específicas,
sendo geralmente utilizada com usuários que desconhecem o assunto.

C funil, na qual procura-se manter o usuário interessado no assunto e para isto utilizam-se perguntas variadas sobre o
sistema, sorteadas com um dado.

D diamante, na qual os usuários escrevem os requisitos em papel, todos ao mesmo tempo, em uma tempestade de ideias,
para estimular requisitos criativos.

E pirâmide, em que inicia-se com perguntas mais específicas sobre o sistema e finaliza-se com perguntas mais genéricas,
sendo geralmente utilizada com usuários mais relutantes.

ID 167350 Tecnologia da Informação Engenharia de Software FCC 2016

Um profissional de TI da Eletrosul está utilizando uma ferramenta CASE para modelagem funcional. Seu objetivo é criar um
DFD − Diagrama de Fluxo de Dados. Para isso ele deve usar

A um DFD comportamental para apresentar uma visão clara do produto com todos os macroprocessos, entidades internas e
depósitos de dados.

B um DFD de implementação para apresentar de forma mais detalhada e mais completa as opções de implementação, incluindo
o tratamento de exceções.

C processos, que são categorias lógicas de objetos ou pessoas, para representar a origem ou destino de dados e acionar ou
receber informações. Podem ser pessoas, sistemas ou unidades departamentais.

D fluxos de dados para representar o tráfego de informações. Os fluxos envolvem processos, não sendo possível o fluxo de
entidade para entidade, de entidade para depósito de dados e de depósito de dados para depósito de dados.

E entidades para representar a transformação de fluxos de dados em uma atividade. As entidades representam os módulos
do sistema.

ID 148390 Tecnologia da Informação Engenharia de Software AOCP 2016

A engenharia de requisitos abrange sete tarefas distintas, as quais são: concepção, levantamento, elaboração, negociação, especificação, validação e gestão. Os problemas de escopo, os problemas de entendimento e os problemas de volatilidade são problemas frequentes em qual dessas tarefas?

A Especificação.

B Negociação.

C Validação.

D Levantamento.

E Gestão.

ID 148359 Tecnologia da Informação Engenharia de Software AOCP 2016

O design de software compreende a concepção, especificação e prototipação das suas partes externas e internas. Sobre essas partes, assinale a alternativa correta.

A A parte externa trata o modelo conceitual da aplicação e da interface com o usuário.

B A parte interna, apesar de mais detalhada, não trata de componentes de software e algoritmos.

C Não é importante conceituar a interface do usuário, pois isso será feito no momento da criação desta.

D O design de software deve acontecer como última atividade depois que o software estiver desenvolvido.

E O modelo conceitual trata somente da interação usuário-sistema.