Gerenciamento de qualidade de software - Guia rápido

Software de qualidade refere-se a um software que é razoavelmente livre de bugs ou defeitos, é entregue no prazo e dentro do orçamento especificado, atende aos requisitos e / ou expectativas e pode ser mantido. No contexto da engenharia de software, a qualidade do software reflete tantofunctional quality assim como structural quality.

  • Software Functional Quality - Reflete o quão bem ele atende a um determinado projeto, com base nos requisitos ou especificações funcionais.

  • Software Structural Quality - Trata do tratamento de requisitos não funcionais que suportam a entrega dos requisitos funcionais, tais como robustez ou manutenibilidade, e o grau em que o software foi produzido corretamente.

  • Software Quality Assurance- Software Quality Assurance (SQA) é um conjunto de atividades para garantir a qualidade nos processos de engenharia de software que resultam em produtos de software de qualidade. As atividades estabelecem e avaliam os processos que produzem os produtos. Envolve ação focada no processo.

  • Software Quality Control- O Controle de Qualidade de Software (SQC) é um conjunto de atividades para garantir a qualidade em produtos de software. Essas atividades se concentram em determinar os defeitos nos produtos reais produzidos. Envolve ação focada no produto.

O desafio da qualidade do software

Na indústria de software, os desenvolvedores nunca declararão que o software está livre de defeitos, ao contrário do que outros fabricantes de produtos industriais costumam fazer. Essa diferença se deve aos seguintes motivos.

Complexidade do Produto

É o número de modos operacionais que o produto permite. Normalmente, um produto industrial permite apenas menos de alguns milhares de modos de operação com diferentes combinações de configurações de sua máquina. No entanto, os pacotes de software permitem milhões de possibilidades operacionais. Portanto, garantir todas essas possibilidades operacionais corretamente é um grande desafio para a indústria de software.

Visibilidade do Produto

Como os produtos industriais são visíveis, grande parte de seus defeitos podem ser detectados durante o processo de fabricação. Além disso, a ausência de uma peça em um produto industrial pode ser facilmente detectada no produto. No entanto, os defeitos nos produtos de software armazenados em disquetes ou CDs são invisíveis.

Desenvolvimento de Produto e Processo de Produção

Em um produto industrial, os defeitos podem ser detectados durante as seguintes fases -

  • Product development - Nesta fase, os designers e a equipe de Garantia de Qualidade (QA) verificam e testam o protótipo do produto para detectar seus defeitos.

  • Product production planning- Durante esta fase, o processo de produção e ferramentas são projetados e preparados. Esta fase também oferece oportunidades de inspecionar o produto para detectar os defeitos que passaram despercebidos durante a fase de desenvolvimento.

  • Manufacturing- Nesta fase, os procedimentos de QA são aplicados para detectar falhas dos próprios produtos. Defeitos no produto detectados no primeiro período de fabricação geralmente podem ser corrigidos por uma mudança no design do produto ou nos materiais ou nas ferramentas de produção, de forma a eliminar tais defeitos em produtos fabricados no futuro.

Porém, no caso do software, a única fase em que os defeitos podem ser detectados é a fase de desenvolvimento. No caso do software, o planejamento da produção do produto e as fases de fabricação não são necessários, pois a fabricação das cópias do software e a impressão dos manuais do software são realizadas automaticamente.

Os fatores que afetam a detecção de defeitos em produtos de software em comparação com outros produtos industriais são mostrados na tabela a seguir.

Característica Produtos de Software Outros Produtos Industriais
Complexidade Milhões de opções operacionais mil opções operacionais
visibilidade do produto Produto invisível, difícil de detectar defeitos à vista Produto Visível Detecção eficaz de defeitos à vista
Natureza do processo de desenvolvimento e produção pode corrigir defeitos em apenas uma fase pode detectar defeitos em todas as fases seguintes
  • Desenvolvimento de produto
  • Planejamento de produção do produto
  • Manufacturing

Essas características do software, como complexidade e invisibilidade, tornam o desenvolvimento da metodologia de garantia da qualidade do software e sua implementação bem-sucedida um desafio altamente profissional.

Os vários fatores que influenciam o software são denominados fatores de software. Eles podem ser amplamente divididos em duas categorias. A primeira categoria dos fatores é daqueles que podem ser medidos diretamente, como o número de erros lógicos, e a segunda categoria agrupa aqueles fatores que podem ser medidos apenas indiretamente. Por exemplo, manutenibilidade, mas cada um dos fatores deve ser medido para verificar o conteúdo e o controle de qualidade.

Vários modelos de fatores de qualidade de software e sua categorização foram sugeridos ao longo dos anos. O modelo clássico de fatores de qualidade de software, sugerido por McCall, consiste em 11 fatores (McCall et al., 1977). Da mesma forma, modelos compostos de 12 a 15 fatores foram sugeridos por Deutsch e Willis (1988) e por Evans e Marciniak (1987).

Todos esses modelos não diferem substancialmente do modelo de McCall. O modelo de fator de McCall fornece um método prático e atualizado para classificar os requisitos de software (Pressman, 2000).

Modelo de fator de McCall

Este modelo classifica todos os requisitos de software em 11 fatores de qualidade de software. Os 11 fatores são agrupados em três categorias - operação do produto, revisão do produto e fatores de transição do produto.

  • Product operation factors - Correção, Confiabilidade, Eficiência, Integridade, Usabilidade.

  • Product revision factors - Capacidade de manutenção, flexibilidade, testabilidade.

  • Product transition factors - Portabilidade, Reutilização, Interoperabilidade.

Fatores de qualidade do software de operação do produto

De acordo com o modelo de McCall, a categoria de operação do produto inclui cinco fatores de qualidade de software, que tratam dos requisitos que afetam diretamente a operação diária do software. Eles são os seguintes -

Exatidão

Esses requisitos tratam da exatidão da saída do sistema de software. Eles incluem -

  • Missão de saída

  • A precisão necessária de saída que pode ser afetada negativamente por dados ou cálculos imprecisos.

  • A integridade das informações de saída, que pode ser afetada por dados incompletos.

  • A atualização da informação definida como o tempo entre o evento e a resposta do sistema de software.

  • A disponibilidade da informação.

  • Os padrões para codificação e documentação do sistema de software.

Confiabilidade

Os requisitos de confiabilidade lidam com a falha do serviço. Eles determinam a taxa de falha máxima permitida do sistema de software e podem se referir a todo o sistema ou a uma ou mais de suas funções separadas.

Eficiência

Trata dos recursos de hardware necessários para executar as diferentes funções do sistema de software. Inclui capacidades de processamento (fornecidas em MHz), sua capacidade de armazenamento (fornecida em MB ou GB) e a capacidade de comunicação de dados (fornecida em MBPS ou GBPS).

Também trata do tempo entre a recarga das unidades portáteis do sistema, como unidades do sistema de informação localizadas em computadores portáteis ou unidades meteorológicas colocadas ao ar livre.

Integridade

Este fator trata da segurança do sistema de software, ou seja, impedir o acesso de pessoas não autorizadas, também distinguir entre o grupo de pessoas a quem será concedida permissão de leitura e escrita.

Usabilidade

Os requisitos de usabilidade lidam com os recursos humanos necessários para treinar um novo funcionário e operar o sistema de software.

Fatores de qualidade de revisão de produto

De acordo com o modelo de McCall, três fatores de qualidade de software estão incluídos na categoria de revisão do produto. Esses fatores são os seguintes -

Capacidade de Manutenção

Este fator considera os esforços que serão necessários aos usuários e pessoal de manutenção para identificar os motivos das falhas de software, para corrigir as falhas e verificar o sucesso das correções.

Flexibilidade

Este fator lida com as capacidades e esforços necessários para apoiar as atividades de manutenção adaptativa do software. Isso inclui adaptar o software atual a circunstâncias e clientes adicionais sem alterar o software. Os requisitos deste fator também suportam atividades de manutenção perfeita, como modificações e inclusões no software, a fim de melhorar seu serviço e adaptá-lo às mudanças do ambiente técnico ou comercial da empresa.

Testabilidade

Os requisitos de testabilidade lidam com o teste do sistema de software, bem como com sua operação. Inclui resultados intermediários predefinidos, arquivos de log e também os diagnósticos automáticos realizados pelo sistema de software antes de iniciar o sistema, para descobrir se todos os componentes do sistema estão em funcionamento e para obter um relatório sobre as falhas detectadas. Outro tipo desses requisitos trata das verificações de diagnóstico automáticas aplicadas pelos técnicos de manutenção para detectar as causas das falhas de software.

Fator de qualidade de software de transição de produto

De acordo com o modelo de McCall, três fatores de qualidade de software estão incluídos na categoria de transição de produto que trata da adaptação do software a outros ambientes e sua interação com outros sistemas de software. Esses fatores são os seguintes -

Portabilidade

Os requisitos de portabilidade tendem à adaptação de um sistema de software a outros ambientes que consistem em hardware diferente, sistemas operacionais diferentes e assim por diante. O software deve ser possível continuar usando o mesmo software básico em diversas situações.

Reutilização

Este fator trata do uso de módulos de software originalmente projetados para um projeto em um novo projeto de software em desenvolvimento. Também podem permitir que projetos futuros façam uso de um determinado módulo ou grupo de módulos do software desenvolvido atualmente. Espera-se que a reutilização de software economize recursos de desenvolvimento, encurte o período de desenvolvimento e forneça módulos de maior qualidade.

Interoperabilidade

Os requisitos de interoperabilidade se concentram na criação de interfaces com outros sistemas de software ou firmware de outro equipamento. Por exemplo, o firmware do maquinário de produção e o equipamento de teste fazem interface com o software de controle de produção.

Software Quality Assurance(SQA) é um conjunto de atividades para garantir a qualidade nos processos de engenharia de software. Ele garante que o software desenvolvido atenda e esteja em conformidade com as especificações de qualidade definidas ou padronizadas. SQA é um processo contínuo dentro do Ciclo de Vida de Desenvolvimento de Software (SDLC) que verifica rotineiramente o software desenvolvido para garantir que ele atenda às medidas de qualidade desejadas.

As práticas de SQA são implementadas na maioria dos tipos de desenvolvimento de software, independentemente do modelo de desenvolvimento de software subjacente usado. SQA incorpora e implementa metodologias de teste de software para testar o software. Em vez de verificar a qualidade após a conclusão, os processos SQA testam a qualidade em cada fase de desenvolvimento, até que o software seja concluído. Com o SQA, o processo de desenvolvimento de software passa para a próxima fase apenas quando a fase atual / anterior está em conformidade com os padrões de qualidade exigidos. O SQA geralmente funciona em um ou mais padrões de mercado que ajudam na construção de diretrizes de qualidade de software e estratégias de implementação.

Inclui as seguintes atividades -

  • Definição e implementação de processos
  • Auditing
  • Training

Os processos podem ser -

  • Metodologia de Desenvolvimento de Software
  • Gerenciamento de Projetos
  • Gerenciamento de configurações
  • Desenvolvimento / Gerenciamento de Requisitos
  • Estimation
  • Design de software
  • Teste, etc.

Uma vez que os processos tenham sido definidos e implementados, a Garantia da Qualidade tem as seguintes responsabilidades -

  • Identifique as fraquezas nos processos
  • Corrija esses pontos fracos para melhorar continuamente o processo

Componentes do Sistema SQA

Um sistema SQA sempre combina uma ampla variedade de componentes SQA. Esses componentes podem ser classificados nas seguintes seis classes -

Componentes de pré-projeto

Isso garante que os compromissos do projeto tenham sido claramente definidos considerando os recursos necessários, o cronograma e o orçamento; e os planos de desenvolvimento e qualidade foram corretamente determinados.

Avaliação dos componentes do ciclo de vida do projeto

O ciclo de vida do projeto é composto por duas fases: a fase do ciclo de vida de desenvolvimento e a fase de operação-manutenção.

Os componentes do estágio do ciclo de vida de desenvolvimento detectam erros de design e programação. Seus componentes são divididos nas seguintes subclasses: Avaliações, Opiniões de especialistas e Teste de software.

Os componentes SQA usados ​​durante a fase de operação-manutenção incluem componentes de manutenção especializados, bem como componentes do ciclo de vida de desenvolvimento, que são aplicados principalmente para funcionalidade para melhorar as tarefas de manutenção.

Componentes de prevenção e melhoria de erros de infraestrutura

O objetivo principal desses componentes, que são aplicados em toda a organização, é eliminar ou pelo menos reduzir a taxa de erros, com base na experiência acumulada de SQA da organização.

Componentes de gerenciamento de qualidade de software

Essa classe de componentes lida com diversos objetivos, como o controle das atividades de desenvolvimento e manutenção, e a introdução de ações de apoio gerencial antecipado que principalmente previnem ou minimizam falhas de cronograma e orçamento e seus resultados.

Componentes de padronização, certificação e avaliação do sistema SQA

Esses componentes implementam padrões profissionais e gerenciais internacionais dentro da organização. Os principais objetivos desta classe são a utilização de conhecimentos profissionais internacionais, a melhoria da coordenação dos sistemas de qualidade organizacional com outras organizações e a avaliação das realizações dos sistemas de qualidade de acordo com uma escala comum. Os vários padrões podem ser classificados em dois grupos principais: padrões de gerenciamento de qualidade e padrões de processo de projeto.

Organização para SQA - os componentes humanos

A base organizacional SQA inclui gerentes, pessoal de teste, a unidade SQA e as pessoas interessadas na qualidade de software, como curadores SQA, membros do comitê SQA e membros do fórum SQA. Seus principais objetivos são iniciar e apoiar a implementação dos componentes do SQA, detectar desvios dos procedimentos e metodologia do SQA e sugerir melhorias.

Componentes de qualidade de software pré-projeto

Esses componentes ajudam a melhorar as etapas preliminares tomadas antes de iniciar um projeto. Inclui -

  • Revisão de contrato
  • Planos de Desenvolvimento e Qualidade

Revisão de contrato

Normalmente, um software é desenvolvido para um contrato negociado com um cliente ou para um pedido interno para desenvolver um firmware a ser incorporado em um produto de hardware. Em todos esses casos, a unidade de desenvolvimento está comprometida com uma especificação funcional, orçamento e cronograma acordados. Portanto, as atividades de revisão do contrato devem incluir um exame detalhado da minuta da proposta do projeto e das minutas do contrato.

Especificamente, as atividades de revisão do contrato incluem -

  • Esclarecimento dos requisitos do cliente

  • Revisão do cronograma do projeto e estimativas de requisitos de recursos

  • Avaliação da capacidade da equipe profissional para realizar o projeto proposto

  • Avaliação da capacidade do cliente de cumprir suas obrigações

  • Avaliação de riscos de desenvolvimento

Planos de Desenvolvimento e Qualidade

Após a assinatura do contrato de desenvolvimento de software com uma organização ou departamento interno da mesma organização, é preparado um plano de desenvolvimento do projeto e suas atividades integradas de garantia de qualidade. Esses planos incluem detalhes adicionais e revisões necessárias com base em planos anteriores que forneceram a base para a proposta e o contrato atuais.

Na maioria das vezes, decorrem vários meses entre a apresentação da proposta e a assinatura do contrato. Durante esse período, recursos como disponibilidade de pessoal e capacidades profissionais podem ser alterados. Os planos são então revisados ​​para refletir as mudanças que ocorreram nesse ínterim.

As principais questões tratadas no plano de desenvolvimento do projeto são -

  • Schedules
  • Recursos humanos e de hardware necessários
  • Avaliações de risco
  • Questões organizacionais: membros da equipe, subcontratados e parcerias
  • Metodologia de projeto, ferramentas de desenvolvimento, etc.
  • Planos de reutilização de software

As principais questões tratadas no plano de qualidade do projeto são -

  • Metas de qualidade, expressas em termos mensuráveis ​​apropriados

  • Critérios para iniciar e terminar cada fase do projeto

  • Listas de análises, testes e outras atividades de verificação e validação programadas

As métricas de software podem ser classificadas em três categorias -

  • Product metrics - Descreve as características do produto, como tamanho, complexidade, recursos de design, desempenho e nível de qualidade.

  • Process metrics - Essas características podem ser utilizadas para melhorar as atividades de desenvolvimento e manutenção do software.

  • Project metrics- Esta métrica descreve as características e execução do projeto. Os exemplos incluem o número de desenvolvedores de software, o padrão de pessoal ao longo do ciclo de vida do software, custo, cronograma e produtividade.

Algumas métricas pertencem a várias categorias. Por exemplo, as métricas de qualidade em processo de um projeto são métricas de processo e métricas de projeto.

Software quality metricssão um subconjunto de métricas de software que se concentram nos aspectos de qualidade do produto, processo e projeto. Eles estão mais intimamente associados às métricas de processo e produto do que às métricas de projeto.

As métricas de qualidade de software podem ser divididas em três categorias -

  • Métricas de qualidade do produto
  • Métricas de qualidade em processo
  • Métricas de qualidade de manutenção

Métricas de qualidade do produto

Essas métricas incluem o seguinte -

  • Tempo médio para a falha
  • Densidade de Defeito
  • Problemas do cliente
  • Satisfação do cliente

Tempo médio para a falha

É o tempo entre as falhas. Essa métrica é usada principalmente com sistemas críticos de segurança, como sistemas de controle de tráfego de companhias aéreas, aviônicos e armas.

Densidade de Defeito

Ele mede os defeitos relativos ao tamanho do software expresso como linhas de código ou ponto de função, etc., ou seja, ele mede a qualidade do código por unidade. Essa métrica é usada em muitos sistemas de software comerciais.

Problemas do cliente

Ele mede os problemas que os clientes encontram ao usar o produto. Ele contém a perspectiva do cliente em relação ao espaço do problema do software, que inclui os problemas não orientados a defeito juntamente com os problemas de defeito.

A métrica de problemas é geralmente expressa em termos de Problems per User-Month (PUM).

PUM = Total Problems that customers reported (true defect and non-defect oriented 
problems) for a time period + Total number of license months of the software during 
the period

Onde,

Number of license-month of the software = Number of install license of the software × 
Number of months in the calculation period

O PUM é normalmente calculado para cada mês após o lançamento do software no mercado e também para médias mensais por ano.

Satisfação do cliente

A satisfação do cliente é frequentemente medida por dados de pesquisa do cliente por meio da escala de cinco pontos -

  • Muito satisfeito
  • Satisfied
  • Neutral
  • Dissatisfied
  • Muito Insatisfeito

A satisfação com a qualidade geral do produto e suas dimensões específicas é geralmente obtida por meio de vários métodos de pesquisas com clientes. Com base nos dados da escala de cinco pontos, várias métricas com pequenas variações podem ser construídas e usadas, dependendo do propósito da análise. Por exemplo -

  • Porcentagem de clientes totalmente satisfeitos
  • Porcentagem de clientes satisfeitos
  • Porcentagem de clientes insatisfeitos
  • Porcentagem de clientes insatisfeitos

Normalmente, esse percentual de satisfação é usado.

Métricas de qualidade em processo

As métricas de qualidade em processo tratam do rastreamento da chegada de defeitos durante o teste formal da máquina para algumas organizações. Esta métrica inclui -

  • Densidade de defeito durante o teste da máquina
  • Padrão de chegada de defeito durante o teste da máquina
  • Padrão de remoção de defeito baseado em fase
  • Eficácia de remoção de defeitos

Densidade de defeito durante o teste da máquina

A taxa de defeitos durante o teste formal da máquina (teste após o código ser integrado à biblioteca do sistema) é correlacionada com a taxa de defeitos no campo. Taxas de defeitos mais altas encontradas durante o teste são um indicador de que o software experimentou uma injeção de erro maior durante seu processo de desenvolvimento, a menos que a taxa de defeitos de teste mais alta seja devido a um esforço de teste extraordinário.

Esta métrica simples de defeitos por KLOC ou ponto de função é um bom indicador de qualidade, enquanto o software ainda está sendo testado. É especialmente útil monitorar releases subsequentes de um produto na mesma organização de desenvolvimento.

Padrão de chegada de defeito durante o teste da máquina

A densidade geral do defeito durante o teste fornecerá apenas o resumo dos defeitos. O padrão de recebimento de defeitos fornece mais informações sobre os diferentes níveis de qualidade no campo. Inclui o seguinte -

  • As chegadas de defeitos ou defeitos relatados durante a fase de teste por intervalo de tempo (por exemplo, semana). Aqui, todos os quais não serão defeitos válidos.

  • O padrão de chegadas de defeitos válidos quando a determinação do problema é feita nos problemas relatados. Este é o verdadeiro padrão de defeito.

  • O padrão de atraso de defeitos ao longo do tempo. Essa métrica é necessária porque as organizações de desenvolvimento não podem investigar e corrigir todos os problemas relatados imediatamente. Esta é uma declaração de carga de trabalho, bem como uma declaração de qualidade. Se a lista de pendências de defeitos for grande no final do ciclo de desenvolvimento e muitas correções ainda tiverem que ser integradas ao sistema, a estabilidade do sistema (daí sua qualidade) será afetada. Um novo teste (teste de regressão) é necessário para garantir que os níveis de qualidade do produto pretendidos sejam alcançados.

Padrão de remoção de defeito baseado em fase

Esta é uma extensão da métrica de densidade de defeito durante o teste. Além de testar, ele rastreia os defeitos em todas as fases do ciclo de desenvolvimento, incluindo as revisões de design, inspeções de código e verificações formais antes do teste.

Como uma grande porcentagem dos defeitos de programação está relacionada a problemas de design, a realização de revisões formais ou verificações funcionais para aprimorar a capacidade de remoção de defeitos do processo no front-end reduz os erros no software. O padrão de remoção de defeitos com base em fases reflete a capacidade geral de remoção de defeitos do processo de desenvolvimento.

Com relação às métricas para as fases de design e codificação, além das taxas de defeitos, muitas organizações de desenvolvimento usam métricas como cobertura de inspeção e esforço de inspeção para gerenciamento de qualidade em processo.

Eficácia de remoção de defeitos

Pode ser definido da seguinte forma -

$$DRE = \frac{Defect \: removed \: during \: a \: development\:phase }{Defects\: latent \: in \: the\: product} \times 100\%$$

Essa métrica pode ser calculada para todo o processo de desenvolvimento, para o front-end antes da integração do código e para cada fase. É chamadoearly defect removal quando usado para o front-end e phase effectivenesspara fases específicas. Quanto maior o valor da métrica, mais eficaz é o processo de desenvolvimento e menos defeitos passam para a próxima fase ou para o campo. Essa métrica é um conceito-chave do modelo de remoção de defeitos para desenvolvimento de software.

Métricas de qualidade de manutenção

Embora muito não possa ser feito para alterar a qualidade do produto durante esta fase, a seguir estão as correções que podem ser realizadas para eliminar os defeitos o mais rápido possível com excelente qualidade de correção.

  • Corrigir o backlog e o índice de gerenciamento do backlog
  • Corrija o tempo de resposta e a capacidade de resposta
  • Porcentagem de correções inadimplentes
  • Qualidade fixa

Corrigir o backlog e o índice de gerenciamento do backlog

O backlog de correção está relacionado à taxa de chegada de defeitos e à taxa em que as correções para problemas relatados se tornam disponíveis. É uma contagem simples dos problemas relatados que permanecem no final de cada mês ou a cada semana. Utilizando-o no formato de um gráfico de tendência, essa métrica pode fornecer informações significativas para o gerenciamento do processo de manutenção.

O Backlog Management Index (BMI) é usado para gerenciar o backlog de problemas abertos e não resolvidos.

$$BMI = \frac{Number \: of \: problems \: closed \: during \:the \:month }{Number \: of \: problems \: arrived \: during \:the \:month} \times 100\%$$

Se o IMC for maior que 100, significa que o acúmulo é reduzido. Se o IMC for inferior a 100, o acúmulo aumentou.

Corrija o tempo de resposta e a capacidade de resposta

A métrica do tempo de resposta do conserto é geralmente calculada como o tempo médio de todos os problemas da abertura ao fechamento. O curto tempo de resposta da correção leva à satisfação do cliente.

Os elementos importantes da capacidade de resposta do conserto são as expectativas do cliente, o tempo combinado para conserto e a capacidade de cumprir o compromisso com o cliente.

Porcentagem de correções inadimplentes

É calculado da seguinte forma -

$Percent \:Delinquent\: Fixes =$

$\frac{Number \: of \: fixes \: that\: exceeded \: the \:response \:time\:criteria\:by\:ceverity\:level}{Number \: of \: fixes \: delivered \: in \:a \:specified \:time} \times 100\%$

Qualidade fixa

A qualidade do conserto ou o número de consertos com defeito é outra métrica de qualidade importante para a fase de manutenção. Uma correção está com defeito se não corrigiu o problema relatado ou se corrigiu o problema original, mas injetou um novo defeito. Para software de missão crítica, as correções defeituosas são prejudiciais à satisfação do cliente. A métrica da porcentagem de correções com defeito é a porcentagem de todas as correções em um intervalo de tempo que está com defeito.

Uma correção defeituosa pode ser registrada de duas maneiras: Registre-a no mês em que foi descoberta ou registre-a no mês em que a correção foi entregue. O primeiro é uma medida do cliente; a segunda é uma medida de processo. A diferença entre as duas datas é o período latente da correção defeituosa.

Normalmente, quanto maior a latência, mais clientes serão afetados. Se o número de defeitos for grande, o pequeno valor da métrica percentual mostrará uma imagem otimista. A meta de qualidade para o processo de manutenção, é claro, é zero consertos defeituosos sem inadimplência.

Medir é a ação de medir algo. É a atribuição de um número a uma característica de um objeto ou evento, que pode ser comparado com outros objetos ou eventos.

Formalmente, pode ser definido como o processo pelo qual números ou símbolos são atribuídos a atributos de entidades no mundo real, de forma a descrevê-los de acordo com regras claramente definidas.

Medição na vida cotidiana

A medição não é usada apenas por tecnólogos profissionais, mas também por todos nós na vida cotidiana. Em uma loja, o preço atua como uma medida do valor de um item. Da mesma forma, as medidas de altura e tamanho garantirão se o tecido se ajustará corretamente ou não. Assim, a medição nos ajudará a comparar um item com outro.

A medição leva as informações sobre os atributos das entidades. Uma entidade é um objeto, como uma pessoa, ou um evento, como uma jornada no mundo real. Um atributo é uma característica ou propriedade de uma entidade, como a altura de uma pessoa, o custo de uma viagem, etc. No mundo real, mesmo que estejamos pensando em medir as coisas, na verdade estamos medindo os atributos dessas coisas.

Os atributos são definidos principalmente por números ou símbolos. Por exemplo, o preço pode ser especificado em número de rúpias ou dólares, o tamanho da roupa pode ser especificado em termos de pequeno, médio, grande.

A precisão de uma medição depende do instrumento de medição, bem como da definição da medição. Depois de obter as medidas, temos que analisá-las e tirar conclusões sobre as entidades.

A medição é uma quantificação direta, enquanto o cálculo é indireto, onde combinamos diferentes medições usando algumas fórmulas.

Medição em Engenharia de Software

A Engenharia de Software envolve gerenciamento, cálculo de custos, planejamento, modelagem, análise, especificação, design, implementação, teste e manutenção de produtos de software. Portanto, a medição desempenha um papel significativo na engenharia de software. Uma abordagem rigorosa será necessária para medir os atributos de um produto de software.

Para a maioria dos projetos de desenvolvimento,

  • Não estabelecemos metas mensuráveis ​​para nossos produtos de software
  • Não conseguimos entender e quantificar o custo dos componentes dos projetos de software
  • Não quantificamos ou prevemos a qualidade dos produtos que produzimos

Assim, para controlar produtos de software, é necessário medir os atributos. Cada ação de medição deve ser motivada por uma meta ou necessidade específica que seja claramente definida e facilmente compreensível. Os objetivos da medição devem ser específicos, testados para o que os gerentes, desenvolvedores e usuários precisam saber. A medição é necessária para avaliar o status do projeto, produto, processos e recursos.

Na engenharia de software, a medição é essencial para as três atividades básicas a seguir -

  • Para entender o que está acontecendo durante o desenvolvimento e manutenção
  • Para controlar o que está acontecendo no projeto
  • Para melhorar processos e objetivos

A Teoria Representacional da Medida

A medição nos diz as regras que estabelecem as bases para desenvolver e raciocinar sobre todos os tipos de medição. É o mapeamento do mundo empírico para o mundo relacional formal. Consequentemente, uma medida é o número ou símbolo atribuído a uma entidade por esse mapeamento para caracterizar uma entidade.

Relações Empíricas

No mundo real, entendemos as coisas comparando-as, não atribuindo números a elas.

Por exemplo, para comparar a altura, usamos os termos 'mais alto que', mais alto que '. Portanto, 'mais alto que', mais alto que 'são relações empíricas para altura.

Podemos definir mais de uma relação empírica no mesmo conjunto.

Por exemplo, X é mais alto que Y. X, Y são muito mais altos que Z.

As relações empíricas podem ser unárias, binárias, ternárias, etc.

X é alto, Y não é alto são relações unárias.

X é mais alto que Y é uma relação binária.

As relações empíricas no mundo real podem ser mapeadas para um mundo matemático formal. Principalmente essas relações refletem as preferências pessoais.

Algumas das técnicas de mapeamento ou classificação usadas para mapear essas relações empíricas com o mundo matemático são as seguintes -

Escala de Likert

Aqui, os usuários receberão uma declaração com a qual devem concordar ou discordar.

For example - Este software funciona bem.

Concordo plenamente Aceita Não concordo nem discordo Discordo Fortemente Disgarado
         

Classificação Forçada

Ordene as alternativas fornecidas de 1 (melhor) a n (pior).

Por exemplo: Classifique os 5 módulos de software a seguir de acordo com seu desempenho.

Nome do Módulo Classificação
Módulo A
Módulo B
Módulo C
Módulo D
Módulo E

Escala de Frequência Verbal

For example - Com que freqüência este programa falha?

Sempre Frequentemente As vezes Raramente Nunca
         

Escala ordinal

Aqui, os usuários receberão uma lista de alternativas e deverão selecionar uma.

For example - Com que freqüência este programa falha?

  • Hourly
  • Daily
  • Weekly
  • Monthly
  • Várias vezes por ano
  • Uma ou duas vezes por ano
  • Never

Escala Comparativa

Aqui, o usuário deve fornecer um número comparando as diferentes opções.

Very superiorAbout the sameVery inferior

12345678910

Escala Numérica

Aqui, o usuário deve dar um número de acordo com sua importância.

UnimportantImportant

12345678910

As regras de mapeamento

Para realizar o mapeamento, temos que especificar o domínio, intervalo e também as regras para realizar o mapeamento.

For example - Domínio - Mundo real

  • Range - Mundo matemático, como números inteiros, números reais, etc.

  • Rules - Para medir a altura, usar sapatos ou não

Da mesma forma, no caso de medição de software, a lista de verificação da declaração a ser incluída nas linhas de código a serem especificadas.

A condição representacional de medição

A condição representacional afirma que um mapeamento de medição (M) deve mapear entidades em números e relações empíricas em relações numéricas de tal forma que as relações empíricas preservem e sejam preservadas por relações numéricas.

Por exemplo: A relação empírica 'mais alto que' é mapeada para a relação numérica '>', ou seja, X is taller than Y, if and only if M(X) > M(Y)

Visto que pode haver muitas relações em um determinado conjunto, a condição representacional também tem implicações para cada uma dessas relações.

Para a relação unária 'é alta', podemos ter a relação numérica

X > 50

A condição representacional exige que para qualquer medida M,

X is tall if and only if M(X) > 50

Estágios chave da medição formal

Os principais estágios de medição podem ser resumidos da seguinte forma -

Os modelos são úteis para interpretar o comportamento dos elementos numéricos das entidades do mundo real, bem como medi-los. Para ajudar no processo de medição, o modelo de mapeamento também deve ser complementado com um modelo do domínio de mapeamento. Um modelo também deve especificar como essas entidades estão relacionadas aos atributos e como as características se relacionam.

A medição é de dois tipos -

  • Medição direta
  • Medição indireta

Medição Direta

Essas são as medidas que podem ser medidas sem o envolvimento de qualquer outra entidade ou atributo.

As seguintes medidas diretas são comumente usadas na engenharia de software.

  • Comprimento do código-fonte por LOC
  • Duração do objetivo do teste por tempo decorrido
  • Número de defeitos descobertos durante o processo de teste, contando os defeitos
  • O tempo que um programador gasta em um programa

Medição Indireta

Essas são medidas que podem ser medidas em termos de qualquer outra entidade ou atributo.

As seguintes medidas indiretas são comumente usadas na engenharia de software.

$$\small Programmer\:Productivity = \frac{LOC \: produced }{Person \:months \:of \:effort}$$

$\small Module\:Defect\:Density = \frac{Number \:of\:defects}{Module \:size}$

$$\small Defect\:Detection\:Efficiency = \frac{Number \:of\:defects\:detected}{Total \:number \:of\:defects}$$

$\small Requirement\:Stability = \frac{Number \:of\:initial\:requirements}{Total \:number \:of\:requirements}$

$\small Test\:Effectiveness\:Ratio = \frac{Number \:of\:items\:covered}{Total \:number \:of \:items}$

$\small System\:spoilage = \frac{Effort \:spent\:for\:fixing\:faults}{Total \:project \:effort}$

Medição para previsão

Para alocar os recursos apropriados ao projeto, precisamos prever o esforço, o tempo e o custo de desenvolvimento do projeto. A medição para predição sempre requer um modelo matemático que relaciona os atributos a serem preditos a algum outro atributo que podemos medir agora. Assim, um sistema de previsão consiste em um modelo matemático junto com um conjunto de procedimentos de previsão para determinar os parâmetros desconhecidos e interpretar os resultados.

Escalas de medição são os mapeamentos usados ​​para representar o sistema de relação empírica. É principalmente de 5 tipos -

  • Escala nominal
  • Escala ordinal
  • Escala de intervalo
  • Escala de razão
  • Escala Absoluta

Escala nominal

Ele coloca os elementos em um esquema de classificação. As aulas não serão encomendadas. Cada entidade deve ser colocada em uma classe ou categoria específica com base no valor do atributo.

Possui duas características principais -

  • O sistema de relação empírica consiste apenas em classes diferentes; não há noção de ordenação entre as classes.

  • Qualquer numeração distinta ou representação simbólica das classes é uma medida aceitável, mas não há nenhuma noção de magnitude associada aos números ou símbolos.

Escala ordinal

Ele coloca os elementos em um esquema de classificação ordenado. Possui as seguintes características -

  • O sistema de relação empírica consiste em classes que são ordenadas em relação ao atributo.

  • Qualquer mapeamento que preserve a ordem é aceitável.

  • Os números representam apenas a classificação. Conseqüentemente, adição, subtração e outras operações aritméticas não têm significado.

Escala de intervalo

Essa escala captura as informações sobre o tamanho dos intervalos que separam a classificação. Portanto, é mais poderoso do que a escala nominal e a escala ordinal.

Possui as seguintes características -

  • Ele preserva a ordem como a escala ordinal.

  • Ele preserva as diferenças, mas não a proporção.

  • Adição e subtração podem ser realizadas nesta escala, mas não multiplicação ou divisão.

Se um atributo é mensurável em uma escala de intervalo, e M e M’ são mapeamentos que satisfazem a condição de representação, então podemos sempre encontrar dois números a e b de tal modo que,

M = aM '+ b

Escala de razão

Esta é a escala de medição mais útil. Aqui, existe uma relação empírica para capturar proporções. Possui as seguintes características -

  • É um mapeamento de medição que preserva a ordenação, o tamanho dos intervalos entre as entidades e a proporção entre as entidades.

  • Existe um elemento zero, representando a falta total dos atributos.

  • O mapeamento de medição deve começar em zero e aumentar em intervalos iguais, conhecidos como unidades.

  • Todas as operações aritméticas podem ser aplicadas.

Aqui, o mapeamento será na forma

M = aM’

Onde ‘a’ é um escalar positivo.

Escala Absoluta

Nesta escala, haverá apenas uma medida possível para um atributo. Portanto, a única transformação possível será a transformação da identidade.

Possui as seguintes características -

  • A medição é feita contando o número de elementos no conjunto de entidades.

  • O atributo sempre assume a forma “número de ocorrências de x na entidade”.

  • Existe apenas um mapeamento de medição possível, a saber, a contagem real.

  • Todas as operações aritméticas podem ser realizadas na contagem resultante.

As investigações empíricas envolvem a investigação científica de qualquer ferramenta, técnica ou método. Esta investigação contém principalmente os 4 princípios a seguir.

  • Escolha de uma técnica de investigação
  • Declarando a hipótese
  • Manter o controle sobre a variável
  • Tornando a investigação significativa

Escolha de uma técnica de investigação

Os principais componentes da investigação empírica em engenharia de software são -

  • Survey
  • Estudo de caso
  • Experimento formal

Pesquisa

Pesquisa é o estudo retrospectivo de uma situação para documentar relações e resultados. Isso sempre é feito após a ocorrência de um evento. Por exemplo, na engenharia de software, as pesquisas podem ser realizadas para determinar como os usuários reagiram a um determinado método, ferramenta ou técnica para determinar tendências ou relacionamentos.

Nesse caso, não temos controle sobre a situação em questão. Podemos registrar uma situação e compará-la com outra semelhante.

Estudo de caso

É uma técnica de pesquisa em que você identifica os principais fatores que podem afetar o resultado de uma atividade e, em seguida, documenta a atividade: suas entradas, restrições, recursos e saídas.

Experimento Formal

É uma investigação controlada rigorosa de uma atividade, onde os fatores-chave são identificados e manipulados para documentar seus efeitos no resultado.

Um método de investigação particular pode ser escolhido de acordo com as seguintes diretrizes -

  • Caso a atividade já tenha ocorrido, podemos realizar levantamento ou estudo de caso. Se ainda não ocorrer, então o estudo de caso ou experimento formal pode ser escolhido.

  • Se tivermos um alto nível de controle sobre as variáveis ​​que podem afetar o resultado, podemos usar um experimento. Se não tivermos controle sobre a variável, o estudo de caso será uma técnica preferida.

  • Se a replicação não for possível em níveis superiores, o experimento não será possível.

  • Se o custo de replicação for baixo, podemos considerar a experiência.

Declarando a Hipótese

Para impulsionar a decisão de uma determinada técnica de investigação, o objetivo da pesquisa deve ser expresso como uma hipótese que queremos testar. A hipótese é a teoria ou suposição provisória que o programador pensa que explica o comportamento que deseja explorar.

Manter o controle sobre as variáveis

Depois de declarar a hipótese, a seguir temos que decidir as diferentes variáveis ​​que afetam sua verdade, bem como quanto controle temos sobre ela. Isso é essencial porque o discriminador chave entre o experimento e os estudos de caso é o grau de controle sobre a variável que afeta o comportamento.

Uma variável de estado que é o fator que pode caracterizar o projeto e também pode influenciar os resultados da avaliação é usada para distinguir a situação de controle da experimental no experimento formal. Se não podemos diferenciar controle de experimento, a técnica de estudo de caso será a preferida.

Por exemplo, se quisermos determinar se uma mudança na linguagem de programação pode afetar a produtividade do projeto, a linguagem será uma variável de estado. Suponha que estamos usando FORTRAN, que queremos substituir por Ada. Então FORTRAN será a linguagem de controle e Ada será a experimental.

Tornando a investigação significativa

Os resultados de um experimento são geralmente mais generalizáveis ​​do que o estudo de caso ou pesquisa. Os resultados do estudo de caso ou pesquisa podem normalmente ser aplicáveis ​​apenas a uma determinada organização. Os pontos a seguir comprovam a eficiência dessas técnicas para responder a uma variedade de perguntas.

Teorias conformes e sabedoria convencional

Estudos de caso ou pesquisas podem ser usados ​​para conformar a eficácia e utilidade da sabedoria convencional e muitos outros padrões, métodos ou ferramentas em uma única organização. No entanto, o experimento formal pode investigar as situações em que as afirmações são geralmente verdadeiras.

Explorando relacionamentos

A relação entre vários atributos de recursos e produtos de software pode ser sugerida por um estudo de caso ou pesquisa.

Por exemplo, uma pesquisa de projetos concluídos pode revelar que um software escrito em uma linguagem específica tem menos falhas do que um software escrito em outras línguas.

Compreender e verificar essas relações é essencial para o sucesso de quaisquer projetos futuros. Cada uma dessas relações pode ser expressa como uma hipótese e um experimento formal pode ser projetado para testar o grau em que as relações se mantêm. Normalmente, o valor de um atributo específico é observado mantendo outros atributos constantes ou sob controle.

Avaliando a precisão dos modelos

Os modelos geralmente são usados ​​para prever o resultado de uma atividade ou para orientar o uso de um método ou ferramenta. Apresenta um problema particularmente difícil ao projetar um experimento ou estudo de caso, porque suas previsões geralmente afetam o resultado. Os gerentes de projeto freqüentemente transformam as previsões em metas de conclusão. Este efeito é comum quando os modelos de custo e cronograma são usados.

Alguns modelos, como os modelos de confiabilidade, não influenciam o resultado, uma vez que a confiabilidade medida como tempo médio até a falha não pode ser avaliada até que o software esteja pronto para uso em campo.

Medidas de validação

Existem muitas medidas de software para capturar o valor de um atributo. Portanto, um estudo deve ser conduzido para testar se uma determinada medida reflete as mudanças no atributo que ela deve capturar. A validação é realizada correlacionando uma medida com outra. Uma segunda medida, que também é uma medida direta e válida do fator que afeta, deve ser usada para validar. Essas medidas nem sempre estão disponíveis ou são fáceis de medir. Além disso, as medidas usadas devem estar de acordo com as noções humanas do fator que está sendo medido.

A estrutura para medição de software é baseada em três princípios -

  • Classificação das entidades a serem examinadas
  • Determinar metas de medição relevantes
  • Identificar o nível de maturidade que a organização atingiu

Classificação das entidades a serem examinadas

Na engenharia de software, existem principalmente três classes de entidades. Eles são -

  • Processes
  • Products
  • Resources

Todas essas entidades têm entidades internas e externas.

  • Internal attributessão aqueles que podem ser medidos puramente em termos do processo, produto ou recursos em si. Por exemplo: tamanho, complexidade, dependência entre módulos.

  • External attributessão aqueles que podem ser medidos apenas no que diz respeito à sua relação com o meio ambiente. Por exemplo: O número total de falhas experimentadas por um usuário, o tempo que leva para pesquisar o banco de dados e recuperar informações.

Os diferentes atributos que podem ser medidos para cada uma das entidades são os seguintes -

Processos

Processos são coleções de atividades relacionadas a software. A seguir estão alguns dos atributos internos que podem ser medidos diretamente para um processo -

  • A duração do processo ou uma de suas atividades

  • O esforço associado ao processo ou uma de suas atividades

  • O número de incidentes de um tipo especificado que surgem durante o processo ou uma de suas atividades

Os diferentes atributos externos de um processo são custo, controlabilidade, eficácia, qualidade e estabilidade.

Produtos

Produtos não são apenas os itens que a gerência está comprometida em entregar, mas também qualquer artefato ou documento produzido durante o ciclo de vida do software.

Os diferentes atributos internos do produto são tamanho, esforço, custo, especificação, comprimento, funcionalidade, modularidade, reutilização, redundância e correção sintática. Entre eles, o tamanho, o esforço e o custo são relativamente fáceis de medir do que os outros.

Os diferentes atributos de produtos externos são usabilidade, integridade, eficiência, testabilidade, reutilização, portabilidade e interoperabilidade. Esses atributos descrevem não apenas o código, mas também os outros documentos que suportam o esforço de desenvolvimento.

Recursos

Essas são entidades exigidas por uma atividade de processo. Pode ser qualquer entrada para a produção do software. Inclui pessoal, materiais, ferramentas e métodos.

Os diferentes atributos internos para os recursos são idade, preço, tamanho, velocidade, tamanho da memória, temperatura, etc. Os diferentes atributos externos são produtividade, experiência, qualidade, usabilidade, confiabilidade, conforto etc.

Determinando metas de medição relevantes

Uma determinada medição será útil apenas se ajudar a compreender o processo ou um de seus produtos resultantes. A melhoria no processo ou produtos pode ser realizada somente quando o projeto tiver metas claramente definidas para os processos e produtos. Uma compreensão clara dos objetivos pode ser usada para gerar métricas sugeridas para um determinado projeto no contexto de uma estrutura de maturidade de processo.

O paradigma Goal – Question – Metric (GQM)

A abordagem GQM fornece uma estrutura envolvendo as três etapas a seguir -

  • Listando os principais objetivos do projeto de desenvolvimento ou manutenção

  • Derivar as perguntas de cada meta que devem ser respondidas para determinar se as metas estão sendo cumpridas

  • Decida o que deve ser medido para poder responder às questões de forma adequada

Para usar o paradigma GQM, primeiro expressamos os objetivos gerais da organização. Em seguida, geramos as perguntas de forma que as respostas sejam conhecidas para que possamos determinar se os objetivos estão sendo alcançados. Posteriormente, analise cada pergunta em termos de qual medida precisamos para responder a cada pergunta.

Metas típicas são expressas em termos de produtividade, qualidade, risco, satisfação do cliente, etc. Metas e perguntas devem ser construídas em termos de seu público.

Para ajudar a gerar os objetivos, perguntas e métricas, Basili & Rombach forneceram uma série de modelos.

  • Purpose - Para (caracterizar, avaliar, prever, motivar, etc.) o (processo, produto, modelo, métrica, etc.) a fim de entender, avaliar, gerenciar, projetar, aprender, melhorar, etc. Example: Caracterizar o produto para aprendê-lo.

  • Perspective - Examinar o (custo, eficácia, correção, defeitos, mudanças, medidas do produto, etc.) do ponto de vista do desenvolvedor, gerente, cliente, etc. Example: Examine os defeitos do ponto de vista do cliente.

  • Environment - O ambiente consiste no seguinte: fatores de processo, fatores de pessoas, fatores de problema, métodos, ferramentas, restrições, etc. Example: Os clientes deste software são aqueles que não conhecem as ferramentas.

Medição e melhoria de processos

Normalmente, a medição é útil para -

  • Compreender o processo e os produtos
  • Estabelecendo uma linha de base
  • Acessando e prevendo o resultado

De acordo com o nível de maturidade do processo dado pela SEI, o tipo de medição e o programa de medição serão diferentes. A seguir estão os diferentes programas de medição que podem ser aplicados em cada um dos níveis de maturidade.

Level 1: Ad hoc

Nesse nível, as entradas são mal definidas, enquanto as saídas são esperadas. A transição da entrada para a saída é indefinida e não controlada. Para este nível de maturidade do processo, as medições de linha de base são necessárias para fornecer um ponto de partida para a medição.

Level 2: Repeatable

Nesse nível, as entradas e saídas do processo, restrições e recursos são identificáveis. Um processo repetível pode ser descrito pelo diagrama a seguir.

As medidas de entrada podem ser o tamanho e a volatilidade dos requisitos. A saída pode ser medida em termos de tamanho do sistema, os recursos em termos de esforço da equipe e as restrições em termos de custo e cronograma.

Level 3: Defined

Nesse nível, as atividades intermediárias são definidas e suas entradas e saídas são conhecidas e compreendidas. Um exemplo simples do processo definido é descrito na figura a seguir.

A entrada e a saída das atividades intermediárias podem ser examinadas, medidas e avaliadas.

Level 4: Managed

Nesse nível, o feedback das atividades iniciais do projeto pode ser usado para definir prioridades para as atividades atuais e, posteriormente, para as atividades do projeto. Podemos medir a eficácia das atividades do processo. A medição reflete as características do processo geral e da interação entre as atividades principais.

Level 5: Optimizing

Nesse nível, as medidas das atividades são usadas para melhorar o processo, removendo e adicionando atividades do processo e alterando a estrutura do processo dinamicamente em resposta ao feedback da medição. Assim, a mudança de processo pode afetar a organização e o projeto, bem como o processo. O processo atuará como sensores e monitores, e podemos alterar o processo significativamente em resposta aos sinais de alerta.

Em um determinado nível de maturidade, podemos coletar as medidas para esse nível e todos os níveis abaixo dele.

Identificando o nível de maturidade

A maturidade do processo sugere medir apenas o que é visível. Assim, a combinação de maturidade de processo com GQM fornecerá medidas mais úteis.

  • Em level 1, é provável que o projeto tenha requisitos mal definidos. Nesse nível, a medição das características do requisito é difícil.

  • Em level 2, os requisitos são bem definidos e as informações adicionais, como o tipo de cada requisito e o número de mudanças em cada tipo, podem ser coletadas.

  • Em level 3, atividades intermediárias são definidas com critérios de entrada e saída para cada atividade

O objetivo e a análise da pergunta serão os mesmos, mas a métrica irá variar com a maturidade. Quanto mais maduro o processo, mais ricas serão as medições. O paradigma GQM, em consonância com a maturidade do processo, tem sido usado como base para diversas ferramentas que auxiliam os gestores na concepção de programas de medição.

O GQM ajuda a entender a necessidade de medir o atributo, e a maturidade do processo sugere se somos capazes de medi-lo de maneira significativa. Juntos, eles fornecem um contexto para medição.

Validar a medição do sistema de software envolve duas etapas -

  • Validando os sistemas de medição
  • Validando os sistemas de previsão

Validando os Sistemas de Medição

Medidas ou sistemas de medição são usados ​​para avaliar uma entidade existente, caracterizando numericamente um ou mais de seus atributos. Uma medida é válida se caracterizar com precisão o atributo que afirma medir.

A validação de um sistema de medição de software é o processo de assegurar que a medida é uma caracterização numérica adequada do atributo reivindicado, mostrando que a condição de representação é satisfeita.

Para validar um sistema de medição, precisamos de um modelo formal que descreva as entidades e um mapeamento numérico que preserve o atributo que estamos medindo. Por exemplo, se houver dois programas P1 e P2, e quisermos concatenar esses programas, esperamos que qualquer medidam de comprimento para satisfazer isso,

m (P1 + P2) = m (P1) + m (P2)

Se um programa P1 tem mais duração do que programa P2, então qualquer medida m também deve satisfazer,

m (P1)> m (P2)

O comprimento do programa pode ser medido contando as linhas de código. Se essa contagem satisfizer as relações acima, podemos dizer que as linhas de código são uma medida válida do comprimento.

O requisito formal para validar uma medida envolve demonstrar que ela caracteriza o atributo declarado no sentido da teoria da medição. A validação pode ser usada para garantir que os medidores sejam definidos corretamente e sejam consistentes com o comportamento do mundo real da entidade.

Validando os Sistemas de Predição

Os sistemas de previsão são usados ​​para prever algum atributo de uma entidade futura envolvendo um modelo matemático com procedimentos de previsão associados.

Validar sistemas de previsão em um determinado ambiente é o processo de estabelecer a precisão do sistema de previsão por meios empíricos, ou seja, comparando o desempenho do modelo com dados conhecidos no ambiente fornecido. Envolve experimentação e teste de hipóteses.

O grau de precisão aceitável para validação depende se o sistema de previsão é determinístico ou estocástico, bem como da pessoa que faz a avaliação. Alguns sistemas de previsão estocástica são mais estocásticos do que outros.

Exemplos de sistemas de previsão estocásticos são sistemas como estimativa de custo de software, estimativa de esforço, estimativa de cronograma, etc. Portanto, para validar um sistema de previsão formalmente, devemos decidir o quão estocástico ele é e, em seguida, comparar o desempenho do sistema de previsão com dados conhecidos.

A métrica de software é um padrão de medida que contém muitas atividades que envolvem algum grau de medição. Ele pode ser classificado em três categorias: métricas do produto, métricas do processo e métricas do projeto.

  • Product metrics descreve as características do produto, como tamanho, complexidade, recursos de design, desempenho e nível de qualidade.

  • Process metricspode ser usado para melhorar o desenvolvimento e a manutenção do software. Os exemplos incluem a eficácia da remoção de defeitos durante o desenvolvimento, o padrão de teste de chegada de defeitos e o tempo de resposta do processo de correção.

  • Project metricsdescrever as características e execução do projeto. Os exemplos incluem o número de desenvolvedores de software, o padrão de pessoal ao longo do ciclo de vida do software, custo, cronograma e produtividade.

Algumas métricas pertencem a várias categorias. Por exemplo, as métricas de qualidade em processo de um projeto são métricas de processo e métricas de projeto.

Escopo das métricas de software

Métricas de software contém muitas atividades que incluem o seguinte -

  • Estimativa de custo e esforço
  • Medidas de produtividade e modelo
  • Coleção de dados
  • Modelos e medidas de quantidade
  • Modelos de confiabilidade
  • Modelos de desempenho e avaliação
  • Métricas estruturais e de complexidade
  • Capacidade - avaliação de maturidade
  • Gestão por métricas
  • Avaliação de métodos e ferramentas

A medição de software é um conjunto diversificado dessas atividades, que vão desde modelos que prevêem os custos do projeto de software em um estágio específico até medidas da estrutura do programa.

Estimativa de custo e esforço

O esforço é expresso em função de uma ou mais variáveis, como o tamanho do programa, a capacidade dos desenvolvedores e o nível de reutilização. Modelos de estimativa de custo e esforço têm sido propostos para prever o custo do projeto durante as fases iniciais do ciclo de vida do software. Os diferentes modelos propostos são -

  • Modelo COCOMO de Boehm
  • Modelo magro de Putnam
  • Modelo de ponto de função de Albrecht

Modelo de produtividade e medidas

A produtividade pode ser considerada em função do valor e do custo. Cada um pode ser decomposto em diferentes tamanhos mensuráveis, funcionalidade, tempo, dinheiro, etc. Diferentes componentes possíveis de um modelo de produtividade podem ser expressos no diagrama a seguir.

Coleção de dados

A qualidade de qualquer programa de medição depende claramente da coleta cuidadosa de dados. Os dados coletados podem ser destilados em tabelas e gráficos simples para que os gerentes possam entender o progresso e o problema do desenvolvimento. A coleta de dados também é essencial para a investigação científica de relacionamentos e tendências.

Modelos e medidas de qualidade

Modelos de qualidade foram desenvolvidos para medir a qualidade do produto sem os quais a produtividade não tem sentido. Esses modelos de qualidade podem ser combinados com o modelo de produtividade para medir a produtividade correta. Esses modelos são geralmente construídos em forma de árvore. Os ramos superiores contêm importantes fatores de qualidade de alto nível, como confiabilidade e usabilidade.

A noção de abordagem dividir para conquistar foi implementada como uma abordagem padrão para medir a qualidade do software.

Modelos de Confiabilidade

A maioria dos modelos de qualidade inclui a confiabilidade como um fator componente, no entanto, a necessidade de prever e medir a confiabilidade levou a uma especialização separada em modelagem e previsão de confiabilidade. O problema básico na teoria da confiabilidade é prever quando um sistema irá eventualmente falhar.

Avaliação e modelos de desempenho

Inclui características de desempenho do sistema observáveis ​​externamente, como tempos de resposta e taxas de conclusão, e o funcionamento interno do sistema, como a eficiência dos algoritmos. É outro aspecto da qualidade.

Métricas Estruturais e de Complexidade

Aqui medimos os atributos estruturais das representações do software, que estão disponíveis antes da execução. Em seguida, tentamos estabelecer teorias empiricamente preditivas para apoiar a garantia de qualidade, controle de qualidade e previsão de qualidade.

Avaliação de maturidade de capacidade

Este modelo pode avaliar muitos atributos diferentes de desenvolvimento, incluindo o uso de ferramentas, práticas padrão e muito mais. Baseia-se nas principais práticas que todo bom empreiteiro deve usar.

Gestão por métricas

Para gerenciar o projeto de software, a medição tem um papel vital. Para verificar se o projeto está no caminho certo, usuários e desenvolvedores podem contar com a tabela e o gráfico baseados em medição. O conjunto padrão de medições e métodos de relatório são especialmente importantes quando o software está embutido em um produto em que os clientes geralmente não conhecem bem a terminologia do software.

Avaliação de métodos e ferramentas

Isso depende do projeto experimental, da identificação adequada dos fatores que podem afetar o resultado e da medição apropriada dos atributos dos fatores.

A métrica de software é um padrão de medida que contém muitas atividades, o que envolve algum grau de medição. O sucesso na medição do software está na qualidade dos dados coletados e analisados.

O que são bons dados?

Os dados coletados podem ser considerados bons dados, se puderem produzir as respostas para as seguintes questões -

  • Are they correct? - Um dado pode ser considerado correto, se ele foi coletado de acordo com as regras exatas de definição da métrica.

  • Are they accurate? - A precisão se refere à diferença entre os dados e o valor real.

  • Are they appropriately precise? - A precisão trata do número de casas decimais necessárias para expressar os dados.

  • Are they consistent? - Os dados podem ser considerados consistentes se não apresentarem grandes diferenças de um dispositivo de medição para outro.

  • Are they associated with a particular activity or time period? - Se os dados estiverem associados a uma determinada atividade ou período de tempo, eles devem ser claramente especificados nos dados.

  • Can they be replicated?- Normalmente, as investigações como pesquisas, estudos de caso e experimentos são frequentemente repetidas em diferentes circunstâncias. Portanto, os dados também devem ser facilmente replicáveis.

Como definir os dados?

Os dados coletados para fins de medição são de dois tipos -

  • Raw data- Os dados brutos resultam da medição inicial de processos, produtos ou recursos. Por exemplo: Quadro de horários semanal dos funcionários de uma organização.

  • Refined data - Os dados refinados resultam da extração de elementos de dados essenciais dos dados brutos para derivar valores para atributos.

Os dados podem ser definidos de acordo com os seguintes pontos -

  • Location
  • Timing
  • Symptoms
  • Resultado final
  • Mechanism
  • Cause
  • Severity
  • Cost

Como coletar dados?

A coleta de dados requer observação e relatórios humanos. Gerentes, analistas de sistema, programadores, testadores e usuários devem registrar dados de linha em formulários. Para coletar dados precisos e completos, é importante -

  • Mantenha os procedimentos simples

  • Evite gravações desnecessárias

  • Treine os funcionários na necessidade de registrar dados e nos procedimentos a serem usados

  • Forneça os resultados da captura e análise de dados aos fornecedores originais prontamente e de uma forma útil que os ajudará em seu trabalho

  • Valide todos os dados coletados em um ponto de coleta central

O planejamento da coleta de dados envolve várias etapas -

  • Decida quais produtos medir com base na análise GQM

  • Certifique-se de que o produto está sob controle de configuração

  • Decida exatamente quais atributos medir e como as medidas indiretas serão derivadas

  • Uma vez que o conjunto de métricas esteja claro e o conjunto de componentes a serem medidos tenha sido identificado, elabore um esquema para identificar cada atividade envolvida no processo de medição

  • Estabeleça um procedimento para lidar com os formulários, analisar os dados e relatar os resultados

O planejamento da coleta de dados deve começar quando o planejamento do projeto começa. A coleta de dados real ocorre durante muitas fases de desenvolvimento.

For example - Alguns dados relacionados ao pessoal do projeto podem ser coletados no início do projeto, enquanto outra coleta de dados, como o esforço, começa no início do projeto e continua durante a operação e manutenção.

Como armazenar e extrair dados

Na engenharia de software, os dados devem ser armazenados em um banco de dados e configurados por meio de um Database Management System (DBMS). Um exemplo de estrutura de banco de dados é mostrado na figura a seguir. Esse banco de dados armazenará os detalhes de diferentes funcionários que trabalham em diferentes departamentos de uma organização.

No diagrama acima, cada caixa é uma tabela no banco de dados e a seta denota o mapeamento muitos para um de uma tabela para outra. Os mapeamentos definem as restrições que preservam a consistência lógica dos dados.

Uma vez que o banco de dados é projetado e preenchido com dados, podemos fazer uso das linguagens de manipulação de dados para extrair os dados para análise.

Depois de coletar os dados relevantes, temos que analisá-los de forma adequada. Existem três itens principais a serem considerados para a escolha da técnica de análise.

  • A natureza dos dados
  • O propósito do experimento
  • Considerações de design

A Natureza dos Dados

Para analisar os dados, devemos também olhar para a população maior representada pelos dados, bem como a distribuição desses dados.

Amostragem, população e distribuição de dados

Amostragem é o processo de seleção de um conjunto de dados de uma grande população. As estatísticas de amostra descrevem e resumem as medidas obtidas de um grupo de sujeitos experimentais.

Os parâmetros populacionais representam os valores que seriam obtidos se todos os sujeitos possíveis fossem medidos.

A população ou amostra pode ser descrita pelas medidas de tendência central, como média, mediana e moda, e medidas de dispersão, como variância e desvio padrão. Muitos conjuntos de dados são distribuídos normalmente, conforme mostrado no gráfico a seguir.

Conforme mostrado acima, os dados serão distribuídos uniformemente sobre a média. que são as características significativas de uma distribuição normal.

Outras distribuições também existem onde os dados são distorcidos para que haja mais pontos de dados em um lado da média do que no outro. Por exemplo: se a maioria dos dados estiver presente no lado esquerdo da média, então podemos dizer que a distribuição está inclinada para a esquerda.

O Objetivo da Experiência

Normalmente, os experimentos são realizados -

  • Para confirmar uma teoria
  • Para explorar um relacionamento

Para atingir cada um deles, o objetivo deve ser expresso formalmente em termos da hipótese, e a análise deve abordar a hipótese diretamente.

Para confirmar uma teoria

A investigação deve ser planejada para explorar a verdade de uma teoria. A teoria geralmente afirma que o uso de um determinado método, ferramenta ou técnica tem um efeito particular sobre os sujeitos, tornando-o melhor de alguma forma do que de outra.

Existem dois casos de dados a serem considerados: normal data e non-normal data.

Se os dados forem de uma distribuição normal e houver dois grupos para comparar, o teste t de Student pode ser usado para análise. Se houver mais de dois grupos para comparar, uma análise geral de teste de variância chamada estatística F pode ser usada.

Se os dados não forem normais, eles podem ser analisados ​​usando o teste de Kruskal-Wallis classificando-os.

Para explorar um relacionamento

As investigações são projetadas para determinar a relação entre os pontos de dados que descrevem uma variável ou várias variáveis.

Existem três técnicas para responder às perguntas sobre um relacionamento: gráficos de caixa, gráficos de dispersão e análise de correlação.

  • UMA box plot pode representar o resumo do intervalo de um conjunto de dados.

  • UMA scatter plot representa a relação entre duas variáveis.

  • Correlation analysis usa métodos estatísticos para confirmar se há um relacionamento verdadeiro entre dois atributos.

    • Para valores normalmente distribuídos, use Pearson Correlation Coefficient para verificar se as duas variáveis ​​são ou não altamente correlacionadas.

    • Para dados não normais, classifique os dados e use o Spearman Rank Correlation Coefficientcomo uma medida de associação. Outra medida para dados não normais é oKendall robust correlation coefficient, que investiga a relação entre pares de pontos de dados e pode identificar uma correlação parcial.

Se a classificação contiver um grande número de valores empatados, um chi-squared testem uma tabela de contingência pode ser usado para testar a associação entre as variáveis. Similarmente,linear regression pode ser usado para gerar uma equação para descrever a relação entre as variáveis.

Por mais de duas variáveis, multivariate regression pode ser usado.

Considerações de design

O desenho da investigação deve ser considerado na escolha das técnicas de análise. Ao mesmo tempo, a complexidade da análise pode influenciar o projeto escolhido. Vários grupos usam estatísticas F em vez do teste T de Student com dois grupos.

Para experimentos fatoriais complexos com mais de dois fatores, é necessário um teste de associação e significância mais sofisticado.

Técnicas estatísticas podem ser usadas para explicar o efeito de um conjunto de variáveis ​​sobre outros ou para compensar os efeitos de tempo ou aprendizagem.

Os atributos internos do produto descrevem os produtos de software de uma forma que depende apenas do próprio produto. A principal razão para medir os atributos internos do produto é que isso ajudará a monitorar e controlar os produtos durante o desenvolvimento.

Medindo Atributos de Produto Interno

Os principais atributos internos do produto incluem size e structure. O tamanho pode ser medido estaticamente sem ter que executá-los. O tamanho do produto nos informa sobre o esforço necessário para criá-lo. Da mesma forma, a estrutura do produto desempenha um papel importante na concepção da manutenção do produto.

Medindo o tamanho

O tamanho do software pode ser descrito com três atributos -

  • Length - É o tamanho físico do produto.

  • Functionality - Descreve as funções fornecidas pelo produto ao usuário.

  • Complexity - A complexidade é de diferentes tipos, como.

    • Problem complexity - Mede a complexidade do problema subjacente.

    • Algorithmic complexity - Mede a complexidade do algoritmo implementado para resolver o problema

    • Structural complexity - Mede a estrutura do software usado para implementar o algoritmo.

    • Cognitive complexity - Mede o esforço necessário para entender o software.

A medição desses três atributos pode ser descrita da seguinte forma -

comprimento

Existem três produtos de desenvolvimento cuja medição de tamanho é útil para prever o esforço necessário para a previsão. Eles são especificação, design e código.

Especificação e design

Esses documentos geralmente combinam texto, gráfico e diagramas e símbolos matemáticos especiais. A medição de especificação pode ser usada para prever o comprimento do design, que por sua vez é um preditor do comprimento do código.

Os diagramas nos documentos têm sintaxe uniforme, como dígrafos rotulados, diagramas de fluxo de dados ou esquemas Z. Como os documentos de especificação e design consistem em textos e diagramas, seu comprimento pode ser medido em termos de um par de números que representam o comprimento do texto e o comprimento do diagrama.

Para essas medições, os objetos atômicos devem ser definidos para diferentes tipos de diagramas e símbolos.

Os objetos atômicos para diagramas de fluxo de dados são processos, entidades externas, armazenamentos de dados e fluxos de dados. As entidades atômicas para especificações algébricas são classificações, funções, operações e axiomas. As entidades atômicas para os esquemas Z são as várias linhas que aparecem na especificação.

Código

O código pode ser produzido de diferentes maneiras, como linguagem procedural, orientação a objetos e programação visual. A medida tradicional de comprimento de programa de código-fonte mais comumente usada são as linhas de código (LOC).

O comprimento total,

LOC = NCLOC + CLOC

ie,

LOC = Non-commented LOC + Commented LOC

Além da linha de código, outras alternativas, como o tamanho e a complexidade sugeridos por Maurice Halsted, também podem ser usadas para medir o comprimento.

A ciência de software de Halstead tentou capturar diferentes atributos de um programa. Ele propôs três atributos internos do programa, como comprimento, vocabulário e volume, que refletem diferentes visões de tamanho.

Ele começou definindo um programa Pcomo uma coleção de tokens, classificados por operadores ou operandos. As métricas básicas para esses tokens eram,

  • μ1 = Número de operadores únicos

  • μ2 = Número de operandos únicos

  • N1 = Total de ocorrências de operadores

  • N2 = Número de operadores únicos

O comprimento P pode ser definido como

$$N = N_{1}+ N_{2}$$

O vocabulário de P é

$$\mu =\mu _{1}+\mu _{2}$$

O volume do programa = número de comparações mentais necessárias para escrever um programa de duração N, é

$$V = N\times {log_{2}} \mu$$

O nível de programa de um programa P de volume V é,

$$L = \frac{V^\ast}{V}$$

Onde, $V^\ast$ é o volume potencial, ou seja, o volume da implementação de tamanho mínimo de P

O inverso do nível é a dificuldade -

$$D = 1\diagup L$$

De acordo com a teoria Halstead, podemos calcular uma estimativa L Como

$${L}' = 1\diagup D = \frac{2}{\mu_{1}} \times \frac{\mu_{2}}{N_{2}}$$

Da mesma forma, a duração estimada do programa é, $\mu_{1}\times log_{2}\mu_{1}+\mu_{2}\times log_{2}\mu_{2}$

O esforço necessário para gerar P é dado por,

$$E = V\diagup L = \frac{\mu_{1}N_{2}Nlog_{2}\mu}{2\mu_{2}}$$

Onde a unidade de medida E são discriminações mentais elementares necessárias para entender P

As outras alternativas para medir o comprimento são -

  • Em termos do número de bytes de armazenamento do computador necessários para o texto do programa

  • Em termos de número de caracteres no texto do programa

O desenvolvimento orientado a objetos sugere novas maneiras de medir o comprimento. Pfleeger et al. descobriram que uma contagem de objetos e métodos levou a estimativas de produtividade mais precisas do que aquelas que usam linhas de código.

Funcionalidade

A quantidade de funcionalidade inerente a um produto dá a medida do tamanho do produto. Existem tantos métodos diferentes para medir a funcionalidade de produtos de software. Discutiremos um desses métodos ─ o método do Ponto de Função de Albrecht ─ no próximo capítulo.

A métrica de ponto de função fornece um método padronizado para medir as várias funções de um aplicativo de software. Ele mede a funcionalidade do ponto de vista do usuário, ou seja, com base no que o usuário solicita e recebe em troca. A análise de pontos de função é um método padrão para medir o desenvolvimento de software do ponto de vista do usuário.

A medida de Ponto de Função originalmente concebida por Albrecht ganhou popularidade crescente com o início do Grupo de Usuários de Ponto de Função Internacional (IFPUG) em 1986. Em 2002, os Pontos de Função do IFPUG se tornaram um padrão ISO internacional - ISO / IEC 20926.

O que é um ponto de função?

FP (Function Point)é a métrica de tipo funcional mais difundida, adequada para quantificar um aplicativo de software. É baseado em cinco "funções" lógicas identificáveis ​​pelos usuários, que são divididas em dois tipos de função de dados e três tipos de função transacional. Para uma determinada aplicação de software, cada um desses elementos é quantificado e ponderado, contando-se seus elementos característicos, como referências de arquivos ou campos lógicos.

Os números resultantes (FP não ajustado) são agrupados em conjuntos de funções Adicionadas, Alteradas ou Excluídas e combinados com o Fator de Ajuste de Valor (VAF) para obter o número final de FP. Uma fórmula final distinta é usada para cada tipo de contagem: Aplicativo, Projeto de Desenvolvimento ou Projeto de Melhoria.

Aplicando o Método de Ponto de Função de Albrecht

Vamos agora entender como aplicar o método do Ponto de Função de Albrecht. Seu procedimento é o seguinte -

Determine o número de componentes (EI, EO, EQ, ILF e ELF)

  • EI- O número de entradas externas. Esses são processos elementares nos quais os dados derivados cruzam a fronteira de fora para dentro. Em um exemplo de sistema de banco de dados de biblioteca, insira o número do cartão de biblioteca de um usuário existente.

  • EO- O número de saídas externas. Esses são processos elementares nos quais os dados derivados cruzam a fronteira de dentro para fora. Em um exemplo de sistema de banco de dados de biblioteca, exiba uma lista de livros retirados para um usuário.

  • EQ- O número de consultas externas. Esses são processos elementares com componentes de entrada e saída que resultam na recuperação de dados de um ou mais arquivos lógicos internos e arquivos de interface externa. Em um exemplo de sistema de banco de dados de biblioteca, determine quais livros estão atualmente com check-out para um usuário.

  • ILF- O número de arquivos de log internos. Esses são grupos identificáveis ​​pelo usuário de dados relacionados logicamente que residem inteiramente dentro dos limites dos aplicativos que são mantidos por meio de entradas externas. Em um exemplo de sistema de banco de dados de biblioteca, o arquivo de livros na biblioteca.

  • ELF- O número de arquivos de log externos. Esses são grupos identificáveis ​​pelo usuário de dados relacionados logicamente que são usados ​​apenas para fins de referência e que residem inteiramente fora do sistema. Em um exemplo de sistema de banco de dados de biblioteca, o arquivo que contém transações no sistema de cobrança da biblioteca.

Calcule a contagem de pontos de função não ajustados (UFC)

  • Avalie cada componente como low, average, ou high.

  • Para transações (EI, EO, and EQ), a classificação é baseada em FTR e DET.

    • FTR - O número de arquivos atualizados ou referenciados.

    • DET - O número de campos reconhecíveis pelo usuário.

    • Com base na tabela a seguir, um EI que referencia 2 arquivos e 10 elementos de dados seriam classificados como average.

FTRs DETs
1-5 6-15 >15
0-1 Baixo Baixo Média
2-3 Baixo Média Alto
>3 Média Alto Alto
  • Para arquivos (ILF and ELF), a classificação é baseada no RET e DET.

    • RET - O número de elementos de dados reconhecíveis pelo usuário em um ILF ou ELF.

    • DET - O número de campos reconhecíveis pelo usuário.

    • Com base na tabela a seguir, um ILF que contém 10 elementos de dados e 5 campos seriam classificados como high.

RETs DETs
1-5 6-15 >15
1 Baixo Baixo Média
2-5 Baixo Média Alto
>5 Média Alto Alto
  • Converter avaliações em UFCs.

Avaliação Valores
EO EQ EI ILF ELF
Low 4 3 3 7 5
Average 5 4 4 10 7
High 6 5 6 15 10

Calcule a contagem final de pontos de função (FPC)

  • Fator de ajuste de valor de cálculo (VAF) com base em 14 características gerais do sistema (GSC).

Características Gerais do Sistema Descrição breve
GSC 1 Comunicações de dados Quantas facilidades de comunicação existem para auxiliar na transferência ou troca de informações com o aplicativo ou sistema?
GSC 2 Processamento de dados distribuído Como os dados distribuídos e as funções de processamento são tratados?
GSC 3 atuação O tempo de resposta ou a taxa de transferência foram exigidos pelo usuário?
GSC 4 Configuração muito usada Quão fortemente utilizada é a plataforma de hardware atual onde o aplicativo será executado?
GSC 5 Taxa de transação Com que frequência as transações são executadas diariamente, semanalmente, mensalmente, etc.?
GSC 6 Entrada de dados on-line Qual porcentagem das informações é inserida online?
GSC 7 Eficiência do usuário final O aplicativo foi projetado para eficiência do usuário final?
GSC 8 Atualização on-line Quantos ILFs são atualizados por transação online?
GSC 9 Processamento complexo O aplicativo possui processamento lógico ou matemático extenso?
GSC 10 Reutilização O aplicativo foi desenvolvido para atender às necessidades de um ou mais usuários?
GSC 11 Facilidade de instalação Quão difícil é a conversão e instalação?
GSC 12 Facilidade operacional Quão eficazes e / ou automatizados são os procedimentos de inicialização, backup e recuperação?
GSC 13 Vários sites O aplicativo foi projetado, desenvolvido e com suporte especificamente para ser instalado em vários locais para várias organizações?
GSC 14 Facilite a mudança O aplicativo foi projetado, desenvolvido e apoiado especificamente para facilitar a mudança?
  • Pesar cada GSC em uma escala de 0 a 5 com base no fato de não ter influência sobre forte influência.

  • Calcule o FPC como segue -

    FPC = UFC * (0,65+ (soma (GSC) * .01))

Complexidade

A complexidade é um componente separado do tamanho. É de dois tipos -

  • Complexity of a problem - É a quantidade de recursos necessários para uma solução ótima do problema.

  • Complexity of a solution- São os recursos necessários para implementar uma solução específica. Tem dois aspectos. Eles são os seguintes -

    • Time complexity - O recurso é o tempo do computador.

    • Space complexity - O recurso é a memória do computador.

Complexidade de medição

Um aspecto da complexidade é a eficiência. Ele mede qualquer produto de software que pode ser modelado como um algoritmo.

Por exemplo: Se um algoritmo para resolver todas as instâncias de um problema particular requer f(n) cálculos, então f(n) é assintoticamente ideal, se para todos os outros algoritmos com complexidade g que resolva o problema f é O(g). Então, a complexidade do problema dado é grande -O do algoritmo assintoticamente ótimo para a solução do problema.

A medição das propriedades estruturais de um software é importante para estimar o esforço de desenvolvimento e também para a manutenção do produto. A estrutura de requisitos, design e código ajuda a compreender a dificuldade que surge na conversão de um produto em outro, no teste de um produto ou na previsão dos atributos externos do software a partir das primeiras medidas internas do produto.

Tipos de medidas estruturais

A estrutura do software tem três partes. Eles são -

  • Control-flow structure - É a seqüência em que as instruções são executadas em um programa.

  • Data-flow structure - É o comportamento dos dados à medida que interage com o programa.

  • Data structure - É a organização dos elementos de dados na forma de listas, fila, pilhas ou outras estruturas bem definidas junto com algoritmo para criar, modificar ou excluir.

Estrutura de medição de controle-fluxo

As medidas de fluxo de controle são geralmente modeladas com gráfico direcionado, onde cada nó ou ponto corresponde às declarações do programa, e cada arco ou borda direcionada indica o fluxo de controle de uma declaração para outra. Esses gráficos são chamados de gráfico de fluxo de controle ou gráfico direcionado.

E se ‘m’ é uma medida estrutural definida em termos do modelo de gráfico de fluxo e se o programa A é estruturalmente mais complexo do que o programa B, então a medida m(A) deve ser maior que m(B).

Medindo Estrutura de Fluxo de Dados

O fluxo de dados ou fluxo de informações pode ser intermodular (fluxo de informações dentro dos módulos) ou intramodular (fluxo de informações entre módulos individuais e o resto do sistema).

De acordo com a forma como os dados estão se movendo pelo sistema, eles podem ser classificados da seguinte forma -

  • Local direct flow - Se um módulo invoca um segundo módulo e passa informações para ele ou o módulo invocado retorna um resultado para o responsável pela chamada.

  • Local indirect flow - Se o módulo invocado retornar informações que são subsequentemente passadas para um segundo módulo invocado.

  • Global flow - Se a informação flui de um módulo para outro por meio de uma estrutura de dados global.

A complexidade do fluxo de informações pode ser expressa de acordo com Henry e Kafura como,

Information flow complexity (M) = length (M) × fan-in (M) × (fan-out (M))2

Onde,

  • Fan-in (M) - O número de fluxos locais que terminam em M + o número de estruturas de dados a partir das quais a informação é recuperada por M.

  • Fan–out (M) - O número de fluxos locais que emanam de M + o número de estruturas de dados que são atualizadas por M.

Medindo Estrutura de Dados

A estrutura de dados pode ser ambas local e global.

Locally, a quantidade de estrutura em cada item de dados será medida. Uma abordagem da teoria dos gráficos pode ser usada para analisar e medir as propriedades de estruturas de dados individuais. Nesses tipos de dados simples, como inteiros, caracteres e booleanos, são vistos como primos e as várias operações que nos permitem construir estruturas de dados mais complexas são consideradas. As medidas da estrutura de dados podem então ser definidas hierarquicamente em termos de valores para os primos e valores associados às várias operações.

Globally, uma contagem do número total de variáveis ​​definidas pelo usuário será medida.

Vários institutos de padrões nacionais e internacionais, organizações profissionais e orientadas para a indústria estão envolvidos no desenvolvimento de padrões SQA.

Os seguintes institutos e organizações são os principais desenvolvedores de padrões de engenharia de software e SQA -

  • IEEE (Instituto de Engenheiros Elétricos e Eletrônicos) Sociedade de Computadores
  • ISO (Organização Internacional de Padronização)
  • DOD (Departamento de Defesa dos EUA)
  • ANSI (American National Standards Institute)
  • IEC (International Electro Technical Commission)
  • EIA (Electronic Industries Association)

Essas organizações fornecem padrões internacionais atualizados para a qualidade das atividades profissionais e gerenciais realizadas em organizações de desenvolvimento e manutenção de software.

Eles também fornecem certificação SQA por meio de auditorias independentes de qualidade profissional. Essas auditorias externas avaliam as realizações no desenvolvimento de sistemas SQA e sua implementação. A certificação, que é concedida após as auditorias periódicas, terá validade apenas até a próxima auditoria, devendo, portanto, ser renovada. Atualmente, o Serviço de Certificação ISO 9000 é o provedor mais proeminente de certificação SQA na Europa e em outros países.

Eles também fornecem as ferramentas para autoavaliação do sistema SQA de uma organização e sua operação. O Capacity Maturity Model (CMM) desenvolvido pelo Software Engineering Institute (SEI), Carnegie Mellon University e ISO / IEC Std 15504 são os exemplos dessa abordagem.

Padrões SQA

Os padrões de garantia de qualidade de software podem ser classificados em duas classes principais -

  • Padrões de gerenciamento de garantia de qualidade de software, incluindo metodologias de certificação e avaliação (padrões de gerenciamento de qualidade)

  • Padrões de processo de desenvolvimento de projeto de software (padrões de processo de projeto)

Padrões de Gestão de Qualidade

Eles se concentram no sistema, infraestrutura e requisitos de SQA da organização, deixando a escolha dos métodos e ferramentas para a organização. Com os padrões de gerenciamento de qualidade, as organizações podem garantir de forma constante que seus produtos de software atinjam um nível aceitável de qualidade.

Example - ISO 9000-3 e o Capability Maturity Model (CMM)

Padrões de Processo de Projeto

Estes enfocam as metodologias de implementação dos projetos de desenvolvimento e manutenção de software. Esses padrões incluem o seguinte -

  • Os passos a serem dados
  • Requisitos de documentação de design
  • Conteúdo dos documentos de design
  • Revisões de design e problemas de revisão
  • Teste de software a ser realizado
  • Tópicos de teste

Naturalmente, devido às suas características, muitos padrões SQA nesta classe podem servir como padrões de engenharia de software e vice-versa.

As características dessas duas classes de padrões estão resumidas na tabela a seguir.

Características Padrões de Gestão de Qualidade Padrões de Processo de Projeto
A unidade alvo Gestão de desenvolvimento de software, manutenção e unidades SQA específicas Uma equipe de projeto de desenvolvimento e manutenção de software
O principal foco Organização de sistemas SQA, infraestrutura e requisitos Metodologias de execução de projetos de desenvolvimento e manutenção de software
O objetivo do padrão “O que” alcançar “Como” executar
O objetivo do padrão Garantir a qualidade do software do fornecedor e avaliar a capacidade do processo de software Garantindo a qualidade do software do fornecedor e avaliando a capacidade do processo do software Assegurando a qualidade de um projeto de software específico.
Exemplos ISO 9000-3 SEI's CMM ISO / IEC 12207 IEEEStd 1012-1998

Certificação ISO 9001

ISO (a Organização Internacional para Padronização) é uma federação mundial de organismos de normalização nacionais. Os comitês técnicos da ISO preparam as Normas Internacionais. A ISO colabora de perto com a Comissão Eletrotécnica Internacional (IEC) em todas as questões de padronização eletrotécnica.

As Normas Internacionais são elaboradas de acordo com as regras apresentadas nas Diretivas ISO / IEC, Parte 2. A minuta das Normas Internacionais adotada pelos comitês técnicos é distribuída aos órgãos membros para votação. A ISO 9001 foi preparada pelo Comitê Técnico ISO / TC 176, Gestão e garantia da qualidade, Subcomitê SC 2, Sistemas de qualidade.

Processo de abordagem

Esta Norma promove a adoção de uma abordagem de processo ao desenvolver, implementar e melhorar a eficácia de um sistema de gestão da qualidade, para aumentar a satisfação do cliente atendendo aos requisitos do cliente. Para que uma organização funcione de maneira eficaz, ela deve determinar e gerenciar várias atividades vinculadas. Uma atividade ou conjunto de atividades que usam recursos e são gerenciados de forma a permitir a transformação de entradas em saídas pode ser considerada um processo.

Freqüentemente, a saída de um processo forma diretamente a entrada para o próximo. A aplicação de um sistema de processos dentro de uma organização, juntamente com a identificação e interações desses processos, e sua gestão para produzir o resultado desejado, pode ser referida como o“process approach”.

Uma vantagem da abordagem de processo é o controle contínuo que ela fornece sobre a ligação entre os processos individuais dentro do sistema de processos, bem como sobre sua combinação e interação. Quando usado dentro de um sistema de gestão da qualidade, tal abordagem enfatiza a importância do seguinte -

  • Compreender e cumprir os requisitos
  • É preciso considerar os processos em termos de valor agregado
  • Obtenha os resultados do desempenho e eficácia do processo
  • Melhoria contínua dos processos com base na medição objetiva

ISO 9001 - Aplicativo para Software: a Iniciativa TickIT

O TickIT foi lançado no final da década de 1980 pela indústria de software do Reino Unido em cooperação com o Departamento de Comércio e Indústria do Reino Unido para promover o desenvolvimento de uma metodologia para adaptar a ISO 9001 às características da indústria de software conhecida como iniciativa TickIT.

A TickIT é, adicionalmente, especializada em tecnologia da informação (TI). Abrange toda a gama de serviços de desenvolvimento e manutenção de software comercial. TickIT, agora gerenciado e mantido pelo DISC Department of BSI (o British Standards Institute), é credenciado para a certificação de organizações de TI no Reino Unido e na Suécia.

Suas atividades incluem -

  • Publicação do Guia TickIT, que apóia os esforços da indústria de software para disseminar a certificação ISO 9001. O guia atual (edição 5.0, TickIT, 2001), que inclui referências à ISO / IEC 12207 e ISO / IEC 15504, é distribuído a todos os clientes TickIT.

  • Realização de avaliações baseadas em auditoria de sistemas de qualidade de software e consultoria às organizações na melhoria dos processos de desenvolvimento e manutenção de software além de sua gestão.

  • Realize auditorias de certificação ISO 9000.

Os auditores TickIT que realizam avaliações baseadas em auditoria e auditorias de certificação são registrados pelo International Register of Certificated Auditors (IRCA). Os auditores IRCA registrados devem, entre outras coisas, ter experiência em gerenciamento e desenvolvimento de software; eles também devem concluir com êxito um curso de auditor.

Os auditores líderes registrados devem ter experiência comprovada na condução e direção de auditorias TickIT.

Uma avaliação de processo de software é um exame disciplinado dos processos de software usados ​​por uma organização, com base em um modelo de processo. A avaliação inclui a identificação e caracterização das práticas atuais, identificando áreas de pontos fortes e fracos, e a capacidade das práticas atuais de controlar ou evitar causas significativas de baixa qualidade (software), custo e cronograma.

Uma avaliação (ou auditoria) de software pode ser de três tipos.

  • UMA self-assessment (first-party assessment) é realizado internamente pelo próprio pessoal da organização.

  • UMA second-party assessment é realizado por uma equipe de avaliação externa ou a organização é avaliada por um cliente.

  • UMA third-party assessment é realizado por uma parte externa ou (por exemplo, um fornecedor sendo avaliado por um terceiro para verificar sua capacidade de celebrar contratos com um cliente).

As avaliações do processo de software são realizadas em um ambiente aberto e colaborativo. São para uso da organização para melhorar seus processos de software e os resultados são confidenciais para a organização. A organização que está sendo avaliada deve ter membros na equipe de avaliação.

Avaliação da maturidade do processo de software

O escopo de uma avaliação de processo de software pode abranger todos os processos na organização, um subconjunto selecionado de processos de software ou um projeto específico. A maioria das abordagens de avaliação de processo baseadas em padrões são invariavelmente baseadas no conceito de maturidade do processo.

Quando o alvo da avaliação é a organização, os resultados de uma avaliação de processo podem diferir, mesmo em aplicações sucessivas do mesmo método. Existem duas razões para os resultados diferentes. Eles são,

  • A organização que está sendo investigada deve ser determinada. Para uma grande empresa, várias definições de organização são possíveis e, portanto, o escopo real da avaliação pode diferir em avaliações sucessivas.

  • Mesmo no que parece ser a mesma organização, a amostra de projetos selecionados para representar a organização pode afetar o escopo e o resultado.

Quando a unidade de avaliação de destino está no nível do projeto, a avaliação deve incluir todos os fatores significativos que contribuem para o sucesso ou fracasso do projeto. Não deve ser limitado por dimensões estabelecidas de um determinado modelo de maturidade de processo. Aqui, o grau de implementação e sua eficácia, conforme comprovado pelos dados do projeto, são avaliados.

A maturidade do processo torna-se relevante quando uma organização pretende embarcar em uma estratégia geral de melhoria de longo prazo. As avaliações de projetos de software devem ser independentes para serem objetivas.

Ciclo de Avaliação de Processo de Software

De acordo com Paulk e colegas (1995), a abordagem de avaliação baseada em CMM usa um ciclo de seis etapas. Eles são -

  • Selecione uma equipe - Os membros da equipe devem ser profissionais com conhecimento em engenharia e gerenciamento de software.

  • Os representantes do site a ser avaliado respondem ao questionário padrão de maturidade do processo.

  • A equipe de avaliação realiza uma análise das respostas do questionário e identifica as áreas que justificam uma exploração posterior de acordo com as principais áreas de processo do CMM.

  • A equipe de avaliação realiza uma visita ao local para obter uma compreensão do processo de software seguido pelo local.

  • A equipe de avaliação produz uma lista de descobertas que identifica os pontos fortes e fracos do processo de software da organização.

  • A equipe de avaliação prepara uma análise de perfil da Key Process Area (KPA) e apresenta os resultados ao público apropriado.

Por exemplo, a equipe de avaliação deve ser liderada por um Avaliador Líder SEI autorizado. A equipe deve consistir de quatro a dez membros da equipe. Pelo menos um membro da equipe deve ser da organização sendo avaliada e todos os membros da equipe devem concluir o curso de Introdução ao CMM da SEI (ou equivalente) e o curso de treinamento da equipe CBA IPI da SEI. Os membros da equipe também devem atender a algumas diretrizes de seleção.

No que diz respeito à coleta de dados, o CBA IPI se baseia em quatro métodos -

  • O questionário de maturidade padrão
  • Entrevistas individuais e em grupo
  • Revisões de documentos
  • Feedback da revisão das conclusões preliminares com os participantes da avaliação

SCAMPI

O Método de Avaliação CMMI Padrão para Melhoria de Processos (SCAMPI) foi desenvolvido para satisfazer os requisitos do modelo CMMI (Software Engineering Institute, 2000). Também é baseado no CBA IPI. Tanto o CBA IPI quanto o SCAMPI consistem em três fases -

  • Plano e preparação
  • Realize a avaliação no local
  • Resultados do relatório

As atividades para o plano e a fase de preparação incluem -

  • Identifique o escopo da avaliação
  • Desenvolva o plano de avaliação
  • Preparar e treinar a equipe de avaliação
  • Faça uma breve avaliação dos participantes
  • Administrar o questionário de avaliação CMMI
  • Examine as respostas do questionário
  • Realizar uma análise inicial do documento

As atividades para a fase de avaliação no local incluem -

  • Conduza uma reunião de abertura
  • Realizar entrevistas
  • Consolidar informações
  • Prepare a apresentação das conclusões preliminares
  • Apresentar as conclusões preliminares
  • Consolidar, classificar e preparar as conclusões finais

As atividades da fase de relatórios de resultados incluem -

  • Apresentar as descobertas finais
  • Conduza uma sessão executiva
  • Conclua a avaliação

A definição IEEE para garantia de qualidade de software é a seguinte -

"Um padrão planejado e sistemático de todas as ações necessárias para fornecer a confiança adequada de que um item ou produto está em conformidade com os requisitos técnicos estabelecidos. Um conjunto de atividades destinadas a avaliar o processo pelo qual os produtos são desenvolvidos ou fabricados."

Objetivos das Atividades SQA

Os objetivos das atividades SQA são os seguintes -

Em desenvolvimento de software (orientado a processos)

  • Garantir um nível aceitável de confiança de que o software estará em conformidade com os requisitos técnicos funcionais.

  • Assegurar um nível aceitável de confiança de que o software estará em conformidade com o agendamento gerencial e os requisitos orçamentários.

  • Iniciar e gerenciar atividades para a melhoria e maior eficiência do desenvolvimento de software e atividades de SQA.

Em manutenção de software (orientada ao produto)

  • Garantir, com um nível aceitável de confiança, que as atividades de manutenção de software estarão em conformidade com os requisitos técnicos funcionais.

  • Garantir, com um nível aceitável de confiança, que as atividades de manutenção de software estarão em conformidade com o planejamento gerencial e os requisitos orçamentários.

  • Iniciar e gerenciar atividades para melhorar e aumentar a eficiência da manutenção de software e atividades de SQA. Isso envolve melhorar as perspectivas de atingir os requisitos funcionais e gerenciais, reduzindo custos.

Organização para Garantia de Qualidade

A estrutura organizacional de garantia de qualidade que opera dentro da estrutura organizacional inclui os seguintes participantes -

Gerentes

  • Executivos da alta administração, especialmente o executivo diretamente responsável pela garantia da qualidade do software

  • Gerentes de departamento de desenvolvimento e manutenção de software

  • Gerentes de departamento de teste de software

  • Gerentes de projeto e líderes de equipe de projetos de desenvolvimento e manutenção

  • Líderes de equipes de teste de software

Testadores

  • Membros de equipes de teste de software

Profissionais de SQA e praticantes interessados ​​-

  • Curadores SQA
  • Membros do comitê SQA
  • Membros do fórum SQA
  • Membros da equipe da unidade SQA

Apenas os gerentes e funcionários do departamento de teste de software ocupam-se em tempo integral no desempenho de tarefas de SQA. Os outros dedicam parte de seu tempo a questões de qualidade, seja durante o cumprimento de suas funções gerenciais ou tarefas profissionais, ou como voluntários em outros, na maioria das vezes um comitê SQA, um fórum SQA ou como curadores SQA.

Basicamente, existe uma estrutura de gerenciamento de três níveis nas organizações de desenvolvimento de software -

  • Alta administração
  • Gestão de departamento
  • Gerenciamento de Projetos

Responsabilidades da Alta Administração em Qualidade de Software

A seguir estão as responsabilidades da alta administração em garantir a qualidade do software -

  • Garantir a qualidade dos produtos de software e serviços de manutenção de software da empresa

  • Comunicar a importância da qualidade do produto e serviço, além da satisfação do cliente, aos funcionários em todos os níveis

  • Garantir funcionamento satisfatório e total conformidade com os requisitos do cliente

  • Garantir que os objetivos de qualidade sejam estabelecidos para o sistema SQA da organização e que seus objetivos sejam alcançados

  • Iniciar o planejamento e supervisionar a implementação das mudanças necessárias para adaptar o sistema SQA às principais mudanças internas e externas relacionadas à clientela, concorrência e tecnologia da organização

  • Intervir diretamente para apoiar a resolução de situações de crise e minimizar danos

  • Garantir a disponibilidade dos recursos exigidos pelos sistemas SQA

As etapas a seguir podem ser realizadas pela alta administração para cumprir suas responsabilidades -

  • Estabelecer e atualizar a política de qualidade de software da organização.

  • Designar um dos executivos, como o vice-presidente de SQA, para ser responsável pelas questões de qualidade de software

  • Realizar análises regulares de gerenciamento de desempenho com relação a problemas de qualidade de software

Política de Qualidade de Software

A política de qualidade de software da organização deve comunicar os seguintes requisitos -

  • Conformidade com o propósito e objetivos da organização

  • Compromisso com os conceitos gerais de garantia de qualidade de software

  • Compromisso com os padrões de qualidade adotados pela organização

  • Compromisso de alocar recursos adequados para garantia de qualidade de software

  • Compromisso com a melhoria contínua da qualidade e produtividade da organização

O Executivo Responsável pela Qualidade de Software

As responsabilidades do executivo responsável pelas questões de qualidade de software podem ser classificadas como -

  • Responsabilidade pela preparação de um orçamento e programa anual de atividades SQA

  • Responsabilidade pela preparação dos planos de desenvolvimento do sistema SQA

  • Controle geral da implementação do programa de atividades regulares SQA anual e projetos de desenvolvimento SQA planejados

  • Apresentação e defesa de questões de SQA para a gerência executiva

Responsabilidade pela Preparação do Programa Anual de Atividades SQA

Isso exige que o executivo -

  • Estabeleça os objetivos de SQA do sistema para o próximo ano

  • Rever as propostas preparadas pela unidade SQA para o programa anual de atividades e verificar o potencial da proposta para cumprir os objetivos definidos para o sistema SQA

  • Determinar se o programa de atividades é adequado às características e escopo dos serviços de subcontratados e compras de software planejadas para o próximo ano

  • Determinar a adequação da mão de obra e outros recursos planejados para a implementação do programa SQA

  • Aprovar a versão final do programa anual de atividades SQA e orçamento

Responsabilidade pela preparação de planos de desenvolvimento de sistema SQA

Esses planos devem ser adaptáveis ​​às mudanças tecnológicas, bem como às demandas dos clientes e à concorrência. As responsabilidades incluem -

  • Revisão das tendências que podem afetar a qualidade do software da organização em um futuro próximo

  • Rever as propostas de adaptações SQA, como a preparação de novos procedimentos apropriados para as novas ferramentas e padrões SQA

  • Preparação de programas de treinamento para equipes veteranas de desenvolvimento de software e membros da equipe recém-recrutados

  • Desenvolvimento de métricas de qualidade de software adequadas para avaliar as novas ferramentas e padrões, bem como o sucesso dos programas de treinamento

  • Aprovação da versão final dos projetos de desenvolvimento SQA planejados, incluindo seus cronogramas e orçamentos

Controle Geral da Implementação do Programa Anual SQA

O executivo encarregado é responsável por -

  • Supervisão geral do programa anual de atividades

  • Revisão do progresso dos projetos de adaptação SQA

  • Supervisão geral das ações tomadas para realizar as conquistas de qualidade ditadas pelos objetivos das equipes (com base em relatórios periódicos)

  • Revisão da conformidade com os procedimentos e padrões SQA com base em auditorias de qualidade internas

  • Acompanhamento geral de conformidade com cronogramas e orçamentos de projetos de desenvolvimento de software

  • Acompanhamento geral da prestação de serviços de manutenção de qualidade para clientes externos e internos

Apresentação e defesa de questões de SQA para a gerência executiva

A fim de promover a qualidade e resolver as dificuldades do sistema SQA que ele requer -

  • Apresentação para aprovação final do programa de atividades anual proposto e orçamento

  • Apresentação para aprovação final dos projetos de adaptação SQA planejados juntamente com os orçamentos correspondentes

  • Iniciação e liderança de reuniões periódicas de análise gerencial dedicadas à qualidade de software da organização

  • Início de discussões de nível gerencial dedicadas a eventos especiais de qualidade de software, como falhas graves de qualidade, ameaças à conclusão bem-sucedida de projetos devido a grave escassez de pessoal profissional, crises gerenciais na unidade SQA e assim por diante

Responsabilidades de gerenciamento de departamento para SQA

As responsabilidades de garantia de qualidade da média gerência incluem -

  • Gestão do sistema de gestão de qualidade de software (tarefas relacionadas ao sistema de qualidade)

  • Gestão de tarefas relacionadas aos projetos e serviços executados por unidades ou equipes sob a autoridade do gerente específico (tarefas relacionadas ao projeto)

Responsabilidades relacionadas ao sistema de qualidade

Isso inclui atividades de SQA a serem realizadas no nível de departamento -

  • Preparação do programa anual de atividades SQA do departamento e orçamento, com base no programa recomendado preparado pela unidade SQA

  • Elaboração dos planos de desenvolvimento de sistemas SQA do departamento, com base no plano recomendado elaborado pela unidade SQA

  • Controle de desempenho do programa de atividades SQA anual do departamento e projetos de desenvolvimento

  • Apresentação das questões de SQA do departamento para a alta administração

Responsabilidades relacionadas ao projeto

Estes variam de acordo com os procedimentos da organização e distribuição de autoridade; eles geralmente envolvem -

  • Controle do cumprimento dos procedimentos de garantia de qualidade nas unidades do departamento, incluindo órgãos CAB, SCM e SCCA

  • Acompanhamento detalhado dos resultados da revisão do contrato e aprovações de propostas

  • Revisão do desempenho da unidade das atividades de revisão planejadas; aprovação dos documentos do projeto e conclusão da fase do projeto

  • Acompanhamento dos testes de software e resultados dos testes; aprovação de produtos de software do projeto

  • Acompanhamento do andamento dos cronogramas do projeto de desenvolvimento de software e desvios de orçamento

  • Aconselhamento e suporte aos gerentes de projeto na resolução de problemas de cronograma, orçamento e relacionamento com o cliente

  • Acompanhamento da qualidade da prestação dos serviços de manutenção

  • Acompanhamento detalhado dos riscos do projeto e suas soluções

  • Acompanhamento da conformidade do projeto com os requisitos do cliente e satisfação do cliente

  • Aprovação de grandes pedidos de mudança de software e desvios significativos das especificações do projeto

Responsabilidades de gerenciamento de projeto sobre qualidade de software

A maioria das responsabilidades de gerenciamento de projetos são definidas em procedimentos e instruções de trabalho; o gestor do projeto é o responsável por garantir que todos os membros da equipa cumpram os referidos procedimentos e instruções.

Suas tarefas incluem tarefas profissionais práticas e gerenciais, principalmente as seguintes -

  • Professional hands-on tasks

    • Elaboração de projetos e planos de qualidade e suas atualizações

    • Participação em comitê conjunto cliente-fornecedor

    • Acompanhamento próximo da equipe do projeto, incluindo atendimento ao recrutamento, treinamento e instrução

  • Management tasks

    Os gerentes de projeto abordam as questões de acompanhamento, como -

    • Desempenho das atividades de revisão e as consequentes correções

    • Desenvolvimento de software e desempenho da unidade de manutenção, integração e atividades de teste de sistema, bem como correções e testes de regressão

    • Desempenho de testes de aceitação

    • Instalação de software em sites remotos do cliente e execução do sistema de software pelo cliente

    • Treinamento SQA e instrução de membros da equipe do projeto

    • Cronogramas e recursos alocados para atividades do projeto

    • Pedidos e satisfação do cliente

    • Evolução dos riscos de desenvolvimento de projetos, aplicação de soluções e controle de resultados

A estrutura da unidade SQA varia de acordo com o tipo e o tamanho da organização. A figura a seguir mostra um exemplo de uma estrutura padrão e todos os componentes em uma unidade SQA. Neste capítulo, discutiremos as funções e responsabilidades de cada subunidade.

Tarefas desempenhadas pelo chefe da unidade SQA

O chefe da unidade SQA é responsável por todas as tarefas de garantia de qualidade realizadas pela unidade SQA e suas subunidades. Essas tarefas podem ser classificadas nas seguintes categorias -

  • Tarefas de planejamento
  • Gestão da unidade
  • Atividades profissionais SQA

Tarefas de planejamento

  • Preparação do programa de atividades anual proposto e orçamento para a unidade

  • Planejar e atualizar o sistema de gestão de qualidade de software da organização

  • Preparação dos programas de atividades SQA anuais recomendados e planos de desenvolvimento de sistemas SQA para os departamentos de desenvolvimento e manutenção de software

Tarefas de Gestão

  • Gestão das atividades da equipe SQA

  • Monitorar a implementação do programa de atividades SQA

  • Nomeação de membros da equipe, membros do comitê SQA e curadores SQA

  • Preparação de relatórios especiais e periódicos, por exemplo, o status dos problemas de qualidade de software dentro da organização e relatórios de desempenho mensais

Atividades Profissionais SQA

  • Participação em comitês conjuntos de projetos
  • Participação em revisões formais de design
  • Revisão e aprovação de desvios das especificações
  • Consulta com gerentes de projeto e líderes de equipe
  • Participação em comitês e fóruns de SQA

SQA do Ciclo de Vida do Projeto

As tarefas de SQA relacionadas à subunidade do ciclo de vida do projeto podem ser classificadas em dois grupos -

  • Acompanhamento gerencial "puro" e tarefas de aprovação (tarefas de controle do ciclo de vida do projeto)

  • Participação “prática” ou ativa nas atividades de SQA da equipe do projeto, onde contribuições profissionais são necessárias (tarefas de participação)

Tarefas de controle do ciclo de vida do projeto

  • Acompanhamento da conformidade da equipe de desenvolvimento e manutenção com os procedimentos e instruções de trabalho do SQA

  • Aprovação ou recomendação de produtos de software de acordo com os procedimentos relevantes

  • Acompanhamento da entrega de serviços de manutenção de software para clientes internos e externos

  • Monitorar a satisfação do cliente e manter contato com os representantes de garantia de qualidade do cliente

Tarefas de Participação

Essas tarefas incluem a participação em -

  • Revisões de contrato
  • Preparação e atualização dos planos de desenvolvimento e qualidade do projeto
  • Avaliações de design formal
  • Revisões formais do projeto dos subcontratados
  • Teste de software, incluindo testes de aceitação do cliente
  • Testes de aceitação de software de produtos de software de subcontratados
  • Instalação de novos produtos de software

Tarefas de operações de infraestrutura SQA

Os sistemas SQA empregam uma variedade de componentes de infraestrutura para operar sem problemas, a saber -

  • Procedimentos e instruções de trabalho
  • Dispositivos de suporte de qualidade (modelos, listas de verificação)
  • Treinamento, instrução e certificação de equipe
  • Ações preventivas e corretivas
  • Gerenciamento de configurações
  • Controle de documentação

Mais especificamente, as tarefas da subunidade SQA em relação a esses componentes incluem -

  • Publicação de versões atualizadas de procedimentos, instruções de trabalho, modelos, listas de verificação e assim por diante, juntamente com sua circulação em papel e / ou por meio eletrônico

  • Transmissão de treinamento e instrução sobre a adesão e aplicação dos procedimentos de SQA, instruções de trabalho e itens semelhantes para funcionários novos e atuais

  • Instrução dos curadores SQA sobre procedimentos novos e revisados, bem como ferramentas e métodos de desenvolvimento, entre outros componentes

  • Monitorar e apoiar a implementação de procedimentos SQA novos e revisados

  • Acompanhamento das atividades de certificação da equipe

  • Proposta de assuntos que requerem ações preventivas e corretivas, incluindo participação em comitês de CAB

  • Acompanhamento das atividades de gerenciamento de configuração, incluindo a participação em comitês CCA

  • Acompanhamento do cumprimento dos procedimentos de documentação e instruções de trabalho

Auditoria Interna SQA e Tarefas de Certificação

Os tipos de auditorias SQA realizadas em ou por organizações de software podem ser classificados da seguinte forma -

  • Audições internas

  • Auditorias de subcontratados e fornecedores para avaliar seus sistemas SQA

  • Auditorias externas realizadas por organismos de certificação

  • Auditorias externas realizadas por clientes que desejam avaliar o sistema SQA antes de aceitar a organização como fornecedor

As duas primeiras classes de auditorias são iniciadas e realizadas pela subunidade SQA, as duas últimas por órgãos externos.

A unidade SQA executa as seguintes tarefas para auditorias SQA internas

  • Preparação de programas anuais para auditorias SQA internas

  • Desempenho de auditorias SQA internas

  • Acompanhamento de correções e melhorias a serem realizadas pelas equipes auditadas e demais unidades

  • Preparação de relatórios periódicos de resumo do status das constatações de auditoria, incluindo recomendações para melhorias

A unidade SQA executa as seguintes tarefas para auditorias de subcontratados e fornecedores -

  • Preparação do programa anual para auditorias SQA de subcontratados e fornecedores

  • Desempenho de auditorias SQA de subcontratados e fornecedores

  • Acompanhamento de correções e melhorias a serem realizadas pelos subcontratados e fornecedores auditados

  • Coleta de dados sobre o desempenho de subcontratados e fornecedores de fontes internas e externas

  • Avaliação periódica dos sistemas de SQA de subcontratados e fornecedores certificados da organização com base em relatórios de auditoria e informações coletadas de outras fontes internas e externas. O relatório de avaliação inclui -

    • Recomendações sobre certificação de subcontratados e fornecedores

    • As auditorias externas realizadas por organismos de certificação envolvem as seguintes tarefas -

      • Coordenação do conteúdo e cronograma da auditoria de certificação

      • Preparação de documentos especificados pelos organismos de certificação

      • Instrução das equipes auditadas e realização dos preparativos necessários para as auditorias de certificação

      • Participação em auditorias de certificação

      • Garantir que as correções e melhorias necessárias sejam realizadas

As auditorias SQA realizadas pelos clientes da organização envolvem essas tarefas -

  • Coordenação do conteúdo e cronograma da auditoria

  • Preparação de documentos especificados pelo auditor do cliente

  • Instrução das equipes auditadas e execução dos preparativos necessários para as auditorias SQA pelos clientes da organização

  • Participação nas auditorias

  • Certifique-se de que as correções e melhorias necessárias sejam realizadas

Tarefas de Suporte SQA

A maioria dos consumidores de serviços de suporte SQA está localizada dentro da organização. Eles incluem gerentes de projeto, líderes de equipe e curadores SQA. Suas tarefas incluem -

  • Preparação de planos de projeto e planos de qualidade do projeto

  • Equipes de revisão de pessoal

  • Escolha de medidas para resolver os riscos de desenvolvimento de software identificados

  • Escolha de medidas para resolver atrasos de cronograma e estouros de orçamento

  • Escolha de métricas SQA e componentes de custos de software

  • Uso do sistema de informação SQA

  • Escolha de metodologias de desenvolvimento e ferramentas que refletem os dados de experiência de falha acumulados pela unidade SQA

Tarefas de Padrões e Procedimentos SQA

A subunidade SQA está intimamente envolvida na decisão de quais padrões SQA serão adotados, bem como no desenvolvimento e manutenção dos procedimentos da organização. Para cumprir as obrigações inerentes, a unidade SQA é obrigada a -

  • Preparar um programa anual para o desenvolvimento de novos procedimentos e atualizações de procedimentos

  • Ser responsável pelo desenvolvimento de novos procedimentos e atualizações de procedimentos, com participação em comitês e fóruns apropriados

  • Acompanhamento dos desenvolvimentos e mudanças nos padrões de SQA e engenharia de software; introdução de procedimentos adicionais e mudanças relevantes para a organização

  • Iniciar atualizações e adaptações de procedimentos em resposta a mudanças nos padrões profissionais, incluindo a adoção ou exclusão de padrões aplicados pela organização

Tarefas de Engenharia SQA

Acompanhamento de avanços profissionais, solução de dificuldades operacionais e análise especializada de falhas são os objetivos imediatos desta subunidade SQA.

Portanto, as principais tarefas de engenharia envolvem o seguinte -

  • Testar aspectos de qualidade e produtividade com relação a novas ferramentas de desenvolvimento e novas versões das ferramentas de desenvolvimento usadas atualmente

  • Avaliação da qualidade e produtividade de novos métodos de desenvolvimento e manutenção e melhorias de método

  • Desenvolvimento de soluções para as dificuldades enfrentadas na aplicação das ferramentas e métodos de desenvolvimento de software atualmente utilizados

  • Desenvolvimento de métodos de medição de qualidade de software e produtividade da equipe

  • Prestação de suporte tecnológico aos comitês CAB durante a análise de falhas de desenvolvimento de software e formulação das soluções propostas

SQA Information Systems Tasks

Os sistemas de informação SQA destinam-se a facilitar e melhorar o funcionamento dos sistemas SQA. As tarefas envolvidas incluem -

  • Desenvolvimento de sistemas de informação SQA para unidades de desenvolvimento e manutenção de software para

    • coleta de dados de atividade

    • processamento de, por exemplo, relatórios periódicos, listas, relatórios de exceção e consultas

    • processamento de, por exemplo, relatórios periódicos, listas, relatórios de exceção e consultas

  • Desenvolvimento de sistemas de informação SQA facilitando o processamento da unidade SQA de informações fornecidas por unidades de desenvolvimento e manutenção de software, incluindo estimativas de métricas de qualidade de software e custos de qualidade de software

  • Atualizando sistemas de informação SQA

  • Desenvolvimento e manutenção do site SQA Internet / Intranet da organização

Curadores da SQA e suas tarefas

Os curadores da SQA são aqueles membros que estão principalmente envolvidos na promoção da qualidade do software. Esses membros fornecem o suporte interno necessário para a implementação bem-sucedida dos componentes SQA.

Suas tarefas podem variar dependendo das organizações. Conseqüentemente, podem ser tarefas relacionadas à unidade e / ou à organização.

Tarefas relacionadas à unidade

  • Apoiar os colegas para resolver as dificuldades durante a implementação de procedimentos de qualidade de software e instruções de trabalho

  • Auxiliar o gerente da unidade na realização de tarefas SQA relacionadas

  • Promova a conformidade e monitore a implementação de procedimentos de SQA e instruções de trabalho por colegas

  • Reportar eventos de não conformidade substanciais e sistemáticos à unidade SQA

  • Reportar falhas graves de qualidade de software à unidade SQA

Tarefas relacionadas à organização

  • Acionar mudanças e atualizações de procedimentos SQA de toda a organização e instruções de trabalho

  • Melhorar os processos de desenvolvimento e manutenção da organização

  • Iniciar pedidos para o CAB sobre soluções para falhas recorrentes observadas nas respectivas unidades

  • Identificar as necessidades de treinamento SQA em toda a organização e propor o treinamento apropriado ou programa de instrução a ser conduzido pela unidade SQA

Comitês de SQA e suas tarefas

Os comitês SQA podem ser permanentes ou ad hoc. As tarefas podem variar consideravelmente de organização para organização.

  • Permanent committees comumente lidam com SCC (Controle de Mudanças de Software), CA (Ações Corretivas), procedimentos, ferramentas de desenvolvimento de métodos e métricas de qualidade.

  • Ad hoc committees normalmente lidam com casos específicos de interesse geral, como atualização de um procedimento específico, análise e solução de uma falha de software, elaboração de métricas de software para um processo ou produto específico, atualização de custos de qualidade de software e métodos de coleta de dados para um problema específico.

Comitês SQA permanentes são partes integrantes da estrutura organizacional SQA; suas tarefas e operações são geralmente definidas nos procedimentos de SQA da organização.

Comitês ad hoc são estabelecidos em uma base de curto prazo por problema, com membros nomeados pelo executivo responsável por questões de qualidade de software, o chefe da Unidade SQA, as subunidades SQA, comitês SQA permanentes ou qualquer outro órgão que iniciou sua formação e tem interesse no trabalho. Este órgão também define as tarefas do comitê ad hoc.