TCE/SC – 2016 – Comentários de Informática

Fala, galera ;)

 

Amanhã viajo para as minhas tão merecidas férias, mas tirei um tempinho agora de madrugada para comentar rapidamente a prova do TCE/SC. A prova foi bem tranquila da nossa parte, exceto pelas malditas questões de ferramentas. Vamos lá…

 

54. A métrica de contagem de pontos por função, disseminada pelo IFPUG (International Function Point User Group) e constituída na evolução das métricas de linhas de código (LOC), visa estimar recursos para projetos de softwares orientados a objetos a partir de documentos de visão e de casos de uso.

 

Comentário: A métrica do IFPUG é constituída na evolução das métricas de linhas de código (LOC)? Nunca! Já podemos parar por aqui – não há nenhuma relação com métricas de linhas de código.

Gabarito Preliminar: Errado.

 

55. Altos valores na métrica Fan-in são indicativo de que uma função possui acoplamento significativo com o restante do projeto, uma vez que essa métrica conta o número de funções que chamam outras, diferentemente da métrica Fan-out, a qual se centra no número de funções que são chamadas por uma função.

 

Comentário: Fan-in é uma medida do número de funções ou métodos que chamam alguma outra função ou método (digamos X). Fan-out é o número de funções chamadas pela função X. Um valor alto para fan-in significa que X está firmemente acoplado com o resto do projeto, e mudanças em X terão grande impacto.

Gabarito Preliminar: Certo.

 

56. As técnicas estáticas de verificação centram-se na análise manual ou automatizada do código-fonte do programa, enquanto a validação dinâmica tem por objetivo identificar defeitos no programa e demonstrar se ele atende a seus requisitos.

 

Comentário: Técnicas estáticas de verificação, de fato, centram-se na análise do código-fonte (i.e., sem executar o programa); já técnicas de validação dinâmica executam o software para encontrar defeitos e demonstrar se ele atende aos seus requisitos.

Gabarito Preliminar: Certo.

 

57. Para se assegurar que o sistema opere com a carga necessária, são realizados testes de desempenho em que se aumenta progressivamente a carga até que se possa definir se o desempenho do sistema está aceitável.

 

Comentário: Calma lá, essa questão é polêmica! Se eu aumentar progressivamente a carga até o sistema falhar, trata-se de um Teste de Carga. Se eu o fizer apenas para verificar se desempenho do sistema está aceitável, eu estou fazendo um teste de desempenho. Essa questão é muito sutil e foi retirada do Sommerville: “Após o sistema ter sido completamente integrado, é possível testá-lo em relação às propriedades emergentes (veja Capítulo 2), como desempenho e confiabilidade. Os testes de desempenho devem ser projetados para assegurar  que o sistema pode operar na carga necessária. Isso envolve, geralmente, o planejamento de uma série de testes em que a carga é constantemente aumentada até que o desempenho se torne inaceitável”. 

Gabarito Preliminar: Certo.

 

58. Depois de ordenados os requisitos do product backlog pelo time de desenvolvimento, o Product Owner avalia a qualidade dos produtos entregues para certificar que os desenvolvedores realizaram adequadamente as avaliações de mercado e as necessidades dos clientes do produto. Práticas de estimativa, como burndown, em conjunto com gráficos de barra, são úteis para estabelecer o burndown baseline e auxiliar o time de desenvolvimento a gerir a complexidade
do projeto.

 

Comentário: Você começa ler a questão: “Depois de ordenados os requisitos do product backlog pelo time de desenvolvimento (…)” e já pode parar. Quem ordena os itens do Product Backlog é o Time de Desenvolvimento? Não, é o PO! Ele é o responsável por ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões.

Gabarito Preliminar: Errado.

 

60. Normalmente, o time do projeto define quando a entrega de uma versão deve ser realizada após analisar o retorno sobre o investimento e avaliar se um conjunto de funcionalidades já pode ser utilizado por clientes e usuários.

 

Comentário: Tudo errado! O que seria o Time do Projeto? Seria o Time Scrum ou o Time de Desenvolvimento? De todo modo, está errado – o responsável por definir quando a entrega de uma versão deve ser realizada após analisar o ROI e avaliar se um conjunto de funcionalidades já pode ser utilizado por clientes e usuários é o Product Owner (PO).

Gabarito Preliminar: Errado.

 

63. A JAX-RS 2.0 fornece APIs portáteis para o desenvolvimento de aplicações Web em conformidade com os princípios do estilo arquitetônico REST.

 

Comentário: Perfeito! O JAX-RS fornece APIs portáteis – com WS-*? Não, com REST!

Gabarito Preliminar: Certo.

 

64. O framework CXF 3.1.5 inclui extensões no padrão que, em comparação com a implementação de referência, facilitam seu uso e, por não requerer um WSDL, gera o código de solicitação e respostas para classes bean.

 

Comentário: É isso aí! O CXF é um framework webservices que não requer WSDL e gera facilmente código de request/response para classes bean.

Gabarito Preliminar: Certo.

 

65. De acordo com as diretivas do Clean Code, o número de argumentos de uma função não deve ser igual ou superior a três, devido a sua influência no entendimento da função.

 

Comentário: Robert C. Martin diz: The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification — and then shouldn’t be used anyway. Logo, questão perfeita!

Gabarito Preliminar: Certo.

 

66. Um dos modos de análise de código-fonte constante no SonarQube é o publish, que analisa completamente o código e o envia para o servidor que irá processá-lo e salvar os resultados no banco de dados.

 

Comentário: Existem dois modos – Preview e Publish (padrão). Esse último analisa tudo que for possível e manda o resultado par aum servidor processar e salvar o resultado no banco de dados (Publish mode performs a full analysis on the entire code base and sends it to the server, which will process it and save the results to the database).

Gabarito Preliminar: Certo.

 

67. Em navegadores que não possuem apoio para a função JavaScript JSON.parse, pode-se utilizar a função eval para converter um texto JSON em um objeto JavaScript, por meio da sintaxe apresentada a seguir. var obj = eval (“(” + text + “)”);

 

Comentário: Há navegadores que realmente não suportam JSON.parse( ). A solução de contorno realmente é usar eval( ) e converter o texto JSON em um objeto JS – você deixará o sistema mais vulnerável a ataques, por isso não é a solução ideal. Galera, fiquem tranquilos! Essa questão foi feita para que ninguém acertasse mesmo – eu tive que pesquisar!

Gabarito Preliminar: Certo.

 

68. O XSLT é utilizado para adicionar e(ou) remover elementos e atributos do arquivo de saída e para transformar um documento XML em um documento HTML ou XHTML, ou, ainda, em outro documento XML.

 

Comentário: XSLT é uma linguagem para transformação de Documentos XML em outros formatos reconhecidos por um navegador web (XML, XHTML, HTML e outros). Em geral, ele faz isso ao transformar cada Elemento XML em Elemento (X)HTML. É possível adicionar ou remover elementos e atributos de/para um arquivo de saída, ou mesmo reorganizar elementos, executar testes, entre outros.

Gabarito Preliminar: Certo.

 

69. Quando a segurança e a implantação do Apache Maven são configuradas, os repositórios são definidos em um projeto na seção <distributionManagement>, na qual devem-se inserir um nome de usuário e uma senha.

 

Comentário: Outra questão para ninguém acertar – fiquem relaxados! A documentação do Maven diz: Repositories to deploy to are defined in a project in the distributionManagement section. However, you cannot put your username, password, or other security settings in that project. Observem que não se pode inserir nome de usuário, senha e outras configurações de segurança.

Gabarito Preliminar: Errado.

 

70. Utilizar validação de entrada e codificação de saída, assegurar a abordagem de metacaracteres e evitar consultas parametrizadas fortemente tipificadas são ações compatíveis com as práticas de programação segura relacionadas a bases de dados.

 

Comentário: Essa questão foi retirada do OWASP. Era para acertar? Só se você for um ninja! Essas são apenas algumas das dezenas de recomendações de segurança – não vale a pena decorar! Quem errou, fica tranquilo! Essa questão está errada porque não se deve evitar consultar parametrizadas fortemente tipificadas – isso na verdade é recomendado.

Gabarito Preliminar: Errado.

 

Bacana, galera? Comentário rápido! Boa sorte e precisando é só chamar ;)