SE/DF 2017 – Comentários da Prova de Engenharia de Software (TI)

Fala, galera! Segue abaixo as questões comentadas de Engenharia de Software da SEDF 2017. Achei a prova em bom nível, nada muito complexo, uma ou outra questão mais polêmica e eu encontrei duas questões passíveis de recursos. Vamos lá…

 

 

79. (CESPE – 2017 – SE/DF – Analista de Sistemas) O gerente funcional e o gerente de projetos têm papéis diferentes na organização: o primeiro é responsável por supervisionar o gerenciamento de uma das áreas da empresa, e o segundo busca atingir os objetivos de um projeto específico.

Comentários: Impecável! O Gerente Funcional geralmente cuida de uma área específica da organização e o Gerente de Projetos cuida de um projeto que pode abranger diversas áreas de uma organização. Gabarito: C

 

 

80. (CESPE – 2017 – SE/DF – Analista de Sistemas) O gerenciamento de escopo garante que todos os esforços necessários estejam incluídos no projeto, com apenas o necessário para que o escopo seja realizado dentro do cronograma previsto.

Comentários: Nops! O gerenciamento de escopo garante que todos os esforços necessários estejam incluídos no projeto, com apenas o necessário para que o escopo seja realizado (projeto finalizado). O controle do cronograma é de responsabilidade do gerenciamento de tempo. Gabarito: E

 

 

81. (CESPE – 2017 – SE/DF – Analista de Sistemas) Quaisquer erros cometidos na fase de planejamento somente serão detectados na fase de finalização.

Comentários: Acredito que ele esteja chamando fase de encerramento de fase de finalização. Dito isso, erros cometidos na fase de planejamento podem ser detectados antes. Gabarito: E

 

 

82. (CESPE – 2017 – SE/DF – Analista de Sistemas) Antes do planejamento da próxima sprint, deve ser feita a retrospectiva da sprint, pois esse é o momento ideal para o time Scrum rever seus erros e acertos antes da próxima sprint de desenvolvimento.

Comentários: Conforme vimos em aula, a questão está perfeita! É aquela hora de lavar a roupa suja com a equipe.​ Gabarito: C

Estava na aula: A Retrospectiva da Sprint (Proporcional a 3 horas) é uma chance para o Scrum Team inspecionar a si próprio e criar um plano de melhorias para a próxima sprint. Ela inspeciona como foi a última sprint em relação às pessoas, às relações, aos processos e às ferramentas. Pode identificar e ordenar os itens que se tornaram potenciais de melhorias e cria um plano para implementar melhorias no trabalho.

 

 

83. (CESPE – 2017 – SE/DF – Analista de Sistemas) A técnica de Kanban é uma forma simples de visualizar o andamento das tarefas da equipe durante uma Sprint de Scrum. Nessa técnica, as tarefas são representadas por meio de pequenos papéis que indicam o que está pendente, em desenvolvimento e finalizado. Com isso, todos visualizam os gargalos e a equipe se organiza melhor, principalmente quando o projeto envolve ciclos longos de desenvolvimento.

Comentários: Conforme vimos em aula, a questão está perfeita! Trata-se de uma técnica que ajuda a visualizar o andamento do projeto. É muito utilizado em conjunto com o Scrum!​ Gabarito: C

Estava na aula: Kanban significa Cartão ou Placa Visual, em japonês. O Kanban é um método para gestão de mudanças com foco na visualização do trabalho em progresso (Work In Progress), identificando oportunidades de melhorias, tornando explícitas as políticas seguidas e os problemas encontrados e, por fim, favorecendo uma cultura de melhoria evolutiva.

 

84. (CESPE – 2017 – SE/DF – Analista de Sistemas) Pontos de estórias (story points) são o meio mais adequado de se determinar o tempo de desenvolvimento de uma tarefa de uma sprint, pois, nesse caso, os desenvolvedores atribuem pontos de dificuldade para o desenvolvimento de uma tarefa específica e a pontuação de menor valor é a que determina o tempo de tarefa da sprint.

Comentários: Conforme vimos em aula, Story Points são o meio mais adequado para se determinar o esforço de desenvolvimento e, não, o tempo. Ademais, a história de usuário com o menor esforço para desenvolvimento servirá de padrão para a pontuação restante.​ Gabarito: E

Estava na aula: Trata-se de uma unidade de medida relativa que leva em consideração o esforço necessário para realizar uma determinada funcionalidade. Se uma funcionalidade requerer o dobro de esforço para ser implementada, ela receberá aproximadamente o dobro de Story Points. Para fazer essa estimativa, a equipe de desenvolvimento realiza uma comparação com outras histórias já estimadas.

 

 

85. (CESPE – 2017 – SE/DF – Analista de Sistemas) Na metodologia Scrum, a lista ordenada de tudo o que é necessário para um produto ser apropriado é identificada como backlog do produto, o qual é atualizado constantemente e nunca está completo.

Comentários: Conforme vimos em aula, essa questão não pode estar mais perfeita! Perceba até que ele salienta que o Product Backlog nunca está completo – como nós vimos em aula. Gabarito: C

Estava na aula: Antes de tudo, o que é um backlog? O backlog é uma lista, um resumo histórico, de acumulação de trabalho num determinado período de tempo, pode ser uma pilha de pedidos que devem ser produzidos. Já o Product Backlog é uma lista ordenada (por valor, risco, prioridade, entre outros) de requisitos ou funcionalidades que o produto deve conter criada pelo Time Scrum.

 

 

86. (CESPE – 2017 – SE/DF – Analista de Sistemas) O modelo de casos de uso representa uma visão funcional do sistema, incluindo-se todas as funções, os processos funcionais e os atores do sistema.

Comentários: De fato, o modelo de casos de uso representa uma visão funcional do sistema. No entanto, não se incluem todas as funções, processos funcionais e atores do sistema (palavra-chave importante). Gabarito: E

 

 

87. (CESPE – 2017 – SE/DF – Analista de Sistemas) Em um diagrama de classes, as associações entre os objetos refletem as necessidades de comunicação definidas no diagrama de sequência e resumidas no diagrama de colaboração.

Comentários: [Cabe Recurso] Vamos de trás para frente! O Diagrama de Comunicação (antigamente chamado Diagrama de Colaboração) realmente é meio que um resumo do Diagrama de Sequência. O Diagrama de Sequência ilustra como objetos (lembrando que são instâncias de Classes) interagem umas com as outras. Por fim, um Diagrama de Classes ilustra classes, interfaces e suas associações. Agora vamos voltar: No Diagrama de Classes, temos classes que se associam umas com as outras. Esse relacionamento pode ser modelagem por meio de objetos em Diagramas de Sequência, que posteriormente podem ser resumidos em Diagramas de Comunicação/Colaboração. Qual é o problema? O problema é que a questão começa falando de Diagrama de Classes e logo menciona as associações entre objetos. É estranho esse raciocínio e caberia recurso. Gabarito: C

 

 

88. (CESPE – 2017 – SE/DF – Analista de Sistemas) Em um gráfico de classes UML, um relacionamento de extensão (extend) é uma relação estrutural na qual um caso de uso maior é estendido por um caso de uso menor, que inclui serviços especiais no caso de uso maior.

Comentários: [Cabe Recurso] Primeiro, esse nome é esquisito – não é Gráfico de Classes, mas Diagrama de Classes. Segundo, o relacionamento de Extensão se dá em um Diagrama de Casos de Uso. Fora isso, realmente em um relacionamento de extensão, o caso de uso maior (seria melhor dizer “principal”) é estendido por um caso de uso menor (seria melhor dizer “alternativo”).​ Gabarito: C

Estava na aula: Relacionamento de Extensão: utilizado quando se deseja modelar um relacionamento alternativo. A imagem abaixo apresenta o contexto de um fórum de discussões. Observem que para cadastrar um usuário, há duas opções: moderador ou administrador. Logo, é um relacionamento opcional, representado por uma linha tracejada com uma seta na ponta.

 

 

89. (CESPE – 2017 – SE/DF – Analista de Sistemas) Para auxiliar na gerência de riscos e prevenir insatisfações das partes interessadas, deve-se dificultar as modificações na especificação dos requisitos.

Comentários: Hahaha… essa questão é engraçada! Como assim, cara? Você vai dificultar as modificações na específicação dos requisitos do produto de um cliente? Imaginem vocês chegarem em um pedreiro e falarem: “Amigão, eu tinha falado que queria essa lâmpada aqui, mas eu mudei de ideia e agora eu quero ela ali”. E o pedreiro dificultar a modificação que você quer fazer na sua própria casa. Isso não faz sentido – você é o cliente! E como isso previne insatisfação das partes interessadas? Com certeza, você vai ficar irritadíssimo! Gabarito: E

 

 

90. (CESPE – 2017 – SE/DF – Analista de Sistemas) Um dos objetivos da engenharia de requisitos é integrar tarefas, técnicas, orientações, responsabilidades e papéis em fluxos de trabalho.

Comentários: Isso foi retirado do livro Engenharia de Requisitos: Software Orientado ao Negócio, de Carlos Eduardo Vazquez e Guilherme Siqueira. Segue o trecho: “A Engenharia de Requisitos facilita a interação com o cliente em termos de identificar e entender suas necessidades e na obtenção de um acordo da solução que será entregue. Ela descreve e integra tarefas, técnicas, orientações, papeis e responsabilidade em fluxos de trabalho que: tem início com o entendimento da necessidade do cliente; e passam pelo acordo sobre a solução que será construída”.

 

 

91. (CESPE – 2017 – SE/DF – Analista de Sistemas) É comum que uma especificação de requisitos inclua as interfaces externas do software.

Comentários: Isso foi retirado do livro Engenharia de Requisitos: Software Orientado ao Negócio, de Carlos Eduardo Vazquez e Guilherme Siqueira. Segue o trecho: “Lista de Requisitos Funcionais: descreve tarefas e serviços que serão fornecidos pelo sistema aos seus usuários (Exemplo: lista de casos de uso, histórias do usuário). Incluir também as interfaces externas do software”. E isso realmente faz todo sentido. A especificação de requisitos deve contemplar as interfaces externas do software. Gabarito: C

 

 

92. (CESPE – 2017 – SE/DF – Analista de Sistemas) O padrão command tem como definição passar uma requisição entre uma lista ou objetos encadeados para a execução de uma ação ou o acionamento de um evento em um momento posterior.

Comentários: A questão já deu a dica: “objetos encadeados”. Pois é, a questão trata do padrão Chain of Responsability. De fato, são padrões um pouco parecidos, no entanto o padrão Command é basicamente um comando encapsulado em um objeto; e o padrão Chain of Responsability é um objeto tentando manipular algo – caso não consiga, passa para outro objeto, e para outro e para outro, formando-se uma “cadeia de responsabilidades. Gabarito: E

Estava na aula: Chain of Responsability: evita o acoplamento do remetente de uma requisição ao seu receptor ao dar a mais de um objeto a chance de lidar com a requisição.

 

 

93. (CESPE – 2017 – SE/DF – Analista de Sistemas) O isolamento dos códigos de construção e representação é um dos objetivos do padrão builder.

Comentários: Conforme vimos em aula, a questão está perfeita!​ Gabarito: C

Estava na aula: Builder: separa a construção de um objeto complexo da sua representação, de forma que o mesmo processo de construção possa criar diferentes tipos de representações.

 

 

94. (CESPE – 2017 – SE/DF – Analista de Sistemas) No padrão GRASP, a alta coesão (high cohesion) serve para mensurar quão fortemente uma classe está conectada a outras classes.

Comentários: Não confundam esses dois padrões! Coesão trata de divisão de responsabilidades e Acoplamento trata da dependência entre partes/componentes. A questão trata do segudo caso: Acoplamento.​ Gabarito: E

Estava na aula: Low Coupling:

 

 

95. (CESPE – 2017 – SE/DF – Analista de Sistemas) O padrão de projeto estrutural bridge fornece um objeto substituto, que faz referência a outro objeto.

Comentários: Essa também ficou fácil! Falou em objeto substituto: Padrão Proxy.​ Gabarito: E

Estava na aula: Proxy: provê um substituto ou ponto através do qual um objeto pode controlar o acesso a outro objeto.

 

 

96. (CESPE – 2017 – SE/DF – Analista de Sistemas) Serviços expressos por meio de contratos web services têm o potencial de evitar completamente a transformação, objetivo-chave dos contratos de serviços padronizados.

Comentários: Galera, essa questão afirma que quando eu ofereço serviços por meio de Web Services e seus contratos (i.e., suas interfaces), eu tenho um grande potencial de evitar a transformação. Isso é verdade! Nós sabemos que mudar a implementação do serviço é irrelevante desde que se mantenha sua interface. No entanto, eventualmente eu posso precisar alterar a interface de um serviço – e, nesse caso, não dá para evitar a transformação do contrato do serviço. Logo, o contrato não é imutável, ele realmente muda raramente, mas ele não é imune a mudanças e não evita completamente transformações. No entanto, a questão afirma que o uso de contratos tem o “potencial” de evitar completamente a transformação. Ter o potencial significa ter a capacidade de realização ou execução de algo. E isso é verdadeiro nesse contexto. Gabarito: C

 

 

97. (CESPE – 2017 – SE/DF – Analista de Sistemas) Por oferecerem um framework de comunicação com base em contratos de serviços fisicamente desacoplados, os web services permitem que um contrato de serviços seja totalmente padronizado, independentemente de sua implementação.

Comentários: Conforme eu disse na questão anterior, contratos de serviços (interfaces) espalhadas pela rede e desacopladas, permitindo que o contrato seja padronizado, sendo sua implementação irrelevante. Gabarito: C

Estava na aula: Um Web Service é um sistema de software projetado para permitir interoperabilidade na interação entre máquinas através de uma rede. É descrito através de uma interface padronizada que disponibiliza um serviço em uma rede de computadores, geralmente a Internet. Uma vez descrito na forma padrão e catalogado, o serviço se torna um componente de software totalmente reutilizável.

 

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