\n\tFala, 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á…\n<\/p>\n
\n\t \n<\/p>\n
\n\t \n<\/p>\n
\n\t79. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>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.\n<\/p>\n \n\tComentários: <\/strong>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:<\/strong> C\n<\/p>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t80. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>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.\n<\/p>\n \n\tComentários: <\/strong>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:<\/strong> E\n<\/p>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t81. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>Quaisquer erros cometidos na fase de planejamento somente serão detectados na fase de finalização.\n<\/p>\n \n\tComentários: <\/strong>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:<\/strong> E\n<\/p>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t82. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>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.\n<\/p>\n \n\tComentários: <\/strong>Conforme vimos em aula, a questão está perfeita! É aquela hora de lavar a roupa suja com a equipe.\u200b Gabarito:<\/strong> C\n<\/p>\n \n\tEstava 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<\/strong>. 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<\/strong>.<\/em><\/span>\n<\/p>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t83. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>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.\n<\/p>\n \n\tComentários: <\/strong>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!\u200b Gabarito:<\/strong> C\n<\/p>\n \n\tEstava na aula: Kanban significa Cartão ou Placa Visual, em japonês. O Kanban é um método para gestão de mudanças <\/strong>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.<\/em><\/span>\n<\/p>\n \n\t\tComo dito no início, Kanban também é uma espécie de cartaz ou placa visual contendo vários post-its (aquele papelzinho colorido para colar lembretes). Ele permite uma melhor visualização do fluxo de trabalho, favorecendo a transparência<\/strong>. Ademais, permite mudar prioridades facilmente e entregar funcionalidades a qualquer momento. Não há preocupação com iterações ou estimativas.<\/em><\/span>\n\t<\/p>\n<\/div>\n \n\t \n<\/p>\n \n\t\t \n\t<\/p>\n<\/div>\n \n\t84. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>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.\n<\/p>\n \n\tComentários: <\/strong>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.\u200b Gabarito:<\/strong> E\n<\/p>\n \n\tEstava 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.<\/em><\/strong> 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. <\/em><\/span>\n<\/p>\n \n\t\tCaso não haja ainda nada estimado no Product Backlog, a equipe localiza a história de usuário com o menor esforço para desenvolvimento e o utiliza como base de comparação. Uma das melhores formas de estimar Story Points é por meio de uma técnica chamada Planning Poker, que não está no guia oficial, mas que é frequentemente utilizada tanto para estimar esforço como para estimar tamanho.<\/strong><\/em><\/span>\n\t<\/p>\n<\/div>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t85. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>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.\n<\/p>\n \n\tComentários: <\/strong>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:<\/strong> C\n<\/p>\n \n\tEstava 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<\/strong>. <\/em><\/span>\n<\/p>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t86. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>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.\n<\/p>\n \n\tComentários: <\/strong>De fato, o modelo de casos de uso representa uma visão funcional do sistema. No entanto, não se incluem todas<\/u><\/strong> as funções, processos funcionais e atores do sistema (palavra-chave importante). Gabarito:<\/strong> E\n<\/p>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t87. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>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.\n<\/p>\n \n\tComentários: <\/strong>[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:<\/strong> C\n<\/p>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t88. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>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.\n<\/p>\n \n\tComentários: <\/strong>[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”).\u200b Gabarito:<\/strong> C\n<\/p>\n \n\tEstava na aula: Relacionamento de Extensão:<\/em><\/strong> 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<\/strong>.<\/em><\/span>\n<\/p>\n \n\t\tExplicando de uma forma mais simples de entender: quando o caso de uso B estende o caso de uso A, significa que quando o caso de uso A for executado o caso de uso B poderá (poderá – talvez não seja) ser executado também. A direção do relacionamento é do caso de uso extensor (aqui o caso de uso B) para o caso de uso estendido (aqui o caso de uso A)<\/strong>.<\/em><\/span>\n\t<\/p>\n<\/div>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t89. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>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.\n<\/p>\n \n\tComentários: <\/strong>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?<\/em> 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”<\/em>. 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?<\/em> Com certeza, você vai ficar irritadíssimo! Gabarito:<\/strong> E\n<\/p>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t90. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>Um dos objetivos da engenharia de requisitos é integrar tarefas, técnicas, orientações, responsabilidades e papéis em fluxos de trabalho.\n<\/p>\n \n\tComentários: <\/strong>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<\/u><\/strong> que: tem início com o entendimento da necessidade do cliente; e passam pelo acordo sobre a solução que será construída<\/em>”.\n<\/p>\n \n\t\tGalera, vou ser sincero com vocês! Eu errei esse item – achei essa descrição absurdamente abstrata e genérica. No entanto, lendo no contexto do livro, faz todo sentido mesmo. Não se martirizem caso tenham errado essa questão :P Gabarito:<\/strong> C\n\t<\/p>\n<\/div>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t91. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>É comum que uma especificação de requisitos inclua as interfaces externas do software.\n<\/p>\n \n\tComentários: <\/strong>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<\/em>”. E isso realmente faz todo sentido. A especificação de requisitos deve contemplar as interfaces externas do software. Gabarito:<\/strong> C\n<\/p>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t92. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>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.\n<\/p>\n \n\tComentários: <\/strong>A questão já deu a dica: “objetos encadeados<\/u><\/strong><\/em>”. 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:<\/strong> E\n<\/p>\n \n\tEstava na aula: Chain of Responsability: evita o acoplamento<\/em><\/strong> do remetente de uma requisição ao seu receptor ao dar a mais de um objeto a chance de lidar com a requisição.<\/em><\/span>\n<\/p>\n \n\t\tPessoal, esse padrão de projeto deve ser utilizado quando se deseja emitir uma solicitação para um dentre vários objetos, sem especificar explicitamente o receptor ou quando mais de um objeto é capaz de lidar com a requisição e ele não for conhecido a priori. Também é utilizado quando um conjunto de objetos que podem lidar com uma requisição forem especificados dinamicamente<\/strong>. <\/em><\/span>\n\t<\/p>\n<\/div>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t93. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>O isolamento dos códigos de construção e representação é um dos objetivos do padrão builder.\n<\/p>\n \n\tComentários: <\/strong>Conforme vimos em aula, a questão está perfeita!\u200b Gabarito:<\/strong> C\n<\/p>\n \n\tEstava na aula: Builder: <\/em><\/strong>separa a construção de um objeto complexo<\/strong> da sua representação, de forma que o mesmo processo de construção possa criar diferentes tipos de representações<\/strong>.<\/em><\/span>\n<\/p>\n \n\t\tPessoal, esse padrão de projeto deve ser utilizado quando o algoritmo para criação de um objeto complexo for independente das partes que compõem o objeto e independente de como ele é montado. Ademais, o processo de construção deve permitir diferentes representações para o objeto que será construído<\/strong>. Esse padrão é bastante parecido com o Abstract Factory. <\/em><\/span>\n\t<\/p>\n<\/div>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t94. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>No padrão GRASP, a alta coesão (high cohesion) serve para mensurar quão fortemente uma classe está conectada a outras classes.\n<\/p>\n \n\tComentários: <\/strong>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.\u200b Gabarito:<\/strong> E\n<\/p>\n \n\tEstava na aula: Low Coupling:<\/em><\/strong><\/span>\n<\/p>\n \n\t\tEsse padrão é responsável por ditar como atribuir responsabilidades para apoiar baixa dependência entre classes, como suportar mudanças em uma classe que tenham baixo impacto em outras classes, e maior potencial de reúso. O acoplamento está sempre associado à coesão. Eu sempre decorei assim: “Acoplamento é a dependência entre as partes<\/u>”<\/strong>.<\/em><\/span>\n\t<\/p>\n<\/div>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t95. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>O padrão de projeto estrutural bridge fornece um objeto substituto, que faz referência a outro objeto.\n<\/p>\n \n\tComentários: <\/strong>Essa também ficou fácil! Falou em objeto substituto: Padrão Proxy.\u200b Gabarito:<\/strong> E\n<\/p>\n \n\tEstava na aula: Proxy: <\/em><\/strong>provê um substituto<\/strong> ou ponto através do qual um objeto pode controlar o acesso a outro objeto. <\/em><\/span>\n<\/p>\n \n\t\tPessoal, esse padrão de projeto deve ser utilizado quando houver uma necessidade de uma referência mais versátil ou sofisticada para um objeto do que um simples ponteiro. Por exemplo, proxies virtuais criam objetos caros por demanda e proxies de proteção controlam o acesso ao objeto original<\/strong>. Considerem a hipótese de um sistema que acesse um banco de dados por meio de uma classe de conexão. <\/em><\/span>\n\t<\/p>\n<\/div>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t96. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>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.\n<\/p>\n \n\tComentários: <\/strong>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:<\/strong> C\n<\/p>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t97. (CESPE – 2017 – SE\/DF – Analista de Sistemas) <\/strong>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.\n<\/p>\n \n\tComentários: <\/strong>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:<\/strong> C\n<\/p>\n \n\tEstava 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<\/strong>. Uma vez descrito na forma padrão e catalogado, o serviço se torna um componente de software totalmente reutilizável. <\/em><\/span>\n<\/p>\n \n\t \n<\/p>\n \n\tÉ isso aí, galera! Forte abraço…\n<\/p>\n \n\t \n<\/p>\n \n\t\t \n\t<\/p>\n<\/div>\n \n\t \n<\/p>\n \n\t \n<\/p>\n \n\t <\/p>\n","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":131,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"post_tipo":"article","footnotes":""},"categories":[1],"tags":[],"tax_estado":[],"class_list":["post-62668","post","type-post","status-publish","format-standard","hentry","category-cursos-e-concursos"],"acf":[],"yoast_head":"\n