Qualidade de software - Software quality

No contexto da engenharia de software , qualidade de software se refere a duas noções relacionadas, mas distintas:

• A qualidade funcional do software reflete o quão bem ele atende ou está em conformidade com um determinado design, com base em requisitos ou especificações funcionais. Esse atributo também pode ser descrito como a adequação ao propósito de um software ou como ele se compara aos concorrentes no mercado como um produto que vale a pena . É o grau em que o software correto foi produzido.
• A qualidade estrutural do software refere-se a como ele atende aos requisitos não funcionais que suportam a entrega dos requisitos funcionais, como robustez ou facilidade de manutenção. Tem muito mais a ver com o grau em que o software funciona conforme necessário .

Muitos aspectos da qualidade estrutural podem ser avaliados apenas estaticamente por meio da análise da estrutura interna do software, seu código-fonte (consulte Métricas de software ), no nível da unidade, nível do sistema (às vezes referido como teste de ponta a ponta), que é na verdade, como sua arquitetura adere aos princípios sólidos da arquitetura de software delineados em um artigo sobre o tópico do Object Management Group (OMG).

No entanto, algumas qualidades estruturais, como usabilidade , podem ser avaliadas apenas dinamicamente (usuários ou outros agindo em seu nome interagem com o software ou, pelo menos, algum protótipo ou implementação parcial; até mesmo a interação com uma versão simulada feita em papelão representa uma dinâmica teste porque tal versão pode ser considerada um protótipo). Outros aspectos, como confiabilidade, podem envolver não apenas o software, mas também o hardware subjacente, portanto, pode ser avaliado tanto estática quanto dinamicamente ( teste de estresse ).

A qualidade funcional é normalmente avaliada dinamicamente, mas também é possível usar testes estáticos (como análises de software ).

Historicamente, a estrutura, classificação e terminologia de atributos e métricas aplicáveis ​​ao gerenciamento de qualidade de software foram derivadas ou extraídas da ISO 9126 e do padrão ISO / IEC 25000 subsequente . Com base nesses modelos (consulte Modelos), o Consórcio para Qualidade de Software de TI (CISQ) definiu cinco principais características estruturais desejáveis ​​necessárias para que uma peça de software forneça valor de negócios : Confiabilidade, Eficiência, Segurança, Capacidade de Manutenção e Tamanho (adequado).

A medição da qualidade do software quantifica até que ponto um programa de software ou sistema avalia em cada uma dessas cinco dimensões. Uma medida agregada da qualidade do software pode ser calculada por meio de um esquema de pontuação qualitativa ou quantitativa ou uma combinação de ambos e, em seguida, um sistema de ponderação refletindo as prioridades. Esta visão da qualidade do software sendo posicionada em um contínuo linear é complementada pela análise de "erros críticos de programação" que, em circunstâncias específicas, podem levar a interrupções catastróficas ou degradação de desempenho que tornam um determinado sistema inadequado para uso, independentemente da classificação baseada em medições agregadas. Esses erros de programação encontrados no nível do sistema representam até 90 por cento dos problemas de produção, enquanto no nível da unidade, mesmo que muito mais numerosos, os erros de programação respondem por menos de 10 por cento dos problemas de produção (consulte também a regra noventa e noventa ). Como consequência, a qualidade do código sem o contexto de todo o sistema, como W. Edwards Deming o descreveu, tem valor limitado.

Para visualizar, explorar, analisar e comunicar medições de qualidade de software, conceitos e técnicas de visualização de informações fornecem meios visuais e interativos úteis, em particular, se várias medidas de qualidade de software tiverem que estar relacionadas umas às outras ou a componentes de um software ou sistema. Por exemplo, mapas de software representam uma abordagem especializada que "pode ​​expressar e combinar informações sobre desenvolvimento de software, qualidade de software e dinâmica de sistema".

A qualidade do software também desempenha um papel na fase de lançamento de um projeto de software. Especificamente, a qualidade e o estabelecimento dos processos de lançamento (também processos de patch ) e o gerenciamento de configuração são partes importantes de um processo geral de engenharia de software.

Motivação

A qualidade do software é motivada por pelo menos duas perspectivas principais:

• Gerenciamento de riscos : a falha de software causou mais do que inconveniência. Erros de software podem causar fatalidades humanas (ver por exemplo: Lista de bugs de software ). As causas variam de interfaces de usuário mal projetadas a erros de programação direta , consulte, por exemplo, o caso do Boeing 737 ou casos de aceleração não intencional ou casos do Therac-25 . Isso resultou em requisitos para o desenvolvimento de alguns tipos de software, particularmente e historicamente para software embutido em dispositivos médicos e outros que regulam infraestruturas críticas: "[Engenheiros que escrevem software embutido] veem programas Java parando por um terço de segundo para executar o lixo coletar e atualizar a interface do usuário, e eles visualizam aviões caindo do céu. ". Nos Estados Unidos, dentro da Federal Aviation Administration (FAA), o FAA Aircraft Certification Service fornece programas de software, política, orientação e treinamento, com foco em software e Hardware Eletrônico Complexo que tem efeito sobre o produto aerotransportado (um "produto" é uma aeronave, um motor ou uma hélice). Padrões de certificação como DO-178C , ISO 26262 , IEC 62304 , etc. fornecem orientação.
• Gerenciamento de custos : como em qualquer outro campo da engenharia, um produto ou serviço de software regido por uma boa qualidade de software custa menos para manter, é mais fácil de entender e pode mudar com maior custo-benefício em resposta às necessidades urgentes do negócio. Os dados da indústria demonstram que a baixa qualidade estrutural do aplicativo nos principais aplicativos de negócios (como planejamento de recursos empresariais (ERP), gerenciamento de relacionamento com o cliente (CRM) ou grandes sistemas de processamento de transações em serviços financeiros) resulta em custos, estouros de cronograma e cria desperdício na forma de retrabalho (ver Muda (termo japonês) ). Além disso, a baixa qualidade estrutural está fortemente relacionada a interrupções de negócios de alto impacto devido a dados corrompidos, interrupções de aplicativos, violações de segurança e problemas de desempenho.
  • Relatórios CISQ sobre o custo de estimativas de baixa qualidade um impacto de:
    • $ 2,08 trilhões em 2020
    • $ 2,84 trilhões em 2018
  • O Relatório de Custo de uma Violação de Dados 2020 da IBM estima que os custos globais médios de uma violação de dados:
    • $ 3,86 milhões

Definições

ISO

Qualidade de software é a "capacidade de um produto de software em conformidade com os requisitos". enquanto para outros, pode ser sinônimo de criação de valor ou cliente, ou até mesmo nível de defeito.

ASQ

ASQ usa a seguinte definição: Qualidade de software descreve os atributos desejáveis ​​de produtos de software. Existem duas abordagens principais: gerenciamento de defeitos e atributos de qualidade.

NIST

O Software Assurance (SA) cobre a propriedade e o processo para alcançá-lo:

• [Justificável] confiança de que o software está livre de vulnerabilidades, seja intencionalmente projetado no software ou inserido acidentalmente a qualquer momento durante seu ciclo de vida e que o software funciona da maneira pretendida
• O conjunto planejado e sistemático de atividades que garantem que os processos e produtos do ciclo de vida do software estejam em conformidade com os requisitos, padrões e procedimentos

PMI

O Project Management Institute 's PMBOK 'Software de Extensão' define Guia não 'qualidade Software' em si, mas Software Quality Assurance (SQA) como "um processo contínuo que as auditorias outros processos de software para garantir que esses processos estão sendo seguidos (inclui, por exemplo, um plano de gerenciamento de qualidade de software). " Considerando que Controle de Qualidade de Software (SCQ) significa "cuidar da aplicação de métodos, ferramentas, técnicas para garantir a satisfação dos produtos de trabalho em relação aos requisitos de qualidade para um software em desenvolvimento ou modificação."

Outros gerais e históricos

A primeira definição de qualidade que a história lembra é de Shewhart no início do século 20: "Existem dois aspectos comuns de qualidade: um deles tem a ver com a consideração da qualidade de uma coisa como uma realidade objetiva independente da existência de homem. O outro tem a ver com o que pensamos, sentimos ou sentimos como resultado da realidade objetiva. Em outras palavras, há um lado subjetivo da qualidade. "

Kitchenham e Pfleeger, relatando posteriormente os ensinamentos de David Garvin, identificam cinco perspectivas diferentes sobre a qualidade:

• A perspectiva transcendental lida com o aspecto metafísico da qualidade. Nessa visão de qualidade, é "algo que buscamos como um ideal, mas nunca podemos implementar completamente". Dificilmente pode ser definido, mas é semelhante ao que um juiz federal uma vez comentou sobre a obscenidade: "Eu sei quando vejo".
• A perspectiva do usuário está preocupada com a adequação do produto para um determinado contexto de uso. Enquanto a visão transcendental é etérea, a visão do usuário é mais concreta, alicerçada nas características do produto que atendem às necessidades do usuário.
• A perspectiva de fabricação representa a qualidade como conformidade com os requisitos. Esse aspecto da qualidade é enfatizado por padrões como a ISO 9001, que define qualidade como "o grau em que um conjunto de características inerentes atende aos requisitos" (ISO / IEC 9001).
• A perspectiva do produto implica que a qualidade pode ser apreciada medindo as características inerentes do produto.
• A perspectiva final da qualidade é baseada no valor. Essa perspectiva reconhece que as diferentes perspectivas da qualidade podem ter diferentes importâncias, ou valores, para várias partes interessadas.

O problema inerente às tentativas de definir a qualidade de um produto, quase qualquer produto, foi afirmado pelo mestre Walter A. Shewhart. A dificuldade em definir qualidade é traduzir as necessidades futuras do usuário em características mensuráveis, para que um produto possa ser projetado e fabricado de forma a dar satisfação a um preço que o usuário pagará. Isso não é fácil, e assim que alguém se sente bem-sucedido no empreendimento, ele descobre que as necessidades do consumidor mudaram, os concorrentes mudaram, etc.

-  W. Edwards Deming

A qualidade é uma determinação do cliente, não uma determinação do engenheiro, não uma determinação do marketing, nem uma determinação da administração geral. Baseia-se na experiência real do cliente com o produto ou serviço, medida em relação aos seus requisitos - declarados ou não declarados, conscientes ou meramente percebidos, tecnicamente operacionais ou inteiramente subjetivos - e sempre representando um alvo móvel em um mercado competitivo.

A palavra qualidade possui vários significados. Dois desses significados dominam o uso da palavra: 1. Qualidade consiste nas características do produto que atendem às necessidades dos clientes e, portanto, proporcionam satisfação com o produto. 2. A qualidade consiste na ausência de deficiências. No entanto, em um manual como este, é conveniente padronizar uma definição curta da palavra qualidade como "adequação ao uso".

Tom DeMarco propôs que "a qualidade de um produto é uma função de quanto ele muda o mundo para melhor." Isso pode ser interpretado como significando que a qualidade funcional e a satisfação do usuário são mais importantes do que a qualidade estrutural para determinar a qualidade do software.

Outra definição, cunhada por Gerald Weinberg em Quality Software Management: Systems Thinking, é "Qualidade é valor para alguma pessoa." Essa definição enfatiza que a qualidade é inerentemente subjetiva - pessoas diferentes terão experiências diferentes com a qualidade do mesmo software. Um ponto forte dessa definição são as questões que ela convida as equipes de software a considerarem, como "Quem são as pessoas que queremos que valorizem nosso software?" e "O que será valioso para eles?".

Outros significados e controvérsias

Um dos desafios na definição de qualidade é que "todos sentem que a entendem" e outras definições de qualidade de software podem ser baseadas na extensão das várias descrições do conceito de qualidade usado nos negócios.

A qualidade do software também costuma se confundir com a garantia de qualidade ou gerenciamento de resolução de problemas ou controle de qualidade ou DevOps . Ele se sobrepõe às áreas mencionadas anteriormente (consulte também as definições do PMI), mas é distinto, pois não se concentra apenas em testes, mas também em processos, gerenciamento, melhorias, avaliações, etc.

Medição

Embora os conceitos apresentados nesta seção sejam aplicáveis ​​à qualidade de software estrutural e funcional, a medição da última é essencialmente realizada por meio de testes [ver artigo principal: Teste de software ]. No entanto, o teste não é suficiente: de acordo com um estudo, os programadores individuais são menos de 50% eficientes em encontrar bugs em seu próprio software. E a maioria das formas de teste são apenas 35% eficientes. Isso torna difícil determinar a qualidade do [software].

Introdução

A medição da qualidade de software consiste em quantificar até que ponto um sistema ou software possui as características desejáveis. Isso pode ser realizado por meios qualitativos ou quantitativos ou uma combinação de ambos. Em ambos os casos, para cada característica desejável, existe um conjunto de atributos mensuráveis ​​cuja existência em um software ou sistema tende a ser correlacionada e associada a essa característica. Por exemplo, um atributo associado à portabilidade é o número de instruções dependentes do destino em um programa. Mais precisamente, usando a abordagem de Implementação da Função de Qualidade , esses atributos mensuráveis ​​são os "comos" que precisam ser aplicados para habilitar o "o quê" na definição de Qualidade de Software acima.

A estrutura, classificação e terminologia de atributos e métricas aplicáveis ​​ao gerenciamento de qualidade de software foram derivadas ou extraídas da ISO 9126-3 e do subsequente modelo de qualidade ISO / IEC 25000: 2005. O foco principal está na qualidade estrutural interna. Subcategorias foram criadas para lidar com áreas específicas, como arquitetura de aplicativos de negócios e características técnicas, como acesso e manipulação de dados ou a noção de transações.

A árvore de dependência entre as características de qualidade de software e seus atributos mensuráveis ​​é representada no diagrama à direita, onde cada uma das 5 características que importam para o usuário (direita) ou proprietário do sistema de negócios depende de atributos mensuráveis ​​(esquerda):

• Práticas de Arquitetura de Aplicativos
• Práticas de Codificação
• Complexidade do aplicativo
• Documentação
• Portabilidade
• Volume Técnico e Funcional

Correlações entre erros de programação e defeitos de produção revelam que os erros básicos do código respondem por 92 por cento do total de erros no código-fonte. Esses numerosos problemas de nível de código acabam sendo contabilizados por apenas 10% dos defeitos na produção. As más práticas de engenharia de software nos níveis de arquitetura são responsáveis ​​por apenas 8% do total de defeitos, mas consomem mais da metade do esforço gasto na correção de problemas e levam a 90% dos problemas sérios de confiabilidade, segurança e eficiência na produção.

Análise baseada em código

Muitas das medidas de software existentes contam elementos estruturais do aplicativo que resultam da análise do código-fonte para tais estruturas de controle de tokens de instruções individuais ( Complexidade ) e objetos.

A medição da qualidade de software consiste em quantificar até que ponto um sistema ou software se classifica ao longo dessas dimensões. A análise pode ser realizada usando uma abordagem qualitativa ou quantitativa ou uma combinação de ambas para fornecer uma visão agregada [usando, por exemplo, média (s) ponderada (s) que refletem a importância relativa entre os fatores sendo medidos].

Esta visão da qualidade do software em um continuum linear deve ser complementada pela identificação de discretos Erros Críticos de Programação . Essas vulnerabilidades podem não falhar em um caso de teste, mas são o resultado de práticas inadequadas que, em circunstâncias específicas, podem levar a interrupções catastróficas, degradações de desempenho, violações de segurança, dados corrompidos e uma miríade de outros problemas que tornam um determinado sistema de fato inadequado para uso independentemente de sua classificação com base em medições agregadas. Um exemplo bem conhecido de vulnerabilidade é o Common Weakness Enumeration , um repositório de vulnerabilidades no código-fonte que torna os aplicativos expostos a violações de segurança.

A medição das características críticas do aplicativo envolve a medição de atributos estruturais da arquitetura do aplicativo, codificação e documentação em linha, conforme mostrado na imagem acima. Assim, cada característica é afetada por atributos em vários níveis de abstração no aplicativo e todos os quais devem ser incluídos no cálculo da medida da característica se ela for um preditor valioso de resultados de qualidade que afetam o negócio. A abordagem em camadas para calcular as medidas características exibidas na figura acima foi proposta pela primeira vez por Boehm e seus colegas na TRW (Boehm, 1978) e é a abordagem adotada nos padrões das séries ISO 9126 e 25000. Esses atributos podem ser medidos a partir dos resultados analisados ​​de uma análise estática do código-fonte do aplicativo. Mesmo as características dinâmicas dos aplicativos, como confiabilidade e eficiência de desempenho, têm suas raízes causais na estrutura estática do aplicativo.

A análise e medição da qualidade estrutural são realizadas por meio da análise do código-fonte , da arquitetura , da estrutura do software , do esquema do banco de dados em relação aos princípios e padrões que, juntos, definem a arquitetura conceitual e lógica de um sistema. Isso é diferente da análise de código básica, local e em nível de componente, normalmente realizada por ferramentas de desenvolvimento, que se preocupam principalmente com as considerações de implementação e são cruciais durante as atividades de depuração e teste .

Confiabilidade

As principais causas da baixa confiabilidade são encontradas em uma combinação de não conformidade com boas práticas de arquitetura e codificação. Essa não conformidade pode ser detectada medindo os atributos de qualidade estáticos de um aplicativo. A avaliação dos atributos estáticos subjacentes à confiabilidade de um aplicativo fornece uma estimativa do nível de risco do negócio e da probabilidade de falhas e defeitos potenciais do aplicativo que o aplicativo enfrentará quando colocado em operação.

A avaliação da confiabilidade requer verificações de pelo menos as seguintes práticas recomendadas de engenharia de software e atributos técnicos:

Dependendo da arquitetura do aplicativo e dos componentes de terceiros usados ​​(como bibliotecas ou estruturas externas), as verificações personalizadas devem ser definidas ao longo das linhas traçadas pela lista de melhores práticas acima para garantir uma melhor avaliação da confiabilidade do software entregue.

Eficiência

Tal como acontece com a confiabilidade, as causas da ineficiência de desempenho são frequentemente encontradas em violações de boas práticas de arquitetura e codificação, que podem ser detectadas medindo os atributos de qualidade estáticos de um aplicativo. Esses atributos estáticos preveem gargalos de desempenho operacional em potencial e problemas de escalabilidade futuros, especialmente para aplicativos que requerem alta velocidade de execução para lidar com algoritmos complexos ou grandes volumes de dados.

Avaliar a eficiência do desempenho requer a verificação de pelo menos as seguintes práticas recomendadas de engenharia de software e atributos técnicos:

• Práticas de Arquitetura de Aplicativos
• Interações adequadas com recursos caros e / ou remotos
• Desempenho de acesso a dados e gerenciamento de dados
• Gerenciamento de memória, rede e espaço em disco
• Conformidade com as práticas de codificação ( melhores práticas de codificação )

Segurança

A qualidade do software inclui a segurança do software. Muitas vulnerabilidades de segurança resultam de práticas de codificação e arquitetura inadequadas, como injeção de SQL ou script entre sites. Eles estão bem documentados em listas mantidas pelo CWE e pelo SEI / Computer Emergency Center (CERT) da Carnegie Mellon University.

Avaliar a segurança requer pelo menos a verificação das seguintes práticas recomendadas de engenharia de software e atributos técnicos:

• Implementação, gerenciamento de um processo de desenvolvimento de proteção e reconhecimento de segurança, por exemplo, Security Development Lifecycle (Microsoft) ou Secure Engineering Framework da IBM.
• Práticas de Arquitetura de Aplicativos Seguros
• Conformidade de design multicamadas
• Práticas recomendadas de segurança (validação de entrada, injeção de SQL, script entre sites, controle de acesso, etc.)
• Práticas de programação boas e seguras
• Tratamento de erros e exceções

Capacidade de Manutenção

A capacidade de manutenção inclui conceitos de modularidade, compreensibilidade, mutabilidade, testabilidade, capacidade de reutilização e transferência de uma equipe de desenvolvimento para outra. Eles não assumem a forma de problemas críticos no nível do código. Em vez disso, a manutenção deficiente é normalmente o resultado de milhares de violações menores com as melhores práticas em documentação, estratégia de prevenção de complexidade e práticas básicas de programação que fazem a diferença entre código limpo e fácil de ler e código desorganizado e difícil de ler .

A avaliação da capacidade de manutenção requer a verificação das seguintes práticas recomendadas de engenharia de software e atributos técnicos:

A capacidade de manutenção está intimamente relacionada ao conceito de dívida técnica de Ward Cunningham , que é uma expressão dos custos resultantes da falta de capacidade de manutenção. As razões pelas quais a facilidade de manutenção é baixa podem ser classificadas como imprudente vs. prudente e deliberado vs. inadvertido, e muitas vezes têm sua origem na incapacidade dos desenvolvedores, falta de tempo e objetivos, seu descuido e discrepâncias no custo de criação e benefícios da documentação e , em particular, código-fonte sustentável .

Tamanho

Medir o tamanho do software requer que todo o código-fonte seja reunido corretamente, incluindo scripts de estrutura de banco de dados, código-fonte de manipulação de dados, cabeçalhos de componentes, arquivos de configuração, etc. Existem essencialmente dois tipos de tamanhos de software a serem medidos, o tamanho técnico (pegada) e o tamanho funcional:

• Existem vários métodos de dimensionamento técnico de software que foram amplamente descritos. O método de dimensionamento técnico mais comum é o número de linhas de código (#LOC) por tecnologia, número de arquivos, funções, classes, tabelas, etc., a partir dos quais os pontos de função de backfiring podem ser calculados;
• O mais comum para medir o tamanho funcional é a análise de pontos de função . A análise de pontos de função mede o tamanho da entrega do software da perspectiva do usuário. O dimensionamento do ponto de função é feito com base nos requisitos do usuário e fornece uma representação precisa do tamanho para o desenvolvedor / avaliador e do valor (funcionalidade a ser entregue) e reflete a funcionalidade do negócio que está sendo entregue ao cliente. O método inclui a identificação e ponderação de entradas, saídas e armazenamentos de dados reconhecíveis pelo usuário. O valor do tamanho fica então disponível para uso em conjunto com várias medidas para quantificar e avaliar a entrega e o desempenho do software (custo de desenvolvimento por ponto de função; defeitos entregues por ponto de função; pontos de função por mês de equipe).

O padrão de dimensionamento de análise de ponto de função é suportado pelo International Function Point Users Group ( IFPUG ). Ele pode ser aplicado no início do ciclo de vida de desenvolvimento de software e não depende de linhas de código como o método de backfiring um tanto impreciso. O método é agnóstico em termos de tecnologia e pode ser usado para análises comparativas entre organizações e setores.

Desde o início da Análise de Ponto de Função, diversas variações evoluíram e a família de técnicas de dimensionamento funcional foi ampliada para incluir medidas de dimensionamento como COSMIC, NESMA, Use Case Points, FP Lite, Early e Quick FPs e, mais recentemente, Story Points. No entanto, os Pontos de Função têm um histórico de precisão estatística e têm sido usados ​​como uma unidade comum de medição de trabalho em vários contratos de gerenciamento de desenvolvimento de aplicativos (ADM) ou terceirização, servindo como a "moeda" pela qual os serviços são entregues e o desempenho é medido.

Uma limitação comum da metodologia de Ponto de Função é que ela é um processo manual e, portanto, pode ser trabalhoso e caro em iniciativas de grande escala, como desenvolvimento de aplicativos ou contratos de terceirização. Este aspecto negativo da aplicação da metodologia pode ser o que motivou os líderes de TI da indústria a formarem o Consórcio para Qualidade de Software de TI, focado na introdução de um padrão de métricas computáveis ​​para automatizar a medição do tamanho do software, enquanto o IFPUG continua promovendo uma abordagem manual, visto que a maior parte de sua atividade depende em certificações de contadores FP.

CISQ define dimensionamento como estimar o tamanho do software para apoiar a estimativa de custos, rastreamento de progresso ou outras atividades de gerenciamento de projeto de software relacionadas. Dois padrões são usados: Pontos de Função Automatizados para medir o tamanho funcional do software e Pontos de Melhoria Automatizados para medir o tamanho do código funcional e não funcional em uma medida.

Identificação de erros críticos de programação

Os Erros Críticos de Programação são práticas específicas de arquitetura e / ou codificação que resultam no maior risco de interrupção dos negócios, imediato ou de longo prazo.

Freqüentemente, eles estão relacionados à tecnologia e dependem muito do contexto, dos objetivos de negócios e dos riscos. Alguns podem considerar o respeito pelas convenções de nomenclatura, enquanto outros - aqueles que estão preparando o terreno para uma transferência de conhecimento, por exemplo - irão considerá-lo absolutamente crítico.

Erros críticos de programação também podem ser classificados de acordo com as características CISQ. Exemplo básico abaixo:

• Confiabilidade
  • Evite padrões de software que levarão a um comportamento inesperado ( variável não inicializada , ponteiros nulos, etc.)
  • Métodos, procedimentos e funções que fazem Inserir, Atualizar, Excluir, Criar Tabela ou Selecionar devem incluir gerenciamento de erros
  • As funções multi-thread devem ser seguras para thread, por exemplo servlets ou classes de ação struts não devem ter campos estáticos de instância / não finais
• Eficiência
  • Garantir a centralização das solicitações do cliente (entrada e dados) para reduzir o tráfego de rede
  • Evite consultas SQL que não usam um índice em grandes tabelas em um loop
• Segurança
  • Evite campos em classes de servlet que não são estáticos finais
  • Evite o acesso a dados sem incluir gerenciamento de erros
  • Verifique os códigos de retorno de controle e implemente mecanismos de tratamento de erros
  • Garanta a validação de entrada para evitar falhas de script entre sites ou falhas de injeção de SQL
• Capacidade de Manutenção
  • Árvores de herança profunda e aninhamento devem ser evitados para melhorar a compreensão
  • Os módulos devem ser fracamente acoplados (fanout, intermediários) para evitar a propagação de modificações
  • Aplicar convenções de nomenclatura homogêneas

Modelos de qualidade operacionalizados

As propostas mais recentes para modelos de qualidade, como Squale e Quamoco, propagam uma integração direta da definição de atributos de qualidade e medição. Ao quebrar os atributos de qualidade ou mesmo definir camadas adicionais, os atributos de qualidade abstratos e complexos (como confiabilidade ou capacidade de manutenção) se tornam mais gerenciáveis ​​e mensuráveis. Esses modelos de qualidade foram aplicados em contextos industriais, mas não receberam uma adoção generalizada.

Curiosidades

• "Uma ciência é tão madura quanto suas ferramentas de medição."
• " Eu sei quando vejo ."
• "Você não pode controlar o que você não pode medir." ( Tom DeMarco )
• "Você não pode inspecionar a qualidade de um produto." ( W. Edwards Deming )
• "A amargura da má qualidade permanece muito depois que a doçura de cumprir o cronograma foi esquecida." (Anônimo)
• "Se você não começar com uma especificação, cada pedaço de código que você escreve é ​​um patch." ( Leslie Lamport )

Veja também

Leitura adicional

• Diretrizes de qualidade do sistema operacional Android, incluindo listas de verificação para interface do usuário, segurança, etc. Julho de 2021
• Associação dos Gestores Marítimos em Tecnologia da Informação e Comunicações (AMMITEC). Diretrizes de qualidade de software marítimo . Setembro de 2017
• Capers Jones e Olivier Bonsignour, "The Economics of Software Quality", Addison-Wesley Professional, 1ª edição, 31 de dezembro de 2011, ISBN  978-0-13-258220-9
• Laboratório CAT - Laboratório de Ferramentas de Análise de Código CNES (no GitHub)
• Girish Suryanarayana, Processo de Software versus Qualidade de Design: Cabo de Guerra?
• Ho-Won Jung, Seung-Gweon Kim e Chang-Sin Chung. Medindo a qualidade do produto de software: Uma pesquisa da ISO / IEC 9126 . IEEE Software , 21 (5): 10–13, setembro / outubro de 2004.
• Organização Internacional para Padronização. Engenharia de software - Qualidade do produto - Parte 1: Modelo de qualidade . ISO, Genebra, Suíça, 2001. ISO / IEC 9126-1: 2001 (E).
• Medindo a qualidade do produto de software: a série ISO 25000 e CMMI (site SEI)
• MSQF - Uma estrutura de qualidade de software baseada em medição Cornell University Library
• Omar Alshathry, Helge Janicke, "Optimizing Software Quality Assurance," compsacw, pp. 87–92, 2010 IEEE 34th Annual Computer Software and Applications Conference Workshops, 2010.
• Robert L. Glass. Software de qualidade de construção . Prentice Hall, Upper Saddle River, NJ, 1992.
• Roland Petrasch, " The Definition of 'Software Quality': A Practical Approach ", ISSRE, 1999
• Profissional de Qualidade de Software, American Society for Quality (ASQ)
• Software Quality Journal da Springer Nature
• Spinellis, Diomidis (2006-04-04). Qualidade do código: a perspectiva do código aberto . Upper Saddle River, Nova Jersey, EUA: Addison-Wesley Professional. ISBN 978-0-321-16607-4.
• Stephen H. Kan. Métricas e Modelos em Engenharia de Qualidade de Software . Addison-Wesley, Boston, MA, segunda edição, 2002.
• Stefan Wagner. Controle de qualidade do produto de software . Springer, 2013.

Referências

Notas

Bibliografia

links externos

• Quando o código é rei: Dominando a excelência do software automotivo (McKinsey, 2021)
• Qualidade de software de sistema integrado: Por que é tão frequentemente terrível? O que podemos fazer sobre isso? (por Philip Koopman )
• Padrões de qualidade de código por CISQ ™
• Blog do CISQ: https://blog.it-cisq.org
• Guia para garantia de qualidade de software (ESA)
• Guia para a aplicação dos padrões de engenharia de software ESA a pequenos projetos de software (ESA)
• Uma Visão Geral dos Serviços de Garantia de Produto de Software ESA (NASA / ESA)
• A nossa abordagem à qualidade no Volkswagen Software Dev Center Lisboa
• Guias de estilo do Google
• Garantindo a qualidade do produto no Google (2011)
• NASA Software Assurance
• Grupo de Qualidade de Software NIST
• Pontos de função automatizados OMG / CISQ ( ISO / IEC 19515 )
• Padrão de dívida técnica automatizada OMG
• Garantia de qualidade automatizada (articulado em IREB por Harry Sneed)
• Teste Estruturado: Uma Metodologia de Teste Usando a Métrica da Complexidade Ciclomática (1996)
• Analisando a qualidade do aplicativo usando ferramentas de análise de código (Microsoft, Documentation, Visual Studio, 2016)