GABARITO COMENTADO TRF 3ª Região – Informática – Engenharia de Software

Prezados amigos, a FCC acabou de divulgar o gabarito oficial das provas do TRF3.

Seguem nossos comentários às questões de engenharia de software.

Prova de Analista Judiciário – Informática

Alta coesão e baixo acoplamento são características positivas, isto é, desejáveis em um software. Alta coesão significa que os módulos do sistema têm responsabilidades bem delimitadas e não extrapolam essas responsabilidades. Baixo acoplamento significa que o nível de dependência entre os módulos do sistema é baixo. Negritei o termo módulos para destacar que os conceitos de alta coesão e baixo acoplamento são princípios essenciais de modularidade do sistema, isto é, da forma como o sistema de decompõe em módulos.

Gabarito letra B

---

Nesta questão, achei o termo “falhas não são toleráveis” muito forte, mas ok. Pelo menos estava no comando do enunciado e não nas alternativas. O mais correto, em vez de “falhas não são toleráveis” seria dizer que há um “foco na análise e mitigação de riscos”. Mas vamos lá.

O modelo de processo de software que tem esse foco na análise de riscos e no planejamento e que, além disso, as atividades são apoiadas pela geração de protótipos é o espiral.

Tenha sempre em mente essa figura do processo espiral. O quadrante 2 (Identify and resolve risks) é a etapa em que é feita a análise de riscos. O quadrante 4 (Plan the next iteration) é a etapa onde se faz o planejamento. Ao completar cada volta da espiral é gerada uma nova versão mais incrementada do protótipo.

Gabarito letra C

---

O avaliador nesta questão está querendo saber qual o nome da atividade do SCRUM em que se abordam os 3 tópicos:

• atualizar o que já foi feito => passado
• o que será feito => futuro
• dificuldades => presente

Observe que os tópicos referem-se a 3 momentos: passado, futuro e presente. Isso é feito na reunião de Daily Scrum, letra D. Trata-se de uma reunião diária realizada normalmente em pé (bem rápida) onde os membros da equipe abordam justamente esses 3 tópicos.

Poderíamos facilmente eliminar as alternativas B (Sprint Backlog), C (Spring Goal) e E (Product Backlog) pois as 3 se referem a artefatos e não a atividades. A letra A (Sprint Review) poderia ser eliminada porque, apesar de ser uma atividade, ela se refere somente ao passado, isto é, tudo o que ocorreu na Sprint que acabou de terminar. Somente a atividade Daily Scrum tem os 3 componentes requeridos de passado, presente e futuro.

Gabarito letra D

---

Questão imediata sobre técnica de levantamento de requisitos. A técnica onde é possível descrever como os funcionários de determinada área realmente trabalham no dia-a-dia é o estudo etnográfico, ou etnografia.

Nessa técnica, o analista de requisitos, em vez de entrevistar os funcionários, ele submerge no cotidiano da empresa para observar as pessoas trabalhando em situações reais. Desta forma, ele consegue extrair requisitos de software relativos à forma de como as pessoas realmente trabalham.

Gabarito letra B

---

Sempre que pensamos em Caso de Uso vem à mente o Diagrama de Caso de Uso da UML, em que os atores são representados pelos “bonecos” e as funcionalidades do sistema pelos balões.

Mas a verdade é que o Caso de Uso também pode ser apresentado como nesta questão, em linguagem textual (não gráfica). Repare que o texto apresentou diversas funcionalidades do sistema de forma contínua e em uma linguagem real. Por isso dizemos que a descrição é contínua de Caso de Uso com formato real.

Gabarito letra C

---

Vocês sabem que há 2 tipos de polimorfismo. O polimorfismo estático é implementado via sobrecarga de métodos, em que métodos com o mesmo nome se diferenciam pela sua lista de seus parâmetros. E o polimorfismo dinâmico que é implementado via sobrescrita de métodos.

O polimorfismo estático pode ser verificado em tempo de compilação e o dinâmico somente em tempo de execução.

O gabarito oficial desta questão é letra C. A FCC estava querendo se referir ao polimorfismo estático, que ocorre via sobrecarga de métodos. Na sobrecarga de métodos, temos na mesma classe diversos métodos com mesmo nome que se diferenciam pela lista de argumentos (ou parâmetros) que cada método recebe como entrada. A FCC não usou o termo “argumento” nem “parâmetro”, que são os termos corretos. Em vez disso, usou o termo “atributo”. No nosso entender, o termo “atributo” não se aplica neste caso e a alternativa C está imprecisa.

---

Mais uma imprecisão da FCC. Nesta questão, ela está querendo explorar atributos de classe com visibilidade private. Só que na última frase do comando do enunciado ela escreve “Assim, considerando que uma classe tenha sido criada com a visibilidade private …”. Na verdade, não é a classe que foi criada com visibilidade private, mas sim os seus atributos. Enunciado mal feito na nossa opinião, mas vamos lá.

Quando os atributos de uma classe são declarados como private o acesso a esses atributos deve ser feito somente por operações (métodos) da própria classe. Ou seja, os atributos private são visíveis somente pela própria classe. O nível de visibilidade private é o mais restritivo de todos.

Gabarito letra E

---

Nesta questão foi apresentado um modelo de processo de software onde se observa claramente uma preocupação em gerar releases (versões). Observe que após a especificação é gerada uma versão inicial. Durante o desenvolvimento são geradas versões intermediárias. E após a validação é gerada uma versão final.

Cada versão (ou release) é um incremento no software. Não resta dúvida que o modelo de processo de software apresentado é de desenvolvimento incremental.

Gabarito letra B

---

Mais uma questão de modelo espiral. A geração dos protótipos ocorre no quadrante 2, de análise de riscos (Identify and resolve risks). Essa análise de riscos ocorre antes da prototipação, conforme podemos observar no esquema.

Gabarito letra D

---

Nesta questão está sendo pedido o artefato de projeto que reúne as seguintes informações:

• como o trabalho será feito =>processo
• antecipação de eventuais problemas e soluções alternativas => análise de riscos

O artefato que formaliza essas questões é o plano de projeto.

Gabarito letra D

---

Numa visão espiral, a especificação de requisitos ocorre de forma em uma ordem intuitiva top-down, em que primeiramente se abordam os requisitos de negócio (para que o projeto atenda à necessidade de negócio de quem contratou o software), depois se abordam requisitos de usuário (mais próximos do processo de negócio da organização) e por último os requisitos de sistema, que são a tradução técnica dos requisitos de usuário.

Gabarito letra A

---

Antes de especificar os requisitos, isto é, gerar o Documento de Especificação de Requisitos, deve-se realizar as etapas de:

• descoberta (elicitação) para levantar os requisitos
• classificação e organização
• priorização e negociação (gerenciamento) de requisitos

Somente após essas 3 etapas é que podemos especificar os requisitos. Isso ocorre porque na etapa de priorização e negociação pode acontecer de alguns requisitos levantados na fase de descoberta serem descartados.

Gabarito letra E

---

O requisito 1 estabelece um tempo de resposta máxima do sistema (15 milissegundos). Isso é uma restrição, um requisito não funcional (NF) de performance.

O requisito 2 fala de uma funcionalidade de pesquisa. Requisito funcional (RF).

O requisito 3 fala de uma funcionalidade de geração de um relatório de juízes disponíveis. Requisito funcional (RF).

O requisito 4 fala de restrições operacionais do sistema. Portanto, requisito não funcional (NF).

Resumindo, a ordem é NF – RF – RF – NF.

Gabarito letra C

---

No RUP, o fluxo que inclui a geração da release, distribuição e instalação do software no local de trabalho dos usuários é a Implantação.

É uma das etapas finais do projeto. Só é possível implantar o software quando ele chega ao ponto de ser funcional, operacional. Observe como a disciplina de Implantação no esquema do RUP só se intensifica no final do projeto, entre a fase de Construção e Transição.

Gabarito letra B

---

É a 2a vez nesta prova que é cobrado conhecimento da Reunião Diária do Scrum, também conhecida como Daily Scrum.

Como vimos na questão 23, o objetivo dessa reunião é

• atualizar o que já foi feito => passado
• o que será feito => futuro
• dificuldades => presente

Ela tem um tempo delimitado de 15 minutos e serve para o time de desenvolvimento sincronizar as atividades (o que foi feito no passado, 24h anteriores) e criar um plano para as próximas 24h (o que será feito em seguida e como serão resolvidas as dificuldades).

Gabarito letra D

---

Resumo da ópera. As questões de Engenharia de Software estavam bem diretas, como de costume na FCC. Ou sabe ou não sabe. Não há muito raciocínio a desenvolver. O aluno bem preparado se sairia bem nessas questões. Vimos todos os assuntos cobrados no nosso curso aqui no Direção, sem exceção.

Encontramos imprecisões nos enunciados das questões 27 e 28, que podem dar margem a pedidos de anulação.

Boa sorte nas próximas etapas deste concurso!