Métricas de processo e projeto de software

Transcrição

1 Métricas de processo e projeto de software Métrica é um conjunto de medidas. Medição existe em qualquer processo de construção de qualquer coisa. A medição é realizada não apenas na Engenharia de Software. É fundamental para qualquer atividade, principalmente de engenharia. Seu propósito é avaliar alguma coisa. A partir dela, podemos ter o entendimento da eficácia de algumas situações, como do processo de software. Por exemplo, para avaliar se o processo pelo qual uma empresa produz software é bom ou ruim, como se faz? O CMM é um modelo para avaliar a qualidade do processo. Ele se baseia em medidas como tempo, número de erros, de linhas de código, de manutenções, etc., para saber se o processo está funcionando bem. Não é possível avaliar algo sem alguma medição. Os processos que estão no nível máximo do CMM têm um melhoramento contínuo, o que significa que eles são constantemente medidos. As métricas são aqui quantitativas (números). Medidas de qualidade e medidas de produtividade são extraídas do processo de software. A medição, além de ajudar na avaliação do processo de software, ajuda ainda nas estimativas, por exemplo, para estimar quanto tempo é necessário para a produção de um sistema. Atualmente erra-se muito nessas estimativas por não se ter muito conhecimento ou medição do processo. Com a medição, aperfeiçoamentos reais podem ser conseguidos ao longo do tempo. Então, as razões para medir processos, produtos e recursos de software podem ser:

2 para caracterizar; para avaliar; para prever; para aperfeiçoar. Um engenheiro de software realiza medidas e desenvolve métricas de modo a obter indicadores. Medida é um valor real, quantidade, dimensão, capacidade ou tamanho de algum atributo. Ex. número de erros encontrados. Métrica é um conjunto de medidas tentando obter algum sentido. Ex. erros encontrados por pessoa-hora empregada. Traz alguma informação que pode ser útil. Indicador é uma métrica, ou conjunto de métricas, que fornece compreensão de um processo de software, de um projeto de software ou do produto propriamente dito. Ex. comparando duas métricas, chega-se a uma conclusão que permite embasar uma tomada de decisão. Exemplos 1. O que é medida, métrica e indicador? Vide acima. 2. Defina duas medidas, uma métrica e um indicador para avaliar um carro. Medidas: potência, peso bruto; Métrica: potência por peso bruto; Indicador: comparando-se a potência por peso bruto de dois carros, pode-se concluir qual é mais veloz. 3. O que são métricas do processo? E do projeto? Qual a principal diferença entre elas? Métricas do processo e do projeto de software são medidas

3 quantitativas que permitem ao pessoal de software ter idéia da eficácia do processo de software. Indicadores de projeto permitem à organização de engenharia de software ter idéia da eficácia de um determinado processo existente, enquanto os indicadores de processo tentam identificar problemas que atingem a produção de todos os projetos na empresa. Métricas de Processo e Projeto de Software A medição é fundamental para qualquer atividade de engenharia. A medição nos permite obter entendimento nos dando um mecanismo para avaliação objetiva. A medição pode ser aplicada ao processo de software, com o objetivo de melhorá-lo continuamente. Métricas do processo e do projeto de software são medidas quantitativasque permite ao pessoal de software ter idéia da eficácia do processo de software. Dados básicos de qualidade e de produtividade são coletados. Com medições, as tendências (boas ou más) podem ser detectadas, melhores estimativas podem ser feitas e aperfeiçoamentos reais podem ser conseguidos ao longo do tempo. Há quatro razões para medir processos, produtos e recursos de software: para caracterizar, para avaliar, para prever ou para aperfeiçoar. Medidas, Métricas e Indicadores Uma medida fornece uma indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de um produto, ou de um processo. A IEEE define métricas como medida quantitativa de grau em que um sistema, componente ou processo possui um determinado atributo.

4 Quando dados de um único ponto são coletados (por exemplo, quantidade de erros descobertos na revisão de um único módulo, pessoas-horas gastas na revisão de um único módulo, etc ), uma medida é estabelecida. Um medição ocorre como resultado da coleta de um ou mais pontos. Uma métrica de software relaciona as medidas individuais de alguma forma (por exemplo, um número médio de erros encontrados por revisão ou um número médio de erros encontrados por pessoahora, emprega nas revisões). Um engenheiro de software realiza medidas e desenvolve métricas de modo a obter indicadores. Um indicador é uma métrica, ou combinação de métricas, que fornece compreensão de um processo de software, de um projeto de software, ou do produto propriamente dito. Exemplo: Quatro equipes de software estão trabalhando em um grande projeto de software. Cada equipe precisa conduzir revisões de projeto, mas pode selecionar o tipo de revisão que irá usar. Pelo exame da métrica, erros encontrados por pessoa-hora empregada, o gerente de projeto nota que duas equipes que estão usando métodos de revisão mais formais, exibem um valor para os erros encontrados por pessoa-hora empregada, que é 40% maior do que o valor das outras equipes. Considerando todos os outros parâmetros iguais, isso, para o gerente de projeto, é um indicador de que os métodos de revisões formais podem fornecer um retorno maior do investimento em tempo que outra abordagem de revisão menos formal. Este pode, então, decidir sugerir que todas as equipes usem a abordagem menos formal. A métrica pode fornecer compreensão ao gerente de um projeto. E compreensão leva a uma tomada de decisão mais

5 precisa. A medição é comum no mundo da engenharia. Medimos consumo de energia, peso, dimensões físicas, temperatura, voltagem, relação entre sinal e ruído.. Na engenharia de software a medição é muito menos comum temos dificuldade em concordar quanto ao que medir e dificuldade em avaliar as medidas que são coletadas. Métricas devem ser coletadas de modo que os indicadores de processo e de produto possam ser determinados. Métricas de Processo Indicadores de processo permitem à organização de engenharia de software ter idéia da eficácia de um processo existente. Elas permitem aos gerentes e profissionais avaliarem o que funciona e o que não funciona. Métricas de processo são coletadas ao longo de todos os projetos e durante longos períodos. Seu objetivo é fornecer indicadores que levem ao aperfeiçoamento do processo de software a longo prazo. Métricas de Projeto Indicadores de Projeto permitem ao gerente de projeto de software: 1. Avaliar o status de um projeto em andamento; 2. Acompanhar riscos potenciais; 3. Descobrir áreas-problemas antes que elas se tornem críticas; 4. Ajustar o fluxo de trabalho ou tarefas; 5. Avaliar a capacidade da equipe de projeto e controlar a qualidade dos produtos do trabalho de software. Em alguns casos, as mesmas métricas de software podem ser usadas para determinar indicadores de projeto e de

6 processo de software. Métricas de Processo e aperfeiçoamento do processo de software Medimos a eficácia de um processo de software indiretamente originamos um conjunto de métricas, baseadas nas saídas que podem ser derivadas do processo. As saídas incluem medidas de erros descobertos antes da entrega do software, defeitos entregues aos usuários finais e por ele relatados, produtividade dos produtos de trabalho entregues, esforço humano despendido, tempo gasto, cumprimento de cronograma e outras medidas. Algumas dessas medidas, tais como defeitos entregues aos usuários finais, só podem ser utilizadas para avaliar o processo, enquanto que outras, tais como erros descobertos antes da entrega do software, podem ser utilizados para avaliar tanto o processo quanto um projeto em específico. As métricas de processo de software podem fornecer benefícios significativos, à medida que a organização trabalha para aperfeiçoar seu nível gerencial de maturidade de processo. Todavia, essas métricas podem ser mal utilizadas, criando mais problemas do que conseguem resolver. Grady (1992) sugere uma etiqueta de métricas de software, que é apropriada tanto para os gerentes quanto para os profissionais, quando eles instituem um programa de métricas de processo: Use bom senso e sensibilidade empresarial quando interpretar dados de métricas. Forneça regularmente realimentação aos indivíduos e equipes

7 que coletam medidas e métricas. Não use métricas para avaliar indivíduos. Trabalhe com profissionais e equipes para estabelecer metas claras e métricas que devem ser usadas para alcançá-las. Nunca use métricas para ameaçar indivíduos ou equipes. Dados de métricas que indicam uma área problemática não devem ser considerados negativos. Esses dados são meramente um indicador para melhoria do processo. Não fique obcecado com uma única métrica em detrimento de outras métricas importantes. À medida que uma organização sente-se mais confortável, coletando e usando métricas de processo, a derivação de indicadores simples dá lugar a uma abordagem mais rigorosa, chamada melhoria estatística de processo de software statistical software process improvement (SSPI). A SSPI usa a análise de falhas de software para coletar informação sobre todos os erros e defeitos encontrados à medida em que uma aplicação, sistema ou produto é desenvolvido e usado. Erro falha num produto de trabalho de engenharia de software, ou resultado a ser produzido, que é encontrado por engenheiros de software antes do software ser entregue ao usuário final. Defeito falha encontrada depois da entrega ao usuário final. A análise de falhas funciona da seguinte maneira: 1. Todos os erros e defeitos são categorizados por origem (por exemplo: falha na especificação, falha de lógica, não atendimento à padrões) 2. O custo para corrigir cada erro e defeito é registrado. 3. A quantidade de erros e defeitos de cada categoria é contada e ordenada de forma decrescente. 4. O custo total de erros e defeitos de cada categoria é

8 calculado. 5. Os dados resultantes são analisados, para descobrir as categorias que produzem um maior custo para a organização. 6. São desenvolvidos planos para modificar o processo, com o objetivo de eliminar (ou reduzir a frequência das) classes de erros e defeitos que são mais dispendiosas. Métricas de Projeto Métricas de processo de software são usadas com finalidade estratégica. Medidas de projeto de software são táticas métricas de projeto e indicadores derivados delas são usados por um gerente de projeto e por uma equipe de software, para adaptar o fluxo de trabalho e as atividades técnicas do projeto. A primeira aplicação das métricas de projeto, na maioria dos projetos de software, ocorre durante as estimativas. Métricas coletadas de projetos anteriores são usadas como base, a partir da qual as estimativas de esforço e de tempo são feitas para o trabalho atual de software. À medida que o projeto prossegue, medidas de esforço e de tempo despendidos são comparadas com as estimativas originais o gerente de projeto usa esses dados para monitorar e controlar o progresso. À medida que o trabalho técnico se inicia, outras métricas de projeto começam a ter importância, como: Taxa de produção representada em termos de páginas de documentação, horas de revisão, pontos-por-função e linhas de código fonte entregue. O objetivo das métricas de projeto é duplo: Primeiro essas métricas são usadas para minimizar o

9 cronograma de desenvolvimento, fazendo os ajustes necessários para evitar atrasos e problemas, e riscos em potencial. Métricas de projeto são usadas para avaliar a qualidade do produto durante sua evolução e, quando necessário modificar a abordagem técnica para aperfeiçoar a qualidade. À medida que a qualidade é aperfeiçoada, os defeitos são minimizados, e, à medida que a contagem de defeitos decresce, a quantidade de retrabalho durante o projeto é também reduzida. Isto leva à diminuição do custo total do projeto. Métricas Orientadas ao Tamanho Métricas orientadas ao tamanho são originadas pela normalização das medidas de qualidade e/ou produtividade, considerando o tamanho do software que foi produzido. Se uma organização de software mantém registros simples, uma tabela de medidas orientadas ao tamanho, pode ser criada. A tabela lista cada projeto de software desenvolvido e as correspondentes medidas daqueles projetos. Deve-se notar que o esforço e o custo registrados na tabela referem-se a todas as atividades de engenharia de software

10 (análise, projeto, codificação e teste), não apenas à codificação. Para o desenvolvimento de métricas foi escolhida uma medida base da tabela anterior LOC (Linhas de Código-Fonte) A partir dos dados rudimentares, contidos na tabela anterior, um conjunto de métricas simples orientadas a tamanho pode ser desenvolvido para cada projeto. Erros por KLOC (milhares de Linhas de Código Fonte); Defeitos por KLOC; R$ por LOC (estimado ); Páginas de documentação por KLOC; Adicionalmente, outras métricas interessantes podem ser calculadas: Erros por pessoa-mês; LOC por pessoa-mês; $ por página de documentação (estimado ); Métricas orientadas a tamanho não são universalmente aceitas como o melhor modo de medir o processo de desenvolvimento de software. A maior parte da controvérsia gira em torno do uso de linhas de código fonte como medidas-chave. Adeptos da medida de linhas de código fonte alegam que LOC é um artefato de todos os projetos de desenvolvimento de software, que pode ser facilmente contado e que muitos modelos de estimativa usam tal artefato. Por outro lado, os oponentes argumentam que as medidas de LOC: São dependentes da linguagem de programação. Penalizam programas curtos, mas bem projetados. Não podem acomodar facilmente linguagens não procedimentais e que seu uso na estimativa requer um

11 nível de detalhes que pode ser difícil de alcançar, ou seja, significa que o planejador deve estimar o LOC a ser produzido, muito antes que a análise e o projeto tenham sido completados. Métricas Orientadas a Função Métricas de software orientadas a função usam uma medida da funcionalidade entregue pela aplicação como valor da normalização. Como funcionalidade não pode ser medida diretamente, deve ser originada indiretamente usando outras medidas diretas. Métricas orientadas a função foram inicialmente propostas por Albrecht em 1979 que sugeriu uma medida chamada pontos-porfunção. Pontos-por-função derivadas a partir da contagem (direta) do domínio da informação do software e avaliação da complexidade do software. São calculados completando a tabela apresentada a seguir. Cinco características do domínio da informação são determinadas e as contagens são registradas nos lugares próprios da tabela.

12 Quantidades de entradas do usuário cada entrada do usuário, que fornece dados distintos orientados à aplicação do software, é contada. Entradas devem ser distinguidas de consultas, que são contadas separadamente. Quantidade de saídas do usuário cada saída do usuário, que fornece informação orientada à aplicação para o usuário, é contada. Nesse contexto, saída refere-se a relatórios, telas, mensagens de erro, etc. Itens de dados individuais dentro de um relatório não são contados separadamente. Novas consultas do usuário uma consulta é definida como uma entrada on- line, que resulta na geração de alguma resposta imediata do software sob forma de saída on-line. Cada consulta distinta é contada. Quantidade de arquivos cada arquivo lógico (isto é, grupo de dados lógicos que pode ser parte de uma base de dados maior ou um arquivo separado) é contado. Quantidade de interfaces externas todas as interfaces que são usadas para transmitir informação a outro sistema, são contadas.

13 Uma vez coletados esses dados, um valor de complexidade é associado com cada contagem. Organizações que usam os métodos de pontos por função desenvolvem critérios para determinar se uma instância particular é simples, média ou complexa. No entanto, esta determinação é um tanto subjetiva. Para determinar os pontos por função é usada a seguinte relação: FP = contagem total X [0,65 + 0,01 X? (Fi)] Os Fi (i=1 a 14) são valores de ajuste de complexidade, baseados nas respostas às seguintes perguntas: O sistema requer salvamento (backup) e recuperação (recovery) Comunicações de dados são necessárias? Há funções de processamento distribuídas? O desempenho é crítico? O sistema vai ser executado em um ambiente operacional existente, intensivamente utilizado? O sistema requer entrada de dados on-line? A entrada de dados on-line, exige que a transação de entrada seja construída através de várias telas ou operações? Os arquivos mestre são atualizados on-line? As entradas, saídas, arquivos ou consultas são complexas? O processamento interno é complexo? O código é projetado para se reusado? A conversão e a instalação estão incluídas? O sistema está projetado para instalações múltiplas em diferentes organizações? A aplicação está projetada para facilitar modificações e para facilidade de uso pelo usuário? Cada uma destas questões é respondida usando uma escala que

14 varia entre: 0 não importante e não aplicável 5 absolutamente essencial Os valores na equação e os fatores de peso da tabela, foram determinados empiricamente. Uma vez calculados, os pontos por função são usados de modo análogo à LOC, como forma de normalizar medidas de produtividade, qualidade e outros atributos de software. Tais como: Erros por FP Defeitos por FP $ por FP Páginas de documentação por FP FP por mês. Fonte: ii/04_metricas_de_processo_e_projeto_de_software.pdf Controle da Administração Pública O Controle da Administração Pública é o dever de verificação e correção que sobre ela exercem os órgãos dos Poderes Judiciário, Legislativo e Executivo, com o objetivo de garantir a compatibilidade de sua atuação com os princípios que lhe são impostos pelo ordenamento jurídico. Para lembrar: Administração Indireta Autarquia, Fundações Públicas,

15 Sociedade de Economia Mista, Empresas Públicas, Associações Públicas; Administração Direta União, Estado, Municípios e DF; Espécies Quanto ao órgão que o exerce: Administrativo; Legislativo; Judicial; Quanto ao momento em que se efetua: Controle prévio (a priori) Controle preventivo, pois busca impedir a expedição de ato ilegal ou contrário ao interesse público; Controle concomitante exercido ao mesmo tempo em que se realiza a atividade; Controle posterior busca reexaminar atos já praticados, para corrigi-los, desfazê-los ou apenas confirmá-los. Ex: aprovação, homologação, revogação, convalidação. Quanto à localização do órgão controlador (integrante ou não da estrutura do órgão controlado): 1. Controle interno controle que cada um dos Poderes exerce sobre sua própria atividade administrativa. Apesar de majoritariamente entender-se como interno o controle efetuado pela Administração Direta sobre a Indireta, o CESPE-UnB classificou como CONTROLE INTERNO- EXTERNO. Ex.: União; 2. Controle externo controle exercido por um dos Poderes sobre o outro ou controle da Adm. Direta sobre a Indireta. Ex: fiscalização contábil, financeira e orçamentária (CF, art. 71) prevê o controle externo a cargo do Congresso Nacional, com o auxílio do TC;

16 Princípio da Autotutela Nos termos da Súmula 473, o Estado pode diretamente anular os seus próprios atos, quando houver vícios ou revogá-los se inconveniente (atos ilícitos). Tutela Administrativa É o controle da Administração Direta sobre a Indireta. Quanto ao aspecto da atividade administrativa a ser controlada: Controle de legalidade exercido pelos 3 Poderes. A decisão administrativa pode ser no sentido de sua conformidade com a ordem jurídica, caso em que será o ato terá confirmada sua validade; ou pela sua desconformidade, caso em que o ato será anulado (ex tunc); Controle de mérito exercido pela própria Administração. Poderá a Administração decidir que o ato permanece conveniente e oportuno com relação ao interesse público, caso em que permanecerá eficaz; ou que o ato não se mostra mais conveniente e oportuno, caso em que será ele revogado pela Administração (ex nunc). Princípio da Segurança Jurídica Decai em 5 anos o direito de Administração Pública anular os seus próprios atos. Controle Administrativo Corresponde ao exame que a Administração Pública faz sobre a sua conduta, quanto à legalidade ou ao mérito de seus atos, por iniciativa própria ou mediante provocação. Abrange os órgãos da Administração direta e as pessoas jurídicas que integram a Administração indireta. Controle sobre os órgãos da Administração direta é um controle interno (hierárquico) e decorre do poder de autotutela que permite à Administração rever os próprios atos quando ilegais,

17 inoportunos ou inconvenientes. Súmula 346 e 473 do STF. Controle sobre as entidades da Administração Indireta (tutela) é um controle externo que só pode ser exercido nos limites estabelecidos em lei, visando a impedir que a autarquia, fundação pública, empresa pública ou sociedade de economia mista se desviem dos objetivos previstos na lei específica que as criou ou instituiu. Controle Legislativo Dois tipos de controle: Controle Político Analisa aspectos de legalidade e de mérito. Ex. convocação de ministro de Estado para prestar informações, apuração de irregularidades pela Comissões Parlamentares do Inquérito; Controle Financeiro art. 70 a 75 fiscalização contábil, financeira e orçamentária a cargo do Congresso Nacional com o auxílio do Tribunal de Contas da União. Controle Judicial Sistema de unidade de jurisdição (jurisdição una) monopólio da função judicial nas mãos do Poder Judiciário art. 5º, XXXV, da CF a lei não excluirá da apreciação do Poder Judiciário lesão ou ameaça a direito. Limites Análise da legalidade (art. 5º, LXXIII e 37, da CF). Poder Judiciário não pode invadir o mérito do ato administrativo, determinado pela Administração Pública.

18 Meios de Controle para movimentar o Poder Judiciário Remédios constitucionais Habeas Corpus art. 5º, LXVIII; Habeas Data art. 5º, LXXII; Mandado de Injunção art. 5º, LXXI; Mandado de Segurança individual art. 5º, LXIX; Mandado de Segurança coletivo art. 5º, LXX; Ação Popular art. 5º, LXXIII; Ação Civil Pública art. 129, III; Controle de constitucionalidade.