Qualidade de software

Transcrição

1 Faculdade de Ciências Sociais e Aplicadas de Petrolina - FACAPE Curso: Ciência da Computação Disciplina:Projeto de Sistemas Qualidade de software cynaracarvalho@yahoo.com.br

2 Qualidade de software Qualidade é um assunto amplo, complexo e ainda muito discutido; Para considerar um resultado satisfatório são vários os fatores considerados. O principal é a SATISFAÇÃO DO CLIENTE. O valor e a utilidade do sistema é verificado em relação a grau de utilidade das reais necessidades do usuário. Qualidade em desenvolvimento de software significa: Alinhamento total entre necessidades/ expectativas do usuário e especificações geradas. Alinhamento total entre especificações aprovadas e produto construído. Produto final com a menor quantidade de erros; Aplicar o conceito de qualidade aos produtos e desenvolvimento de software, não é fácil.

3 Qualidade de software O problema esta na forma como se desenvolve o software. Deve-se aplicar a qualidade o quanto antes. Padrões Qualidade de software é um conjunto de propriedades a serem satisfeitas de modo que o software atenda as necessidades do usuário. Inserir qualidade desde a 1ª fase do ciclo de vida de desenvolvimento de software

4 Especificar qualidade Como especificar e o que é qualidade de software pouco se sabe. Projetar e concluir sistemas com níveis satisfatórios de qualidade, e avaliar e controlar os resultados da construção e uso quanto a sua qualidade, ainda é uma tarefa muito complicada, que demanda tempo e esforço. Em qualquer ramo industrial, a qualidade do produto é o objetivo do projeto, sendo raras as situações em que a qualidade poderá ser incorporada ao produto após este ter sido concluído. Portanto, no desenvolvimento deve se conhecer o objetivo e trabalhar para alcançá-lo no inicio do projeto. Sem isso, torna-se impossível assegurar a qualidade de software no final da sua construção. A qualidade é um conceito multidimensional.

5 Qualidade das especificações A qualidade do desenvolvimento de software depende de suas especificações Erros e inadequações alto custo e atraso nos prazos Alto nível de especificações A qualidade das especificações é determinada por variados atributos. A qualidade de uma especificação pode ser determinada basicamente, através de duas características: utilizabilidade e confiabilidade.

6 Qualidade das especificações Utilizabilidade: uma especificação existe para ser utilizada, mas elas devem atingir outros dois objetivos: confiabilidade conceitual e confiabilidade de representação. O conceito do usuário sobre o que espera do produto que deseja. O que o produto pronto representa para o usuário. A utilização de uma especificação pode ser evidenciada durante as fazes do ciclo de vida do desenvolvimento. Especificação facilidade de alteração, reutilização, avaliação e implementação. Portanto, um sistema especificado e focado, antes do inicio do desenvolvimento. Desenvolvedor e cliente com as mesmas idéias sobre o produto

7 Revisão da especificação Documentos completos e consistentes, durante todo o ciclo de desenvolvimento, maior chance para um produto como qualidade. Revisão feita por pessoa qualificada garantir a qualidade Encontrar possíveis falhas Ter uma serie de perguntas a serem respondidas Perguntar se: Requerimento possui as informações necessárias? Entradas são suficientes? Se esta sendo mencionado na sessão apropriada da especificação.

8 Tipos de defeitos encontrados na revisão da especificação 1) Informação ausente; Característica de funcionalidade, performance, atributos; Seções inteiras de um requerimento de um documento; Rótulos, referências de figuras, tabelas ou diagramas. 2) Informação ambígua; Múltiplas interpretações, termos, seus significados. 3) Informações irrelevantes Informações desnecessárias, não utilizadas; 4) Informações inconsistentes Dois ou mais requerimentos que conflitem com um terceiro. 5) Informações diversas Outros erros, ex: inclusão de um requerimento em uma seção incorreta; - Falhas descobertas no inicio resultados satisfatórios e vantagens verificadas - Falhas descobertas após a disponibilização do produto o esforço para corrigir é enorme, pode inviabilizar o projeto.

9 Utilização da especificação CARACTERÍSTICAS Manutenibilidade facilmente modificada e detalhada. Atingida pelas subcaracteristicas: Modificabilidade fácil alterar Evolutibilidade fácil trabalhar à medida que for detalhando Reutilizabilidade servir de apoio em outro projeto semelhante, a especificação deve ser reutilizada totalmente ou em parte. Avaliabilidade avaliação da forma (como é apresentada) e conteúdo (o que é apresentado). Atingida pelas subcaracteristicas: Verificabilidade avaliada conforme forma apresentada Validabilidade - avaliada conforme conteúdo.

10 Utilização da especificação CARACTERÍSTICAS Implementabilidade Viabilidade econômica Viabilidade técnica Viabilidade financeira Viabilidade de mão-de-obra Viabilidade de recursos de suporte Viabilidade de cronograma (tempo) Viabilidade social

11 Compreensão da especificação Comunicabilidade Uso apropriado da linguagem Concisão Uniformidade de terminologia Uniformidade do nível de abstração Modularidade Manipulabilidade - Abrange controle de revisão da especificação Fidelidade grau entre especificação e percepção do especificador Consistência Não existir contradições Não ambigüidades Suficiência Completeza todos os aspectos especificados Necessidade - todos os aspectos imprescindíveis Ser explicita não haver hipóteses, restrições ou considerações implícitas.

12 Validação e Verificação de software Uma estratégia de teste de software: Resultam Técnicas de projeto de casos de teste Construção bem sucedida de software

13 Validação e Verificação de software A atividade de teste inicia-se no nível de módulos e prossegue "para fora", na direção da integração de todo o sistema baseado em computador. Diferentes técnicas de teste são apropriadas a diferentes pontos de tempo. É realizada pela equipe de desenvolvimento do software e para grandes projetos por um grupo de testes independente.

14 Validação e Verificação de software A diferença entre Verificação e validação: A verificação refere-se ao conjunto de atividades que garante que o software realiza corretamente uma função específica. A validação refere-se a um conjunto diferente de atividades que garante que o software que foi construído e é rastreável às exigências do cliente Sob outro ponto de vista, proposto por Boehm: Verificação: "Estamos construindo certo o produto?" Validação: "Estamos construindo o produto certo?"

15 Fatores de Qualidade em Software O que é um bom software? Que fatores influenciam ou determinam a qualidade de um programa? Um programa que funciona é um bom programa?

16 Visões da qualidade Usuário - Facilidade de Uso, Desempenho, Confiabilidade dos Resultados, Preço do Software, etc. Desenvolvedor taxa de defeitos, facilidade de manutenção e conformidade em relação aos requisitos de usuários, etc. Organização cumprimento de prazo, boa previsão de custo, boa produtividade. Qualidade é compromisso de todos!

17 Fatores externos e internos em qualidade de software Fatores Externos (usuário) Facilidade de usar: Interface simples e clara Comandos não ambíguos Rapidez de execução Eficiência no uso de recursos (memória) Corretude: Habilidade do software de executar corretamente as tarefas definidas através de especificações e requerimentos. Portabilidade: Facilidade de transportar o software para outras plataformas Robustez: Capacidade do software de executar em condições anormais ou inesperadas Integridade: Capacidade de autoproteção;

18 Fatores externos e internos em qualidade de software Fatores Internos (Desenvolvedor) Legibilidade: Facilidade de se entender o código Reusabilidade: Facilidade de se reutilizar o software desenvolvido em novas aplicações Modularidade: Sistema dividido em unidades conceituais que encapsulam informações relacionadas Extensibilidade: Facilidade de introduzir novas funções e adaptar o software a mudanças nas especificações Testabilidade: Facilidade com que o software pode ser depurado

19 Visão Profissional de Qualidade PROCESSO DE SOFTWARE usuário Requisitos de software Processo De Desenvolvimento desenvolvedor organização Requisitos atendidos SOFTWARE PRODUTO SOFTWARE COM QUALIDADE

20 Qualidade de produtos de software

21 Qualidade de produtos de software O Método de Avaliação oficial que serve de apoio à prestação de serviços quanto à avaliação para qualidade de produto de software, tem como referência às normas NBR (Norma traduzida pela ISO/IEC 9126 de 1991), A estrutura da ISO/IEC 9126 possui, também, um conjunto de documentos técnicos, que definem características de qualidade de software e seus indicadores, orientando o planejamento e a execução da avaliação (SCALET, 1995): ISO/IEC : fornece características e subcaracterísticas de qualidade, sendo uma norma essencialmente de definições (WEBER, 1997, TSUKUMO et al., 1995, HAUSEN et al., 1993), como representado abaixo;

22 Qualidade de produtos de software ISO/IEC : define métrica externa para a medição das características e subcaracterísticas de qualidade da ISO/IEC Essas métricas referem-se a medições indiretas de um produto de software, a partir da medição do comportamento do sistema computacional, do qual o produto faz parte. ISO/IEC : estabelece métricas internas para a avaliação de um produto de software. Essas métricas referem-se a medições diretas de um produto, a partir de suas características internas, sem que seja necessária a execução do programa. ISO/IEC : estabelece métricas para qualidade em uso para as características definidas na ISO/IEC , traz um conjunto de indicadores para cada característica, exemplos de como aplicar métricas durante o ciclo de vida do software.

23 Qualidade de produtos de software - características A Norma ISO/IEC 9126 define seis características, que descrevem, com um mínimo de sobreposição, a qualidade de produto de software. Características Descrição Funcionalidade Evidencia que o conjunto de funções atende às necessidades explícitas e implícitas para a finalidade a que se destina o produto. Confiabilidade Evidencia que o desempenho se mantém ao longo do tempo e em condições estabelecidas. Usabilidade Evidencia a facilidade para a utilização do software. Eficiência Evidencia que os recursos e os tempos envolvidos são compatíveis com o nível de desempenho requerido para o produto. Manutenibilidade Evidencia que há facilidade para correções, atualizações e alterações. Portabilidade Evidencia que é possível utilizar o produto em diversas plataformas com pequeno esforço de adaptação.

24 Qualidade de produtos de software - subcaracterísticas Para cada uma destas características são definidas subcaracterísticas: Características Funcionali dade (satisfaz as necessidades?) Subcaracterísticas Adequação Acurácia (Precisão) Interoperabilidade Conformidade Descrição / pergunta chave Presença de conjunto de funções e sua apropriação para as tarefas. Faz o que é apropriado? Geração de resultados ou efeitos corretos. Faz o que foi proposto da melhor forma? Capacidade de interagir com outros sistemas. Interage com outros sistemas? Estar de acordo com normas, convenções, regulamentações. Está de acordo com as normas, leis, etc? Segurança de Acesso Estabilidade Capacidade de evitar acesso não autorizado a programas e dados Permite apenas acesso autorizado aos dados? Ausência de riscos de efeitos inesperados. Há grandes riscos quando se faz alterações?

25 Qualidade de produtos de software - subcaracterísticas Confiabilidade (imune à falhas?) Maturidade Freqüência de falhas. Apresenta freqüentemente falhas? Tolerância a Falhas Manter nível de desempenho em caso de falha; Ocorrendo falhas reage de modo apropriado? Recuperabilidade Capacidade de se restabelecer e restaurar dados após falha; recupera dados em caso de falhas? Usabilidade (é fácil usar?) Inteligibilidade Facilidade de entendimento dos conceitos utilizados. É fácil entender o conceito e a aplicação? Apreensibilidade Facilidade de aprendizado. É fácil aprender a usar? Operacionalidade Facilidade de operar e controlar a operação. É fácil operar e controlar?

26 Qualidade de produtos de software - subcaracterísticas Eficiência (é rápido?) Comportamento em relação ao tempo Tempo de resposta, de processamento. Tempo de resposta rápida? Comportamento em relação a recursos Quantidade de recursos utilizados. Utiliza poucos recursos? Manutenibilidade (é fácil modificar?) Analisabilidade Facilidade de diagnosticar deficiências e causas de falhas. É fácil encontrar uma falha quando ocorre? Modificabilidade Facilidade de modificação e remoção de defeitos. É fácil modificar e adaptar? Estabilidade Ausência de riscos de efeitos inesperados. Há grandes riscos quando se faz alterações? Testabilidade Facilidade de ser testado. É fácil testar quando se faz alterações?

27 Qualidade de produtos de software - subcaracterísticas Portabilidade (é fácil usar em outro ambiente?) Adaptabilidade Capacidade de ser adaptado a ambientes diferentes. É fácil adaptar a outro ambiente? Capacidade para ser Instalado Facilidade de instalação. É fácil instalar em outro ambiente? Conformidade Acordo com padrões ou convenções de portabilidade. Esta de acordo com os padrões de portabilidade? Capacidade para substituir Substituir outro software. É fácil usar para substituir outro?

28 Qualidade de produtos de software A norma se aplica na definição dos requisitos da qualidade do software e na avaliação (medida, pontuação e julgamento) dos produtos de software. Através dela tornase possível: Definir requisitos da qualidade de um produto de software; Avaliar a especificação do software, para verificar se vai satisfazer os requisitos da qualidade; Descrever as peculiaridades e atributos do software implementado. Ex: manual do usuário. Avaliar o software desenvolvido, antes da entrega e aceitação do usuário final. Não é possível sua medição direta, devido à maneira com que estas características de qualidade foram definidas. Por isso há a necessidade de definição de métricas para correlacionar a estas.

29 Qualidade de produtos de software - PADRÕES Padrão ISO Sistemas de qualidade - Modelo para garantia de qualidade em Projeto, Desenvolvimento, Instalação e Assistência Técnica (processo). Os padrões ISO enunciam procedimentos para a garantia da qualidade de software em relação a seu processo de desenvolvimento, presumindo que o produto de software é o resultado de um acordo contratual entre um cliente e um fornecedor, sendo este último uma organização com um sistema de qualidade suportado pela ISO A ISO está constituída de três partes (ISO, 1990): Estrutura: envolve aspectos organizacionais da produção de software. Atividades do ciclo de vida: define as ações necessárias para as fases ao longo do processo de desenvolvimento. Atividades de apoio: estabelece atividades de suporte à produção, operação e manutenção de software.

30 Qualidade de produtos de software A aceitação do padrão internacional de qualidade ISO 9000 tem despertado um grande interesse das organizações, pois, através dele, podem conquistar sua certificação de qualidade. Essa certificação significa alcançar um padrão internacional em seus processos. Da mesma forma, os clientes, que adquirem produtos e serviços, vêem, nessa certificação, um indicador que assegura a qualidade de seus fornecedores (WEBER et al., 1997, DAVIS etal., 1993, SANDERS et al., 1994). Muitas organizações buscam novos paradigmas, que conduzam a uma melhoria contínua e progressiva da qualidade de seus processos, atenuando os problemas com o desenvolvimento de seus produtos de software. Assim, surgiram alguns modelos, como o Modelo de Maturidade e Capacidade do Software (Capability Maturity Model - CMM) (SEI, 1995).

31 CMM - Capability Maturity Model O CMM é estruturado em cinco níveis em ordem crescente de maturidade. Quando a organização se encontra em um certo nível, deve seguir atividades determinadas pelo modelo, para atingir o nível seguinte (HUMPHREY, 1991): Nível 1 ou inicial: as organizações não possuem um ambiente estável para o desenvolvimento e a manutenção de software, ficando na dependência exclusiva da habilidade e eficácia de seu pessoal técnico. Nível 2 ou repetitivo: a instituição já possui projetos, cujos processos são gerenciados, medidos, documentados, tendo sua equipe devidamente treinada. Nível 3 ou definido: há uma retroalimentação contínua do aprendizado dos processos utilizados na empresa, havendo, para isto, uma biblioteca de processos padrões, que podem ser escolhidos durante a fase de planejamento. Nível 4 ou gerenciado: são estabelecidas métricas mais estritas, para a identificação de pontos críticos e oportunidades de melhoria. Nível 5 ou otimizado: a organização se encontra em uma contínua melhoria de seus processos.

32 SW-CMM (Capability Maturity Model) Guia para melhoria contínua do processo de software Estrutura básica para métodos confiáveis de avaliação Melhoria contínua Estabelecimento de uma política Documentação de um padrão 3. DEFINIDO Estabelecimento de metas 2. REPETITÍVEL 1. INICIAL Compromisso em fazer 4. GERENCIADO 5. OTIMIZADO

33 CMM - Capability Maturity Model A partir do nível 2 do CMM, são incluídos grupos de atividades chaves, KPAs (key process areas), que têm por objetivo segmentar e facilitar o trabalho de melhoria dos processos de software, em cada nível considerado. As KPAs são conjuntos de atividades a serem seguidas, visando a obtenção de um novo nível de maturidade, e estão subdividas em (SAIEDIAN et al., 1995) : Alvos, Desempenho de execução, Habilidades para execução, Atividades de execução, Medidas e análise, e... Verificação da implementação.

34 CMM - Capability Maturity Model Conforme estudos do SEI/CMU, uma empresa de software, que alcance certificação ISO 9001, atende a todos os requisitos para ser classificada no nível 2 do CMM, mesmo que tenha alcançado alguns dos requisitos de níveis superiores (WEBER, 1997). O CMM possui quatro critérios para determinar se há compromissos e habilidade para a garantia da qualidade (JONES, 1995): Existe pessoal designado para uma unidade organizacional, responsável pela garantia da qualidade? Há recursos financeiros (e outros) suficientes e disponíveis para a realização do trabalho desse pessoal? O pessoal responsável pela qualidade tem sido treinado, de tal forma que estejam conscientes do que é esperado deles e de como farão os seus trabalhos? O grupo de garantia da qualidade é tido como pessoal de alto nível, que está satisfeito com o que faz?