CAPITULO 10 Analisando Cada Fase dos Testes de Verificagao Cada fase do projeto de software cumpre uma importante etapa de en- tendimento do problema e da definicao de uma solugao mais adequada as necessidades do cliente. Cabe ao processo de qualidade de software garantir que cada etapa esta sendo concluida adequadamente para que a etapa poste- rior seja desempenhada da forma mais tranquila e produtiva possivel. Aetapa de verificacdo tem importancia fundamental no processo de qua- lidade, pois focaliza suas aces nas etapas iniciais do projeto, nas quais geral- mente ocorre a maior incidencia de defeitos geralmente associados a defini- c6es erradas ou a falhas nas decisdes realizadas. Tabela 10.7 Anélise das fases dos testes de validagao Modelo de Negécios | e Revisar Contexto do Mercado Analise de Riscos e Necessidades do Cliente e Arvore de Deciséo e Revisar Riscos do Projeto S Estudo de Viabilidade | Auditar Alternativas de Execugao do Projeto ; Revisar Estudo de Viabilidade do Projeto ‘ Modelo de Negocios84 GARANTIA DA QUALIDADE DE SOFTWARE Tabela 10.7 Anilise das fases dos testes de validagao (continuagao) Especificagao | « Especificagdo « Revisar Especificagao de Requisitos de Requisitos dos Requisitos Funcionais Rastreabilidade « Revisar Especificagéo de Requisitos Nao-Funcionais « Revisar Priorizacdo de Requisitos « Auditar Rastreabilidade de Requisitos Revisar Arquitetura da Aplicagéo Anilise e Arquitetura da . Modelagem Aplicagaéo © Revisar 0 Modelo Estatico Modelos Estaticos do Projeto de Software Modelos Dinaémicos e Revisar 0 Modelo Dindémico Modelos de do Projeto de Software Distribuigéo. Revisar Nivel de Componentizagao Revisar Nivel de Reutilizagao Impiementacao | * Cédigo-fonte ¢ Revisar 0 Cédigo-fonte Componentes Avaliar Complexidade « Manual do Usuario do Cédigo-fonte e Auditar Rastreabilidade entre Componentes Revisar Manual do Usuario Normalmente, as etapas de um projeto de software produzem documen- tos sem que estes sofram uma avaliacao direta, o que impede que determina- dos problemas sejam avaliados por diferentes angulos, aumentando os tis- cos das decisées formalizadas serem inconsistentes na sua pratica. E nesse ponto que o processo de verificagéo ganha forca e torna-se um importante mecanismo de prevencao de defeitos, pois atua diretamente na fonte das de- cisdes e avalia se determinadas atividades criticas do processo de software est4o sendo realizadas. 10.1. Verificagao de Negécios -Normalmente, a fase de modelagem de'negécios nao € convenientemente explorada nos projetos de desenvolvimento de software. Como € nessa fase que estabelecemos o primeiro contato com as necessidades, expectativas © exigéncias do cliente, conseguimos estabelecer uma macrovisao da extens40Analisando Cada Fase dos Testes de Verificagao "= Modelar as necessidades e estabelecer uma macrovisio. + Identificar expectativas e exigéncias do cliente. ~ ‘+ Estimar prazos € custos do projeto de software. Ls ‘= Verificar aderéncia do modelo de negécios com a macrovisio. + Verificar as expecativase exigéncias do projeto. + Verificar se projesbes foram realizadas criteriosamente. Figura 10.1 Objetivo da verificagéo de negécios do projeto e dos principais objetivos a serem alcancados com a construc¢do de um novo software. Atender a essas expectativas é crucial para 0 sucesso de um projeto de software. Assim, espera-se que nessa fase exista uma modelagem de negécios que possibilite a criacao da macrovisdo, a qual possibilitara um dimensio- namento adequado dos recursos humanos, fisicos e financeiros necessa- rios para a construcao do software e para sua adequada operacionaliza- ¢ao. Com essa visdo bem definida e os prazos e custos adequadamente projetados, poderemos avaliar se € vantajoso ou nao dar prosseguimento ao projeto. 10.1.1. Pontos de Ve O objetivo dessa fase € garantir que os diversos documentos produzidos te- nham total aderéncia as necessidades apontadas pelos clientes. Muitas ve- Zes, OS projetos sao iniciados sem que os clientes tenham validado essa ma- crovisao, fazendo com que a equipe do projeto superestime as necessidades do cliente, criando um “canhdo para matar uma tinica mosca”. O exercicio de revisar esses documentos com o cliente possibilita explorar alguns aspec- tos que podem inviabilizar um projeto de software, fazendo com que o clien- te perca uma oportunidade real de negocios devido ao mau dimensionamen- to do problema. agao Abaixo estdo relatados alguns pontos que poderiam ser considerados criticos para se avaliar a qualidade desses documentos. v Avaliar se todas as necessidades, metas e exigéncias foram listadas. ¥ Verificar se a modelagem de negécios cobre todas as necessidades. Conferir se as projecdes realizadas s4o baseadas em métricas e indica- dores confiaveis. v Avaliar a existéncia de alternativas a essa solucdo.86 GARANTIA DA QUALIDADE DE SOFTWARE ¥ Avaliar o retorno sobre o investimento em cada alternativa exis, tente (ROI). v Validar as opcdes de investimento (arvore de decisao). 10.1.2. Um Exemplo de Checklist Dever existir uma tinica checklist para cada documento produzido na fase de verificagao da modelagem de negécios. Nesta etapa, éconveniente que to- dos os documentos gerados sejam revisados pelo cliente, uma vez que serio eles que “pagardo a conta” caso as coisas nao sejam adequadamente bem pla- nejadas. Tabela 10.2 Exemplo de checklist do modelo de negécios Sue aH ios Sasa NSE Levantamento das Necessidades do Cliente — Todas as necessidades foram devidamente registradas. O Sim 0 Nao ~ Cada necessidade apontada possui uma descrigao. oO Sim O Nao De igdo das Caracteristicas do Software ~ Cada caracteristica atende ao menos a uma necessidade 0 Sim 0 Nao identificada. = Cada caracteristica possui uma descrigao clara. O Sim OG Nao — Cada caracteristica possui exemplos que auxiliam seu 0 Sim 0 Nao entendimento. —Existe uma rastreabilidade entre caracteristicas e 0 Sim O N&o necessidades. Tabela 10.3 Exemplo de checklist da proposta de projeto de software Todos os objetivos foram apontados e claramente Oo Sim Oo Nao descritos. — Todos os objetivos podem ser quantificaveis, OSim | GNao87 Analisando Cada Fase dos Testes de Verificagao Tabela 10.3 Exemplo de checklist da proposta de projeto de software (conti uagao) Definigao dos Objetivos do Pro} -Todos os objetivos possuem data-limite para ocorrer. 0 Sim 0 Nao - Existe rastreabilidade entre objetivos e necessidades. usim | Nao Defini¢o dos Riscos ~ Todos os riscos foram identificados e adequadamente osim | 0 Nao descritos. ~Existe um plano de agéo para cada risco definido. asim | Nao -Foram definidos “impacto” e "probabilidade” paracada_ | O Sim | O Nao risco apontado, 10.1.3. Um Exemplo de Critério de Finalizagao Como se trata de uma fase extremamente critica do projeto de software, é re- comendavel estabelecer um critério de finalizac4o apoiado no aceite de todaa documentacao referente 4 modelagem de negécios e ao documento que des- creve as condi¢des técnicas ¢ financeiras a que sera submetido esse: projeto; portanto, abaixo estao listados alguns critérios que poderiam ser empregados: ¥ Modelagem de negocios assinada pelas diretorias e geréncias envol- vidas. v Proposta de projeto de software assinada pelas diretorias e geréncias envolvidas. 10.2. Verificagéo de Requisitos Uma vez encerrada a fase de modelagem de negocios, temos um projeto que Possui orcamento definido, objetivos e necessidades a serem alcancados, além de uma macro-visao que possibilita definir o escopo do projeto de soft- ware com relativa precisdo. Portanto, nesta nova fase do processo de enge- nharia de software, teremos agora a missao de detalhar todos os aspectos funcionais e nao funcionais relativos a solucao a ser construida, estabelecen- do todoo conjunto de especificacdes de negécio em seu nivel maximo de de- talhamento.88 GARANTIA DA QUALIDADE DE SOFTWARE e depende dessa fase de defini- areas de negocios e tecnologia ” do projeto, apontando to- O sucesso de qualquer projeto de softwar ¢40 dos requisitos. E neste momento que as detalham e estabelecem a “verdadeira dimensa0” dos os aspectos a serem implementados. Também € ai que refinamos aex- pectativa do cliente em relacao ao produto, uma vez que © nivel de detalha- mento possibilita a descoberta de aspectos que nao tinham sido previstos, Caso seja necessério, serao rediscutidos custos € prazos com © cliente, para que sejam introduzidas as novas caracteristicas no projeto do software. + Identfcar os requisites funcionais. + Identificar os requisitosnéo funcionais. Tdentifcar a arquitetura da aplcacao. + Verificar consisténcia dos requisitos funcionais. + Verficar consisténcia dos requisitos nao funcionais. + Verficarrastreabilidade entre requisitos e necessidades. Figura 10.2 Objetivo da veriticagao de requisitos Os requisitos direcionarao todas as fases posteriores do desenvolvimen- to do software, estabelecendo um escopo para o produto final. Esses requisi- tos sao registrados sem especificar como serao implementados. Servem tam- bem para ajudar a definir a arquitetura e avaliar o sistema a medida que este evolui em seu desenvolvimento. A qualidade dos requisitos é um importante indicador de uma organiza- ¢do. Bons controles de requisitos estao geralmente associados ao nivel de maturidade organizacional. E comum que no avangar do projeto novos re- quisitos venham a ser incorporados, provocando mudancas e aumento do volume total de trabalho. Gerenciar bem essa demanda adicional de requisi- tos significa controlar os impactos de tempo e recursos que isso ira deman- dar, portanto, trata-se de uma fase critica do processo como um todo. 10.2.1. Pontos de Verificagao Nessa etapa, os revisores deverao concentrar-se na identificacdo de todos 05 requisitos funcionais e nao funcionais de um software. E muito comum nes- sa fase que os requisitos sejam relatados de forma simplificada, sem que exis" ta real entendimento sobre o item que esta sendo listado. Cada requisito deve ser claro o suficiente para que nao produza uma interpretacao errad@Analisando-Cada Fase dos Testes de Verificagao sobre sua real intencdo, o que provocaria falha na concep¢ao do produto, ge- rando custo adicional no projeto de software. Assim, cabe aos profissionais que estao atuando como revisores investi- gar esses requisitos e garantir sua adequada definicao. Abaixo estado relata- dos alguns exemplos de pontos que poderiam ser considerados criticos na avaliacdo da qualidade dos requisitos. v Completo: Todos os requisitos do projeto devem estar documenta- dos. v Claro: Cada requisito deve expressar seu propésito em relacdo ao pro- jeto. v Simples: Cada requisito deve expressar sua esséncia com uma simples definicdo. v Preciso: Cada requisito deve ser exato, nao dar margens a duvidas. v Consistente: Cada requisito nao deve possuir conflitos com outros re- quisitos existentes. v Relevante: Cada requisito deve pertencer ao escopo do projeto.em questao. v Testavel: Cada requisito devera fornecer informacoes que possibili- tem quantificar se um determinado item foi adequadamente imple- mentado. v Factivel: Cada requisito deve ser viavel em sua implementacao, avali- ando as condi¢ées financeiras, humanas e tecnolégicas disponiveis no projeto. Express6es como ser um software seguro, facil de usar, facil de manter, com boa performance, s4o muitas vezes citadas mas nunca bem. explicadas. Cada uma parece ser uma grande armadilha que deve ser desarmada e essa é a missao dos revisores. Quando estamos lendo os requisitos pelo ponto de vista da qualidade, essas afirmacoes passam a ter valor fundamental, afinal, Serd através desses parametros que iremos avaliar se os requisitos foram ade- quadamente implementados. Quando um revisor encontrar a frase “As consultas a pedidos deverao ter uma boa performance”, este logo tentard estabelecer parametros mensura- veis, como por exemplo, “As consultas a pedidos (100 usuarios simultanea- mente em sites diferentes) deverao ocorrer em até 10 segundos”. Dessa for- ™ma, estabelecemos um acordo de servico entre a area de negocios e a de'tec- nologia, sendo devidamente documentado como um requisito do'software.90 GARANTIA DA QUALIDADE DE SOFTWARE 10.2.2. Um Exemplo de Checklist Tabela 10.4 Exemplo de checklist Diagrama de Casos de Uso ~ Existe um modelo de casos de uso para cada subsistema oO Sim O Nao identificado. — Todos os casos de usos estéo adequadamente descritos. asim | ONao O Sim 0 Nao ~ Todos os atores estéo adequadamente representados. Levantamento de Requisitos oSim | ONao O Sim 0 Nao —Cada caso de uso representa um requisite funcional. - Existe rastreabilidade entre requisitos identificados e necessidades. ~ Requisitos foram avaliados por importancia, volatilidade idade. oO Sim 0 Nao e criti Especificagées Funcionai — Cada requisito funcional possui uma especificagao oO Sim | ONao detalhada. — As especificagées contemplam os fluxos basicos, alternativos e excecao. ~ As especificagées contemplam pré-requisitos e pés-condigées. Especificagées Nao Funcionais oO Sim 0 Nao O Sim Nao _ Todas as categorias de requisitos nao funcionais foram 0 Sim 0 Nao levantadas. — Cada requisito nao funcional possui uma especificagéo Osim | o Nao detalhada. ~ Todas as dependéncias dos componentes foram Sim | O Nao estabelecidas. Be) 10.2.3. Um Exemplo de Critério de Finalizagao O critério de finalizacao da fase de levantamento dos requisitos deve garantit ue todos os requisitos foram adequadamente identificados pelo projet de software. Os requisitos devem efletir todas as caracteristicas funcionais © nao funcionais que 0 cliente espera receber quando o software esté disponi-91 Analisando Cada Fase dos Testes de Verificagao pilizado, funcionando como uma espécie de contrato de servico. Portanto, as especificagdes que detalham esses requisitos serdo revisadas com a area ysudria para que nao exista um desvio das expectativas originais do cliente em relacdo ao software que esta sendo desenvolvido. Alguns critérios que poderiam ser empregados para finalizar essa fase sao: v Especificacdes funcionais criadas e revisadas. v Especificacdes nao funcionais criadas e revisadas. v Rastreabilidade entre requisitos e entre necessidades. 10.3. Verificagdo da Analise e Modelagem Uma vez determinados os réquisitos que sao esperados, conseguimos pro- duzir uma imagem mais nitida sobre o que deveremos atender, possibilitan- doa modelagem de uma solucdo mais aderente e flexivel as exigéncias e ex- pectativas do cliente. Nessa etapa o objetivo é definir uma solugdo tecnolégica que suporte nao somente os requisitos estabelecidos pelo cliente, mas também requisitos de qualidade que deverao ser atendidos pela arquitetura do software a ser modelada. A modelagem de uma boa arquitetura deve contemplar caracte- risticas como flexibilidade (capacidade de absorver mudangas e arranjos di- ferenciados de processamento), escalabilidade (suportar 0 crescimento de transacoes), ser reutilizavel (intensificar a reutilizacao de partes do software). Tudo isso deverd estar inserido no contexto da solucdo tecnoldgica que sera definida nessa fase. Muitas vezes, as solugdes modeladas nem sempre sao adequadas ao longo ptazo, evidenciando falhas no processo de definicao da arquitetura. As revi- s6es possibilitam validar determinados aspectos criticos de uma soluc4o, ava- liando a existéncia de mecanismos que suportem um alto nfvel de parametri- zacdo, possibilitando assimilar mudancas nos negécios e em tecnologias. * Modelar uma soliucdo que suporte todos os requisitos. ‘Modelar uma arquteturaflexvel,escaldvel e reutilizavel. jodelar uma arqutetura que suporte mudancas. Neriicagao "= Veriicar consisténcia da arquitetura da Solucio. ‘Andlise e + Verificar aderéncia de requisites funcionais com a solucao; i + Netfcaraderncia de requistos nao funcionais com a solugdo, Figura 10.3 Objetivo da verificagao de andlise e modelagem92 GARANTIA DA QUALIDADE DE SOFTWARE 10.3.1. Pontos de Verificagaéo O objetivo desta fase nao esta somente na avaliacao da aderéncia da solucag tecnologica aos requisitos funcionais endo funcionais estabelecidos pelo gj. ente, mas também em avaliar a modelagem da solucdo como um todo. Nessa fase, as revisdes devem simular cenarios de mudancas que possibilitem ava. liar o quanto a solucdo consegue absorver as modificagoes de negocios e tec. nologias que poderao ocorrér ao longo do tempo, simulando um impacto di- reto na arquitetura da solucdo modelada. Abaixo, alguns pontos que pode- riam ser avaliados durante esse processo: v Avaliar se todos os requisitos funcionais e nao funcionais contemplam a solucdo. v Avaliar sea arquitetura suporta o crescimento e a seguranga desejados. v Avaliar se a arquitetura suporta futuras mudangas de negocios e de tecnologia. v Avaliar se a arquitetura pode ser operacionalizada em varios am- bientes. v Avaliar as restricdes e problemas conhecidos da arquitetura a ser ado- tada. 10.3.2. Um Exemplo de Checklist Uma checklist de verificacao da andlise e modelagem deverd existir para cada documento a ser revisado. Caso o projeto esteja utilizando diagramas UML para representar as decisdes de modelagem e da arquitetura, poderemos em- pregar uma checklist que siga as seguintes caracteristicas. Tabela 10.5 Exemplo de checklist de diagramas UML Diagramas de Classes = Todas as classes possuem nome e descrigéo adequados, | O Sim | 0 N&O — Todos 0 atributos da classe possuem nome e descrigao | Sim | ONo adequados. — Todos os servigos da classe possuem nomee descrigao | O Sim | O N&O adequados.93 Analisando Cada Fase dos Testes de Verificagdo Tabela 10.5 Exemplo de checklist de diagramas UML (continuagao) Diagrama de Estado Todas as transi¢des de estado possuem um servigo OSim | ONao ou evento associado. - Todos os estados possuem nome e descrigéio asim | ONao adequados. ~ Todas as transigées de estado refletem o real ciclo O Sim Nao de vida da classe. Diagramas de Componentes ~~ ~ Os packages agrupam componentes com as mesmas caracteristicas. ~ Cada componente agrupa classes de tinica camada: user, || O Sim 0 Nao business, data. = Todas as dependéncias dos componentes foram asim | oO Nao estabelecidas. Tabela 10.6 Exemplo de checklist de arquitetura ~Existem parametrizagées que modificam a funcionalidade Nao da aplicagao. Suportar Mudangas Tecnolégicas, : ~ 0 software possui independéncia do banco de dados. asim | oNao - 0 software possui independéncia do sistema operacional. O Sim O Nao [+0 software possui independéncia de browsers. osim | oO Nao 10.3.3. Um Exemplo de Critério de Finalizagao Ocritério de finalizacao da fase de andlise e modelagem deve garantir que aso- lucdo tecnologica que foi modelada atende adequadamente a todos os requisi- tos dos clientes, além de incorporar caracteristicas que deixam a arquitetura94 GARANTIA DA QUALIDADE DE SOFTWARE flexivel e aderente a futuras mudangas. Essa arquitetura devera ser validagg com toda a equipe de profissionais, inclusive a equipe técnica do cliente, gue discutira todos os pontos referentes a utilizagao da soluc4o modelada. Alguns critérios que poderiam ser empregados para finalizar essa fase sao: ¥ Diagramas estaticos (classes e objetos) criados e revisados. ¥ Diagramas dinamicos (estados, sequencia e atividades) criados e reyi. sados. + Diagramas de distribuicdo (components e implantacao) criados e re- visados. 10.4. Verificagao da Implementagao Essa fase encerra o ciclo de verificacao de testes. Nela, toda a documentacao produzida pelas fases anteriores serao transformadas em cédigo de uma de- terminada linguagem de desenvolvimento. A maioria das organiza¢6es co- mega seu ciclo de verificagéo nessa fase. Como muitas delas possuem um fraco processo de coleta de requisitos e modelagem de negocio, tal verifica- ¢ao torna-se inocua. Transformar em codigo especificacdes ruins, incomple- tas e imprecisas acarreta produtos nao adequados e pouco confiaveis. “Traduzir 0s modelos em estruturasinternas dos cbigos. + Traduzir 0s requistos de negdcos, regras e comportamentos em cigofonte. icacko . + Garantir que fones estdo compativeis com os modelos. Nee + Garantirnormas e padtées de desenvolvimento, japleveions * Caranirreduzid nivel de complexidade das fontes. Figura 10.4 Objetivo da verificagao da implementagéo Algumas empresas de software realizam um processo formal de verifica- cao do cédigo produzido. Os testadores avaliam linha por linha em busca de erros, analisam alternativas melhores e mais simples de produzir os mesmos resultados, comentam nomes e declaracdes néo compativeis com os docu mentos gerados nas fases anteriores. Enfim, produzem um qualitativo pro- cesso de verificacao do cdigo-fonte; porém, esse processo pode ser extte- mamente informal, no qual cada desenvolvedor avalia o cédigo de outro profissional em busca de erros realizados.Analisando Cada Fase dos Testes de Verificagao 10.4.1. Pontos de Verificagao O objetivo dessa fase é garantir a qualidade do cédigo-fonte gerado pela equipe de desenvolvimento. Essa qualidade sera atribuida pela pratica das chamadas “regras da boa programacao”, que podem contemplar diversas normas ¢ padrées corporativos seguidos pelas diversas equipes de desenvol- vimento. Abaixo estdo relatados alguns exemplos de pontos que poderiam. ser considerados criticos para avaliar a qualidade dos fontes. v Comparar os modelos de arquitetura com os cédigos-fontes. v Utilizar ferramenta de andlise estatica para avaliar a complexidade dos fontes. v Avaliar as mensagens apresentadas ao usuario final. v Inspecionar a existéncia de rotinas de tratamentos de erros nos pro- cessos criticos. v Inspecionar se o volume de comentarios é suficiente. v Inspecionar a legibilidade do cédigo. v Inspecionar o padrao de-nomenclaturas existentes. 10.4.2. Um Exemplo de Checklist Uma checklist da implementacao devera contemplar um unico documen- to a ser inspecionado. No caso de linguagens de programacao, alguns Pontos da checklist serao especificos de cada tecnologia, enquanto que outros pontos serao comuns a todas as linguagens existentes. No caso de tevisdes dos bancos de dados, também existira uma checklist especifica para essa verificacdo. Tabela 10.7 Exemplo de checklist de cédigo-fonte ‘ eae go He ECA SU RRUE e Coeuee rental ot Comparagao do Modelo de Arquitetura do Software com o Cédigo-fonte > t ~ Todas as classes do modelo foram implementadas. Oo Sim O Nao ~ Todos os métodos de cada classe foram O Sim 0 Nao implementados. ~ Todos os atributos de cada classe foram asim | oO Nao implementados. 396 GARANTIA DA QUALIDADE DE SOFTWARE Tabela 10.7 Exemplo de checklist de cédigo-fonte (continua: go) — Todos os desvios de rotinas possuem um comentario. Oo Sim 0 Nao ~ Todas as mensagens séo claras e bem objetivas: Oo sim | 0 Nao ~ Todas as mensagens apresentam {cones adequados a0 oO Sim OD Nao contexto. Legibilidade do Cédi 3 sill i ~ Todas as estruturas esto adequadamente identadas. Oo sim O Nao = Nao existem linhas agrupadas com IF, SELECT, FOR asim | Nao NEXT e FOR EACH. — Tratamentos de erros e desvios sempre estao no final das Sim 0 Nao rotinas. ~Todas as declaragées de varidveis e constantes estéo no Oo Sim Nao inicio da rotina. — Nao existem varios comandos em uma dnica linha. Oo Sim | O Nao Volume de Comentarios 2 : ~ Todas as rotinas possuem descrigdo sobre seu 0 Nao comportamento. O Sim 0 Nao Tabela 10.8 Exemplo de checklist do banco de dados Comparacao do Modelo de Dados com o Ban _ Todas as tabelas do modelo de dados foram oSim | ONéo implementadas. — Todos 0s campos de cada tabela foram implementados. oO Sim O Nao — Todos os indices de cada tabela foram implementados. Oo Sim | Nao _ Todos os stored procedures de cada tabela foram oO Sim Nao implementados. — Todas as vis6es do modelo de dados foram implementadas. | _O Sim | 0 Néo — Todos os campos de cada visdo foram implementados, Osim | o Nao97 Analisando Cada Fase dos Testes de Verificagao 10.4.3, Um Exemplo de Critério de Finalizagao Podemos empregar uma ferramenta cujo objetivo é realizar, de forma auto- matica, inspecdes nos codigos gerados pela equipe de desenvolvimento. Essa ferramenta realizaré uma analise de normas e padrées relacionada as boas praticas de programacao. Também seré realizada andlise da complexi- dade do c6digo-fonte produzido pelos programadores, 0 que permitira ava- liar se os cédigos estao sendo bem construidos ou nao. O resultado dessa andlise sera uma lista de ndo-conformidades que deverd ser analisada pela equipe de desenvolvimento até que os critérios de finalizacdo sejam alcanga- dos, considerando neste momento o cédigo-fonte OK. Analise de Normas e Padrées de Cod icagao Sera necessario parametrizar a ferramenta com as praticas de codificacao da organizacao, como padroes de varidveis, bibliotecas de uso comum, padroes de internacionalizacao, regras de portabilidade entre versdes de sistemas operacionais, entre outros. A ferramenta ira melhorar a qualidade final do cédigo-fonte, uma vez que conduz o programador a utilizar padroes conhecidos de trabalho, facili- tando o entendimento e, consequentemente, a manuten¢ao dos cédigos- fonte. Abaixo estao relacionados os critérios de finalizac4o segundo aanalise de Normas e Padrées: Banco de Dados Nenhuma _|Nenhuma | Nenhuma Internacionalizacao Nenhuma _|Nenhuma _|Nenhuma Logica Nenhuma _|Nenhuma._|Nenhuma Performance Nenhuma | 10 eros’ |10 eros Portabilidade Nenhuma__|Nenhuma _ |Nenhuma Usabilidade 5S erros 10 erros 20 erros APIs do Windows Nenhuma___|Nenhuma _ |Nenhuma v Critérios Analisados: identificam todos os critérios que serao auto- maticamente analisados e apontados como nao-conformidades do c6- digo-fonte. v Tolerancia a Erros: estabelece os niveis de erros tolerados para cada critério analisado pela ferramenta.a8 GARANTIA DA QUALIDADE DE SOFTWARE Anilise da Complexidade do Cédigo A ferramenta realiza a andlise da complexidade dos cédigos-fonte inspecig. om complexidade acima da perm. nados, identificando quais rotinas estdo ¢ an tida pelos padrées definidos pela organizacao. A ferramenta uuiliza as métri- cas de McCabe para determinar o nivel de complexidade do cédigo (comple. xidade ciclomatica) e identificar a probabilidade. <5 Simples Baixo esforco 5-10 Moderada Médio esforgo 5% 11-20 Dificil Grande esforgo 10% 21-50 Muito dificil Muito complexo 30% > 50 Impossivel testar Refazer - Onde: v Complexidade Ciclomatica: ¢ o nivel de complexidade de um cédi- go-fonte segundo as métricas definidas por McCabe. v Avaliacio da Complexidade: estabelece as categorias de complexi- dades possiveis a serem atribuidas a um c6digo-fonte segundo os cri- térios de McCabe. v Esforco de Manutencao e Teste: dimensiona 0 esforco necessari0 paraa realizacao de testes de caixa branca e realizacao de manv- tencoes nas diversas categorias de complexidades de um cédi- go-fonte. v Probabilidade de Inser¢do de Erros: dimensiona a possibilidade do risco associado as categorias de complexidades de uma determinad# manutenc4o inserir um novo erro no cédigo-fonte. Segundo o critério de finalizacao pela andlise de complexidade de codi- go, segundo as métricas definidas por McCabe, somente serao considerados em conformidade os fontes que estiverem de acordo com os critérios estabe- lecidos pela seguinte tabela:Analisando Cada Fase dos Testes de Verificagao Simples 100% 5-10 Moderada 20% 11-20 Dificil 5% 21-50 2 Muito dificil Nao permitido > 50 Impossivel testar Nao permitido Observacao: Notem que esse critério de finalizagéo estabelece um padrao minimo de qualidade do cédigo-fonte, ou seja, existe uma tolerancia para os cédigos “dificil” e “moderado” desde que nao representem mais de 5% e 20%, respectivamente. No entanto, os cédigos categorizados como “muito dificil” e “impossivel de testar” nao serao aceitos em hipétese alguma. Trata-se de uma regra que esta explicita tanto para desenvolvedores quanto para os profissionais da area de qualidade. Cabe aos desenvolvedores produzir cédigos segundo esse critério, enquanto cabe aos profissionais de qualidade garantirem que esses valores estéo sendo respeitados.