TCE_SC - 2016 - Comentários de Informática

8/16/2019 TCE_SC - 2016 - Comentários de Informática

1/3

02/06/2016 TCE/SC - 2016 - Comentários de Informática

http://www.estrategiaconcursos.com.br/blog/tcesc-2016-comentarios-da-prova-de-engenharia-de-software-e-desenvolvimento/ 1/3

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 deferramentas. Vamos lá…

54. A métrica de contagem de pontos por função, disseminada pelo IFPUG (International Function PointUser Group) e constituída na evolução das métricas de linhas de código (LOC), visa estimar recursospara 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 umafunção.

Comentário: Fan-in é uma medida do número de funções ou métodos que chamam alguma outra função oumétodo (digamos X). Fan-out é o número de funções chamadas pela função X. Um valor alto para fan-in significaque 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-fontedo programa, enquanto a validação dinâmica tem por objetivo identificar defeitos no programa edemonstrar 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., semexecutar o programa); já técnicas de validação dinâmica executam o software para encontrar defeitos edemonstrar se ele atende aos seus requisitos.


57. Para se assegurar que o sistema opere com a carga necessária, são realizados testes de desempenhoem 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 sistemafalhar, 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 doSommerville:“Após o sistema ter sido completamente integrado, é possível testá-lo em relação às propriedadesemergentes (veja Capítulo 2), como desempenho e confiabilidade. Os testes de desempenho devem ser

projetados para assegurar que o sis tema 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 setorne inaceitável”.


58. Depois de ordenados os requisitos do product backlog pelo time de desenvolvimento, o Product


2/3



Owner avalia a qualidade dos produtos entregues para certificar que os desenvolvedores realizaramadequadamente as avaliações de mercado e as necessidades dos clientes do produto. Práticas deestimativa, como burndown, em conjunto com gráficos de barra, são úteis para estabelecer o burndownbaseline e auxiliar o time de desenvolvimento a gerir a complexidadedo projeto.

Comentário: Você começa ler a questão: “Depois de ordenados os requisitos do product backlog pelo time dedesenvolvimento (…) ” e já pode parar. Quem ordena os itens do Product Backlog é o Time deDesenvolvimento? 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.


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

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


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

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


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

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


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 comesone (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!


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


3/3



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


67. Em navegadores que não possuem apoio para a função JavaScript JSON.parse, pode-se utilizar afunção eval para converter um texto JSON em um objeto JavaScript, por meio da sintaxe apresentada aseguir. 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!


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

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


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

Comentário: Outra questão para ninguém acertar – fiquem relaxados! A documentação do Mavendiz: Repositories to deploy to are defined in a project in the distributionManagement section. However, youcannot 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.


70. Utilizar validação de entrada e codificação de saída, assegurar a abordagem de metacaracteres eevitar consultas parametrizadas fortemente tipificadas são ações compatíveis com as práticas deprogramaçã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ãoapenas algumas das dezenas de recomendações de segurança – não vale a pena decorar! Quem errou, ficatranquilo! Essa questão está errada porque não se deve evitar consultar parametrizadas fortemente tipificadas –isso na verdade é recomendado.


TCE_SC - 2016 - Comentários de Informática

Documents

Transcript of TCE_SC - 2016 - Comentários de Informática