Questões de Concurso Comentadas sobre engenharia de software
Foram encontradas 13.115 questões
Q476384
Engenharia de Software
A engenharia de requisitos envolve a execução de diversas tarefas, sendo uma delas definida como a ação de modelagem de análise, guiada pela criação e refinamento de cenários do usuário, que descrevem como o usuário final vai interagir com o sistema. O produto final gerado por essa tarefa é um modelo de análise que define o domínio do problema informacional, funcional e comportamental.
A tarefa descrita é denominada:
A tarefa descrita é denominada:
Q476380
Engenharia de Software
Na Análise de Pontos de Função, são levadas em consideração funções representadas pela funcionalidade fornecida ao usuário para processar dados.
Essas funções são denominadas:
Essas funções são denominadas:
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:
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 |
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 |
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
Ano: 2014
Banca:
CEC
Órgão:
Prefeitura de Piraquara - PR
Prova:
CEC - 2014 - Prefeitura de Piraquara - PR - Analista de Sistema |
Q471059
Engenharia de Software
Analise as afirmativas sobre Orientação a Objetos:
• Na programação OO (Orientação a Objetos), objetos são usados para representar entidades do mundo real ou computacional.
• O objeto tipo Pessoa pode ter comportamento associado, por exemplo: correr, andar e pular. Por isso afirmamos que na Programação Orientada a Objetos os objetos possuem características e comportamentos.
• Cada classe funciona como um molde para a criação de um objeto.
• Um método é uma sub-rotina que é executada por um objeto ao receber uma mensagem.
• A Programação Orientada a Objetos tem como principal objetivo reduzir a complexidade no desenvolvimento de software e aumentar sua produtividade.
Quantas afirmativas são corretas?
• Na programação OO (Orientação a Objetos), objetos são usados para representar entidades do mundo real ou computacional.
• O objeto tipo Pessoa pode ter comportamento associado, por exemplo: correr, andar e pular. Por isso afirmamos que na Programação Orientada a Objetos os objetos possuem características e comportamentos.
• Cada classe funciona como um molde para a criação de um objeto.
• Um método é uma sub-rotina que é executada por um objeto ao receber uma mensagem.
• A Programação Orientada a Objetos tem como principal objetivo reduzir a complexidade no desenvolvimento de software e aumentar sua produtividade.
Quantas afirmativas são corretas?
Ano: 2014
Banca:
IV - UFG
Órgão:
CELG/GT-GO
Prova:
CS-UFG - 2014 - CELG/GT-GO - Analista de Gestão - Analista de Sistemas |
Q468377
Engenharia de Software
No gerenciamento da qualidade de software, complexidade ciclomática é uma métrica de produto, que se refere
Ano: 2014
Banca:
IV - UFG
Órgão:
CELG/GT-GO
Prova:
CS-UFG - 2014 - CELG/GT-GO - Analista de Gestão - Analista de Sistemas |
Q468376
Engenharia de Software
O termo baseline está associado ao gerenciamento de configurações e corresponde
Conheça nossos planos