Buscar

AVS- medidas de esforço de software

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você viu 3, do total de 3 páginas

Prévia do material em texto

BDQ Prova Página 1 de 3 
http://bquestoes.estacio.br/bdq_prova_resultado_preview_aluno.asp 08/07/2014 
 
Avaliação: » MEDIDAS DE ESFORÇO DE DESENVOLVIMENTO DE SOFTWARE 
Tipo de Avaliação: AVS 
Aluno: 
Professor: HORACIO DA CUNHA E SOUZA RIBEIRO Turma: 9002/AB 
Nota da Prova: 7,0 Nota de Partic.: 2 Data: 25/06/2014 19:56:22 
 
Segundo a proposta de Albretch, a funcionalidade funcional a ser medida é fundamenta em que aspectos de um sistema? 
Resposta: A funcionalidade funcional a ser medida por Albretch é fundamentada através de tudo aquilo que é gerado em um sitema, que é 
contado e que tem processamento de dados,(como Entradas, Saidas, Consultas, Arquivos e Funcionalidades) e não contado como os 
arquivos TEMP e Batch e o que não são referenciados. 
Gabarito: A medida da funcionalidade proposta por Albretch é baseada no número de saída, número de entradas, número de consultas, 
número de arquivos, número de interfaces. 
 
O que é CoCoMo (Constructive Cost Model)? 
Resposta: CoCoMo é um metodo criado para estabelecer esforço, prazo, tamanho de equipe e custo necessário para implementação do 
software, desde que conhecido o seu tamanho através de APF. 
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. 
 
Devemos acompanhar a produção de código correto feito pelos programadores. E foi acertada entre os gerentes uma métrica de medida 
indireta que irá dar um índice para cada programador que será: índice-qualidade = (números de erro *2 + 1) bonzão. Assim um 
programador com 236 bonzão é duas vezes pior do que o programador com 118 bonzão. Podemos afirmar de forma correta quanto à 
definição da métrica. 
 A métrica está adequada, pois esta corretamente definida e os gerentes facilmente entenderão que quatro bozão são pior que 
dois bonzão. 
 No ponto de vista esta métrica define a qualidade do trabalho, pois quem tem mais erros tem mais bonzão e para um projeto 
desejamos quem tem menos bonzão. A métrica mostra isto intuitivamente. Quando se tem mais é melhor. 
 A métrica não deve ter esta preocupação do senso comum. É necessário que os gerentes aprendam e memorizem esta nova forma 
de medir. 
 
O custo é adequado, pois nos podemos contar os erros pelo número de comparações feitas por programa. Então quanto mais se 
compila um programa melhor, pois indica que o programador terá mais bonzões, portanto melhor qualidade do trabalho. 
 
 
 
 
 
 
 
 
 
BDQ Prova Página 2 de 3 
http://bquestoes.estacio.br/bdq_prova_resultado_preview_aluno.asp 08/07/2014 
 A métrica esta inadequada, pois o consenso comum indica que quando uma coisa é melhor deve ter um valor maior e a métrica 
está invertida. 
 
 
Uma empresa que está iniciando em fazer gestão por PF , estabeleceu apenas medições nas etapas macro do processo. E após vários 
projetos, a base estatística gerou a tabela abaixo, com uma variação de 5% de erro. 
etapa % do prazo % do esforço 
Levantar 5 
requisitos 
5 
analise 15 25 
Projeto lógico 25 15 
programação 20 15 
Testes 20 20 
Implantação 15 20 
Totais da etapa 100 100 
Marque a sentença correta: 
 Para um projeto de 400 PF, para um custo de R$ 1200,00 por PF pode-se dar um orçamento sem correr riscos, para a fase de 
analise: 15% * R$ 1200 *1,05. 
 Para um projeto de 400 PF, para um custo de R$ 1200,00 por PF pode-se dar um orçamento sem correr riscos, para a fase de 
analise: 25% * R$ 1200. 
 Para um projeto de 400 PF, para um custo de R$ 1200,00 por PF pode-se dar um orçamento sem correr riscos, para a fase de 
analise: 25% * R$ 1200 *1,05. 
 Para um projeto de 400 PF, para um custo de R$ 1200,00 por PF pode-se dar um orçamento sem correr riscos, para a fase de 
analise: 15% * R$ 1200 /1,05. 
 Para um projeto de 400 PF, para um custo de R$ 1200,00 por PF pode-se dar um orçamento sem correr riscos, para a fase de 
analise: 25% * R$ 1200 /1,05. 
 6a Questão (Ref.: 201102272757) Pontos: 0,0 / 0,5 
Podemos afimar sobre a classificação do tipo do software chamado de básico, no modelo COCOMO de Bhoem, que: 
incorpora um conjunto de requisitos não tão rígidos, pode-se exemplificar pequenos sistemas. 
incorpora um desenvolvimento dentro de restrições operacionais, como por exemplo, sistema de controle de telefonia. é um 
modelo estático de valor simples que computa o esforço de desenvolvimento de software. 
 computa o esforço de desenvolvimento como uma função do tamanho, e de um conjunto de direcionadores de custo (definidos 
em tabelas) que incluem avaliações subjetivas do produto, hardware, experiência do pessoal e dos atributos do projeto. 
 
 
 
 
 
 
 
 
 
 
 
 
BDQ Prova Página 3 de 3 
http://bquestoes.estacio.br/bdq_prova_resultado_preview_aluno.asp 08/07/2014 
 incorpora a avaliação dos impactos nos direcionadores de custo sobre cada passo do processo de desenvolvimento (análise de 
projeto, codificação, testes...). 
 7a Questão (Ref.: 201102412106) Pontos: 1,0 / 1,0 
Não são fatores de risco para a determinação do trabalho os seguintes fatos: 
As estimativas na contratação são feitas com nível de erro. Normalmente quem contrata subdimensiona o trabalho para 
minimizar o seu custo. 
O trabalho é mal especificado não definindo limites do que precisa ser feito e geralmente o contratante pode pedir outros (quebra 
galhos) do contratado o que leva ao desentendimento. 
A falta de clareza ou entendimento dos requisitos. Devem-se aplicar metodologias que esclareçam os requisitos (analise, 
completude e consistência) para se minimizar este aspecto. 
Falta de processo de controle nas modificações solicitada. Uma modificação, na maioria das vezes, implica em aumento do custo e 
prazo. 
O pagamento de faturas emitidas pelo fornecedor após aprovada pelo contratante. 
 
 
 
Período de não visualização da prova: desde 20/06/2014 até 07/07/2014.

Outros materiais