MPOG/ATI (2015) – Comentários da Prova de Engenharia de Software

Fala, galera.

Achei a prova mais pesada do que eu esperava. Por conta da última prova (em que sobraram vagas), eu achei que essa viria mais leve, mas não foi tão assim (principalmente a discursiva). Estão dizendo por aí que talvez sobrem vagas de novo… vamos aos comentários (mais tarde tem webinário ao vivo).

76. (Dificuldade: Fácil) Metodologias de desenvolvimento ágil enfocam atividades de projeto e implementação, desconsiderando as atividades de elicitação de requisitos e a produção de documentação.

Errado. É absurdo pensar que se desconsidera atividades de elicitação de requisitos – não há o que se discutir nesse ponto. Além disso, o Manifesto Ágil afirma que, mesmo havendo valor na documentação extensa de software, valoriza-se mais o software em funcionamento. Em outras palavras, é errado afirmar que se desconsidera a produção de documentação, tendo em vista que há uma codificação não formal. Nós ressaltamos isso em aula:

“O manifesto enfatiza que os itens à direita (Documentação Abrangente) têm seu valor, entretanto os itens à esquerda (Software em funcionamento) são mais valorizados! Por que valorizar mais software em funcionamento do que documentação abrangente? Porque apresentar software funcionando aos clientes em uma reunião é mais útil e desejado do que apresentar documentos“.

77. (Dificuldade: Fácil) No ciclo de vida do software, o congelamento dos requisitos do software garante que este, quando em desenvolvimento, atenda à expectativa do usuário, desde que tudo que tenha sido requisitado seja implementado.

Errado. Requisitos não são estáticos, são dinâmicos e precisam ser refinados constantemente. O processo de definição de requisitos gera um feedback que acaba modificando os próprios requisitos. Dessa forma, é evidente que o congelamento de requisitos não garante o atendimento à expectativa do usuário. Em geral, usuários não sabem o que querem; aqueles que sabem, mudam de opinião durante o processo de desenvolvimento de software. Logo, mesmo que tudo que foi requisitado tenha sido implementado, pode não atender às expectativas do usuário, tendo em vista que, logo após o congelamento dos requisitos, o usuário pode muito bem querer modificá-lo.

78. (Dificuldade: Fácil) A aplicação da análise de pontos de função determina o custo do software a ser desenvolvido, independentemente dos índices de produtividade de cada empresa.

Errado. A APF permite determinar indiretamente o custo do software a ser desenvolvido, no entanto é necessário saber históricos de índices de produtividade de cada empresa. Conforme eu disse em aula:

79. (Dificuldade: Difícil) A métrica conhecida como resposta para uma classe relaciona o nível de complexidade de uma determinada classe com a quantidade de interações que ela faz com objetos de outras classes.

Errado. A banca foi muito, mas muito profunda nesse item! Eu confesso que nunca havia ouvido falar nessa métrica. Trata-se de uma métrica orientada a objetos, criada em 1994, chamada Response for a Class (Resposta para uma Classe) e mede a complexidade de uma classe por meio da quantidade de métodos diferentes que potencialmente podem ser executados em resposta a uma mensagem recebida por um objeto dessa classe. Dessa forma, não se trata da quantidade de interações que ela faz com objetos – é mais específico: é a quantidade de métodos que podem ser executados em uma classe, em resposta a uma solicitação (invocação de um método). Quanto maior, mais difícil será de manter e testar a classe. Logo, se o objeto de uma Classe X recebe uma mensagem e ele pode potencialmente executar cinco métodos dentro dessa classe, então RFC = 5.

80. (Dificuldade: Média) A aplicação de métricas estáticas de produto é comumente usada para se avaliar a complexidade de um software.

Correto. As métricas dinâmicas são aquelas coletadas durante a execução de um programa; as métricas estáticas são aquelas coletadas de representações do sistema como projeto, programa ou documentação. De fato, é comum utilizar métricas estáticas para avaliar a complexidade e manutenção de um software, por meio – por exemplo – de um Modelo de Design.

“Professor, como uma organização consegue saber qual deve ser a produtividade esperada para um projeto que ainda irá se iniciar? Bem, isso pode ocorrer de duas maneiras: ela pode manter um repositório privado com dados sobre seus projetos anteriores ou ela pode utilizar um repositório público com dados de diversos projetos para realizar essas estimativas“.

84. (Dificuldade: Fácil) Uma forma de validação dos requisitos é a geração de casos de teste para os requisitos documentados.

Correto. Foram explicitadas três técnicas de validação de requisitos: Revisão de Requisitos, Prototipação e Geração de Casos de Teste. Para este último, foi dito em aula:

“Enfim, uma série de técnicas de validação de requisitos pode ser usada em conjunto ou individualmente, entre elas: Geração de Casos de Teste – os requisitos devem ser testáveis. Se os testes dos requisitos forem criados como parte do processo de validação, eles frequentemente revelarão problemas de requisitos. Se um teste for difícil ou impossível de ser projetado, significa geralmente que os requisitos serão difíceis de serem implementados e devem ser reconsiderados para implementação”.

85. (Dificuldade: Fácil) A definição de um protótipo para a validação dos requisitos pode tornar o processo de requisitos mais barato e mais simplificado, já que ele vai corresponder à real forma de uso do sistema a ser construído.

Errado. Observem que a questão afirma que ‘pode tornar o processo mais barato e simplificado’. Quando o item afirma que ‘pode’, ele abre margem para muitas interpretações – facilitando nossa vida. E, sim, ele pode tornar o processo mais barato e simplificado. No entanto, o protótipo não necessariamente vai corresponder à real forma de uso do sistema a ser construído. Na verdade, o protótipo, em geral, é utilizado para validar requisitos de alto nível, logo ele não vai contemplar diversas funcionalidades que estarão no sistema real. Pressman afirma:

“Yet, prototyping can be problematic for the following reasons: 1. Stakeholders see what appears to be a working version of the software, unaware that the prototype is held together haphazardly, unaware that in the rush to get it working you haven’t considered overall software quality or long-term maintainability. When informed that the product must be rebuilt so that high levels of quality can be maintained, stakeholders cry foul and demand that “a few fixes” be applied to make the prototype a working product. Too often, software development management relents”.

86. (Dificuldade: Fácil) Os requisitos não funcionais a serem especificados estabelecerão restrições que devem ser seguidas por todo o sistema da referida empresa, podendo até mesmo levar à necessidade de definição de requisitos funcionais.

Correto. Observem novamente que a questão afirma ‘podendo até levar’, logo ela abre margem para muitas interpretações – facilitando nossa vida. E, sim, a definição de requisitos não-funcionais pode levar a definição de requisitos funcionais.

87. (Dificuldade: Fácil) Para a elicitação dos requisitos, é indicada à empresa a realização de um workshop de requisitos, em que seja determinado um facilitador, mesmo que sem grande experiência com os processos de gerenciamento de requisitos.

Correto. Bem, alguns podem argumentar que não é técnica mais indicada. No entanto, a questão não afirma isso, ela apenas afirma que é indicada – e, de fato, ela é indicada para elicitação de requisitos. Além disso, conforme eu disse em aula, o facilitador deve ser neutro e responsável por atividades de logística, organização, etc. Muitas vezes, ele não precisa ser sequer um cara da área de tecnologia, pode ser um cara da área de gestão de pessoas, por exemplo. Seu papel é facilitar o workshop, mas – similar ao Scrum Master no contexto de Gestão de Projetos de Desenvolvimento de Software – não precisa ter nenhuma experiência específica no gerenciamento de requisitos. A questão poderia até ser passível de recurso se falasse ‘sem experiência alguma’, mas como ela disse apenas ‘sem GRANDE experiência’, eu a avalio como correta. O facilitador deve ter experiência em facilitar Conforme vimos em aula:

“Reunião estruturada e intensiva entre analistas e usuários com o intuito de obter um conjunto de requisitos bem definidos. Possui um facilitador neutro responsável pelas atividades de logística e promoção de momentos de descontração, como forma de dinamizar o trabalho em equipe. Permite utilizar técnicas como brainstorming ou interpretação de papéis”.

88. (Dificuldade: Médio) As mudanças de requisitos em processos ágeis de desenvolvimento não seguem um processo formal de gerenciamento de requisitos

Correto. De fato, as mudanças de requisitos em processos ágeis de desenvolvimento seguem um processo mais informal de gerenciamento. Não há, por exemplo, documentação extensa ou matrizes de rastreabilidade. Metodologias ágeis não podem se dar ao luxo de processos formais, em geral.

89. (Dificuldade: Fácil) As informações de rastreabilidade de requisitos possibilitam a realização de estimativa do custo de mudanças em requisitos

Correto. Mais uma vez, a banca nos ajuda com esse ‘possibilitam’. Como a rastreabilidade permite avaliar impacto, possibilita estimar o custo de mudanças em requisitos. Conforme foi dito em aula:

“É preciso manter o acompanhamento dos requisitos individuais e manter as ligações entre os requisitos dependentes, de modo que seja possível avaliar o impacto das mudanças de requisitos (rastreabilidade). É necessário, também, estabelecer um processo formal para fazer propostas de mudança e ligá-las aos requisitos de sistema”.

90. (Dificuldade: Fácil) Tão logo exista uma versão do documento de requisitos, o processo de gerenciamento de requisitos deverá ser iniciado.

Correto. Essa questão estava quase ipsis litteris em nosso material. Vejam abaixo:

“O processo de gerenciamento de requisitos deve se iniciar assim que uma versão inicial do documento de requisitos esteja disponível, mas o planejamento das mudanças de requisitos deve ser iniciado durante o processo de elicitação de requisitos. A evolução de requisitos, durante o processo de engenharia de requisitos e após a entrada de um sistema em operação, é inevitável”.

91. (Dificuldade: Difícil) Em arquiteturas orientadas a serviço, um serviço deve ser implementado de forma a garantir um fraco acoplamento.

Correto. Para quem participou do curso, ficou fácil. Nós dissemos que há, entre os princípios da Arquitetura Orientada a Serviços, o Princípio do Baixo/Fraco Acoplamento (Service Loose Coupling).

92. (Dificuldade: Difícil) Embora normalmente os sistemas desenvolvidos se baseiem em padrões de arquitetura, cada um deles tem arquitetura totalmente específica, em consequência dos seus requisitos.

Errado. De fato, eu posso usar padrões de arquitetura, tais como uma arquitetura em camadas, uma arquitetura distribuída, uma arquitetura mainframe ou uma arquitetura orientada a serviços. Embora cada sistema tenha uma arquitetura baseada em seus requisitos, elas não são TOTALMENTE específicas.

94. (Dificuldade: Difícil ) As informações relativas a formato de protocolo e mensagem são associadas às operações (elementos operation) por meio de elementos binding.

Correto. Nós vimos em aula que o elemento <operation> trata da especificação das assinaturas das operações disponibilizadas (na seção abstrata) e o elemento <binding> trata dos protocolos de comunicação utilizados (na seção concreta). Os elementos <binding> associam detalhes de formato de protocolo e mensagem às operações.

95. (Dificuldade: Difícil) Em uma arquitetura de portal corporativo, a camada web é a responsável por prover a integração com os sistemas de bancos de dados da organização.

Errado. Quem participou do curso viu em nossa aula as quatro camadas. A questão trata da Camada de Conectores e, não, Web.

“Aplicações Web: engloba uma grande variedade de soluções, dependendo de seu contexto, tais como: intranet, internet, correio eletrônico, fórum de discussões, business, groupware, workflow, CMS, etc. Conectores: essa camada é responsável pelo controle de acesso e integração entre sistemas de informações, tais como bancos de dados, sistemas legados, ERP, CRM, entre outros”.

É isso, espero que vocês tenham gostado! Grande abraço e até a próxima…