ID 17773 Banca CESGRANRIO Órgão BNDES Ano 2008 Provas CESGRANRIO - 2008 - BNDES - Profissional Básico - Análise de Sistemas - Desenvolvimento Disciplina Engenharia de Software Assuntos Metodologia de desenvolvimento de software Modelos de Sistemas de Informação Suponha que um projeto de software siga o modelo cascata e utilize técnicas de refatoração apoiadas por uma ferramenta durante a etapa de implementação. Qual o impacto resultante na etapa de análise e projeto? Alternativas Pode aumentar o trabalho do analista, pois o código deve estar preparado para utilizar as técnicas de refatoração. Pode aumentar o trabalho do analista se o profissional que realizar a etapa de análise for diferente do profissional que implementará o software. Pode diminuir o trabalho do analista, mas apenas se o profissional que realizar a etapa de análise for o mesmo que implementar o software. Pode diminuir o trabalho do analista, já que o profissional de análise e projeto saberá que mudanças futuras no modelo gerado durante essa etapa poderão ser realizadas com um custo menor na etapa de implementação. Não terá impacto se o profissional já conhecer as técnicas de refatoração. Responder Comentários Achei uma pergunta um tanto capciosa do examinador, porque existem diversos aspectos envolvidos em um projeto de software que podem influir de modo favorável ou prejudicial ao se utilizar 'refactoring'. Um deles, de grande relevância, é o uso de testes unitários e funcionais. A XP se baseia efetivamente nisso, desenvolver os testes primeiramente. E sem um bom projeto de testes, fazer refatoração pode até ser desastroso em alguns casos.Mas partindo do pressuposto de "condições normais de temperatura e pressão (CNTP)" eu pensei do seguinte modo: o gestor responsável pela fase de análise e projeto ficaria bem mais tranquilo porque ao promover mudanças no modelo estas seriam implementadas mais facilmente e com mais segurança num código refatorado, pois este tem como premissas ser mais claro (limpo, fácil de entender e de manter) e funcional. Quando se utiliza uma ferramenta de refatoração o custo das mudanças na implementação são reduzidos, consequentemente pode-se fazer um projeto menos aprofundado pois caso se encontre algum erro o custo para correção deste é reduzido quando comparado aos projetos que não utilizam tais ferramentas.Esse conceito foi extraído do livro de refatoração do Martin Fowler. Segue o trecho do livro que trata a respeito:As refactoring becomes less expensive, design mistakes become less costly. Because it is less expensive to fix design mistakes, less design needs to be done up front. Upfront design is a predictive activity because the requirements will be incomplete. Because the code is not available, the correct way to design to simplify the code is not obvious. In the past, we had to livewith whatever design we initially created because the cost to change the design was too great. With automatic refactoring tools, we can allow the design to be more fluid because changing it is much less costly. Given this new set of costs, we can design to the level of the current problem knowing that we can inexpensively extend the design to add additional flexibility in the future. Nolonger do we need to attempt to predict every possible way the system might change in the future. If we find that the current design makes the code awkward with the smells described in Chapter 3, we can quickly change the design to make the code clean and maintainable. Gostei da citação que o Renato fez. Muito bom o livro do Fowler...O que Fowler quis dizer foi que antigamente, corrigir um erro de programação ou acabar com a ambiguidade ou simplesmente, refinar o software era muito dispendioso. Qualquer mudança no código tinha um efeito no modelo de análise e no projeto. Com o aparecimento das ferramentas, essas mudanças para melhor nos códigos (refabricação - Pressman) pode ser feita sem medo de aumentar os custos nas etapas anteriores.Antes, quando o modelo de análise estava pronto, quando o projeto estava pronto, o código estava imutável, praticamente. Qualquer refabricação era custoso demais para ser aplicado. Hoje, a história é diferente. Se for necessário otimizar o código, faça. As ferramentas automatizadas lhe ajudarão a encaixar essas mudanças no modelo de análise e no projeto.Lembrando que o modelo de análise é uma abstração do sistema, utilizado para construção do projeto. Complementando: se um analista de análise e projeto sabe que na fase de implementação são usadas ferramentas de refabricação, ele fica mais tranquilo. Não terá que prever o melhor modelo e projeto para ser implementado. Ele poderá desenvolver os modelos e projeto com o que tem no momento. Sabe ainda que quaisquer mudanças nessas etapas serão adaptadas na implementação mais facilmente, pois há o uso das ferramentas automatizadas. Achei o enunciado muito mal escrito.Pois há ambiguidade na frase "mudanças futuras no modelo gerado durante essa etapa poderão ser realizadas com um custo menor na etapa de implementação".Menor custo em relação a implementação sem refactoring? O que torna a alternativa verdadeira.Ou menor custo em relação às outras fases? O que é falso. Pois mudanças na fase de implementação é mais custoso do que na fase de concepção.