Qualidade de Software: Testes e Conceitos Fundamentais

unidade 1 TESTE DE SOFTWARE Qualidade e unidade 1 Qualidade de Software Prezado estudante Estamos começando uma unidade desta disciplina Os textos que a compõem foram organizados com cuidado e atenção para que você tenha contato com um conteúdo completo e atualizado tanto quanto possível Leia com dedicação realize as atividades e tire suas dúvidas com os tutores Dessa forma você com certeza alcançará os objetivos propostos para essa disciplina OBJETIVO GERAL Conhecer qualidade de software e concetruar os níveis de confiança de software OBJETIVOS ESPECÍFICOS Conceituar qualidade de software Classificar e analisar as técnicas formais e de software Aplicar os métodos das garantias de software Conceituar e aplicar os níveis de confiança de software unidade 1 O conteúdo deste livro é disponibilizado por SAGAH Parte 1 Qualidade de Software QUALIDADE E TESTE DE SOFTWARE 12 Qualidade de software Objetivos de aprendizagem Ao final deste texto você deve apresentar os seguintes aprendizados Conceituar qualidade de software Identificar os benefícios da qualidade de software Aplicar os conceitos de qualidade Introdução Ao adquirir um produto ou serviço o cliente deseja que esse produto seja entregue em pleno funcionamento de acordo com aquilo que foi solicitado e livre de falhas No contexto de software essa realidade é exatamente a mesma quando o cliente solicita um software criase uma expectativa e por isso fazse necessário garantir que o software atenda a ela O produto deve ser entregue em funcionamento e deve atender aos requisitos solicitados pelo cliente O responsável pela garantia dessa entrega eficaz é o setor de qua lidade de software A qualidade de software atua em dois segmentos distintos qualidade de produto e qualidade de processo Neste capítulo você vai estudar os conceitos fundamentais desses dois segmentos bem como conhecer os benefícios da qualidade de software e como aplicála nos projetos de desenvolvimento de sistemas Conceitos A palavra qualidade parece ter um signifi cado bastante óbvio contudo trata se de um elemento complexo e de difícil mensuração dado que a qualidade é relativa e pode assumir diversos valores de acordo com a pessoa que a observa Nesse sentido a qualidade do software pode ser medida de acordo com o quanto ele está em conformidade com o que o cliente solicitou Ou seja mensurase se o software está em conformidade com os requisitos funcionais 13 Qualidade de Software UNIDADE 1 Qualidade de Software PARTE 1 e não funcionais especifi cados explicitamente pelo cliente conforme leciona Basu 2015 Façamos uma analogia suponha que você tenha preferência por chocolate do tipo meio amargo e seu irmão tenha preferência por chocolate ao leite ao chegar em casa se seu pai trouxer um chocolate ao leite muito provavelmente seu irmão dirá que esse chocolate é de alta qualidade enquanto você dirá que o chocolate não tem qualidade porque não atende ao seu gosto à sua expectativa Embora a qualidade do software seja uma prática recente que ganhou evi dência com o advento da tecnologia a qualidade no geral é uma preocupação bem antiga Existem registros de que há mais de quatro mil anos os egípcios estabeleceram um padrão de medida para realizar seus trabalhos de forma apurada chamado de cúbito que equivalia ao tamanho do braço do faraó reinante conforme Koscianski e Soares 2007 Entretanto mesmo a qualidade sendo um conceito tão antigo os projetos de software contam com vários desafios para entregar o software em perfeito funcionamento devido a uma série de fatores em especial a complexi dade Isso porque construir um sistema envolve diversas habilidades como comunicação e interpretação para conseguir entender o que o cliente deseja além de habilidades específicas para as etapas de programação análise da qualidade entre outras que são de grande complexidade Dada a multidisciplinariedade envolvida no processo de desenvolvimento de software e a complexidade de todo o processo o segmento de qualidade se divide em duas áreas relacionadas porém distintas qualidade de processos e qualidade de produtos A área de qualidade de processos trata da organi zação sistemática dos processos da empresa visando ao melhor andamento dos projetos de desenvolvimento de sistemas otimizando o tempo tornando os processos repetitivos e evitando problemas em situações críticas para os projetos por exemplo estimativa custo entrada e saída de recursos humanos Ao buscar garantir a qualidade de um software estamos diante do desafio de estabelecer uma cultura de não tolerância a erros por meio de processos que objetivem inibir ou impedir falhas segundo Bartié 2002 É a área de qualidade de processos que se responsabiliza pela definição da metodologia ou Qualidade de software 2 QUALIDADE E TESTE DE SOFTWARE 14 do ciclo de vida de software que a equipe utilizará podendo optar por exemplo por trabalhar com métodos ágeis ou métodos tradicionais Independentemente da metodologia escolhida o importante é que um processo seja seguido para que a equipe tenha um padrão para se basear Isso melhora a comunicação e influencia na qualidade dos produtos desenvolvidos pela equipe A área de qualidade de produtos tem por objetivo garantir a qualidade do produto tecnológico gerado durante o ciclo de desenvolvimento Para esse fim são realizadas atividades com o objetivo de estressar as funcionalidades do sistema identificando o comportamento dele nesse contexto Essas atividades são chamadas de testes de software Essa área possui algumas divisões sendo a mais importante a subdivisão entre testes que fazem uso do códigofonte do programa chamados de caixa branca e testes que não fazem uso do código fonte do programa chamados de caixa preta Além disso os testes podem ser feitos de forma manual ou automatizada e fazendo uso das mais diversas técnicas conforme Bartié 2002 A eficiência de um processo de testes é afetada diretamente por alguns fatores que devem ser considerados para evitar problemas nas organizações aponta Bartié 2002 falta de planejamento das atividades de testes ausência de testes que validem funcionalidades antigas e ausência de processos de automação de testes Uma terminologia bastante importante e comum na área de testes de quali dade de software é o conceito de bug que abrange erros defeitos e falhas Por curiosidade o termo bug corresponde à palavra inseto em inglês e começou a ser utilizado justamente quando um inseto causou uma falha em um equipamento É importante entender que os termos erro defeito e falha se referem a coisas distintas Defeito é um comportamento inesperado de um produto O defeito está em uma parte do produto e em geral referese a uma funcionalidade que está implementado no código de maneira incorreta Erro é aquilo que foi cometido pelo programador e que gerou um código defeituoso enquanto a falha se dá quando o programa defeituoso é executado e interfere no funcionamento do sistema para o usuário final Falhas também podem ocorrer por fatores externos ao programa como corrupção de bases de dados ou invasões de memória por outros programas conforme Koscianski e Soares 2007 Considere por exemplo o código a seguir conforme Koscianski e Soares 2007 a input c ba d a ba 0 3 Qualidade de software 15 Qualidade de Software UNIDADE 1 Qualidade de Software PARTE 1 A linha de código que calcula o valor para a variável c pode apresentar um problema dado que não é feita uma verificação para validar se o valor de a é 0 Dessa forma pode acontecer um erro ao tentar realizar uma divisão por zero O comportamento anormal do programa que provavelmente gera um bug ou uma interrupção da execução é provocado pela divisão ba Em um primeiro momento podemos dizer que essa linha de código é defeituosa Existe entretanto outra hipótese o defeito pode estar na rotina input Imagine que a especificação dessa rotina estabeleça que ela não deve jamais retornar um valor nulo Nesse caso o erro foi cometido pelo programador responsável por essa rotina Essa segunda hipótese é bastante razoável pois para a maioria dos programas não é recomendado preceder cada operação de divisão com um teste if Nesse caso um erro cometido pelo programador na rotina input fez com que o programa apresentasse um defeito ao executar a divisão de a por b Benefícios Inúmeros são os benefícios que as empresas podem ter ao demandar uma atenção especial para a área de qualidade de software Os benefícios vão muito além de valores fi nanceiros podendo estar relacionados inclusive com evitar transtornos legais ou preservar vidas Empresas que desenvolvem sistemas de semáforos têm uma responsabilidade muito grande uma vez que um erro de programação pode causar um grande acidente de trânsito ou na melhor das hipóteses um transtorno no trânsito É por isso que o controle de qualidade é totalmente importante e benéfico nos dias atuais A qualidade de software possui diversos benefícios que ajudam os usuários a não sofrerem com falhas de software e as empresas a oferecerem produtos melhores impedindo até mesmo grandes catástrofes Vamos verificar alguns dos benefícios da qualidade de software com base em Basu 2015 Qualidade de software 4 QUALIDADE E TESTE DE SOFTWARE 16 1 Economiza dinheiro quanto dinheiro um projeto de software defeituoso lhe custa Custa usuários e clientes E é bem sabido que quanto mais tempo leva para um bug ser detectado em seu software mais difícil e caro é consertálo Ao empregar testes de controle de qualidade durante o processo de desenvolvimento do software você economizará tempo e dinheiro após a implantação 2 Impede emergências corporativas catastróficas com o software corporativo as apostas são ainda maiores Bugs no software corporativo podem levar a blecautes do sistema falta de dados e falhas de comu nicação Se você estiver empregando software em toda a empresa ou lidando com informações confidenciais é melhor ter certeza de que o software funcionará exatamente como ele precisa funcionar Não há margem para erro 3 Inspira a confiança do cliente ao tornar o teste de software de controle de qualidade uma prioridade clara para o desenvolvimento de software você está enviando uma mensagem para seus clientes de que deseja que o software deles seja o mais bemsucedido possível Isso é extremamente importante quando você busca oferecer qualidade e criar relacionamentos de longo prazo 4 Mantém o nível de experiência do usuário elevado está se tornando cada vez mais claro hoje em dia que a experiência do usuário pode que brar ou impulsionar um negócio Se o software estiver com problemas ou estiver lento isso impedirá a experiência do usuário com o produto Má experiência do usuário resulta em insatisfação e frustração A boa experiência do usuário que você obtém quando testa meticulosamente um produto de software resulta em um usuário satisfeito que tem muito mais probabilidade de recomendar o produto e sua empresa a outras pessoas 5 Traz mais lucro se você está criando um software para comercializar ou vender investir em qualidade de software significa que você pode vender seu produto a uma taxa maior Não há nada pior do que um usuário irritado que pagou por um produto que não funciona 6 Aumenta a satisfação do cliente relacionado ao ponto anterior esse benefício está focado na reputação que a satisfação do cliente traz à sua empresa não apenas no lucro Ao oferecer um software de qualidade que funciona quando e como você quer que ele funcione você estará aumentando sua reputação produzindo clientes satisfeitos Não sobre carregue a paciência dos seus clientes com um software defeituoso 5 Qualidade de software 17 Qualidade de Software UNIDADE 1 Qualidade de Software PARTE 1 que você precisa consertar constantemente Dêlhes qualidade desde o início e eles lhe recompensarão com lealdade 7 Promove organização produtividade e eficiência o que você menos deseja é o caos de um software defeituoso uma comunicação frenética e correções apressadas Ser organizado com o teste de controle de qua lidade desde o início de sua estratégia de desenvolvimento permitirá que você trabalhe em paz e seja mais produtivo com seu tempo Ao utilizar metodologias ágeis nas quais os desenvolvedores de software criam e entregam pequenos trechos de um produto em uma linha do tempo clara você pode começar a testar o software à medida que ele é criado em vez de sempre esperar até o final Existe uma regra que vigora desde os princípios do teste de software chamada regra 10 de Myers Essa regra estipula que o custo de encontrar um defeito no sistema aumenta 10 vezes a cada etapa do processo em que esse erro avançar conforme aponta Myers 1979 Essa regra é mais aplicada para o contexto de projetos com ciclo de vida em cascata em que as etapas são executadas sequencialmente dado que em equipes ágeis não existe essa divisão exata de etapas A Figura 1 ilustra essa regra Figura 1 Regra 10 de Myers Fonte MPT 2010 p 8 12000 10000 8000 6000 4000 2000 0 Desenho Especificação Construção Teste Produção Fases do processo de desenvolvimento Custo em US Qualidade de software 6 QUALIDADE E TESTE DE SOFTWARE 18 Aplicando a qualidade de software Conforme vimos anteriormente a área de qualidade de software pode ser dividida em qualidade de produtos e qualidade de processos e é uma im portante área no desenvolvimento de sistemas Para a garantia da qualidade de processos as empresas podem buscar certifi cações Essas certifi cações fazem com a empresa seja de certa forma obrigada a seguir um processo que implemente a qualidade de processos de forma prática As principais certifi cações são CMMI e MPSBR O CMMI sigla para Capability Maturity Model Integration é um mo delo de maturidade utilizado para medir a maturidade dos processos de uma empresa Ele serve também como um guia para a melhoria dos processos das organizações Esse modelo classifica as empresas em cinco níveis conforme Koscianski e Soares 2007 sendo eles Inicial processos caóticos em geral não existe um ambiente propício para o desenvolvimento de software Gerenciado nesse nível já é perceptível uma melhoria em relação ao nível 1 Aqui já existem requisitos gerenciados e processos planejados medidos e controlados Definido nesse nível a maturidade da empresa já está em um nível considerável Aqui os processos são caracterizados e entendidos Gerenciado quantitativamente nesse nível os processos são controlados usando métodos estatísticos e outras técnicas quantitativas Otimizado nesse nível os processos são continuamente melhorados com base em análises feitas pela equipe O MPSBR sigla para Melhoria do Processo de Software Brasileiro também é um modelo de maturidade similar ao CMMI e com o mesmo objetivo O MPSBR foi proposto no Brasil e é utilizado por empresas brasi leiras Esse modelo considera seis níveis sendo eles A processo em otimização B processo gerenciado quantitativamente C processo definido D processo largamente definido E processo parcialmente definido F processo gerenciado 7 Qualidade de software 19 Qualidade de Software UNIDADE 1 Qualidade de Software PARTE 1 G processo parcialmente gerenciado Já para a qualidade de produto diversas são as técnicas que podem ser empregadas A área de testes de software é bastante abrangente e completa sendo sempre recomendado que o trabalho de testes seja feito em conjunto com o desenvolvedor e durante o desenvolvimento do sistema isto é sem esperar que o sistema seja concluído para então testar Vamos falar aqui de alguns tipos de testes e como aplicálos com base em Graham et al 2008 Teste unitário é um tipo de teste realizado diretamente no código fonte do programa em teste Nesse tipo de teste são criadas funcionalidades de testes que validam o comportamento dos métodos ou funções implementadas pelo programador No teste unitário são identificados os primeiros erros e quando obtido sucesso nos testes ou seja quando não forem localizadas falhas as funcionalidades principais do programa devem estar funcionando Um exemplo de técnica para teste unitário é o TDD test driven development que tem por objetivo o desenvolvedor criar primeiro o código de teste para depois criar a funcionalidade e então executar o teste que valida essa funcionalidade Teste funcional é um tipo de teste realizado após o desenvolvimento do sistema ou de um módulo do sistema O teste funcional pode ser automatizado ou manual No caso de teste automatizado são utilizados scripts de teste que simulam o comportamento de um usuário no sistema por exemplo clicando em botões e inserindo valores em campos e verificam a resposta do sistema para esses comportamentos Para testes automatizados esses scripts são executados automaticamente e os defeitos localizados são sinalizados também de forma automática No caso de testes manuais os scripts são substituídos por casos de teste Caso de teste é um documento em que é descrita a ação do usuário e a resposta esperada do sistema para ela Nesse caso a execução do caso de teste é feita manualmente e o registro dos defeitos também Teste de aceitação esse teste é realizado junto com o cliente e visa a verificar se o sistema que foi ou está sendo construído é realmente o que foi solicitado Teste exploratório esse tipo de teste é muito comum mais rápido de ser realizado e se torna uma alternativa para projetos com cronograma apertado Nesse tipo de teste o testador usa a sua experiência para navegar no sistema visando a localizar erros A principal vantagem desse tipo de testes é localizar defeitos que não seriam localizados nos demais testes por exemplo casos em que o usuário tem um comportamento incomum como clicar duas vezes em um botão de salvar Para organizar esses testes e garantir que as funcionalidades principais sejam testadas é comum criar um checklist que Qualidade de software 8 QUALIDADE E TESTE DE SOFTWARE 20 ENCERRA AQUI O TRECHO DO LIVRO DISPONIBILIZADO PELA SAGAH PARA ESTA PARTE DA UNIDADE PREZADO ESTUDANTE nada mais é do que uma lista que registra os principais pontos que devem ser testados nas telas do sistema BARTIE A Garantia da qualidade de software Rio de Janeiro Elsevier 2002 BASU A Software quality assurance testing and metrics India PHI Learning 2015 GRAHAM D et al Foundations of software testing ISTQB certification United Kingdom Cengage Learning EMEA 2008 KOSCIANSKI A SOARES M Qualidade de software aprenda as metodologias e técnicas mais modernas para o desenvolvimento de software 2 ed São Paulo Novatec 2007 MPT Melhoria de processo de teste brasileiro 2010 Disponível em httpwww mptorgbrwpcontentuploads201012MPTBRNivel1v22pdf Acesso em 23 jan 2019 MYERS G J Art of software testing New York John Wiley Sons 1979 Leitura recomendada LEWIS W E Software testing and continuous quality improvement Boca Raton CRC Press 2016 9 Qualidade de software unidade 1 O conteúdo deste livro é disponibilizado por SAGAH Parte 2 Revisões das Técnicas Formais e de software QUALIDADE E TESTE DE SOFTWARE 22 Revisão das técnicas formais e de software Objetivos de aprendizagem Ao final deste texto você deve apresentar os seguintes aprendizados Classificar as técnicas formais Analisar as técnicas formais e de software Ordenar as principais técnicas formais e de software Introdução Entregar para o cliente um produto de qualidade é fundamental para qualquer desenvolvedor ou empresa de desenvolvimento de software Existem muitas formas de buscar a qualidade durante todas as fases da produção de um software Encontrar erros precocemente é fundamental para que no fim o produto possa ser entregue ao cliente com o mínimo de falhas possíveis além é claro de minimizar os custos de correção de defeitos As técnicas de revisão formal RTF consistem em metodologias que reservam certo formalismo e que por seu rigor ajudam na detecção de erros que possam se transformar em defeitos Neste capítulo você vai classificar analisar e ordenar as principais técnicas formais Por que a revisão é importante As técnicas formais são recursos de revisão de software que utilizam uma série de metodologias de verifi cação geralmente baseadas em regras rígidas Esses métodos contribuem signifi cativamente para a identifi cação de possíveis falhas de sistemas À primeira vista a revisão técnica formal RTF pode parecer uma parte da fase de testes uma vez que por meio dela são encontradas as falhas no 23 Qualidade de Software UNIDADE 1 Revisões das Técnicas Formais e de Software PARTE 2 software Contudo a revisão técnica vem muito antes da fase de testes Ela pode ser realizada para cada artefato do software construído Se a RTF fosse realizada durante a fase de testes do software significaria que o produto já estaria pronto e nesse caso todas as falhas de cada artefato já teriam se transformado em defeitos Imagine fazer a RTF de um sistema extremamente complexo apenas no final do processo de desenvolvimento Apesar de ser uma forma importante de manter a qualidade de um produto de software esses métodos não são muito utilizados na prática para qualquer software pois são processos lentos caros e que demandam muita energia para sua execução Sommerville 2007 explica que apesar de essas técnicas serem extrema mente onerosas e se tornarem infinitamente mais complexas à medida que o tamanho e a complexidade do software aumentam elas são fundamentais para sistemas críticos Um sistema crítico é aquele que não pode apresentar falhas pois falhas em certos sistemas podem acarretar danos graves e até a perda de vidas conforme Sommerville 2007 Imagine por exemplo um software que controla trens em uma ferrovia Esse software não pode falhar ao verificar se outro trem está vindo Assim o autor aponta que a confiança é um atributo fundamental desse tipo de sistema O autor define esses sistemas críticos em três categorias Sistema crítico de segurança que se refere aos sistemas que podem resultar em perda de vidas humanas ou dano ambiental Sistema crítico de missão que se refere a sistemas que podem levar à falha em relação a metas como o sistema de navegação de aeronaves Sistema crítico de negócios que se refere a sistemas que ao falharem podem acarretar em perdas financeiras e fracasso em negócios Sommerville 2007 exemplifica esse tipo de situação com um acidente envolvendo um avião em processo de pouso Na ocasião o sistema de freio não foi ativado no momento necessário porque o software entendeu que o avião ainda não havia pousado Isso acarretou na colisão do avião com um prédio e em dezenas de mortos e feridos De acordo com o autor uma inves tigação apontou que o software se comportou exatamente como ele havia sido programado para fazer ou seja o emprego dos testes não foi suficiente para identificar e corrigir o erro do sistema Outro exemplo de software de risco seria um sistema que controlasse todos os carros no trânsito Nós já sabemos que muito em breve os carros poderão Revisão das técnicas formais e de software 2 QUALIDADE E TESTE DE SOFTWARE 24 andar sozinhos nas ruas desviar de outros traçar percursos reconhecer a sinalização e evitar muitos acidentes Também sabemos que esses sistemas já existem mas ainda precisam evoluir para que esse sonho se materialize Agora a pergunta é esse tipo de sistema está totalmente livre de falhas É óbvio que a probabilidade de um sistema falhar e causar uma colisão é muito menor do que a probabilidade de um motorista se atrapalhar e colidir o carro com outro Para um sistema como esse ser eficaz ele necessitará de muita qualidade e o emprego de técnicas formais será fundamental para a redução das possibilidades de erros Existem métodos formais para praticamente todas as fases do software desde o início do processo de concepção As técnicas formais de revisão são recursos que podem ser aplicados aos softwares após certa fase do desenvol vimento uma vez que se busca encontrar possíveis erros no desenvolvimento do software O processo de revisão de um software pode ser feito de muitas maneiras Imagine que dois amigos iniciaram um software para ajudar no controle do estoque do negócio e desenvolveram um sistema sem nenhum tipo de norma Ao final o sistema faz basicamente o que eles precisavam mas é provável que a quantidade de erros seja enorme Para ajudar em um processo de revisão eles podem fazer testes junto com clientes ou pedir a ajuda para outros colegas programadores tentarem encontrar erros Esse processo seria então uma abordagem informal Fazer a revisão de maneira informal é bastante simples e não exige métodos rígidos para a verificação de possíveis erros Ao contrário desse exemplo os métodos de revisão formal exigem conhe cimento e rigidez durante o processo de revisão Existe uma série de formas de realizar a RTF dentre as mais comuns podemos citar walkthrough peer review e inspeção Na próxima seção deste capítulo detalharemos cada uma delas Análise das técnicas formais Qualquer tipo de revisão seja ela formal ou não é fundamental para o reco nhecimento de falhas que podem se tornar defeitos após a entrega do produto Descobrir erros precocemente assegura que o sistema possa ser corrigido o mais rápido possível garantindo um baixo custo tanto fi nanceiro quanto temporal para a correção do produto Pressman e Maxin 2016 ressaltam que a não descoberta e correção no início do processo acarreta em levar esses erros para outras etapas e isso geralmente amplia a falha o que vai tornando o problema cada vez mais difícil de encontrar e mais complexo para 3 Revisão das técnicas formais e de software 25 Qualidade de Software UNIDADE 1 Revisões das Técnicas Formais e de Software PARTE 2 solucionar O autor ressalta que a empresa precisa investir tempo e dinheiro caso não invista terá de fazer um investimento muito maior para a correção de problemas muito mais graves após a entrega do produto Uma grande questão no âmbito da revisão do produto de software é o tempo De acordo com Pressman e Maxin 2016 muitas empresas consideram não ter o tempo necessário para a realização de um processo minucioso de revisão o que acarreta na entrega de um software com muitos erros Essa postura faz com que o custo em tempo para manutenção e correção de erros seja muito maior do que se fosse utilizada uma metodologia de revisão do software durante o processo de desenvolvimento do produto Sommerville 2007 explica que não encontrar um erro a tempo acarreta em um efeito cascata que levará à ampliação do erro transformandoo mais tarde em um defeito Ou seja a correção de falhas em cada artefato de software revisado garante que esses erros não sejam maximizados e transformados em defeitos que demandariam muito mais energia para a correção Apesar de haver uma relutância na aplicação de métodos de revisão formal para encontrar e minimizar erros a Figura 1 mostra que no final do processo o custo de tempo em projetos que não possuíam processos de revisão é muito maior do que naqueles que aplicaram a RTF Isso significa que à primeira vista pode parecer que aplicar uma revisão seja algo banal e um desperdício de tempo e consequentemente de dinheiro mas no médio prazo esse custo é totalmente maximizado se comparado a projetos que não aplicaram RTF Figura 1 Custo de tempo relacionado à aplicação ou não da revisão técnica formal Fonte Pressman e Maxin 2016 437 Esforço Tempo Sem a realização de inspeções Com a realização de inspeções Entrega Teste Código Projeto Requisitos Planejamento Revisão das técnicas formais e de software 4 QUALIDADE E TESTE DE SOFTWARE 26 Na seção anterior exemplificamos o teste informal de software ao apre sentar uma situação hipotética em que dois amigos tentam encontrar erros no sistema sem nenhum tipo de norma ou regra Uma abordagem formal significa que é necessário o uso de formalidade para encontrar o erro Essas metodo logias pressupõem portanto um certo rigor que não está presente em uma revisão não formal A seguir apresentamos algumas possibilidades de RTF Walkthrough Walkthrough é uma técnica bastante comum de revisão em que é executado passo a passo um procedimento ou programa com vistas a encontrar erros Nesse processo um testador disponibilizará um conjunto de casos e os in tegrantes da equipe de revisão buscarão simular a execução de um artefato O tempo de duração desse procedimento é de aproximadamente duas horas envolvendo equipes pequenas normalmente de três a cinco pessoas Peer review Peer review ou revisão em pares consiste em um método de revisão em que dois programadores são responsáveis por revisar o código um do outro de forma que essa revisão possa apontar inconsistências Esse método é bastante utilizado e relativamente fácil de ser aplicado As regras desse método de revisão podem ser estipuladas pela própria equipe de revisão ou pela dupla responsável pela revisão do artefato De maneira geral um dos integrantes da dupla é responsável por programar enquanto o outro fica responsável pela revisão A cada ciclo previamente definido invertemse os papéis para que ambos possam tanto programar como revisar o código do colega É importante ressaltar que o formalismo da revisão se caracteriza pelas normas que serão previamente definidas dentro do processo de revisão Ou seja uma revisão em pares se for realizada sem nenhum tipo de formalismo pode não caracterizar uma RTF Inspeção A inspeção é um tipo de RTF que envolve a revisão em equipe de um determi nado artefato Geralmente uma inspeção se baseia na distribuição do artefato analisado ou de parte dele para equipes distintas seguida de reuniões de revisão em que são mencionados os erros encontrados para o autor do artefato 5 Revisão das técnicas formais e de software 27 Qualidade de Software UNIDADE 1 Revisões das Técnicas Formais e de Software PARTE 2 Nessa situação o autor geralmente fi ca responsável pela correção dos erros encontrados Em detalhes a inspeção pode apresentar as seguintes etapas 1 Planejamento 2 Apresentação 3 Preparação 4 Reunião de revisão 5 Retrabalho 6 Análise final do moderador Pressman e Maxin 2016 ressaltam que o momento da reunião de revisão precisa ser muito bem planejado e que é importante deixar claro que a revisão é do artefato e não do programador Algumas situações durante o processo de revisão podem afetar os egos dos participantes por esse motivo é sempre importante deixar esse processo o mais neutro possível para que não haja problemas futuros na equipe Esse tipo de revisão pode ser aplicado a todos os artefatos do software desde a fase de requisitos A Figura 2 detalha esse processo de inspeção Figura 2 Inspeções de software Fonte Adaptada de Ackerman Buchwald Lewski 1989 Requisitos Projeto de altonível Projeto detalhado Código Execução dos testes Inspeção Plano de testes Caso de testes Como podemos perceber o processo de inspeção pode ser realizado após cada fase do processo de desenvolvimento de software inclusive após a de finição do modelo de requisitos É importante ressaltar que quanto antes um erro for encontrado e corrigido menor será o custo para o reparo Após ser aplicado qualquer um dos processos de revisão a equipe poderá levantar dados que poderão ser úteis para dar indicativos sobre a qualidade dos artefatos e inclusive para supor a situação de outros artefatos não analisados baseandose no que foi descoberto acerca dos artefatos analisados A exemplo Revisão das técnicas formais e de software 6 QUALIDADE E TESTE DE SOFTWARE 28 disso temos o cálculo da densidade de erros A seguir detalhamos essa forma de complementar a RTF Encontrando a densidade de erros Independentemente da metodologia de revisão encontrar a densidade de erros de um projeto pode ser importante Existe uma série de métricas que segundo Pressman e Maxin 2016 podem ser usadas para nos dar indicativos importantes acerca do software que está em processo de revisão O Quadro 1 especifi ca essas métricas Fonte Adaptado de Pressman e Maxin 2016 Métrica Definição Esforço de preparação Ep Esforço em pessoashora exigido para revisar um artefato antes da reunião de revisão Esforço de avaliação Ea Esforço em pessoashora que é despendido durante a revisão em si Esforço de reformulação Er Esforço em pessoashora dedicado à correção dos erros revelados durante a revisão Tamanho do artefato de software TAS Uma medida do tamanho do artefato de software que foi revisto por exemplo o número de modelos UML do inglês unified modeling language ou linguagem de modelagem unificada o número de páginas de documento ou então o número de linhas de código Erros secundários encontrados Errsec O número de erros encontrados que podem ser classificados como secundários exigindo menos para serem corrigidos do que algum esforço préespecificado Erros graves encontrados Errgraves O número de erros encontrados que podem ser classificados como graves exigindo mais para serem corrigidos do que algum esforço préespecificado Quadro 1 Métricas de revisão 7 Revisão das técnicas formais e de software 29 Qualidade de Software UNIDADE 1 Revisões das Técnicas Formais e de Software PARTE 2 Estimar a densidade de erros em um projeto é importante para que se possa ter uma ideia de quantos erros serão encontrados em outros artefatos de um projeto ou mesmo para poder estimar de forma induzida a possibilidade de erros que poderão ser encontrados em um novo projeto A densidade de erros é calculada da seguinte forma Densidade de Erros Errtot TAS Onde Errtot Errsec Errgraves Suponha o seguinte caso um modelo de requisitos contém 14 erros secundários e dois erros graves distribuídos em 20 diagramas UML e 35 páginas Qual é a densidade de erros por diagrama UML e por página Nesse caso temos Errtot 14 2 16 Densidade de erros por diagrama UML 1620 08 Densidade de erros por página 1635 046 Quando utilizar as revisões técnicas formais Podemos dizer que no âmbito das técnicas formais de revisão algumas apre sentam mais formalidade do que outras Se fossemos estipular uma ordem para os métodos de revisão apresentados na seção anterior podemos defi nir a peer review como a menos formal seguida da revisão walkthrough por fi m a técnica de inspeção seria o mais formal dos métodos Podemos traduzir a formalidade como o rigor que esses métodos trazem Para entender melhor pense que um método de revisão em pares pode ser feito de maneira aleatória sem nenhum tipo de regra Um colega revisa o código de outro e aponta deliberadamente os erros dos sistemas Esse tipo de processo é um processo de revisão mas não formal Se o mesmo colega executar um processo de revisão sistematicamente definido e com procedimentos especí ficos seguindo uma metodologia rígida podemos dizer que ele aplicou uma revisão com certa formalidade Revisão das técnicas formais e de software 8 QUALIDADE E TESTE DE SOFTWARE 30 As técnicas de revisão formal são fundamentais para diminuir a possibili dade de defeitos no software Como já mencionado em especial em software críticos elas são fundamentais para evitar falhas que venham a causar sérios danos às pessoas ou à sociedade Escolher a melhor técnica de revisão dependerá dos recursos disponíveis e da natureza do software que está sendo desenvolvido Um software de gestão empresarial certamente não demandará as mesmas necessidades de revisão se comparado à um software de gerenciamento de linhas ferroviárias A escolha do método normalmente está relacionada ao tempo e ao orça mento disponível para a execução O método de peer review pode ser executado rapidamente por uma dupla de programadores sem que seja necessário deman dar tanto tempo se comparado a um método de inspeção Contudo é sabido que a inspeção por ser um método mais rígido apresenta melhores chances de identificar uma quantidade superior de erros do que os outros métodos O método de revisão walkthrough também exige menos tempo e possui menos formalidade do que as inspeções O que determinará o melhor método para revisão será certamente a disponibilidade temporal e financeira da equipe para buscar uma maior qualidade do ponto de vista do desenvolvimento do software Revisão por amostragem Conforme detalhamos anteriormente o tempo e o custo são fatores críticos no decorrer do projeto e do desenvolvimento de um software Muitas vezes não é possível realizar a RTF para todos os artefatos do software O problema é que no caso dos softwares críticos a revisão é imprescindível e não pode ser simplesmente descartada por falta de tempo ou recursos fi nanceiros Nesse sentido temos uma alternativa que pode ser benéfica em um con texto em que o software precisa de revisão mas a equipe de desenvolvimento não possui o tempo e os recursos necessários Essa alternativa consiste em estimar por amostragem a quantidade de erros em uma parte de um artefato Essa estimativa pode servir como elemento para a indução dos erros no arte fato completo ou ainda uma amostra de vários artefatos poderia indicar a quantidade de erros em todo o projeto Basicamente a indução é uma metodologia de pesquisa em que se ana lisa uma amostra significativa encontrase um padrão e aplicase uma generalização 9 Revisão das técnicas formais e de software 31 Qualidade de Software UNIDADE 1 Revisões das Técnicas Formais e de Software PARTE 2 Para você entender melhor a revisão por amostragem pense em casos em que é utilizado o princípio da indução para se chegar a um possível resultado Na nossa vida podemos ver exemplos de amostragem em várias situações Um exemplo é a maneira como são feitas as pesquisas eleitorais Em linhas gerais um número relativamente significativo de pessoas é entrevistado são geralmente pessoas de várias regiões que dizem em quem elas pretendem votar Após a tabulação desses resultados é feita uma estimativa de quem poderia ganhar as eleições Esse raciocínio se baseia no princípio da indução se a maioria das pessoas vai votar em um candidato X é possível que todas as outras também votem o que caracteriza um raciocínio indutivo O grande problema da indução é que ela pode revelar uma realidade distinta do real se a amostra não for significativa Ou seja quanto maior for a amostra melhores são as chances de a indução estar correta Vamos considerar o seguinte exemplo uma equipe de desenvolvimento pre cisa revisar um artefato em um tempo ligeiramente curto e terá a possibilidade de revisar no máximo ¼ 25 do artefato Para ganhar tempo a equipe optou por revisar apenas 20 encontrando 15 erros secundários e 2 erros graves Qual é a probabilidade de erros que poderão ser encontrados no artefato todo A revisão por amostragem é uma possibilidade mas ela nos dá um indicativo da quantidade total de erros de um artefato ou projeto de software É importante sempre considerar que a indução pode não ser real principalmente se a amostra não for significativa Considerandose que 20 representa 15 do artefato temos 15 5 2 5 85 Dessa forma podemos estimar que o artefato todo terá aproximadamente 85 erros É importante ressaltar que a análise por amostragem nos dá indícios da quantidade de erros mas não garante uma informação totalmente confiável Para se ter um resultado muito confiável é necessário que a amostra seja bastante significativa Aplicar revisões por amostragem é uma possibilidade Revisão das técnicas formais e de software 10 QUALIDADE E TESTE DE SOFTWARE 32 ENCERRA AQUI O TRECHO DO LIVRO DISPONIBILIZADO PELA SAGAH PARA ESTA PARTE DA UNIDADE PREZADO ESTUDANTE em um cenário em que não se possuem todos os recursos necessários para a revisão completa e que envolve um software que não pode simplesmente não ser revisado A revisão por amostragem se encaixa nos métodos de RTF mencionados anteriormente A questão nesse caso é que apenas uma parte do software ou do artefato é revisada com as mesmas técnicas e rigidez dos métodos de RTF ACKERMAN A BUCHWALD L LEWSKI F Software inspections an effective verification process IEEE Software v 6 n 3 p 3137 jun 1989 PRESSMAN R S MAXIN B R Engenharia de software uma abordagem profissional 8 ed Porto Alegre AMGH 2016 SOMMERVILLE I Engenharia de software 8 ed São Paulo Addison Wesley 2007 Leitura recomendada REZENDE D A Engenharia de software e sistemas de informação Rio de Janeiro Bras port 2005 11 Revisão das técnicas formais e de software unidade 1 O conteúdo deste livro é disponibilizado por SAGAH Parte 3 Garantias da Qualidade de Software QUALIDADE E TESTE DE SOFTWARE 34 Garantias da qualidade de software Objetivos de aprendizagem Ao final deste texto você deve apresentar os seguintes aprendizados Definir as garantias da qualidade de software Analisar as garantias da qualidade de software Aplicar os métodos das garantias de software Introdução A garantia da qualidade de software do inglês quality assurance pode ser definida como as atividades que dão suporte aos processos continua mente estabelecidos visando a fornecer confiabilidade a esses processos Para esse fim os processos estão em contínua revisão melhoria e adap tação para produzir produtos que atendam aos requisitos estipulados pelo cliente e que sejam adequados para o uso pretendido A garantia de qualidade de software está associada com todas as atividades que formam o ciclo de desenvolvimento de um software desde o primeiro contato com o cliente até a programação do software em si Dessa forma a área de garantia da qualidade se preocupa com a verificação e a validação do software a verificação quanto aos processos e às definições garantia da qualidade de processos e a validação quanto ao produto garantia da qualidade de produto Para esse fim diversas são as técnicas os modelos e as atividades empregadas conforme Campos 2019 Neste capítulo você vai estudar o conceito de garantia da qualidade e vai analisar algumas das técnicas que podem ser utilizadas para a garantia da qualidade Por fim algumas dessas técnicas serão demonstradas por meio de exemplos de aplicação 35 Qualidade de Software UNIDADE 1 Garantias da Qualidade de Software PARTE 3 Garantias da qualidade de software A garantia da qualidade de software ou os modelos de garantia da qualidade de software como o próprio nome diz tem como objetivo garantir que o software seja entregue ao cliente fi nal com qualidade e que o processo de verifi cação dessa qualidade seja conduzido de forma organizada Para que esse processo de garantia de qualidade de software tenha êxito em seu objetivo e possa ser executado pela equipe sem causar um consumo excessivo de tempo ou uma desmotivação do time é necessário que esteja completamente integrado ao processo de desenvolvimento de software Um bom processo de garantia de qualidade pode ser visto como uma relação de um para um com cada fase do processo de desenvolvimento de software ou seja realizase uma etapa de garantia da qualidade de software para cada etapa de desenvolvimento Todo esse processo deve ser feito visando e reforçando a colaboração entre as áreas e a ciência por parte dos profissionais de um objetivo comum no time segundo Bartié 2002 Garantia de qualidade e controle de qualidade são áreas diferentes da engenharia de software A área de controle de qualidade age diretamente sobre o produto e realiza a execução dos processos enquanto a área de garantia da qualidade estrutura tanto o controle de processos quanto o controle de produtos e garante que estes estejam sendo executados Diversos são os modelos que podem ser utilizados para a garantia da qualidade Esses processos incluem garantia da qualidade de processos e garantia da qualidade de produtos verificação e validação Um dos processos é o modelo de qualidade de software em U que será descrito a seguir Modelo de qualidade de software em U As fases do modelo de qualidade de software podem ser organizadas em um formato de U sendo nesse caso o modelo de qualidade de software chamado de modelo U Nesse modelo as fases são executadas sequencialmente O objetivo é garantir que durante o ciclo de desenvolvimento de software sejam Garantias da qualidade de software 2 QUALIDADE E TESTE DE SOFTWARE 36 produzidos efetivamente todos os produtos previstos na metodologia empregada e que o software entregue esteja de acordo com o requisito esperado Esse modelo considera dois tipos de testes de software testes de verificação e testes de validação Os testes de verificação validam o processo de engenha ria de software e os testes de validação garantem a qualidade do produto de software Analisando a Figura 1 podemos verificar a divisão das etapas do modelo U conforme esses dois tipos de testes As etapas que compreendem o modelo U são as seguintes Testes de verificação Verificação do modelo de negócios aqui os testes verificam se foram levantadas informações suficientes sobre o modelo de negócios do cliente e como essas informações foram levantadas Verificação da especificação de requisitos aqui os testes verificam se a partir do modelo de negócio do cliente foram definidos requisitos compatíveis que vão agregar valor ao cliente por meio do produto de software Verificação da análise e da modelagem nessa etapa é verificado se a modelagem do sistema atende ao especificado nos requisitos e como essa modelagem é feita Verificação da implementação aqui se inicia a etapa de implemen tação é verificada a estrutura para realização da implementação do sistema e o processo que será seguido para a implementação Testes de validação Validação da unidade especificada ou modificada nessa etapa é validada uma pequena unidade ou um componente de software que foi desenvolvido ou modificado Validação da integração da unidade especificada ou modificada nessa etapa é validada a integração dessa pequena unidade ou componente de software que foi desenvolvida ou modificada com o restante do sistema ou com sistemas externos conforme a necessidade Validação do sistema especificado ou modificado aqui é realizada a validação do sistema como um todo de suas funcionalidades imple mentadas e seus requisitos Validação da disponibilização da solução nessa etapa o software já foi entregue ao cliente por meio de sua implementação aqui é acom panhado se a implementação foi feita de forma correta e se o software 3 Garantias da qualidade de software 37 Qualidade de Software UNIDADE 1 Garantias da Qualidade de Software PARTE 3 apresenta no cliente o mesmo comportamento que apresentou no am biente de testes Figura 1 Modelo de processo de qualidade de software em U Fonte Adaptada de Bartie 2002 5 Implementação Verificação da implementação 3 Análise e modelagem Verificação análise e modelagem 5 Unidade especificada ou modificada Validação da unidade 6 Integração especificada ou modificada Validação da integração 7 Sistema especificado ou modificado Validação da integração 8 Disponibilização da solução Validação do aceite 1 Modelo de negócios Verificação de negócios 2 Especificação de requisitos Verificação de requisitos TESTE DE VERIFICAÇÃO TESTES DE VALIDAÇÃO Clientes patrocinadores usuários Testes de verificação O processo de desenvolvimento de software considera duas etapas principais sendo elas planejamento em que são coletadas as informações e é planejada a arquitetura do software e desenvolvimento em que o sistema é de fato desen volvido Os testes de verifi cação são realizados na etapa de planejamento e têm como objetivo avaliar se a documentação e o processo utilizado nessa etapa estão sendo feitos de forma correta Nesse momento não existem componentes tecnológicos mas sim documentos que especifi cam o comportamento do software a ser construído Os testes de verificação são aplicados de acordo com o estágio de desen volvimento São realizados testes na etapa de levantamento das necessidades do cliente e das caracterís ticas específicas para o software Garantias da qualidade de software 4 QUALIDADE E TESTE DE SOFTWARE 38 na etapa de identificação de requisitos funcionais e não funcionais do software na etapa de definição do modelo de arquitetura e da solução tecnológica na etapa de construção do software Testes de validação Os testes de validação são um processo formal de avaliação de software e podem ser aplicados em componentes isolados em módulos ou em funciona lidades já implementadas no sistema ou mesmo no sistema como um todo O objetivo desses testes é avaliar a conformidade do software com os requisitos especifi cados nas etapas iniciais do projeto A principal característica desses testes é a necessidade de o software já estar em execução para ser testado devidamente Diversas são as categorias de testes que podem ser aplicados durante o processo de desenvolvimento de software sendo que as atividades de planejamento modelagem execução e conferência dos testes deverão ocorrer em paralelo às atividades de construção do software As validações serão aplicadas respeitandose os estágios de desenvolvi mento São realizados testes em componentes executáveis testes de interface entre componentes testes em sistemas ou módulos completos aceite de um sistema ou módulo pelo cliente Testes de verificação e testes de validação fazem parte do modelo U de qualidade sendo que cada um desses tipos de teste compreende diversas atividades que precisam ser executadas visando a garantir a qualidade do software Na próxima seção vamos analisar algumas das técnicas de garantia de qualidade de software tanto de verificação quanto de validação Análise das garantias de qualidade de software O processo de garantia da qualidade considera um olhar detalhado para a qua lidade tanto do processo quanto do produto No processo podemos quantifi car a sua qualidade por meio de métricas e nos produtos por meio de técnicas de verifi cação e validação Todo esse processo de garantia da qualidade pode ser 5 Garantias da qualidade de software 39 Qualidade de Software UNIDADE 1 Garantias da Qualidade de Software PARTE 3 avaliado por exemplo pela normativa ISO 9000 por auditorias por inspeções formais ou por testes de software conforme Campos 2019 A área de garantia da qualidade tem alguns papéis fundamentais conforme aponta Bastos et al 2007 ajuda a estabelecer processos determina programas de medida para avaliar processos identifica fraquezas de medida para avaliar processos é uma responsabilidade de gerenciamento está relacionada com todos os produtos que serão gerados por um processo avalia se o controle de qualidade está funcionando Conforme citado uma das principais formas de garantia da qualidade é por meio de auditorias Vamos analisar algumas das principais auditorias que podem ser feitas em processos de desenvolvimento de software considerando os cenários em que cada uma pode ser aplicada A normativa ISO 9000 é utilizada para a garantia da qualidade de processos nos mais diversos aspectos Empresas de todos os segmentos utilizam a ISO 9000 inclusive como estratégia de marketing para seus produtos Essa norma teve origem na norma britânica BS 570 publicada em 1979 pelo SBI British Standards Institute baseada em padrões militares Em 1987 a norma foi revisada mudando seu foco de exclusivamente empresas de manufatura para outras empresas prestadoras de serviços No ano seguinte o documento foi aceito pela ISO como padrão mundial A ISO 9000 é um conjunto de normas genéricas que serve a qualquer organização de qualquer ramo de atividade que queira realizar o controle de qualidade de seus produtos e serviços Essa norma é mais conhecida pela sua versão 9001 A ISO 9001 descreve exigências para o sistema de gerência de qualidade da empresa A qualidade de produtos e serviços não é estabele cida pela norma mas sim pela própria empresa e pelas exigências de seus clientes A norma ISO 9001 define processos que descrevem como a empresa deve realizar determinadas atividades ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS 2015 Os documentos que definem os processos são chamados pela ISO 9000 de procedimentos Garantias da qualidade de software 6 QUALIDADE E TESTE DE SOFTWARE 40 Uma empresa que tem ISO 9001 para os seus processos terá por exemplo um pro cedimento que define como a telefonista deve atender ao telefone isto é qual frase deve ser dita ao receber uma ligação Já o CMM e o CMMI são dois dos principais modelos para melhoria de processos especificamente para software criados pelo Software Engineering Institute SEI CMM é o acrônimo de capability maturity model ou modelo de capacidade de maturidade Por esse modelo ser focado especificamente em software ele não avalia outras áreas da empresa como recursos humanos ou setor financeiro conforme lecionam Koscianski e Soares 2007 O CMM busca que as empresas conheçam e melhorem os seus processos de desenvolvimento de software com a implementação de práticas bem de finidas Ele define uma escala para a maturidade da empresa que se divide em cinco passos Cada nível do CMM define áreaschave que identificam um conjunto de objetivos que a empresa precisa cumprir para atingir esse nível de maturidade Os níveis são 1 Inicial 2 Gerenciado 3 Definido 4 Gerenciado quantitativamente 5 Otimizado No nível 1 nenhum processo está definido e no nível 5 todos os processos estão definidos são seguidos e estão apenas sendo otimizados constantemente conforme lecionam Koscianski e Soares 2007 Com a evolução do CMM foram criados modelo semelhantes para diversas áreas das empresas por exemplo PCMM para gestão de recursos humanos SACMM para aquisição de software SECMM para engenharia de sistemas Para integrar todos esses modelos surgiu o CMMI ou capability maturity model integration O CMMI mantém os mesmos cinco níveis do CMMI contudo amplia as áreas de foco de cada nível exceto o nível 1 que não tem objetivos específicos por ser a ausência de processos As áreas definidas para cada nível do CMMI são mostradas nos Quadro 1 7 Garantias da qualidade de software 41 Qualidade de Software UNIDADE 1 Garantias da Qualidade de Software PARTE 3 Fonte Adaptado de Koscianski e Soares 2007 Nível de maturidade 2 gerenciado Gerência de requisitos Planejamento do projeto Gerência e controle do projeto Gerência e acordos com fornecedores Medição e análise Garantia da qualidade do processo e do produto Gerencia de configuração Nível de maturidade 3 definido Desenvolvimento de requisitos Solução técnica Integração do produto Verificação Validação Foco no processo organizacional Treinamento organizacional Gerência de projeto integrada Gerência de risco Análise de decisão e resolução Desempenho no processo organizacional Definição do processo organizacional Nível de maturidade 4 gerenciado quantitativamente Desempenho do processo organizacional Gerência quantitativa do projeto Nível de maturidade 5 otimizado Inovação e implementação na organização Análise e resolução de causas Quadro 1 Níveis de maturidade e processos do modelo MPSBR Garantias da qualidade de software 8 QUALIDADE E TESTE DE SOFTWARE 42 Por sua vez o modelo MPSBR um acrônimo de melhoria de processo de software brasileiro teve seu desenvolvimento iniciado no ano de 2003 pelas instituições SOFTEX Riosoft COPPEUFRG CESAR CenPRA e CELE PAR Esse modelo tem foco em empresas de micro pequeno e médio porte e objetiva ser um modelo de qualidade com um custo inferior ao modelo CMMI Esse modelo foi criado para adequar os processos de engenharia de software para a realidade brasileira baseandose nas abordagens internacionais para avaliação e melhoria de processos de software conforme abordam Koscianski e Soares 2007 As bases do modelo MPSBR são as normas ISOIEC 12207 ISOIEC 15504 e o CMMI Esse modelo se divide em três componentes sendo eles modelo de referência MRMPS método de avaliação MAMPS e modelo de negócios MNMPS Ele classifica as empresas de acordo com sete níveis de maturidade e assim como o CMMI também estabelece objetivos para cada nível Os níveis estipulados para o MPSBR são os seguintes a Em otimização b Gerenciado quantitativamente c Definido d Largamente definido e Parcialmente definido f Gerenciado g Parcialmente gerenciado Nesse modelo o nível A é o nível mais avançado que considera os processos sendo executados e apenas em etapa de inovação e otimização e o nível G é o início da organização dos processos da empresa conforme Koscianski e Soares 2007 O Quadro 2 demonstra os níveis de maturidade e os processos gerenciados por cada nível do modelo MPSBR 9 Garantias da qualidade de software 43 Qualidade de Software UNIDADE 1 Garantias da Qualidade de Software PARTE 3 Fonte Adaptado de Koscianski e Soares 2007 A Inovação e implantação na organização Análise de causas e resolução B Desempenho do processo organizacional Gerência quantitativa do projeto C Análise de decisão e resolução Gerência de riscos D Desenvolvimento de requisitos Solução técnica Integração de produto Instalação de produto Liberação de produto Verificação Validação E Treinamento Avaliação e melhoria do processo organizacional Definição do processo organizacional Adaptação do processo para gerência do projeto F Medição Gerência de configuração Aquisição Garantia da qualidade G Gerência de requisitos Gerência de projetos Quadro 2 Níveis de maturidade e processos do modelo MPSBR Outra técnica de garantia de qualidade de software que tem sua utilização recomendada é a organização dos processos de testes de software Os testes são Garantias da qualidade de software 10 QUALIDADE E TESTE DE SOFTWARE 44 uma medida de controle de qualidade e a organização e o acompanhamento do processo de testes são garantia da qualidade do software O principal documento que norteia a organização do processo de testes e é utilizado para monitorar se os testes estão sendo realizados de acordo com o planejado é um documento chamado de plano de testes De acordo com a International Software Testing Qualifications Board ISTQB em seu glossário de termos o plano de testes é a documentação descrevendo os objetivos do teste a serem alcançados os meios para realizálo e o cronograma para atingilo organizados para coordenar as atividades de teste ISTQB 2018 p 22 O plano de teste não é um documento estático ele pode ser modificado durante todo o ciclo de vida do produto caso novas necessidades sejam identi ficadas O feedback de cada atividade do ciclo de vida pode ser utilizado como parâmetro para incluir ou remover itens do plano de testes O planejamento dos testes de um projeto pode ser feito em um plano de teste principal e em planos de teste separados para cada nível de teste Por exemplo criase um plano de testes para os testes de sistema que serão feitos logo após a conclusão do desenvolvimento da primeira funcionalidade e outro plano de testes para o teste de aceitação que será feito juntamente com o cliente ou repre sentante dele conforme exemplifica o ISTQB 2018 O plano de testes é personalizável conforme as necessidades de cada em presa mas em geral conforme aponta o ISTQB 2018 ele deve determinar o escopo os objetivos e os riscos do teste definir a abordagem geral do teste integrar e coordenar as atividades de teste nas atividades do ciclo de vida do software tomar decisões sobre o que testar as pessoas e outros recursos necessá rios para realizar as várias atividades de teste e como essas atividades serão realizadas programar as atividades de análise projeto implementação execução e avaliação de testes em datas específicas p ex desenvolvimento sequen cial ou no contexto de cada iteração p ex desenvolvimento iterativo 11 Garantias da qualidade de software 45 Qualidade de Software UNIDADE 1 Garantias da Qualidade de Software PARTE 3 selecionar as métricas para monitoramento e controle de testes orçar as atividades de teste determinar o nível de detalhes e a estrutura da documentação de teste p ex fornecendo modelos ou exemplos de documentos O conteúdo dos planos de teste varia e pode se estender além dos tópicos identificados acima Uma amostragem de planos de teste pode ser encontrada nos documentos do padrão ISO ISOIECIEEE 291193 Métodos de garantia de qualidade de software Diversas são as estratégias que podem ser utilizadas para a garantia da qua lidade de software algumas foram descritas na seção anterior Nesta seção essas estratégias são apresentadas com uma abordagem mais aplicada Como se preparar para uma auditoria Como estruturar um plano de testes Auditoria ISO A auditoria é o momento de verifi car se os processos que foram defi nidos para a empresa estão sendo cumpridos É por meio da auditoria que as em presas recebem o almejado selo ISO 9001 e é também por meio dela que periodicamente as empresas renovam esse selo Contudo para obter êxito nas auditorias é necessário saber como elas funcionam e executar alguns passos importantes os quais serão descritos a seguir com base em Oliveira 2018 O primeiro passo para se preparar para uma auditoria ISO é estudar as normas os padrões definidos pela sua empresa Toda a empresa que almeja uma certificação ISO obrigatoriamente tem seus procedimentos definidos pelo SGQ Sistema Gerenciador de Qualidade O profissional que vai acompanhar a auditoria precisa conhecer esses processos Além do responsável pela qualidade da empresa os demais colaboradores precisam também estar preparados para a auditoria Dessa forma é necessário preparar a equipe apresentar a todos os procedimentos uma vez que o auditor poderá conversar com qualquer pessoa para confirmar se os processos são executados conforme o determinado Além disso a organização é fundamental para o processo de auditoria O responsável pela qualidade da empresa que acompanha a auditoria precisa saber onde estão arquivados todos os documentos que são utilizados diaria mente e que constam nos procedimentos É importante que todas as evidências Garantias da qualidade de software 12 QUALIDADE E TESTE DE SOFTWARE 46 de que os processos definidos são cumpridos sejam apresentadas de forma organizada para o auditor Para garantir que nenhuma surpresa acontecerá quando a auditoria oficial com a certificadora da ISO acontecer é aconselhável a realização de uma auditoria interna Na auditoria interna será possível para a empresa identifi car pontos fracos que podem ser melhorados para a auditoria externa Além disso a auditoria interna aumenta a confiança da equipe o que faz com que na auditoria externa a equipe esteja tranquila e não cause transtornos apenas por nervosismo Segundo Oliveira 2018 uma auditoria ISO é constituída basicamente por Reunião de abertura em que o responsável pela qualidade da empresa e o auditor se reúnem pela primeira vez e é definido o cronograma da auditoria Auditoria dos processos nessa etapa é feita a análise dos procedi mentos dos documentos que comprovam a sua execução e quando necessário ocorre uma conversa com os profissionais da empresa para garantir que o processo está sendo executado corretamente Reunião de conclusão é o momento em que o auditor analisa a auditoria junto com todos os gestores da empresa envolvida e faz re comendações com base no resultado da auditoria Preparando seu plano de testes Agora vamos analisar cada parte do plano de testes e discutir como preencher esse plano e como identifi car as informações que devem constar em cada parte Determinar o escopo os objetivos e os riscos do teste o escopo e os objetivos do teste dizem respeito a quais funcionalidades do sistema serão testadas Os riscos dizem respeito a situações que podem impedir a realização dos testes Por exemplo para testar o sistema de uma ope radora telefônica podem ser necessários dados de números de telefones válidos para entrada de dados no sistema entretanto a operadora pode atrasar a disponibilidade desses dados e o teste pode atrasar ou então a equipe pode ter um limite mínimo de colaboradores e alguém pode pedir demissão durante o projeto e por isso as demandas da equipe acabam atrasando Definir a abordagem geral do teste quais tipos e níveis de testes serão empregados no projeto Os testes serão manuais ou automatizados 13 Garantias da qualidade de software 47 Qualidade de Software UNIDADE 1 Garantias da Qualidade de Software PARTE 3 Essas perguntas precisam ser definidas no plano de testes é necessário especificar se a equipe vai realizar teste unitário teste funcional teste de performance teste de segurança entre outros Essas definições são de extrema importância para a organização do ambiente de desenvol vimento e do cronograma Integrar e coordenar as atividades de teste nas atividades do ciclo de vida do software em que momento do ciclo de desenvolvimento os testes serão iniciados Será possível iniciar a análise de testes junto com a análise do sistema Tomar decisões sobre o que testar as pessoas e outros recursos neces sários para realizar as várias atividades de teste e como essas atividades serão realizadas de acordo com o escopo que foi definido para o pro jeto toda a funcionalidade será testada ou apenas a parte fundamental dela O projeto dispõe de recursos humanos e financeiros para testar a funcionalidade por completo Programar as atividades de análise projeto implementação execução e avaliação de testes em datas específicas p ex em desenvolvimento sequencial ou no contexto de cada iteração p ex no desenvolvimento iterativo nessa etapa definese como o projeto de testes será estrutu rado em que momento será feita a análise de testes e de quanto tempo se dispõe para isso Em que momento será feita a implementação dos testes e quanto tempo se dispõe para isso Selecionar as métricas para monitoramento e controle de testes qual é o parâmetro para que um projeto de testes seja considerado concluído com êxito Orçar as atividades de teste qual será o custo do projeto para cumprir com o cronograma estabelecido e atingir todo o escopo de testes Determinar o nível de detalhes e a estrutura da documentação de teste p ex fornecendo modelos ou exemplos de documentos serão criados casos de testes As falhas serão reportadas em alguma ferramenta Cada uma dessas etapas é fundamental para o projeto e pode ser adaptada dependendo das necessidades da equipe Em síntese um plano de testes precisa conter obrigatoriamente o escopo do projeto os tipos de testes que serão executados o cronograma o orçamento disponível as ferramentas que serão utilizadas e a definição dos documentos entregáveis que serão gerados ao final do projeto Garantias da qualidade de software 14 QUALIDADE E TESTE DE SOFTWARE 48 ENCERRA AQUI O TRECHO DO LIVRO DISPONIBILIZADO PELA SAGAH PARA ESTA PARTE DA UNIDADE PREZADO ESTUDANTE ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS ABNT NBR ISO 9001 sistemas de gestão da qualidade requisitos Rio de Janeiro 2015 BARTIE A Garantia da qualidade de software Rio de Janeiro Elsevier 2002 BASTOS A et al Base de conhecimento em testes de software 2 ed São Paulo Martins Fontes 2007 CAMPOS F M Qualidade qualidade de software e garantia da qualidade de software são mesma coisa 2019 Disponível em httpwwwlinhadecodigocombrartigo1712 qualidadequalidadedesoftwareegarantiadaqualidadedesoftwaresaoasmes mascoisasaspxixzz5bar4W0yD Acesso em 23 jan 2019 INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD ISTQB Glossário de termos de teste CTFL foundation level versão 32br 2018 Disponível em httpswww bstqborgbruploadsglossarioglossarioctfl32brpdf Acesso em 23 jan 2019 KOSCIANSKI A SOARES M S Qualidade de software aprenda as metodologias e técnicas mais modernas para desenvolvimento de software 2 ed São Paulo Novatec 2007 OLIVEIRA G Como se preparar para uma auditoria ISO e o que esperar dela 2018 Dispo nível em httpsblogsoftexpertcomcomoseprepararparaumaauditoriaiso Acesso em 23 jan 2019 Leitura recomendada INTERNATIONAL SOFTWARE TESTING QUALIFICATIONS BOARD ISTQB Certified tester CTFL foundation level syllabus 32 2018 Disponível em httpswwwbstqborgbr uploadssyllabussyllabusctfl2018brpdf Acesso em 23 jan 2019 15 Garantias da qualidade de software unidade 1 O conteúdo deste livro é disponibilizado por SAGAH Parte 4 Confiabilidade de Software QUALIDADE E TESTE DE SOFTWARE 50 Confiabilidade de software Objetivos de aprendizagem Ao final deste texto você deve apresentar os seguintes aprendizados Conceituar confiabilidade de software Descrever a dimensão confiança de software Aplicar os níveis de confiança de software Introdução Podese dizer que o ciclo completo de vida de um sistema compreende duas fases importantes o desenvolvimento do sistema e sua operação A confiabilidade de software se refere ao desenvolvimento de um software confiável ou seja seus conceitos são tratados amplamente na fase de desenvolvimento Neste capítulo você terá a oportunidade de estudar os conceitos que permeiam a confiabilidade de software principalmente no que se refere às dimensões de confiança de software Confiabilidade de software O software deve estar disponível sempre que necessário bem como operar adequadamente com segurança e confi abilidade sem quaisquer efeitos co laterais adversos ou preocupações de segurança É essencial que o software utilizado em sistemas críticos seja confi ável pois a consequência de uma falha por exemplo a falha em uma usina nuclear pode resultar em um dano massivo que poderá signifi car a perda de vidas De acordo com o ANSI 1991 a confiabilidade de software é definida como a probabilidade de um software operar sem falhas por um período de tempo específico em um ambiente específico Embora a confiabilidade de software seja definida como uma função probabilística e venha a sugerir uma noção de tempo devemos observar que diferentemente da confiabilidade de hardware tradicional a confiabilidade de software não é uma função direta do tempo 51 Qualidade de Software UNIDADE 1 Confiabilidade de Software PARTE 4 Peças eletrônicas e mecânicas podem se tornar velhas e desgastadas com o tempo e o uso mas o software não enferruja ou se desgasta durante seu ciclo de vida O software não será alterado com o tempo a menos que seja alterado ou atualizado intencionalmente Costumavase acreditar que o software nunca se danificava Intuitivamente ao contrário de peças mecânicas como parafusos alavancas ou peças ele trônicas como transistores e capacitores o software permanecerá no mesmo estado a menos que haja problemas no hardware que alterem o conteúdo do armazenamento ou o caminho dos dados O software não envelhece enfer ruja desgasta deforma ou racha Além disso o software não tem forma cor material ou massa mas tem um papel crucial no funcionamento dos sistemas A confiabilidade do software é um atributo importante para a qualidade do software juntamente com a funcionalidade a usabilidade o desempenho a capacidade de manutenção a instalabilidade e a capacidade de manutenção e documentação A confiabilidade é difícil de atingir porque a complexidade do software tende a ser alta Embora em qualquer sistema com alto grau de complexidade seja difícil alcançar certo nível de confiabilidade os desen volvedores de sistemas tendem a empurrar a complexidade para a camada de software Como exemplos de tendências nesse sentido temos que as aeronaves de última geração terão mais de um milhão de linhas de códigofonte de software a bordo os sistemas de controle de tráfego aéreo da próxima geração conterão entre um e dois milhões de linhas a próxima estação espacial internacional terá mais de dois milhões de linhas a bordo e mais de dez milhões de linhas de software de suporte terrestre vários sistemas de defesa críticos terão mais de cinco milhões de linhas de software Embora a complexidade do software esteja inversamente relacionada à confiabilidade do software ela está diretamente relacionada a outros fato res importantes na qualidade do software especialmente funcionalidade e capacidade A ênfase nesses recursos tende a adicionar mais complexidade ao software As falhas de software ocorrem devido a erros ambiguidades descuidos ou interpretações errôneas da especificação do software descuido ou incompe tência ao escrever o código testes inadequados uso incorreto ou inesperado do software ou outros problemas não previstos É comum fazer uma analogia Confiabilidade de software 2 QUALIDADE E TESTE DE SOFTWARE 52 entre confiabilidade de software e confiabilidade de hardware mas software e hardware têm características básicas que os tornam diferentes quanto aos mecanismos de falha As falhas de hardware são principalmente falhas físicas enquanto as falhas de software são falhas de projeto que são mais difíceis de se detectar classificar e corrigir As falhas de projeto estão intimamente relacionadas a fatores humanos diversos e às fases do projeto mais complexas conforme Lyu 1995 Com o passar do tempo o hardware exibe as características de falha mostradas na Figura 1 conhecidas como a curva da banheira Nessa curva é possível identificar o período de vida útil do hardware ao longo do tempo Já a confiabilidade do software não possui as mesmas características uma curva de software possível é apresentada na Figura 2 se projetarmos a confiabilidade do software nos mesmos eixos Existem duas grandes diferenças entre as curvas de hardware e software Uma diferença é que na última fase o software não tem uma taxa de falhas crescente como acontece com o hardware Nessa fase o software está se aproximando da obsolescência e não fazem sentido quaisquer atualizações ou alterações no software Portanto a taxa de falha não será alterada A segunda diferença é que na fase da vida útil o software sofrerá um aumento drástico na taxa de falhas cada vez que uma atualização for feita A taxa de falha é desativada gradualmente em parte devido aos defeitos encontrados e corrigidos após as atualizações Figura 1 Taxa de falhas de hardware ao longo do tempo Fonte Adaptada de Ribeiro 2011 documento online Tempo Vida útil Falhas prematuras Fim da vida útil Taxa de falha 3 Confiabilidade de software 53 Qualidade de Software UNIDADE 1 Confiabilidade de Software PARTE 4 Figura 2 Taxa de falhas de software ao longo do tempo Fonte Adaptada de Hartz e Walker 1996 Tempo Taxa de falha λ Testes Vida útil Obsolência Upgrade Upgrade Upgrade Segundo Avizienis Laprie e Randell 2001 são três os fatores que afetam a confiabilidade de sistemas 1 falta 2 erro 3 falha A falta é conhecida como defeito ou bug e é considerada em estado dor mente até a sua ocorrência Um exemplo comum de falta é a declaração de uma variável como tipo incorreto nesse caso a falta só ocorrerá quando essa variável for acessada A falta pode ser a causa de um erro que é um estado interno do sistema que causará uma falha perceptível de alguma forma A falha ocorre quando é entregue um resultado diferente do esperado A Figura 3 apresenta a cadeia fundamental da dependabilidade que é definida pela relação entre falta erro e falha Figura 3 Cadeia fundamental da dependabilidade Fonte Adaptada de Avizienis Laprie e Randell 2001 Falta Ativação Erro Propagação Falha Causação Falta Confiabilidade de software 4 QUALIDADE E TESTE DE SOFTWARE 54 Dimensão confiança A confi ança em um sistema de computador está relacionada com o quanto o usuário acredita no funcionamento de um sistema baseado no que espera em termos de comportamento do mesmo O grau de confi ança pode ser expresso como sendo não confi ável muito confi ável e ultra confi ável conforme aponta Sommerville 2008 No contexto de confiança de software existem quatro principais dimensões relacionadas com a dependabilidade 1 disponibilidade 2 confiabilidade 3 segurança 4 proteção A dimensão disponibilidade se refere à probabilidade de o sistema estar em funcionamento entregando os serviços conforme as solicitações dos usuários Em um sistema que possui sua disponibilidade semanal definida como sendo 0999 significa que durante uma semana o mesmo estará em perfeito fun cionamento durante 999 do tempo A disponibilidade de um sistema deve ser estabelecida conforme o ambiente de utilização e suas finalidades pois quando é mensurada para um determinado cenário é precipitado acreditar que em um cenário com características diferentes a disponibilidade será idêntica A confiabilidade está diretamente relacionada com a disponibilidade porém é importante definir qual é a prioridade para o desenvolvimento de um sistema A confiabilidade se refere à probabilidade de entrega dos resultados de um sistema tal qual sua especificação No que diz respeito à confiabilidade é de extrema importância a exatidão na definição pois no caso de especificações incorretas ou incompletas os desenvolvedores terão dificuldades pelo fato de não serem especialistas no domínio do sistema Essas duas dimensões podem ser expressas em termos quantitativos Em algumas situações é possível colocar a disponibilidade de um sistema junta mente com a confiabilidade pois quando um sistema não está disponível por exemplo ele também não está fornecendo os serviços especificados Porém é possível haver sistemas com baixa confiabilidade mas disponíveis Contanto que as falhas de sistema sejam rapidamente reparadas e não causem danos aos dados a baixa confiabilidade pode não ser um problema em alguns casos A dimensão segurança reflete a habilidade do sistema em operar nor malmente ou não sem o perigo de causar grandes prejuízos gerados por 5 Confiabilidade de software 55 Qualidade de Software UNIDADE 1 Confiabilidade de Software PARTE 4 falhas catastróficas a pessoas ou ambientes É extremamente importante que a segurança de software seja considerada pois cada vez mais os sistemas incorporam controles baseados em software A segurança deve assegurar que não ocorram acidentes e que as consequências catastróficas sejam minimizadas Esses objetivos podem ser alcançados de três maneiras 1 Prevenção de perigos fundamentase na concepção do sistema baseado na minimização de riscos 2 Detecção e remoção de perigos a concepção do sistema tem como premissas a detecção e a remoção dos perigos antes da ocorrência 3 Limitação de danos os sistemas devem incluir recursos de proteção que minimizem os danos quando os mesmos surgirem A dimensão de proteção se refere à realização de análises do sistema no sentido de definir se o mesmo pode resistir às tentativas de intrusões aciden tais ou deliberadas Em alguns casos esta é a dimensão mais importante da confiança de um sistema como sistemas militares de comércio eletrônico e de transações bancárias No que diz respeito a custos os mesmos tendem a aumentar de maneira exponencial conforme o nível de confiança que se deseja alcançar Isso ocorre devido ao uso de técnicas de desenvolvimento mais caras além de o preço de hardware confiável também ser mais elevado Além disso a necessidade de realizar testes de validação para os clientes e órgãos reguladores também gera uma elevação nos custos conforme Gama 2014 A Figura 4 apresenta a relação entre custo e confiança Confiabilidade de software 6 QUALIDADE E TESTE DE SOFTWARE 56 Figura 4 Curva que representa o custo em função do nível de confiança Fonte Sommerville 2008 Custo Confiança Baixa Média Alta Muito alta Super alta Além das quatro principais propriedades da dimensão confiança que já foram apresentadas outras também podem ser definidas conforme mostrado a seguir Reparabilidade essa propriedade se refere à minimização de inter rupções causadas por falhas no sistema Quando se tem acesso ao códigofonte de um sistema é possível melhorar essa propriedade pois será possível realizar as alterações necessárias Manutenibilidade referese à capacidade de realização de alterações no sistema conforme os requisitos demandados pelos usuários Ou seja é a capacidade de realizar atualizações sem a ocorrência de erros e de modo que seja viável do ponto de vista econômico Capacidade de sobrevivência principalmente nos sistemas para internet esta é uma propriedade importante pois se refere à capacidade de um sistema se manter em funcionamento durante um ataque mesmo que seja sem todas as funcionalidades Tolerância a erros essa propriedade se refere à capacidade do sistema em evitar falhas oriundas de entradas erradas realizadas por usuários Esses erros devem ser detectados e corrigidos ou informados 7 Confiabilidade de software 57 Qualidade de Software UNIDADE 1 Confiabilidade de Software PARTE 4 A especificação de confiabilidade de um sistema pode ser definida como um atributo mensurável ou seja pode ser acompanhada periodicamente por meio de medições relacionadas ao comportamento do sistema ao longo do tempo Por exemplo uma especificação de sistema pode ser a quantidade de reinicializações durante uma semana Caso seja definido nesse caso que a quantidade de reinicializações seja duas vezes no máximo em uma semana basta monitorar o sistema para verificar se a especificação está sendo cumprida Caso não seja é necessário avaliar a viabilidade de modificações no sistema a fim de garantir a especificação de confiabilidade Os requisitos de funcionalidade podem ser de dois tipos funcionais e não funcionais Os requisitos não funcionais são quantitativos e definem a quan tidade de falhas aceitável ou o número de paradas permitido Já os requisitos funcionais se referem aos defeitos toleráveis do sistema garantindo que os mesmos não se tornem falhas Existem três métricas de confiabilidade utilizadas 1 POFOD probability of failure on demand essa métrica especifica a confiabilidade a partir da probabilidade de falha sob demanda É mais indicada para casos em que uma falha sob demanda possa causar uma falha geral do sistema 2 ROCOF rate of occurrence of failures é a taxa de ocorrência de falhas em um determinado período Essa métrica é mais indicada para situações em que existem demandas regulares no sistema 3 AVAIL availability essa métrica se refere à probabilidade de o sistema operar com o surgimento de demandas A utilização da redundância e diversidade de hardware de processos de software e de sistemas de software é essencial para o desenvolvimento de sistemas confiáveis As arquiteturas de sistemas confiáveis podem ser de diferentes estilos como sistemas de proteção arquiteturas de automonitora mento programação multiversão e diversidade de software A arquitetura de sistemas de proteção é baseada no monitoramento do ambiente de modo independente Conforme as observações dos sensores o sistema de proteção pode ser ativado para um determinado processo ou equipamento Um bom exemplo é um sistema de controle de tráfego de trens que ao detectar que o trem cruzou por um sinal vermelho ativa o processo de desaceleração do trem As arquiteturas de sistemas de automonitoramento como o próprio nome diz funcionam com o próprio sistema realizando monitoramento baseado em Confiabilidade de software 8 QUALIDADE E TESTE DE SOFTWARE 58 cálculos Caso seja detectada alguma falha o próprio sistema deve realizar alguma ação de solução Esse tipo de arquitetura é indicado para sistemas em que a confiabilidade é mais importante do que a disponibilidade Como exemplo podese citar um sistema de tratamento e diagnóstico médico em que uma resposta incorreta pode levar a um diagnóstico ou tratamento inadequado As arquiteturas de sistema baseadas em programação multiversão N version utilizam como estratégia o desenvolvimento realizado por várias equipes As diferentes versões do sistema geradas são executadas separada mente em computadores diferentes As saídas são comparadas e quando forem inconsistentes são rejeitadas Nesse caso outras versões do sistema deverão estar disponíveis a fim de encontrar duas versões com resultados consistentes Todas as arquiteturas citadas anteriormente são baseadas na diversidade de software ou seja em processos de implementação independentes Estes têm como base o fato de que os erros não serão comuns sendo assim os sistemas não falharão ao mesmo tempo e da mesma forma Aplicação da dimensão confiança Para que seja aplicada a dimensão confi ança no contexto de desenvolvimento de sistemas vamos utilizar como exemplo o sistema de controle da bomba de insulina apresentado por Sommerville 2008 A bomba de insulina é utilizada por diabéticos para medir a glicose do sangue utilizando um microssensor que calcula a dose necessária para a metabolização da glicose A Figura 5 apresenta o modelo de fl uxo de dados para um sistema como este Figura 5 Fluxo de dados do sistema da bomba de insulina Fonte Adaptada de Gama 2014 documento online Sangue Sensor de açúcar no sangue Parâmetros de sangue Nível de açúcar no sangue Análise do açúcar no sangue Controlador de liberação de insulina Cálculo de insulina necessária Insulina necessária Comandos de controle de bomba Insulina Bomba de insulina 9 Confiabilidade de software 59 Qualidade de Software UNIDADE 1 Confiabilidade de Software PARTE 4 Nesse contexto os requisitos de confiança do sistema são a disponibilidade do sistema consiste na liberação de insulina sempre que for requisitada é imprescindível a confiança na quantidade liberada de insulina pelo sistema não poderão ser liberadas doses excessivas de insulina pelo sistema Do ponto de vista das quatro principais propriedades da dimensão con fiança devese ter 1 Disponibilidade o sistema deve funcionar sempre que for solicitado conforme os horários e rotinas dos hospitais que realizam o tratamento por meio do sistema 2 Confiabilidade o sistema deve fornecer sempre as doses corretas de insulina conforme as especificações definidas no projeto do sistema 3 Segurança o sistema não poderá liberar doses inadequadas de insulina pois isso é uma potencial ameaça de vida 4 Proteção o sistema deve garantir que não ocorra uma programação indevida do sistema como esse sistema não opera em rede não é alvo de ataques de hackers Para esse sistema de controle da bomba de insulina as dimensões confia bilidade disponibilidade e segurança são as mais importantes pois sempre que o sistema for requisitado deverá estar em funcionamento A adminis tração das doses de insulina deve ser precisa a fim de evitar problemas que podem até deixar um paciente em estado de coma A proteção também deve ser considerada pois caso o sistema venha a ser sabotado isso se dará via acesso físico ao equipamento por exemplo com o desligamento de algum cabo Nesse caso os sensores do sistema devem parar imediatamente o seu funcionamento a fim de evitar que sejam administradas doses erradas de insulina ou que ocorra alguma outra anomalia Do ponto de vista da reparabilidade e manutenibilidade o sistema da bomba de insulina deverá permitir que sejam realizadas atualizações no sistema com o objetivo de restringir a possibilidade de falhas que possam vir a causar interrupções Essas atualizações podem ser demandadas pelos especialistas ou pelos desenvolvedores caso eles detectem uma possibilidade de melhoria na performance do sistema ou uma correção de falhas Confiabilidade de software 10 QUALIDADE E TESTE DE SOFTWARE 60 No que se refere à capacidade de sobrevivência do sistema de bomba de insulina como o mesmo não funciona conectado à internet ou à rede local esta acaba sendo uma propriedade irrelevante Já a propriedade de tolerância a erros deve garantir que caso ocorram entradas fora de contexto como doses de insulina não convencionais nos tratamentos sejam gerados alarmes que possam corrigir ou informar o operador do sistema Podese considerar esse software para controle da bomba de insulina como um sistema crítico de segurança primária pois a ocorrência de falhas pode causar danos significativos aos usuários Em um sistema crítico é impres cindível que todos os perigos envolvidos com a utilização do sistema sejam conhecidos e sejam contemplados na especificação de confiabilidade Com base nos perigos elencados para o desenvolvimento de sistemas críticos de segurança como o da bomba de insulina são desenvolvidos sistemas capazes de monitorar as condições perigosas que podem causar falhas ANSIIEEE STD729 Standard glossary of software engineering terminology New Jersey ANSIIEEE 1991 AVIZIENIS A LAPRIE J RANDELL B Fundamental concepts of dependability Newcastle upon Tyne University of Newcastle upon Tyne 2001 GAMA K Sistemas críticos Recife Universidade Federal de Pernambuco 2014 Dis ponível em httpwwwcinufpebrkievIF68203SistemasCriticospdf Acesso em 4 fev 2019 HARTZ M WALKER E Introduction to software reliability a state of the art review Sl The Center 1996 LYU M R Handbook of software reliability engineering New York McGrawHill 1995 RIBEIRO R A Planejamento e controle 2011 Disponível em httpspcmusinawordpress comcategoryplanejamentoecontrole Acesso em 4 fev 2019 SOMMERVILLE I Engenharia de software 8 ed São Paulo Pearson Prentice Hall 2008 11 Confiabilidade de software QUALIDADE E TESTE DE SOFTWARE 62 ENCERRA AQUI O TRECHO DO LIVRO DISPONIBILIZADO PELA SAGAH PARA ESTA PARTE DA UNIDADE PREZADO ESTUDANTE Se você encontrar algum problema nesse material entre em contato pelo email eadproducaounilasalleedubr Descreva o que você encontrou e indique a página Lembrese a boa educação se faz com a contribuição de todos CONTRIBUA COM A QUALIDADE DO SEU CURSO Av Victor Barreto 2288 Canoas RS CEP 92010000 0800 541 8500 eadproducaounilasalleedubr