Qualidade de Software.pdf

Qualidade de Software

by Tatiana Felix2012

Qualidade de SoftwareHistórinha clássica....

Qualidade de SoftwareDEFINIÇÃO:

“Qualidade de software é a conformidade a requisitos funcionais e de desempenho explicitamente estabelecidos, a padrões de desenvolvimento explicitamente documentados, e a características implícitas que são esperadas de todo software desenvolvido profissionalmente”

Pressman


DEFINIÇÃO:

“Qualidade é a totalidade das características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas”

NBR ISO 8402


O QUE FAZER ?

A qualidade do produto deve ser especificada para aquilo que o cliente deseja.


Em software, não sabemos como especificar com toda precisão características tais como, facilidade de manutenção ou de uso. Ou seja:

É muito difícil descrever especificações de softwares completas.


GESTÃO DA QUALIDADE DE SOFTWARE

Para sistemas pequenos é suficiente estabelecer uma cultura de qualidade entre as equipes envolvidas de forma que todos os membros tenham uma abordagem para qualidade de software.

Mas como gerenciar qualidade em sistemas de grande porte ??

Qualidade de Software Em sistemas de grande porte o gerenciamento da qualidade pode ser estruturado em três atividades principais:

Planejamento da Qualidade - Definir os requisitos de

qualidade;

Garantia da Qualidade - Embutir qualidade no produto,

definição e controle do processo;

Controle de Qualidade - Medir a qualidade.


Planejamento da qualidade (QA)

Estabelece as qualidades de software desejadas e descreve como elas devem ser avaliadas.

Sem essa definição os engenheiros de software podem entrar em conflito sobre quais atributos do produto devem ser otimizados (ex. segurança, facilidade de uso).

Qualidade de SoftwareUma estrutura geral para um plano de qualidade é sugerida por Humphrey (1989) e inclui:

Apresentação do produto – Descrição do produto e expectativas de

qualidade Plano de produto – Datas críticas de liberação e responsabilidades Descrições de processos – Os processos que devem ser usados para

desenvolvimento (padrões de processos). Metas de qualidades – Identificação e justificativa de atributos críticos de

qualidade Gerenciamento de riscos – Riscos que podem impactar na qualidade


- Um plano de qualidade deve ainda conter um processo definido de avaliação do produto.

- Essa seria uma forma padronizada de avaliação se certa qualidade, como facilidade de manutenção ou robustez, está presente no produto.

Qualidade de Software Garantia da qualidade (QA)

Está diretamente relacionada a seleção de padrões que devem ser aplicados ao processo de desenvolvimento de software e ao produto final.

Os padrões de software são importantes por várias razões:

- São baseadas no conhecimento sobre as melhores práticas;

- Dispõem de frameworks para implementação;- Ajudam na continuidade do processo.


Padrões de Processos x Padrões de Produtos

Padrões de produto – Aplica-se aos artefatos de produto (documentos de requisitos, padrões de codificação).

Padrões de processo – Define os processos que devem ser seguidos durante o desenvolvimento do software.


Garantia da qualidade no tempo....

- 1900 Avalia o produto depois de pronto

- 1950 Avalia todo o procedimento de produção

- 1970 Avalia e otimiza cada processo

- 1990 Avalia a concepção do produto


Os sistemas de manufatura nos mostrou que a qualidade do processo de desenvolvimento afeta diretamente a qualidade dos produtos entregues.

Embora softwares não sejam manufaturado, mas sim projetados, a experiência tem mostrado que a qualidade de processo também tem influência significativa na qualidade do produto.


A fim de alcançar garantia de qualidade, algumas medidas podem ser tomadas para evitar problema de não aderência aos padrões estabelecidos

a) Revise os padrões regularmente para refletirem mudanças de tecnologia.

a) Envolva os engenheiros de softwares na seleção de padrões e inclua no documento de padrões as razões pela quais as decisões de padronização foram tomadas.

a) Disponha de ferramentas de software para apoiar padrões.


Órgãos responsáveis pela avaliação e a criação de normas e padrões:

ISO

IEEE

IEC

ABNT


A ISO e a IEC definem processo de software como sendo:

“Conjunto de processos usados por uma organização para: planejar, gerenciar, executar, monitorar e melhorar as atividades relacionadas ao software.”

Qualidade de SoftwarePRINCIPAIS NORMAS PARA SOFTWARE'

ISO9000-3ISO9000-3: Normas para aplicação da série ISO9000 e processos de software.ISO12207ISO12207: Processos do ciclo de vida do software.ISO25000ISO25000: SQuaRE–Software Quality Requirements and Evaluation CMMCMM: Capability Maturity ModelCMMICMMI: Capability Maturity Model IntegrationPSPPSP: Personal software ProcessISO15504ISO15504 ( (SPICE)SPICE): Software Process Improvement and Capability dEtermination MPS.BRMPS.BR:: Melhoria de Processo de Software Brasileiro Melhoria de Processo de Software Brasileiro


Maior centralizador e publicador internacional de

padrões

Desenvolvedor internacional de padrões para as áreas de

eletrotécnica

ENTENDENDO AS ESTRUTURAS DE PADRÕES

Desenvolvedor internacional de padrões para formatos de dispositivos computacionais


Aqui entra a

certificação


ISO 9000

ISO 9001Sistemas da Qualidade - Modelo para Garantia da Qualidade em Projeto, Desenvolvimento, Produção, Instalação e Assistência

ISO 9002 Modelo para Garantia da Qualidade em Produção, Instalação e Serviços Associados (MANUFATURA)

ISO 9003 Modelo para Garantia da Qualidade em Inspeção e Ensaios Finais

PRINICPAIS NORMAS ISO 9000


ISO 9000-3

NORMAS ISO 9000

Qualidade de SoftwareISO 9000-3

É a norma ISO 9001 direcionada para software. Para cada item da ISO 9001 existem um correspondente na ISO 9000-3.

Destina-se a fornecer orientação quando um contrato

entre duas partes exigir a demonstração da

capacidade do fornecedor em desenvolver, fornecer e

manter produtos de software.

Qualidade de SoftwareISO 9000-3

Principais Diretrizes:

- E s trutura : Des c reve as pec tos organizac iona is re lac ionados ao s is tema de qua lidade (res pons abilidade da gerênc ia ).

- Atividades do C ic lo de Vida : Des envolver e doc umentar proc edimentos para c ontrolar todo o projeto de des envolvimento do s oftw are .

- Atividades de apoio: Des c reve atividades que apoiam o c ic lo de vida (rea lizaç ão de tes tes , ins peç ão)

LEMA DA NORMA:

“Diga o que você faz, faça tudo o

que você diz e documento tudo!”

Sequência para certificação ISO:

1) Estabelece o Sistema de Qualidade

2) Solicitação ao órgão certificador

3) Visita à empresa

4) Auditoria

5) Emissão do Certificado

Qualidade de SoftwareCERTIFICAÇÃO ISO 9000

Qualidade de SoftwareLimitações das normas ISO 9000-3

Não trata aspectos de melhoria contínua dos processos – Software Process Improvements (SPI).

Apenas indica quais processos a organização dever ter e manter, mas não diz como desenvolver esses processos.


ISO/IEC-12207

Lançada em 1995, a norma formaliza a arquitetura do Ciclo de Vida do Software, onde os processos eram divididos em três grupos. Com sua atualização em 2008 passou-se a ter sete grupos.

Ela descreve com detalhes os processos, atividades e tarefas que envolvem o fornecimento, desenvolvimento, operação e manutenção de produtos de Software


ISO/IEC-12207Estrutura

A norma categoriza seus grupos de processos em Processos de Contexto de Sistema e Processos Específicos de Software.

Cada processo é descrito em termos da sua finalidade e os resultados desejados e lista atividades e tarefas que necessitam de ser realizados para atingir esses resultados

Grupos de Processos

Processostem

Atividades

tem Propósitos

Resultados esperado

Tarefas

tem

tem

Padrões sempre dizem o que fazer,

mas não como fazer!

tem

Qualidade de SoftwareISO/IEC-12207 Categorias

Grupos de processos

Qualidade de SoftwareISO/IEC-12207

Exemplo para categoria Processos de Contexto do Sistema

Grupo de processo: – 1. Agreement ProcessesProcessos definidos: - 1.1 - Acquisition Process e 1.2 – Supply Process 1.1.1. - Propósito : obter o produto que o aquisitor (cliente) necessita

1.1.2. - Resultados: a) critérios de necessidades de aquisição, as metas de produtos e/ou serviço de aceitação e estratégias de aquisição são definidos;

b) um acordo é desenvolvido que expressa claramente as expectativas, responsabilidades e obrigações de ambas as adquirente eo fornecedor;

c) um ou mais fornecedores é selecionada; d) um produto e / ou serviço é adquirido que satisfaz a necessidade do

adquirente indicado; e) a aquisição é monitorado para que as restrições especificadas, tais

como custo, cronograma e qualidade são cumpridos; f) entregas de fornecedores são aceitos;

g) quaisquer itens identificados abertos tem uma conclusão satisfatória, conforme acordado pelo adquirente eo fornecedor.

1.1.3.1. - Atividades: Acquisition Preparation1.3.1.1.1 - Tarefa: O adquirente começa o processo de aquisição por descrever um

conceito ou uma necessidade de adquirir, desenvolver ou melhorar um sistema, produto de software ou serviço de software

1.3.1.1.2. O adquirente deve definir e analisar os requisitos de sistema(...)


ISO/IEC- 25000

Software Quality Requirements and Evaluation(SQuaRE)

Qualidade de SoftwareISO/IEC- 25000 - SQuaRE

SquaRE significa Software Product Quality Requirements and Evaluation (Requisitos de Qualidade e Avaliação deProdutos de Software)

Consiste de cinco divisões: Gestão de Qualidade (2500n)Modelo de Qualidade (2501n)Medição da Qualidade (2502n)Requisitos de Qualidade (2503n)Avaliação da Qualidade (2504n)

Evolução das séries de normas ISO/IEC-9126 e ISO/IEC-14598. É uma segunda geração de padrões para qualidade de produtos de software

Qualidade de SoftwareISO/IEC- 9126 e 14598

As normas ISO/IEC 9126 e ISO/IEC 14598 são compostas por 10 documentos:

Norma Conteúdo9126-1 Modelo de qualidade de software

9126-2 Métricas externas

9126-3 Métricas internas

9126-4 Métricas para qualidade em uso

14598-1 Guia de Avaliação – Visão Geral

14598-2 Planejamento e gerenciamento de avaliações

14598-3 Processo de avaliação para desenvolvedores

14598-4 Processo de avaliação para adquirentes

14598-5 Processo de avaliação para avaliadores

14598-6 Documentação de módulos de avaliação



Qualidade de SoftwareISO/IEC- 25000 - SQuaRE

Gerenciamento : os documentos desta divisão estão voltados a todos possíveis usuários dela,gerentes, programadores, avaliadores, compradores. Aqui são definidos os termos utilizados em todos os demais documentos e são feitas recomendações e sugestões de caráter geral sobre como utilizar o Square.

Modelo de qualidade : É definido um modelo hierárquico de características de qualidade, descrevendo o que se espera de um produto. São definidos também os conceitos de qualidade externa, interna e em uso , que permitem orientar diferentes perspectivas de avaliação.

Medição : Define- se o que é uma medição e descreve os diversos aspectos relacionados à realização dessa tarefa. Propõe também uma série de métricas que podem ser utilizadas ou adaptadas a necessidades especificas.

Requisitos de qualidade : Para garantir qualidade é preciso que valores-alvo tenham sido previamente especificados, o que faz parte evidentemente da especificação de requisitos.

Avaliação: a Square concretiza-se na realização de uma avaliação de qualidade a partir de medições cujos resultados são confrontados contra um modelo definido pelo usuário. Para realizar uma avaliação são sugeridos procedimentos a serem adotados para diferentes públicos da norma, como desenvolvedores e compradores.


(CMM)Capability Maturity Model

Qualidade de SoftwareCMM – Capability Maturity Model

O modelo CMM serve para orientar a organização a implementar a melhoria contínua do processo de software.

O modelo foi proposto inicialmente por Watts S. Humphrey. Foi aperfeiçoado pelo SEI - Software Engineering Institute, da Carnegie Mellon University, dos EUA.

Possui 5 níveis para classificar a organização. A cada nível de maturidade corresponde um conjunto de práticas de software e de gestão específicas, denominadas áreas-chave do processo (KPAs - Key Process Areas). Estas devem ser implantadas para que a organização possa atingir o nível de maturidade desejado

Qualidade de SoftwareCMM – Níveis de maturidade

Quantitativo, controle por mediçãoGerenciado (4)

Auto-adaptativo, melhoria do processo contínuoOtimizado (5)

Definido (3) Qualitativo, processo sistematizado e controlado(consciente)

Repetível (2) Intuitivo, baseado na experiência. Inicia-se a implantação de mecanismos de gerenciamento de projetos

Inicial (1) Caótico, imprevisível e pessimamente controlado (ad-hoc). Depende exclusivamente dos indivíduos


O CMM enfatiza a documentação dos processos, seguindo a premissa de que para realizar alguma melhoria no processo, é preciso primeiro, conhecê-lo e entendê-lo, e que a qualidade de um produto é reflexo da qualidade e gerenciamento do processo utilizado em seu desenvolvimento.

As KPA's (Key Process Areas) são exatamente os pontos chaves levantado pelo modelo CMM, nos quais a organização deve focar para melhorar o seu processo.


NÍVEL CMM FOCO KPAS

1) Inicial Pessoas competentese heróis

--

2) Repetitivo Processos degerenciamento deprojetos

• Gerenciamento de requisitos• Planejamento do projeto• Visão geral e acompanhamento do

projeto• Gerenciamento de subcontratados• Garantia da qualidade do software• Gerenciamento de configuração


NÍVEL CMM FOCO KPAS

3) Definido Processos de engenhariae apoio

• Foco do processo organizacional• Definição do processo organizacional• Programa de treinamento• Gerenciamento de software integrado• Engenharia de produto de software• Coordenação intergrupos• Revisão conjunta

4) Gerenciado Qualidade do produto e doprocesso

• Gerenciamento quantitativo dosprocessos

• Gerenciamento da qualidade de software 5) Otimizado Melhoramento contínuo do

processo• Prevenção de defeitos• Gerenciamento de mudanças

tecnológicas• Gerenciamento de mudanças no

processo

Qualidade de SoftwareCMM – Capability Matutity Model

CMM é composto de vários modelos com diferentes processos de avaliação:

SW-CMM ou Software CMM, relacionado a área de engenharia de software;SA-CMM ou Software Acquisiton, voltado pra disciplina de aquisição;SE-CMM ou Systems Engineering CMM, relacionado a engenharia de sistemas; P-CMM ou People CMM, direcionado a área de gestão de recursos humanos

Qualidade de SoftwareCMM – Capability Matutity Model

- CMM contempla apenas a forma de representação por estágios através dos níveis de maturidade

- Exige alto custo para empresa aplicar mais de um modelo CMM, por exemplo SW-CMM e SE-CMM

- Não é compatível com a norma ISO/IEC 15540


CMMI = Capability Maturity Model IntegrationCMMI = Capability Maturity Model Integration

Qualidade de SoftwareCMMI – Capability Matutity Model Integration

Criado pelo SEI (Software Engineering Institute), com o objetivo de gerar uma nova versão do CMM a fim de suportar a melhoria de processos e produtos reduzindo a redundância e eliminando as inconsistências quando da utilização de modelos isoladamente


O modelo CMMI é mais abrangente que o CMM. A adição do ‘i’ representa a integração de modelos de capacidade e maturidade, aumentando a complexidade e exigência deste novo modelo.

Integra os modelos CMMs (SW-CMM, SE-CMM, AS-CMM e IPD-CMM) numa estrutura única e tornar o CMM.


CMMI melhora a eficiência, o retorno em investimento e a efetividade, pois integra também disciplinas como engenharia de sistemas e engenharia de software, desenvolvimento de integração de processos e subcontratação.

Permite a utilização da representação estagiada e também contínua, no processo de maturidade, o que o torna compatível com a norma ISO/IEC 15504.


CMMI – Representações

Representação Estagiada: utilizada para verificar o nível de maturidade (Maturity levels) da organização em geral.

Representações Contínua: utilizada para verificar níveis de capacidade (Capability Levels) em grupos de processos.

Qualidade de SoftwareREPRESENTAÇÃO ESTAGIADA:

Qualidade de SoftwareREPRESENTAÇÃO CONTÍNUA

Qualidade de SoftwareUm jeito simples de entender CMMI

Nivel 1 - A matéria-prima entra o

produto sai, mas ninguém sabe dizer ao certo como

ele saiu

Nivel 2 - Com a gestão por projetos os processos são executados de

forma sistematizada

Nivel 3 - Agora é possível conhecer melhor os processos e seu

funcionamento


Nivel 4 - Com o entendimento do

processo é possível medir desempenho e realizar

previsões mais precisas

Nivel5 - Com o conhecimento

adquirido, já é possível elaborar estratégias de melhoria desempenho

dos processos

Um jeito simples de entender CMMI


PSP - Personal software process

É um processo de desenvolvimento de software projetado para ser utilizado por engenheiros de software para a elaboração de projetos individuais.

Em resumo, PSP se propõe a ajudar as pessoas a serem melhores engenheiros de softwares

Benefícios:– melhoria da produtividade: melhor conhecimento e controledos mecanismos e tempos de produção– qualidade dos produtos: resultado do conhecimento dascausas dos erros e do seu controle estatístico


ISO 2500 - SQuaRE

Uma evolução das normas ISO/IEC 9126 (Software product quality) e ISO/IEC 14598 (Software product evaluation)

O Software product Quality Requirements and Evaluation (SquaRE ) é uma série de normas e consiste de cinco divisões :

• ISO/IEC 2500n - Quality Management Division• ISO/IEC 2501n - Quality Model Division• ISO/IEC 2502n - Quality Measurement Division• ISO/IEC 2503n - Quality Requirements Division• ISO/IEC 2504n - Quality Evaluation Division

SPICE = Software Process Improvement and Capability dEterminationSPICE = Software Process Improvement and Capability dEtermination

Qualidade de SoftwareISO 15004

Qualidade de SoftwareISO 15004 - SPICE

Desenvolvida pela ISO/IEC com apoio do SPICE com base em vários padrões como o CMM, o Trillium (Bell) e a Norma 12207.

Não é uma metodologia e sim uma iniciativa para uma padronização Internacional de Avaliação de Processos de Software visando a melhoria de processos e a determinação da capacidade de processos

Foi publicada já como Norma ISO 15504 em março de 2006

Qualidade de SoftwareISO 15004 - SPICE

Inclui um modelo de referência, dividido em cinco categorias de processo e seis níveis de capacitação para cada processo

Categorias:

Cliente-Fornecedor (CUS)Engenharia (ENG)Gerenciamento (MAN)Suporte (SUP)Organização (ORG)

Níveis de capacitação: Nível 0 - Incompleto Nível 1 - Realizado Nível 2 - Gerenciado Nível 3 - Estabelecido Nível 4 - Previsível Nível 5 - Otimizado

Qualidade de SoftwareISO 15004 -Categorias

Qualidade de SoftwareISO 15004 -Categorias

Qualidade de SoftwareISO 15004 - Categorias

Qualidade de SoftwareISO 15004 – Niveis de Capacidade

Qualidade de SoftwareMPS-BR


O MPS-BR acrônimo de Melhoria de Processo de Software Brasileiro foi criado em dezembro de 2003 e é coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX)

O objetivo do programa é estabelecer e disseminar modelos de referência para processos de software que sejam adequado ao perfil de diferentes empresas com diferentes tamanhos e características, principalmente as micro, pequenas e médias empresas

O modelo é baseado nas normas ISO/IEC 12207, ISO/IEC 15504 e no CMMI-DEV. O MPS-BR é uma adaptação do CMMI para a realidade do mercado brasileiro.


MPS estabelece um modelo de referência para processos de software (MR), um processo e um método de avaliação de processos (MA) e também um modelo de negócio (MN) para apoiar a sua adoção pelas empresas brasileiras desenvolvedoras de software.


- O Modelo de Referência MPS define níveis de maturidade que são uma combinação entre processos e sua capacidade seguindo os requisitos da norma ISO/IEC 15504.

- A capacidade do processo é a caracterização da habilidade do processo para alcançar os objetivos de negócio, atuais e futuros;

- A declaração do propósito e os resultados esperados na execução dos processos, permite avaliar e atribuir graus de efetividade na execução dos processos

Lembre-se que quando falamos em maturidade devemos pensar: transparente, medido e gerenciado


MPS-BR e os 7 níveis de maturidade

Qualidade de SoftwareMPS-BR - Como funciona?

Gerência de Requisito

Gerência deProjeto

ProcessosAP 1.1 -

O processo é executado

AP 1.1 - O processo é

gerenciado


CONTROLE DA QUALIDADE

CQS (Controle de Qualidade de Software) é um conjunto planejado e sistemático de todas as ações necessárias para fornecer uma confiança adequada de que o item ou produto está de acordo com os requisitos técnicos estabelecidos.

ANSI/IEEE



Todos os produtos de trabalho tem especificações definidas e mensuráveis com as quais podemos comparar o resultado de cada processo.

Controle de qualidade envolve a monitoração do desenvolvimento do software para assegurar que os procedimentos e os padrões estão sendo seguidos.



Pesquisa realizada pela IBM em 1981 comprovaram que um erro descoberto durante o projeto custava 1,0 Unidade Monetária (UM) para correção. A correção do mesmo erro descoberto imediatamente após o início do teste custaria 6,5 UM's. Já a correção durante o teste aumentaria para15 UM's. Depois da entrega custaria entre 60 e 100 UM's.

Embora os dados tenha mais de 20 anos, a experiência nos mostra que permanecem aplicáveis no contexto atual.



Verificação: assegura a correção e a consistência dos produtos de cada fase do desenvolvimento e, também, com relação as normas fornecidas como entrada para a referida fase.

Validação:avalia a adequação do produto de software aos seus propósitos, assegurando que o mesmo atenda aos requisitos especificados.

Teste: execução do código para produzir resultados a serem analisados.



A abordagem para Controle de qualidade pode ser divido em duas vertentes:

- Revisões de Qualidade

- Avaliação de software com métricas


Revisões de Qualidade

Este é o principal método de validação da qualidade de um processo ou de um produto

As revisões são aplicadas em vários pontos durante a engenharia de software e servem para descobrir erros ou defeitos que podem depois ser removidos

Qualidade de SoftwareRevisões de Qualidade

Existem diferentes tipos de revisão com objetivos diferentes:

Inspeções: Detecta erros detalhados nos requisitos, projeto ou código

Revisões Técnicas Formais: Fornece informações para a gerência sobre progresso geral do projeto. Foco em prazo, planejamento e custos.

Além disso, conduz uma análise técnica dos componentes do produto ou documentação para encontrar inconsistência entre especificação e projeto, código ou documentação e assegurar que os padrões de qualidade foram seguidos

Qualidade de SoftwareInspeções

A realização de uma inspeção implica, além do planejamento, preparação e reunião, numa etapa de apresentação, onde os desenvolvedores fazem um tutorial, de aproximadamente trinta minutos, sobre o material a ser inspecionado, destacando o que deve ser analisado. Na preparação individual, os inspetores devem avaliar o material, de acordo com a lista de critérios previamente estabelecida.

Ao final, a lista de critérios deve ter sido completamente analisada e com respostas consensuais a todas as questões. Deve-se decidir, como resultado: aceitação do produto, ou aceitação com alterações ou rejeição

Qualidade de SoftwareRevisões Técnicas Formais

Walkthrough

Envolve as atividades de planejamento, preparação e uma reunião, com duração em torno de duas horas, com a participação de três a cinco pessoas.

O material a ser avaliado é distribuído previamente, para os avaliadores se prepararem para a reunião, através da identificação dos problemas encontrados.

A reunião é composta de um moderador, de representantes da equipe dos usuários e de desenvolvimento e de avaliadores externos.

Ao final tem-se como resultado: aceitação do produto, ou aceitação com alterações ou rejeição

Qualidade de SoftwareAlgumas diretrizes gerais podem ser seguidas no processo de revisões formais:

Revise o produto e não o produtor Estabeleça uma agenda e a siga Limitar debates Enunciar os problemas, mas não se preocupar em resolver todos

naquele momento Tome nota por escrito Limitar o número de participantes Desenvolver um checklist Rever suas revisões Programar tempo para as reuniões


Avaliação de software com métricas

- Se dedica a derivar um valor numérico para algum atributo de um produto de software ou de processo de software. Comparando os resultados é possível tirar conclusões sobre a qualidade do software ou do processo- As medições permitem fazer previsões de pontos críticos comparando a complexidade entre componentes.



Ao introduzir métricas de software como parte do processo de gerenciamento da qualidade, as organizações devem experimentar descobrir as métricas mais apropriadas para as suas necessidades

As métricas de produtos se dividem em duas classes: Métricas Dinâmicas e Estáticas



Métricas Dinâmicas são coletadas por meio de medições realizadas durante a execução do programa. Elas estão relacionadas diretamente com a eficiência do sistema e confiabilidade.

Exemplo: Tempo de inicialização do sistema, tempo de execução de determinada função



Métricas Estáticas são coletadas por meio de medições realizadas em representações do sistema, como projeto, documentação. Estão diretamente relacionadas a complexidade do sistema, facilidade de compreensão ou manutenção do software

Exemplos: Quantidade de Fan-in/Fan-out, complexidade ciclomática, profundidade de If's

- Fan-in mede o número de funções que chama uma determinada função- Fan-out mede o número de funções que uma determinada função chama.



Outras métricas de softwares podem ser estabelecidas a fim de alcançar qualidade

Disponibilidade: Tempo médio entre falhas, tempo de médio de reparo

Segurança: probabilidade de ocorrências de riscos identificados.


Métricas e Seis Sigmas

“Seis Sigmas é uma metodologia rigorosa e disciplinada que usa dados e análise estatística para medir e aperfeiçoar o desempenho operacional de uma empresa pela identificação e eliminação de defeitos nos processos de fabricação e relacionado a serviços”

iSixSigma



Originalmente foi desenvolvidas pela Motorola para melhorar sistematicamente os processos ao eliminar defeitos

Para alcançar o Seis Sigma, um processo não deve produzir mais de 3,4 defeitos por milhão de oportunidades, implicando em uma norma de qualidade extremamente alta

A metodologia é inspirada pelo ciclo Plan-Do-Check-Act e seus três passos centrais são:

Defina (os requisitos do cliente), Meça (o processo existente e sua saída) e Analise (causa-raíz do defeito)



Para empresas focadas em criar novos processos, dois

passos adicionais são incluídos:

Desenhe detalhes do projeto;

Verifique o modelo definido, sua eficácia;

Para empresas focadas em melhorar processos, dois

passos adicionais são incluídos:

Aperfeiçoe o processo, eliminando causas básicas de

defeitos;

Controle o processo;

Qualidade de SoftwareResumo Qualidade

A Gestão da qualidade de Software está preocupada com a garantia de que o software cumpre seus padrões exigidos, devendo assim ter seus processos de produção bem definidos.

Procedimentos de garantia de qualidade devem ser documentados em um manual da qualidade organizacional

Padrões de software (normas) são um encapsulamento das melhores práticas.

Qualidade de SoftwareResumo Qualidade

Revisões são a abordagem mais amplamente utilizado para avaliar a qualidade do software

A medição de software reúne informações tanto sobre o processo de software quanto do produto de software.

Métricas de qualidade de produtos devem ser usados para identificar componentes potencialmente problemáticos.

Não existem métricas de software padronizadas e universalmente aplicável

( FIM )

Documents

Qualidade de Software.pdf