Estimativas e Métricas de Software avaliação I

Prévia do material em texto

Estimativas e Métricas de Software - Avaliação I - 
Individual 
1 
As métricas de software e o tempo de ciclos são fundamentais para avaliar a qualidade, 
eficiência e desempenho de um sistema. As métricas, que variam desde a complexidade 
do código até a taxa de defeitos, fornecem insights valiosos sobre a saúde e a 
manutenção do software. No entanto, entender o tempo de ciclos vai além da simples 
coleta de dados; requer uma compreensão profunda dos processos de desenvolvimento e 
das interações entre equipes. O tempo de ciclos, que abrange desde a concepção até a 
entrega de um recurso ou projeto, é um indicador crítico da eficiência operacional e da 
capacidade de resposta da equipe às demandas do cliente. Além disso, a análise 
cuidadosa dessas métricas pode revelar padrões, gargalos e oportunidades de melhoria 
dentro do ciclo de desenvolvimento de software, capacitando as organizações a tomar 
decisões informadas e aprimorar continuamente seus processos e produtos. 
Fonte: adaptado de: GIDO, J. et al. Gestão de projetos. São Paulo: Cengage Learning, 
2007. 
Sobre a métrica do tempo de ciclo, analise as afirmativas a seguir: 
I. Tempo de conversão contempla a primeira ação realizada em um compilador. 
II. Tempo de Pickup contempla a revisão de um segmento do código recém-escrito. 
III. Tempo de manutenção contempla desde o primeiro pull request de um segmento do 
código até a sua rejeição ou aprovação. 
IV. Tempo de Deploy contempla a revisão do pull request, os testes de funcionalidades 
e a aprovação final do segmento. 
É correto o que se afirma em: 
A 
II e IV, apenas. 
B 
I e IV, apenas. 
C 
I, II e III, apenas. 
D 
II, III e IV, apenas. 
2 
Quando falamos em métrica de software, encontramos várias vantagens em utilizá-la e 
também algumas desvantagens na sua utilização, portanto, sempre é interessante 
explorar alguns pontos das vantagens que ela nos traz para entender um pouco melhor a 
sua utilização. Dentre as vantagens que são de grande importância para a métrica de 
software, podemos destacar a produtividade das pessoas que estão envolvidas no 
desenvolvimento do sistema de software, isso nos trará uma identificação do tempo que 
levará para desenvolver o software e os riscos que esse processo pode ter. 
Fonte: adaptado de: PANDIAN, C. Software Metrics: a guide planning, analysis and 
aplication. Boca Raton: Auerbach Publications, 2004. 312 p. 
As métricas de software têm vários benefícios potenciais. Quanto aos benefícios 
potenciais, analise as afirmativas a seguir: 
I. O apoio à verificação do cumprimento dos requisitos e especificações dos sistemas de 
software. 
II. A estimativa auxilia no esforço necessário para o projeto e desenvolvimento de 
sistemas de software. 
III. A aplicação de métricas de software se caracteriza pela facilidade e pode ser 
desafiadora e cara. 
IV. As informações são omitidas sobre a complexidade do código de software, o que 
pode ser útil para decidir se um módulo complexo deve ser dividido ainda mais. 
É correto o que se afirma em: 
A 
II, III e IV, apenas. 
B 
I, apenas. 
C 
I e II, apenas. 
D 
III e IV, apenas. 
3 
Uma medição é uma manifestação do tamanho, quantidade ou dimensão de um atributo 
específico de um produto ou processo. É uma autoridade dentro da engenharia de 
software. O processo de medição de software é definido e regido pela Norma ISO. Na 
estimativa e métrica de software, uma medição é uma manifestação do tamanho do 
projeto, tanto em sua complexidade quanto em sua extensão. Essas medições são 
fundamentais para determinar o esforço necessário, os recursos envolvidos e o 
progresso alcançado durante o desenvolvimento de software. Elas podem incluir linhas 
de código, pontos de função, casos de uso, entre outros indicadores. Por meio dessas 
medidas, os profissionais de desenvolvimento conseguem planejar, controlar e avaliar o 
processo de criação de software de maneira mais precisa. No entanto, é essencial 
compreender que a medição do tamanho do software não é apenas quantitativa, mas 
também qualitativa, refletindo a complexidade e os requisitos específicos de cada 
projeto. 
Fonte: adaptado de: GIMENES, I. M. S. O Processo de Software: Ambientes e 
Formalismos. In: CONGRESSO DA SOCIEDADE BRASILEIRA DE 
COMPUTAÇÃO, 14., 1994, Caxambu. Anais [...]. Maringá: Sociedade Brasileira de 
Computação, 1994. p. 1-40. 
A medição de software se caracteriza através de cinco atividades. Assinale a alternativa 
correta quanto à função e justificativa: 
A 
Feedback: o mecanismo usado para acumular os dados necessários para derivar as 
métricas formuladas. 
B 
Análise: cálculo de métricas e a aplicação de ferramentas matemáticas. 
C 
Coleta: recomendação derivada da interpretação das métricas do produto transmitidas à 
equipe de software. 
D 
Formulação: a avaliação das métricas resultando em insights sobre a qualidade da 
representação. 
4 
As equipes de gerenciamento se beneficiam das métricas de software porque podem 
rastrear o desenvolvimento de software, definir metas e analisar o desempenho 
prontamente. A simplificação excessiva do desenvolvimento de software, por outro 
lado, pode desviar a atenção dos desenvolvedores de objetivos mais importantes, como 
fornecer produtos úteis e aumentar a satisfação do cliente. Claro, nada disso importa se 
os dados de métricas de software não forem coletados ou analisados. A primeira questão 
é que as equipes de desenvolvimento de software podem acreditar que fazer o trabalho 
em vez de medir é mais importante. 
Fonte: adaptado de: CAMPÊLO, G. M. C. A utilização de métricas na Gerência de 
Projetos de Software: uma abordagem focada no CMM Nível 2. Recife: [s. n.], 2002. 
Com base nas informações apresentadas, avalie as asserções a seguir e a relação 
proposta entre elas: 
I. É importante tornar a medição fácil de coletar, caso contrário, ela não será feita. 
Torne as métricas de software úteis para a equipe de desenvolvimento de software para 
que possam trabalhar com mais eficiência. 
PORQUE 
II. É importante que os processos de medir e analisar devam ser mais longos quando se 
trata de escrever uma linha de código. 
A respeito dessas asserções, assinale a opção correta: 
A 
A asserção I é uma proposição verdadeira, e a II é uma proposição falsa. 
B 
As asserções I e II são verdadeiras, e a II é uma justificativa correta da I. 
C 
A asserção I é uma proposição falsa, e a II é uma proposição verdadeira. 
D 
As asserções I e II são verdadeiras, mas a II não é uma justificativa correta da I. 
5 
Existem várias diferenças importantes entre produto e processo. No contexto de 
qualquer empreendimento, seja na indústria, no desenvolvimento de software ou em 
outras áreas, é fundamental compreender as diferenças entre processo e produto. O 
processo refere-se às etapas, métodos e procedimentos utilizados para criar ou alcançar 
um determinado resultado. Ele engloba a sequência de atividades, desde a concepção até 
a entrega final, e é crucial para garantir a eficiência, consistência e qualidade do produto 
ou serviço. Por outro lado, o produto é o resultado tangível ou intangível desse 
processo, ou seja, é o produto final ou o resultado alcançado após a execução das etapas 
do processo. Enquanto o processo representa o "como" algo é feito, o produto 
representa o "o que" é produzido. Entender e gerenciar tanto o processo quanto o 
produto são essenciais para alcançar os objetivos organizacionais e satisfazer as 
necessidades dos clientes. 
Fonte: adaptado de: HENRY, S. D. K. Software structure metrics based on information 
flow. IEEE Transactions on Software Engineering, [s. l.], v. 7, n. 5, p. 510-518, maio 
1981. 
Considerando as principais diferenças entre produto e processo, analise as afirmativas a 
seguir: 
I. O ciclo de vida de um produto costuma ser mais longo. Em contraste, o ciclo de vida 
de um processo é mais curto. 
II. O produto está preocupadocom o resultado final. Em contraste, o método enfatiza a 
conclusão de cada fase específica do projeto em desenvolvimento. 
III. O objetivo principal do produto é fazer a tarefa com sucesso. Por outro lado, o 
objetivo do processo é aumentar a qualidade do projeto cada vez que um novo projeto é 
produzido usando as mesmas etapas do processo. 
IV. O layout de produto é um estilo de design de layout em que os materiais são 
necessários para criar o produto que é colocado em uma única linha com base nas 
ordens de operações. Por outro lado, um layout de processo é criado quando recursos 
com processos ou funções comparáveis são agrupados. 
É correto o que se afirma em: 
A 
II e IV, apenas. 
B 
III e IV, apenas. 
C 
I, II, III e IV. 
D 
II, III e IV, apenas. 
6 
A análise da exposição ao risco é composta por duas estimativas: o tamanho da perda 
potencial (no tempo) de um fator de risco identificado e a probabilidade correspondente 
de que a perda realmente ocorrerá. Uma fórmula simples é padrão na indústria para 
determinar um cálculo de exposição ao risco: (% de probabilidade de perda) * (tamanho 
da perda em semanas) = fator de exposição ao risco. Por exemplo, se fôssemos usar 
qualquer projeto de desenvolvimento em uma grande organização financeira na qual o 
autor trabalhou há vários anos como linha de base, teríamos que assumir que há mais de 
75% de probabilidade de algum impacto em um projeto por atrasos do suporte técnico. 
Se assumirmos uma estimativa conservadora de uma perda no tempo de 
aproximadamente quatro semanas, a exposição ao risco seria de 0,75 * 4 = 3 (semanas). 
O resultado é um fator de exposição ao risco de uma possível perda de três semanas. 
Como estamos estimando apenas 75% de probabilidade de isso ocorrer, não esperamos 
perder as quatro semanas completas no tempo. Estimar o tamanho de uma perda é muito 
mais fácil do que fazer isso para a probabilidade de uma perda. 
Fonte: adaptado de: QUADRI, S. M. K. Software Testing – Goals, Principles, and 
Limitations. International Journal of Computer Applications, [s. l.], v. 6, n. 9, set. 
2010. 
Existem várias atividades possíveis que podem ser executadas para determinar com 
mais precisão essa parte da equação do tamanho da perda. Sobre o exposto, analise as 
afirmativas a seguir: 
I. Uso do recrutamento de membros da equipe muito antes do início do projeto. 
II. Uso da probabilidade estimada de cada risco pela pessoa mais familiarizada com o 
sistema, bem como com o ambiente de desenvolvimento e a infraestrutura política, em 
seguida, revisão dessa estimativa de risco. 
III. Uso da calibração de adjetivos em que cada membro da equipe selecionaria um 
nível de risco em termos de uma escala verbal de frases de “altamente provável” a 
“altamente improvável”. Em seguida, a conversão das avaliações verbais em avaliações 
quantitativas. 
IV. Uso da abordagem Delphi em que cada membro da equipe do projeto estima cada 
fator de risco individualmente. Em seguida, revisões de estimativa de risco para discutir 
e determinar a probabilidade mais provável de cada fator de risco até que toda a equipe 
esteja satisfeita com uma análise final. 
É correto o que se afirma em: 
A 
II e III, apenas. 
B 
III e IV, apenas. 
C 
II, III e IV, apenas. 
D 
I, II e III, apenas. 
7 
As métricas públicas geralmente assimilam informações que originalmente eram 
privadas para indivíduos e equipes. Taxas de defeitos no nível do projeto 
(absolutamente não atribuídas a um indivíduo), esforço, tempo de calendário e dados 
relacionados são coletados e avaliados na tentativa de descobrir indicadores que possam 
melhorar o desempenho do processo organizacional. As métricas de processo de 
software podem fornecer benefícios significativos à medida que uma organização 
trabalha para melhorar seu nível geral de maturidade de processo. Como todos os tipos 
de métricas, elas também podem ser utilizadas de uma maneira errada, tornando mais 
difícil a solução do problema. 
Fonte: adaptado de: FENTON, N.; PFLEEGER, S. Software Metrics. Boston: PWS 
Publishing Company, 1997. 638 p. 
Quanto às etiquetas de métricas de software, analise as afirmativas a seguir: 
I. Utilização de métricas para avaliar indivíduos. 
II. Priorização de uma métrica por vez. 
III. Utilização de métricas para alertar e motivar grupos de trabalho. 
IV. Definição clara das metas que serão usadas para atingir o objetivo entre os 
profissionais de cada setor. 
É correto o que se afirma em: 
A 
I, apenas. 
B 
III e IV, apenas. 
C 
I, II e III, apenas. 
D 
II e IV, apenas. 
8 
O desenvolvimento de software é um processo complexo e multifacetado que apresenta 
uma série de desafios e riscos inerentes. Entre os riscos mais significativos estão os 
relacionados à gestão de projetos, à qualidade do produto e à segurança da informação. 
Em termos de gestão de projetos, os atrasos no cronograma, mudanças nos requisitos e 
falta de comunicação eficaz entre as partes interessadas podem resultar em falhas no 
cumprimento dos prazos e orçamentos estabelecidos. Além disso, a falta de experiência 
ou competência técnica da equipe de desenvolvimento pode levar a erros de projeto e 
implementação, comprometendo a qualidade do produto final. Com relação à segurança 
da informação, a exposição a vulnerabilidades de software e ataques cibernéticos 
representa um risco significativo, especialmente em sistemas que lidam com dados 
sensíveis ou críticos. 
Fonte: adaptado de: QUADRI, S. M. K. Software Testing – Goals, Principles, and 
Limitations. International Journal of Computer Applications, [s. l.], v. 6, n. 9, set. 
2010. 
Quando falamos em riscos de desenvolvimento de software, existem alguns fatores que 
vão contribuir para verificar o risco de estimativa de software. Sobre o exposto, analise 
as afirmativas a seguir: 
I. Capacidade de visualizar fatores de performance e qualidade dos produtos de 
software. 
II. Capacidade do desenvolvedor, incluindo pessoas, processos, planos e produtividade 
histórica. 
III. Capacidade de atingir os níveis esperados de itens de não desenvolvimento (NDI) de 
software, incluindo software comercial pronto para uso (COTS) e reutilização. 
IV. Capacidade de gerenciar requisitos e mudanças com eficiência, o que resulta em 
crescimento do tamanho do software e afeta negativamente as estimativas de esforço e 
cronograma. 
É correto o que se afirma em: 
A 
I, II e III, apenas. 
B 
II, III e IV, apenas. 
C 
III e IV, apenas. 
D 
II e III, apenas. 
9 
As métricas são extremamente importantes para um software de qualidade e com uma 
maior precisão no seu processo de construção. É vital lembrar que a lista de métricas 
deve ser definida caso a caso antes de começarmos. É uma perda absurda de tempo e 
esforço apenas rastrear o que quer que uma ferramenta de gerenciamento de projeto 
forneça ou uma estrutura/modelo de desenvolvimento de software recomende, ou 
duplicar cegamente as métricas fornecidas por outro projeto. Segundo Pandian (2004), é 
interessante evitar métricas que não respondam a perguntas específicas das partes 
interessadas do projeto ou que não tenham nenhum impacto possível no processo do 
projeto. Um sistema de processamento em tempo real, por exemplo, colocará forte 
ênfase nas medições de desempenho, mas um sistema assíncrono distribuído colocará 
forte ênfase na disponibilidade. 
Fonte: adaptado de: PANDIAN, C. Software Metrics: a guide planning, analysis and 
aplication. Boca Raton: Auerbach Publications, 2004. 312 p. 
Considerando o que pode ser medido na questão de desempenho da medição e que terá 
um impacto direto no processo do projeto, analise as opções a seguir: 
I. Qualidade do código. 
II. Satisfação do usuário. 
III. Qualidade do processo. 
IV. Qualidade da solução entregue. 
É correto o que se afirma em: 
A 
II e IV, apenas. 
B 
I, II, III e IV. 
C 
III e IV, apenas. 
D 
I, II e III, apenas. 
RevisarConteúdo do Livro 
10 
A otimização da produtividade com relação aos custos é o cerne da Estimativa de 
Custos. Esse processo busca determinar o máximo de eficiência que pode ser alcançado 
dentro de um orçamento estabelecido, visando a atingir os objetivos do projeto. Ao 
estimar os custos, é fundamental considerar não apenas os gastos diretos, como mão de 
obra e matéria-prima, mas também os custos indiretos e os possíveis imprevistos. 
Embora as estimativas não sejam precisas, representam uma importante ferramenta para 
planejar e gerenciar recursos financeiros. A correta avaliação dos custos de produção é 
crucial para evitar desvios orçamentários e garantir a viabilidade do projeto ao longo do 
tempo. 
Fonte: adaptado de: VARGAS, R. V. Gerenciamento de Projetos: estabelecendo 
diferenciais competitivos. 8. ed. São Paulo: Brasport, 2016. 
Existem cinco tipos principais de custos que compõem o custo total do projeto. Analise 
as afirmativas a seguir quanto aos seus conteúdos: 
I. Os custos diretos são custos mais fáceis de estimar com precisão. 
II. Os custos indiretos em um projeto são aqueles que dão suporte ao projeto. 
III. Os custos fixos são aqueles que incluem custos de instalação e custos de aluguel. 
IV. Os custos de sequência absoluta ¿¿são variáveis ¿¿por natureza e podem incluir 
salários de mão de obra por hora, materiais. 
É correto o que se afirma em: 
A 
III e IV, apenas. 
B 
II e IV, apenas. 
C 
I, II e III, apenas. 
D 
I, II, III e IV.