Questões de Concurso Sobre engenharia de software
Foram encontradas 14.683 questões
Q476379
Engenharia de Software
Uma estratégia para teste de software pode ser vista no contexto de uma espiral, conforme ilustrado a seguir.
Em conformidade com a figura, os testes de integração, de unidade, de sistema e de validação correspondem respectivamente, aos números:
Em conformidade com a figura, os testes de integração, de unidade, de sistema e de validação correspondem respectivamente, aos números:
Q476378
Engenharia de Software
Entre os diagramas empregados na UML 2, um é utilizado desde o nível de análise até a especificação, para representar o aspecto estrutural estático de um sistema orientado a objetos. Um exemplo desse tipo de diagrama é mostrado na figura a seguir.
A figura ilustra o uso do diagrama de:
A figura ilustra o uso do diagrama de:
Q476377
Engenharia de Software
De a cordo com os princípios da UML, o desenvolvimento de um sistema deve permitir um estudo sob diversas visões, cada uma enfatizando aspectos diferentes do sistema, sendo duas delas descritas a seguir.
I. Enfatiza as características de concorrência, sincronização e desempenho do sistema.
II. Enfatiza a distribuição física do sistema em seus subsistemas e a conexão entre essas partes.
As visões I e II são denominadas, respectivamente:
I. Enfatiza as características de concorrência, sincronização e desempenho do sistema.
II. Enfatiza a distribuição física do sistema em seus subsistemas e a conexão entre essas partes.
As visões I e II são denominadas, respectivamente:
Q476376
Engenharia de Software
A “Extreme Programming (XP)” representa uma das metodologias mais utilizadas quando se trata de métodos ágeis. Dois princípios da XP são descritos a seguir.
I. Um representante do usuário final do sistema deve estar disponível em tempo integral, sendo um membro da equipe de desenvolvimento o responsável por trazer os requisitos do sistema à equipe de XP para implementação.
II. Os pares de desenvolvedores trabalham em todas as áreas do sistema, de tal maneira que não se formem ilhas de conhecimento, com todos os desenvolvedores de posse de todo o código.
Os princípios I e II são conhecidos, respectivamente, como:
I. Um representante do usuário final do sistema deve estar disponível em tempo integral, sendo um membro da equipe de desenvolvimento o responsável por trazer os requisitos do sistema à equipe de XP para implementação.
II. Os pares de desenvolvedores trabalham em todas as áreas do sistema, de tal maneira que não se formem ilhas de conhecimento, com todos os desenvolvedores de posse de todo o código.
Os princípios I e II são conhecidos, respectivamente, como:
Q476375
Engenharia de Software
A figura q seguir ilustra o processo "Extreme Programming (XP)" e mostra ideias-chave e tarefas associadas às atividades desenvolvidas, que podem ser organizadas em etapas.
As etapas I, II, III, e IV são conhecidas, respectivamente, por:
As etapas I, II, III, e IV são conhecidas, respectivamente, por:
Q476374
Engenharia de Software
Analise as afirmativas a seguir, relacionadas ao modelo ágil de processo conhecido porScrum.
I. Teste e documentação constantes são realizados à medida que o produto é construído.
II. O trabalho e desenvolvimento, e o pessoal que o efetua, são realizados por completo, com partições de alto acoplamento sem possibilidade de reuso.
III. Pequenas equipes de trabalho são organizadas de modo a maximizar a comunicação, minimizar a supervisão e maximizar o compartilhamento de conhecimento tácito informal.
IV. A complexidade do processo dificulta e não permite a produção de versões do software, que podem ser inspecionados e testados.
V. O processo precisa ser adaptável tanto a modificações técnicas quanto de negócios, para garantir que o melhor produto possível seja produzido.
Estão em conformidade com os princípios de desenvolvimento ágil Scrum, somente as seguintes afirmativas:
I. Teste e documentação constantes são realizados à medida que o produto é construído.
II. O trabalho e desenvolvimento, e o pessoal que o efetua, são realizados por completo, com partições de alto acoplamento sem possibilidade de reuso.
III. Pequenas equipes de trabalho são organizadas de modo a maximizar a comunicação, minimizar a supervisão e maximizar o compartilhamento de conhecimento tácito informal.
IV. A complexidade do processo dificulta e não permite a produção de versões do software, que podem ser inspecionados e testados.
V. O processo precisa ser adaptável tanto a modificações técnicas quanto de negócios, para garantir que o melhor produto possível seja produzido.
Estão em conformidade com os princípios de desenvolvimento ágil Scrum, somente as seguintes afirmativas:
Q476373
Engenharia de Software
O Rational Unified Process (RUP) é um modelo constituído por quatro fases no processo de software, relacionadas mais estritamente aos negócios do que a assuntos técnicos, descritas a seguir.
I. Trata do estabelecimento das entidades que irão interagir com o sistema e de suas interações.
II. Trata do entendimento do domínio do problema e estabelecer um framework de arquitetura para o sistema.
III. Trata do projeto, programação e teste do sistema.
IV. Trata da implantação do sistema no ambiente real de funcionamento.
As fases I, II, III e IV são denominadas, respectivamente:
I. Trata do estabelecimento das entidades que irão interagir com o sistema e de suas interações.
II. Trata do entendimento do domínio do problema e estabelecer um framework de arquitetura para o sistema.
III. Trata do projeto, programação e teste do sistema.
IV. Trata da implantação do sistema no ambiente real de funcionamento.
As fases I, II, III e IV são denominadas, respectivamente:
Q476370
Engenharia de Software
O desenvolvimento de software direcionado aos negócios apresenta uma seqüência de etapas bem definidas, cada uma com uma finalidade, entrada e saída distintas. Uma dessas etapas tem por objetivo especificar o que precisa ser feito e não como é feito, e visa compreender um problema antes de experimentar uma solução. Os requisitos são coletados e examinados minuciosamente por meio da construção de modelos.
Essa etapa é denominada:
Essa etapa é denominada:
Q476369
Engenharia de Software
Os projetos de sistemas para negócios aceitam diversos estilos de ciclo de vida. No entanto, um tipo tem sido adotado com frequência, pois é mais flexível e se baseia nas características listadas a seguir.
I. Primeiramente, um núcleo para o sistema é desenvolvid o , analisando , projetando , implementando e entregando um código preliminar que funciona.
II. Posteriormente, o escopo do sistema é ampliado, adicionando propriedades e comportamento aos objetos existentes, bem como incluindo novos tipos de objetos.
III. Constitui a melhor escolha para a maioria das aplicações, já que responde bem às mudanças e minimiza o risco de falha, além de oferecer um feedback de progresso aos usuários da gerência e do negócio.
O tipo descrito é conhecido por desenvolvimento:
I. Primeiramente, um núcleo para o sistema é desenvolvid o , analisando , projetando , implementando e entregando um código preliminar que funciona.
II. Posteriormente, o escopo do sistema é ampliado, adicionando propriedades e comportamento aos objetos existentes, bem como incluindo novos tipos de objetos.
III. Constitui a melhor escolha para a maioria das aplicações, já que responde bem às mudanças e minimiza o risco de falha, além de oferecer um feedback de progresso aos usuários da gerência e do negócio.
O tipo descrito é conhecido por desenvolvimento:
Ano: 2014
Banca:
FCC
Órgão:
TCE-GO
Prova:
FCC - 2014 - TCE-GO - Analista de Controle Externo - Tecnologia da Informação |
Q473134
Engenharia de Software
A UML especifica um conjunto de diagramas para modelar sistemas orientados a objeto em suas várias perspectivas. Dois destes diagramas podem ser muito úteis para apresentar uma visão de nível mais alto do sistema, como:
I. adequado para captar os requisitos funcionais de um sistema, ajudando no entendimento destes requisitos.
II. suporta e estimula o comportamento paralelo, sendo útil para modelagem de fluxo de trabalho e de processos, principal- mente, processos de negócio.
Os diagramas descritos em I e II são, correta e respectivamente, de
I. adequado para captar os requisitos funcionais de um sistema, ajudando no entendimento destes requisitos.
II. suporta e estimula o comportamento paralelo, sendo útil para modelagem de fluxo de trabalho e de processos, principal- mente, processos de negócio.
Os diagramas descritos em I e II são, correta e respectivamente, de
Ano: 2014
Banca:
FCC
Órgão:
TCE-GO
Prova:
FCC - 2014 - TCE-GO - Analista de Controle Externo - Tecnologia da Informação |
Q473133
Engenharia de Software
Em aplicações orientadas a objetos é possível construir diferentes tipos de classes, como
Ano: 2014
Banca:
FCC
Órgão:
TCE-GO
Prova:
FCC - 2014 - TCE-GO - Analista de Controle Externo - Tecnologia da Informação |
Q473131
Engenharia de Software
Paulo trabalha com requisitos de sistemas. Ele está focado em um sistema mal documentado, que possui milhares de linhas de código, em que os requisitos mudam com frequência. Isso tem causado diversas paradas inesperadas no sistema decorrentes de alterações em partes do código que causam falhas em outras partes, aumentando muito o custo de manutenção do sistema. Observando tal situação, Paulo propôs o uso de uma disciplina da Engenharia de Requisitos que consiste na definição formal de uma metodologia que permita compreender e controlar as mudanças nos requisitos do sistema, denominada
Ano: 2014
Banca:
CAIP-IMES
Órgão:
Prefeitura de São Paulo - SP
Prova:
CAIP-IMES - 2014 - Prefeitura de São Paulo - SP - Analista de TIC I - Infraestrutura |
Q472754
Engenharia de Software
A seguir são descritas técnicas de Análise e Desenvolvimento de Sistemas, exceto pelo que se lê na alternativa:
Ano: 2014
Banca:
FCC
Órgão:
TRT - 2ª REGIÃO (SP)
Prova:
FCC - 2014 - TRT - 2ª REGIÃO (SP) - Analista Judiciário - Tecnologia da Informação |
Q472328
Engenharia de Software
A tabela abaixo mostra o uso de uma técnica muito usada no gerenciamento de projetos e processos, recomendada pelo PMBoK, CobiT, ITIL v3 e outras práticas de mercado.
A tabela mostrada é um exemplo de
A tabela mostrada é um exemplo de
Ano: 2014
Banca:
FCC
Órgão:
TRT - 2ª REGIÃO (SP)
Prova:
FCC - 2014 - TRT - 2ª REGIÃO (SP) - Analista Judiciário - Tecnologia da Informação |
Q472314
Engenharia de Software
Ana foi contratada em uma empresa para efetuar trabalhos de desenvolvimento relacionados à área de informática. Logo no primeiro dia foi convidada a participar de uma reunião que é efetuada diariamente, de apenas 15 minutos. Todos os participantes ficam em pé e ela é conduzida pelos próprios desenvolvedores. Durante este pequena reunião, foram abordados o que cada desenvolvedor conseguiu concluir desde a última reunião, o que ele pretende efetuar até a próxima e, o que Ana achou muito importante, o que está impedindo que este desenvolvedor prossiga com seu trabalho. Ana foi informada que esta reunião pertence ao método ágil
Ano: 2014
Banca:
FCC
Órgão:
TRT - 2ª REGIÃO (SP)
Prova:
FCC - 2014 - TRT - 2ª REGIÃO (SP) - Analista Judiciário - Tecnologia da Informação |
Q472313
Engenharia de Software
No sistema de controle de versões Git, para efetuar o download dos commits de um repositório remoto para o repositório local é utilizado o comando git
Ano: 2014
Banca:
FCC
Órgão:
TRT - 2ª REGIÃO (SP)
Prova:
FCC - 2014 - TRT - 2ª REGIÃO (SP) - Analista Judiciário - Tecnologia da Informação |
Q472303
Engenharia de Software
UML é uma linguagem visual para modelagem de sistemas orientados a objeto. Considere o diagrama UML:
Uma primitiva importante dos diagramas de ..I... é a troca de mensagem, como na figura acima, que ilustra a troca de mensagens entre objetos e entre atores e objetos. Estas mensagens, utilizadas para indicar interação ou comunicação, podem ter diferentes significados:
- Chamada: significa que um objeto está solicitando a execução de ...II.... de um outro objeto. Para isso, é necessário que ele seja declarado como público ..III...... correspondente.
- Ocorrência de Evento: um evento é algum acontecimento externo ao software, mas que é a ele notificado, pois lhe diz respeito. Exemplos são as saídas para dispositivos (como disco ou monitor) feitos através de serviços do sistema operacional. Esta é a forma padrão de interação entre ...IV..... .
As lacunas I, II, III e IV são, correta e respectivamente, preenchidas em:
Uma primitiva importante dos diagramas de ..I... é a troca de mensagem, como na figura acima, que ilustra a troca de mensagens entre objetos e entre atores e objetos. Estas mensagens, utilizadas para indicar interação ou comunicação, podem ter diferentes significados:
- Chamada: significa que um objeto está solicitando a execução de ...II.... de um outro objeto. Para isso, é necessário que ele seja declarado como público ..III...... correspondente.
- Ocorrência de Evento: um evento é algum acontecimento externo ao software, mas que é a ele notificado, pois lhe diz respeito. Exemplos são as saídas para dispositivos (como disco ou monitor) feitos através de serviços do sistema operacional. Esta é a forma padrão de interação entre ...IV..... .
As lacunas I, II, III e IV são, correta e respectivamente, preenchidas em:
Ano: 2014
Banca:
FCC
Órgão:
TRT - 2ª REGIÃO (SP)
Prova:
FCC - 2014 - TRT - 2ª REGIÃO (SP) - Analista Judiciário - Tecnologia da Informação |
Q472302
Engenharia de Software
O modelo de ciclo de vida incremental e iterativo foi proposto como uma resposta aos problemas encontrados no modelo em cascata. Em relação a este tipo de modelo de processo, é INCORRETO afirmar que
Ano: 2014
Banca:
FCC
Órgão:
TRT - 2ª REGIÃO (SP)
Prova:
FCC - 2014 - TRT - 2ª REGIÃO (SP) - Analista Judiciário - Tecnologia da Informação |
Q472301
Engenharia de Software
Há diversos processos e práticas ágeis de desenvolvimento de software. Considere:
I. Seu objetivo é criar um “código limpo que funcione”. Trabalha com a estratégia Red - Green - Refactor:
- Codifique o teste;
- Faça-o compilar e executar. O teste não deve passar (Red).
- Implemente o requisito e faça o teste passar (Green).
- Refatore o código (Refactor).
II. Suas práticas, regras e valores garantem um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos pelos princípios básicos:
- Comunicação - manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação;
- Simplicidade - implementar apenas requisitos atuais, evitando adicionar funcionalidades que podem ser importantes somente no futuro;
- Feedback - o desenvolvedor terá informações constantes do cliente e do código, em que testes constantes indicam os erros tanto individuais quanto do software integrado;
- Coragem - encorajar as pessoas que não possuem facilidade de comunicação e bom relacionamento interpessoal, encorajar a equipe a experimentar e buscar novas soluções, além de encorajar a obtenção de feedback do cliente.
III. Objetiva capturar os critérios de aceitação para as funcionalidades em desenvolvimento. Trabalha com as seguintes etapas:
- Discutir (Discuss): discussão colaborativa com a equipe visando elicitar os critérios de aceitação.
- Refinar (Distill): refinamento dos critérios de aceitação em um conjunto concreto de cenários/exemplos de uso descrevendo o comportamento esperado da aplicação em uma linguagem comum a todos os membros da equipe.
- Desenvolver (Develop): transformação dos testes de aceitação (descrevendo o comportamento esperado do software) em testes/especificação automatizados.
IV. Suas práticas incluem:
- Envolver as partes interessadas no processo através de Outside-in Development.
- Usar exemplos para descrever o comportamento de uma aplicação ou unidades de código.
- Automatizar os exemplos para prover um feedback rápido e testes de regressão.
- Usar o verbo deve (should) ao descrever o comportamento de software para ajudar a esclarecer responsabilidades e permitir que funcionalidades sejam questionadas.
- Usar dublês de teste (mocks, stubs, fakes, dummies, spies) para auxiliar na colaboração entre módulos e códigos que ainda não foram escritos.
Os processos ágeis I, II, III e IV são, correta e respectivamente, denominados:
I. Seu objetivo é criar um “código limpo que funcione”. Trabalha com a estratégia Red - Green - Refactor:
- Codifique o teste;
- Faça-o compilar e executar. O teste não deve passar (Red).
- Implemente o requisito e faça o teste passar (Green).
- Refatore o código (Refactor).
II. Suas práticas, regras e valores garantem um agradável ambiente de desenvolvimento de software para os seus seguidores, que são conduzidos pelos princípios básicos:
- Comunicação - manter o melhor relacionamento possível entre clientes e desenvolvedores, preferindo conversas pessoais a outros meios de comunicação;
- Simplicidade - implementar apenas requisitos atuais, evitando adicionar funcionalidades que podem ser importantes somente no futuro;
- Feedback - o desenvolvedor terá informações constantes do cliente e do código, em que testes constantes indicam os erros tanto individuais quanto do software integrado;
- Coragem - encorajar as pessoas que não possuem facilidade de comunicação e bom relacionamento interpessoal, encorajar a equipe a experimentar e buscar novas soluções, além de encorajar a obtenção de feedback do cliente.
III. Objetiva capturar os critérios de aceitação para as funcionalidades em desenvolvimento. Trabalha com as seguintes etapas:
- Discutir (Discuss): discussão colaborativa com a equipe visando elicitar os critérios de aceitação.
- Refinar (Distill): refinamento dos critérios de aceitação em um conjunto concreto de cenários/exemplos de uso descrevendo o comportamento esperado da aplicação em uma linguagem comum a todos os membros da equipe.
- Desenvolver (Develop): transformação dos testes de aceitação (descrevendo o comportamento esperado do software) em testes/especificação automatizados.
IV. Suas práticas incluem:
- Envolver as partes interessadas no processo através de Outside-in Development.
- Usar exemplos para descrever o comportamento de uma aplicação ou unidades de código.
- Automatizar os exemplos para prover um feedback rápido e testes de regressão.
- Usar o verbo deve (should) ao descrever o comportamento de software para ajudar a esclarecer responsabilidades e permitir que funcionalidades sejam questionadas.
- Usar dublês de teste (mocks, stubs, fakes, dummies, spies) para auxiliar na colaboração entre módulos e códigos que ainda não foram escritos.
Os processos ágeis I, II, III e IV são, correta e respectivamente, denominados:
Ano: 2014
Banca:
VUNESP
Órgão:
SEDUC-SP
Prova:
VUNESP - 2014 - SEDUC-SP - Analista de Tecnologia - Tecnologia da Informação |
Q471516
Engenharia de Software
Na programação orientada a objetos, o conceito de polimorfismo indica que
Conheça nossos planos