A maior rede de estudos do Brasil

Grátis
4 pág.
AVS 2014 Medidas de Esforco e Desenvolvimento de Software

Pré-visualização | Página 1 de 2

Fechar 
 
Avaliação: CCT0190_AVS_201308357575 (AG) » MEDIDAS DE ESFORÇO DE DESENVOLVIMENTO DE SOFTWARE 
Tipo de Avaliação: AVS 
Aluno: 201308357575 - CHRISTIANO SERRA CABREIRA 
Professor: OSWALDO BORGES PERES Turma: 9004/AB 
Nota da Prova: 6,5 Nota de Partic.: 2 Data: 02/07/2014 18:55:33 
 
 
 1a Questão (Ref.: 201308547692) Pontos: 1,5 / 1,5 
Por que uma medida direta não é adequada para o planejamento? 
 
 
Resposta: A medida é feita no produto ou processo, portanto, o produto ou processo precisam estar prontos ou 
serem realizados. O planejamento deve ser feito antes da produção ou realização. 
 
 
Gabarito: A medida direta é feita no produto ou processo, portanto o produto ou processo precisam estar 
prontos ou serem realizados. O planejamento deve ser feito antes da produção ou realização 
 
 
 
 2a Questão (Ref.: 201308635870) Pontos: 1,5 / 1,5 
O que é CoCoMo (Constructive Cost Model)? 
 
 
Resposta: Constructive Cost Model é um metodo que busca medir o esforço, prazo, tamanho, equipe, custo 
necessário para o desenvolvimento do software, desde que tenha dimensão do mesmo através de um modeo de 
estimativa de tamanho de software, como Análise do Ponto de Função. 
 
 
Gabarito: CoCoMo é um método que busca medir esforço, prazo, tamanho de equipe e custo necessário para o 
desenvolvimento do software, desde que se tenha a dimensão do mesmo, através de um modelo de estimativa 
de tamanho de software, como Análise de Pontos de Função. 
 
 
 
 3a Questão (Ref.: 201308493064) Pontos: 0,5 / 0,5 
O valor total de influência para uma aplicação é 39 e o fator de ajuste é 1,04. As características dessa aplicação 
são: 
 
Comunicação de dados 3 
Atualizações on line 5 
Processamento distribuído 3 
Processamento complexo 1 
Performace 3 
Reusabilidade 3 
Configuração altamente utilizada 3 
Facilidade de instalação 2 
Volume de transações on line 4 
Facilidade de operação 2 
Eficiência do usuário final 5 
Múltiplos locais 2 
Entrada de dados on line 3 
Modificação facilitada 0 
 
Assinale o novo fatra de ajuste, caso todas as características tivessem nota cinco: 
 
 
39 
 1,35 
 
1,04 
 
0,39 
 
0,65 
 
 
 
 4a Questão (Ref.: 201308493095) Pontos: 0,5 / 0,5 
Um arquivo referenciado: 
 
 
É uma tabela do sistema. 
 É uma ALI lido ou mantido por um processo elementar ou um AIE lido por um processo elementar. 
 
É um conjunto de itens de dados logicamente relacionados que podem ou não ser usados por processos 
elementares. 
 
É um ALI lido ou mantido pela aplicação que está sendo contada. 
 
São dados usados pelo sistema e solicitados ou não pelos usuário. 
 
 
 
 5a Questão (Ref.: 201308634912) Pontos: 0,0 / 0,5 
O processo de contagem, definido pelo IPFUG, é feito em sete passos. Um destes é destinado a determinar o 
tipo de Contagem. 
 
Com base neste passo, correlacione as colunas abaixo: 
 
i. Contagem de Projeto de desenvolvimento 
ii. Contagem de Projeto de melhoria 
iii. Contagem de Projeto de aplicação 
 
( ) A contagem de pontos de função de uma aplicação já instalada, mede a funcionalidade fornecida ao 
usuário 
( ) Após a conclusão e implantação do projeto de melhoria , o número de pontos de função da aplicação deve 
ser atualizado para refletir as mudanças nas funcionalidades da aplicação. 
( ) O número de pontos de função mede as modificações para uma aplicação já existente, ou seja, as funções 
adicionais , modificadas ou excluídas do sistema pelo projeto e as funções de conversões de dados. 
( ) Ela é iniciada ao final da contagem do projeto de desenvolvimento e atualizado no final do projeto de 
melhoria.; 
( ) O número de pontos de função de um projeto de desenvolvimento mede a funcionalidade fornecida aos 
usuários finais, quando da primeira instalação do software. 
 
 
ii, ii, iii, i, ii 
 
ii, iii, ii, i, i 
 
i, ii, iii, ii, i 
 iii, ii, iii, ii, i 
 iii, ii, ii, iii, i 
 
 
 
 6a Questão (Ref.: 201308516444) Pontos: 0,5 / 0,5 
Um projeto medido em Kloc mostrou que a produtividade do programador era de 10 linhas de código por dia, 
em uma linguagem X. Outro projeto em uma linguagem Y mostrou que a produtividade foi de 12 linhas de 
código por dia. Marque a afirmativa correta. 
 
 
Podemos ter certeza que a linguagem x exige menos comandos que a linguagem y para uma mesma 
tarefa. 
 
Nada podemos falar sobre a qualidade do código gerado, mas sendo x e y linguagens com características 
diferente, podemos concluir que o programador que trabalhou com X é melhor do que o da linguagem y. 
 
Podemos ter certeza que o código gerado para a linguagem y é estruturado e o da linguagem x não é. 
 
Podemos ter certeza que a produtividade do programador que trabalhou com a linguagem X é maior que 
o que trabalhou com a linguagem Y gerando código de melhor qualidade. 
 Não há como comparar o trabalho ao se utilizar a linguagem X e a linguagem Y, vai depender das 
características da linguagem. 
 
 
 
 7a Questão (Ref.: 201308516659) Pontos: 0,5 / 0,5 
Considere a contagem para uma tabela de clientes que tem: I - Uma consulta que retorna quase todos os itens 
de dados da tabela para uma tela. II - Outra consulta retorna-se uma lista de CPF e Nome de clientes. 
 
 
Deve-se contar como uma entrada externa e uma consulta externa 
 
Deve-se contar duas entradas e duas saídas 
 
Deve-se contar duas entradas externas 
 Deve-se contar duas consultas externas. 
 
Deve-se contar uma saída externa e uma consulta 
 
 
 
 8a Questão (Ref.: 201308493846) Pontos: 0,5 / 0,5 
Ao se definir as variáveis de estimativa usadas para "classificar por tamanho" cada elemento e etapa no 
processo de desenvolvimento do software, de forma sempre correta, estamos: 
 
 
Uma "base line" não é única pois para cada tipo de projeto deve-se ter um conjunto diferente de pontos 
de medida. Mas, quando se faz à estimativa considera-se um conjunto único. Isto permite que quem faz 
à estimativa tenha um erro menor independente do tipo de projeto e portanto trabalhará com um risco 
muito menor. 
 
Escolhendo um conjunto de pontos para controle do software, e que será base para pontos de 
pagamento e de avaliação de futuras estimativas. 
 Definindo uma "base line" para coletar dados históricos e que serão usados como um conjunto com 
variáveis de estimativa para que se desenvolva projeções de custo e de esforço. 
 
Definindo uma "base line" que é fixa para todos os tipos de sistemas (software e hardware) que serão 
feitos na empresa, desta forma estabelece-se um conjunto único de parâmetros de estimativa e custo o 
que diminui o risco, considerando um tratamento único para todos os projetos da empresa. 
 
Definindo um conjunto de variáveis para as quais se irá fazer registros estatísticos. Estes registros serão 
plotados em curvas. Estas curvas serão utilizadas de forma comum para qualquer tipo de projeto, pois 
desta forma se compensa os riscos introduzidos na estimativa. 
 
 
 
 9a Questão (Ref.: 201308633112) Pontos: 0,0 / 1,0 
No Software orientado a objetos, segundo o Prof. Pressman, podemos afirmar: 
 
 Deve-se usar a estimativa por PF usando-se a decomposição de casos e uso. 
 
Deve-se analisar cada caso e uso e fazer estimativas de tamanho somando-os no final. 
 
Devem-se modelar as classes principais e depois aplicar PF que servirá de unidade para o resto do 
projeto. 
 
Deve-se usar a estimativa de tamanho para dimensionar um caso e uso. 
 Deve-se definir um caso e uso padrão e o resultado aplicado ao longo do projeto.