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

Prévia do material em texto

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