TRE(PE)/2017 – Comentários da Prova de Engenharia de Software (Tecnologia da Informação)

Fala pessoal,

Vamos aos comentários da prova de TI do TRE/PE (Tecnologia da Informação/Engenharia de Software). Eu achei uma boa prova, nível razoável e que cobriu praticamente todos os itens de Engenharia de Software do edital. Vocês concordam? Deixem nos comentários!

Ah, não se esqueçam de entrar no meu Facebook para qualquer outra dúvida:

E no nosso grupo de TI no Facebook:

Agora vamos lá…

29. (CESPE – 2017 – TRE/PE – Analista de Sistemas) Com relação aos artefatos Scrum, assinale a opção correta.

a) A estrutura analítica do projeto desenvolvido na reunião de revisão da Sprint contém a subdivisão das entregas e do trabalho do projeto em componentes menores e de gerenciamento mais fácil.

b) O burndown é produzido na reunião do backlog da Sprint apenas antes de propriamente iniciar a Sprint.

c) O poker report é produzido ao longo da Sprint para mensurar quanto cada integrante está atarefado em uma métrica de 0 por cento a 100 por cento.

d) O backlog da Sprint contém a lista de funcionalidades remanescentes da execução da Sprint, ou seja, os requisitos que, por quaisquer motivos, não tenham sido implementados na Sprint.

e) O backlog do produto jamais se completa e evolui conforme o produto e o ambiente no qual ele será utilizado; além disso, é dinâmico, sendo alterado constantemente para identificar o que seja necessário para o produto ser mais apropriado, competitivo e útil.

Comentários:

Estava na aula: "É a origem única dos requisitos para qualquer mudança a ser feita no produto. Costuma-se dizer que ele é um artefato dinâmico que nunca estará completo e existirá enquanto o produto também existir. Por que? Porque sempre haverá novos requisitos, novas necessidades e mudanças a serem incorporadas. Logo, ele é um artefato vivo – sempre em movimento."

(a) Errado, não há nenhuma Estrutura Analítico de Projeto (EAP) no Scrum – isso é um artefato do PMBOK; (b) Errado, não existe Reunião de Backlog da Sprint – a reunião antes do início propriamente da sprint é a Reunião de Planejamento da Sprint; (c) Errado, nada nesse item faz sentido; (d) Errado, esse é o Backlog do Produto; (e) Correto, tudo nessa frase está perfeito.

Gabarito: E

30. (CESPE – 2017 – TRE/PE – Analista de Sistemas) O DevOps consiste em:

a) um processo similar ao I R U P (I B M Rational Unified Process), que tem como objetivo dividir o processamento em fases e disciplinas de software para paralelizar as ações de desenvolvimento e de manutenção das soluções.

b) uma plataforma aberta cuja função é substituir a virtualização de aplicações e serviços em containers e, com isso, agilizar a implantação de soluções de software.

c) um aplicativo que permite o gerenciamento de versões de códigos-fonte e versões de programas, bem como a implantação da versão mais recente de um software em caso de falha.

d) um processo de promoção de métodos que objetivam aprimorar a comunicação, tornando a colaboração eficaz especialmente entre os departamentos de desenvolvimento e teste e entre os departamentos de operações e serviço para o negócio.

e) uma metodologia ágil que, assim como a X P (extreme programming) e o Scrum, tem foco na gestão de produtos complexos relativos à equipe de desenvolvimento.

Comentários:

DevOps não é um processo similar ao iRUP, não é uma plataforma aberta, não é um aplicativo e não é uma metodologia ágil. DevOps é um processo de promoção de métodos que objetivam aprimorar a comunicação, tornando a colaboração eficaz especialmente entre os departamentos de desenvolvimento e teste e entre os departamentos de operações e serviço para o negócio.

Gabarito: D

38. O modelo de processo de desenvolvimento de software que enfatiza a estreita relação entre as atividades de testes e as demais fases do processo de desenvolvimento é denominado modelo:

a) R A D.
b) concorrente.
c) em V.
d) incremental.
e) em espiral.

Comentários:

Galera, falou de processo de desenvolvimento de software com estreita relação com atividades de teste, trata-se do Modelo em V.

Gabarito: C

39. (CESPE – 2017 – TRE/PE – Analista de Sistemas) No contexto da análise de requisitos, confiabilidade e usabilidade são atributos de qualidade classificados como:

a) requisitos funcionais.

b) requisitos de domínio.

c) requisitos não funcionais.

d) dependências.

e) regras de negócio.

Comentários:

Lembram-se daquele diagrama com os Requisitos Não-Funcionais divididos em Requisitos de Produto, Organizacionais e Externos? Pois é, Confiabilidade e Usabilidade são Requisitos Não-Funcionais de Produto.

Gabarito: C

40. (CESPE – 2017 – TRE/PE – Analista de Sistemas) Assinale a estrutura empregada em UML para representar o comportamento dinâmico de um sistema por meio do fluxo de controle entre ações que o sistema executa.

a) diagrama de caso de uso

b) diagrama de distribuição

c) diagrama de comunicação

d) diagrama de sequência

e) diagrama de atividade

Comentários:

Estava na aula: "O Diagrama de Atividades descreve lógica de procedimento, processo de negócio e fluxos de trabalho. De várias formas, eles desempenham um papel semelhante aos fluxogramas, mas se diferenciam, pois suportam comportamentos paralelos. Mas o que é uma atividade? É um comportamento parametrizado representado como um fluxo coordenado de ações."

Galera, vamos ler esse item por partes: “Assinale a estrutura empregada em UML para representar o comportamento dinâmico”. Se pararmos aqui, já podemos eliminar todos os itens que contenham diagramas estruturais, como o Diagrama de Distribuição (também conhecido como Diagrama de Implantação). Seguindo: “(…) de um sistema por meio do fluxo de controle entre ações que o sistema executa”. Dessa parte, quando a questão fala de fluxo de controle entre ações, já podemos concluir que se trata do Diagrama de Atividades.

Gabarito: E

42. (CESPE – 2017 – TRE/PE – Analista de Sistema) A ISO barra IEC 9126 descreve uma das características do modelo de qualidade de software como capacidade do produto de software de apresentar desempenho apropriado, relativo à quantidade de recursos usados, sob condições especificadas. Essa característica corresponde à:

a) confiabilidade.

b) eficiência.

c) manutenibilidade.

d) funcionalidade.

e) usabilidade.

Comentários:

Estava na aula:

Eficiência

Capacidade do produto de software de apresentar desempenho apropriado, relativo à quantidade de recursos usados, sob condições especificadas.

Conforme vimos em aula, a questão está perfeita!

Gabarito: B

43. (CESPE – 2017 – TRE/PE – Analista de Sistemas) Com relação ao processo de contagem de pontos de função, assinale a opção correspondente à etapa responsável por reconhecer a complexidade e a contribuição de cada uma das funções contadas.

a) Calcular os pontos de função não ajustados.

b) Contar as funções transacionais.

c) Identificar o escopo de contagem e a fronteira da aplicação.

d) Determinar a contagem de pontos de função não ajustados.

e) Determinar o valor do fator de ajuste.

Comentários:

Conforme vimos em aula, o reconhecimento da complexidade só vai ocorrer na etapa de Calcular Pontos de Função Não-Ajustados.

Gabarito: A

44. (CESPE – 2017 – TRE/PE – Analista de Sistemas) A respeito de arquitetura orientada a serviços (SOA), assinale a opção correta.

a) WS – Transaction é um padrão de suporte que garante que uma mensagem seja entregue uma vez e apenas uma vez.

b) Trata-se de uma forma de desenvolvimento de sistemas distribuídos cujos componentes são serviços autônomos, executados em computadores geograficamente distribuídos.

c) Um serviço na SOA é agnóstico, ou seja, dependente da aplicação que o utiliza.

d) WSDL (web service definition language) na SOA para Web é uma linguagem utilizada como padrão para troca de mensagens e para definição de componentes de web services.

e) WS – realiable messaging é um padrão SOA que define como as informações devem ser representadas em uma mensagem SOAP.

Comentários:

(a) Errado, esse é o WS-Reliable Messaging. O WS-Transaction é uma especificação que apresenta como as transações através de serviços distribuídos devem ser coordenadas, garantindo quem uma transação seja atômica, i.e., uma transação é executada integralmente com sucesso ou é completamente abortada; (b) Correto. Questão retirada da última edição do Sommerville e que, a princípio, eu discordo. SOA não é uma forma de desenvolvimento, mas já que foi o Sommerville que disse, a partir de agora passaremos a considerar como referência; (c) Errado, ele é independente da aplicação que o utiliza, i.e., agnóstico; (d) Errado, WSDL é um padrão para a definição de interface de serviço; (e) Errado, esse é o WS-Adressing.

Gabarito: B

45. (CESPE – 2017 – TRE/PE – Analista de Sistemas) Assinale a opção que apresenta o padrão de projeto que tem por objetivo separar o display de estado de um objeto a partir do objeto em si e que permite que sejam fornecidos displays alternativos.

a) Decorator

b) Prototype

c) Facade

d) Observer

e) Iterator

Comentários:

Questão retirada integralmente do Sommerville, 9ª Ed., Cap. 7, Pág. 134. Trata-se do Padrão Observer.

Em muitas situações, você precisa fornecer vários displays de informações do estado, como um display gráfico e em tabela. Nem todos eles podem ser conhecidos quando a informação é especificada. Todas as apresentações alternativas devem apoiar a interação e, quando o estado é alterado, todos os displays devem ser atualizados.

Esse padrão pode ser usado em todas as situações em que mais de um formato de display de informações de estado é necessário, e em que saber sobre os formatos de display específicos usados não é necessário para o objeto que mantém as informações do estado. Péssima questão!

Gabarito: D

46. (CESPE – 2017 – TRE/PE – Analista de Sistemas) REST (Representational State Transfer) é:

a) um estilo de desenvolvimento que utiliza o protocolo HTTP e se baseia na interação simples entre cliente e servidor.

b) um software de infraestrutura em um sistema distribuído que auxilia no gerenciamento de interações entre entidades distribuídas em serviços web.

c) uma linguagem web voltada a definição de predicados que se apliquem a classes de objetos e de interações em um modelo UML.

d) uma linguagem de programação com tipos dinâmicos, voltada principalmente para desenvolvimento de aplicações web.

e) um modelo de desenvolvimento de software estruturado e organizado como um conjunto de classes de objeto e de relações entre essas classes.

Comentários:

Estava na aula: "Ficou mais fácil de entender agora? Essas restrições são correspondentes às tecnologias/protocolos e ajudam a diferenciar uma arquitetura de um estilo arquitetural. Professor, mas o que é o REST? REST significa REpresentational State Transfer e se trata de um estilo arquitetural para projetar aplicações de rede distribuídas. Agora, sim, vamos falar mais a fundo sobre o assunto da nossa aula…"

Pessoal, essa questão tem quatro itens que não fazem o menor sentido, logo vamos comentar direto o primeiro item. Notem só o nosso dilema! Eu falei para vocês diversas vezes que o REST é um Estilo Arquitetural. O gabarito da questão afirma que REST é um Estilo de Desenvolvimento. Ora, na minha opinião, questão errada e ponto final! Simples assim…

Porééééééém esse item foi retirado diretamente da última versão do Sommerville (9ª Ed.) e ele afirma exatamente assim:

“REST é um estilo de desenvolvimento baseado em interação simples de cliente /servidor e que usa o protocolo HTTP. REST é baseado na ideia de recurso identificável, o qual possui uma URI. Todas as interações com recursos são baseadas em HTTP POST, GET, PUT e DELETE. Atualmente é muito usado para implementar web services de baixo overhead”.

O que isso significa? Isso significa que, a partir de agora, vamos ter que considerar o REST – pelo menos no contexto de provas de concurso – também como um Estilo de Desenvolvimento. Eu discordo veementemente, não vejo o menor sentido nessa afirmação. Porém, contudo, todavia, entretanto, se o Sommerville diz, vira referência! Bacana?

Gabarito: A

48. (CESPE – 2017 – TRE/PE – Tecnologia da Informação) O DDD (domain-driven design)

a) consiste em uma técnica que trata os elementos de domínio e que garante segurança à aplicação em uma programação orientada a objetos na medida em que esconde as propriedades desses objetos.

b) não tem como foco principal a tecnologia, mas o entendimento das regras de negócio e de como elas devem estar refletidas no código e no modelo de domínio.

c) prioriza a simplicidade do código, sendo descartados quaisquer usos de linguagem ubíqua que fujam ao domínio da solução.

d) constitui-se de vários tratadores e (ou) programas que processam os eventos para produzir respostas e de um disparador que invoca os pequenos tratadores.

e) define-se como uma interface de domínio normalmente especificada e um conjunto de operações que permite acesso a uma funcionalidade da aplicação.

Comentários:

Estava na aula: "O DDD utiliza princípios como alinhamento do código ao negócio, favorecimento da reutilização de código, mínimo acoplamento e independência de tecnologia. As pessoas que trabalham na construção de aviões, por exemplo, têm uma visão limitada do que, de fato, constitui o avião. Elas enxergam o avião como um apanhado de peças, as quais precisam ser colocadas juntas."

Estava na aula: "Para ter um software que atenda perfeitamente a um determinado domínio, é necessário que se estabeleça, em primeiro lugar, uma Linguagem Ubíqua. Nessa linguagem estão termos que fazem parte das conversas diárias entre especialistas de negócio e times de desenvolvimento. Todos devem usar os mesmos termos tanto na linguagem falada quanto no código."

(a) Errado, isso se parece mais com encapsulamento; (b) Correto. Conforme vimos em aula, um de seus princípios é a independência de tecnologia, com foco nas regras de negócio; (c) Errado, incentiva-se o uso de uma linguagem ubíqua; (d) Errado, isso é Programação Orientada a Eventos e, não, a Domínio; (e) Errado, isso se parece mais Programação Orientada a Objetos.

Gabarito: B

52. (CESPE – 2017 – TRE/PE – Analista de Sistemas) Refactoring é o processo que:

a) implementa todas as funcionalidades da camada de model para depois implementar as camadas de controller e de viewer, nos casos em que a arquitetura MVC é utilizada.

b) efetua mudanças em um código existente e funcional sem alterar seu comportamento externo, com o objetivo de aprimorar a estrutura interna do código.

c) inclui funcionalidades extras no código, com o intuito de aprimorá-lo (rich source-code).

d) aprimora a extração e o refinamento iterativo dos requisitos do produto ainda na fase de planejamento do software, sendo considerado um valor na XP (extreme programming).

e) estabelece os métodos, um após o outro, para depois definir as classes e suas abstrações e implementar as interfaces.

Comentários:

Estava na aula: "Uma importante atividade sugerida por diversas metodologias ágeis de desenvolvimento de software, a Refatoração é uma técnica (inclusive preconizada pelo XP) de reorganização que simplifica o projeto (ou código) de um componente de software sem modificar sua função ou seu comportamento. Martin Fowler define refatoração da seguinte maneira: “É o processo de mudar um sistema de software de tal forma que não altere o comportamento externo do código, embora melhore sua estrutura interna”."

Conforme vimos em aula, nenhum desses itens faz sentido, exceto o segundo.

Gabarito: B

53. (CESPE – 2017 – TRE/PE – Analista de Sistemas) O desenvolvimento orientado a testes (TDD):

a) é um conjunto de técnicas que se associam ao X P (extreme programming) para o desenvolvimento incremental do código que se inicia com os testes.

b) agrega um conjunto de testes de integração para avaliar a interconexão dos componentes do software com as aplicações a ele relacionadas.

c) avalia o desempenho do desenvolvimento de sistemas verificando se o volume de acessos/transações está acima da média esperada.

d) averigua se o sistema atende aos requisitos de desempenho verificando se o volume de acessos/transações mantém-se dentro do esperado.

e) testa o sistema para verificar se ele foi desenvolvido conforme os padrões e a metodologia estabelecidos nos requisitos do projeto.

Comentários:

O Test-Driven Development (TDD) é um método ágil de desenvolvimento de software que se baseia na repetição de um ciclo de desenvolvimento curto, focado em testes unitários, em que os casos de teste que verificam uma nova funcionalidade são escritos antes mesmo da própria funcionalidade. Escreve-se o teste, encontre uma falha e refatore-o, ciclicamente – conhecido como Red, Green e Refactor.

Conforme vimos em aula, o único item que faz algum sentido em relação ao TDD é o primeiro, ou seja, conjunto de técnicas intimamente ligadas ao XP para o desenvolvimento de software que se inicia com os testes.

Gabarito: A

É isso aí! Forte abraço, pessoal…