Buscar

(AS II) MELHORIA DE PROCESSOS 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

Você também pode ser Premium ajudando estudantes

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ê também pode ser Premium ajudando estudantes

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ê também pode ser Premium ajudando estudantes
Você viu 3, do total de 3 páginas

Prévia do material em texto

Pergunta 1
Resposta
Selecionada:
d. 
Respostas: a. 
b. 
c. 
d. 
e. 
Comentário da
resposta:
A classificação do estágio de melhoria em que os processos são avaliados são conhecidas como
nível de maturidade. A classificação de uma organização em um nível de maturidade é importante:
 
 porque permite prever os resultados mais prováveis esperados do próximo
projeto de software que a organização empreender.
apenas para a equipe de desenvolvimento conhecer sua capacidade produtiva.
apenas para potenciais clientes em busca de fornecedores de sistema.
por aplicar os indicadores quantitativos na etapa de medição.
 porque permite prever os resultados mais prováveis esperados do próximo
projeto de software que a organização empreender.
somente para empresas de consultoria.
 Por meio das avaliações obtidas, temos bons instrumentos para prever os
resultados mais prováveis esperados do próximo projeto de software que a
organização empreender.
Pergunta 2
Resposta
Selecionada:
c. 
Respostas:
a. 
b. 
c. 
d. 
Um indicador é composto de uma ou mais métricas, e a Engenharia de Software destaca grupos de
indicadores relevantes ao desenvolvimento. Identifique, nos exemplos a seguir, um indicador de
qualidade.
 
Os bugs encontrados na etapa de desenvolvimento totalizaram 198; após a
liberação para usuário, foram encontrados cinco.
 5% dos projetos consomem orçamento maior que o programado.
 A empresa executa 12 projetos por ano.
 
 
Os bugs encontrados na etapa de desenvolvimento totalizaram 198; após a
liberação para usuário, foram encontrados cinco.
 95% dos projetos são entregues dentro do prazo.
0,2 em 0,2 pontos
0,2 em 0,2 pontos
e. 
Comentário da
resposta:
A equipe implementa 2.000 linhas de código por semana.
Indicador de qualidade: uma das partes fundamentais tanto para o ambiente de
trabalho quanto para os concorrentes é medir e comparar a qualidade, as falhas
do software e os bugs, pois permite elaborar melhorias durante o processo
produtivo.
Pergunta 3
Resposta Selecionada:
a. 
Respostas:
a. 
b. 
c. 
d. 
e. 
Comentário
da resposta:
Qual é o primeiro modelo de nível de maturidade?
 
CMM.
CMM.
CMMI.
ISO/IEC 15504.
MPS.BR.
ISO/IEC 33000.
O modelo referencial de maturidade no desenvolvimento de software surgiu nos
anos 1990 com a solicitação do Departamento de Defesa dos Estados Unidos para
o Instituto de Engenharia de Software (SEI), na Universidade Carnegie Mellon. A
solicitação pedia a criação de um método que avaliasse a capacidade dos
fornecedores de software. Surgiu, assim, o “The Capability Maturity Model:
Guidelines for Improving the Software Process – CMM”.
Pergunta 4
Resposta
Selecionada:
d. 
Respostas:
a. 
b. 
A métrica Q1 = ni/nr, que analisa ambiguidade em relação aos requisitos apresentados pelos clientes
aos desenvolvedores, revela que:
 
todos os desenvolvedores compreenderam da mesma forma o conjunto de
requisitos.
garante a qualidade total do projeto.
a maior qualidade do projeto deve ter um valor de Q1 próximo a zero.
0,2 em 0,2 pontos
0,2 em 0,2 pontos
c. 
d. 
e. 
Comentário
da resposta:
é utilizada para detectar ambiguidade somente para análise dos requisitos
funcionais.
todos os desenvolvedores compreenderam da mesma forma o conjunto de
requisitos.
é relevante apenas para os clientes.
se o resultado for 1 (a situação ideal), indica que os revisores foram
unânimes na interpretação dos requisitos;
valores menores que 1 representam um grau de ambiguidade quanto aos
requisitos. O grau de ambiguidade é um forte indício de que uma nova
revisão deve ser feita.
Essa métrica não garante que clientes e desenvolvedores estejam em perfeita
sintonia (eventualmente, todos os revisores entenderão de forma igual, mas
diferente das intenções dos usuários). Ainda assim, é uma forma de detectar
ambiguidade de requisitos entre desenvolvedores, na etapa que antecede ao início
de codificação.

Outros materiais