Representação contínua

Ao escolher a representação contínua para a organização, o modelo CMMI:

• Permite selecionar a ordem e melhoria que mais se adéqua aos objetivos de negócios da organização e diminui as áreas de risco.
• Habilita que haja comparações em uma empresa e entre empresas por área de processo ou pela comparação de resultados em estágio equivalentes.

Há quatro níveis de capacidade, numerados de 0 até 3 (veja a Tabela 1). Cada nível de capacidade corresponde a metas genéricas e a um conjunto de práticas genéricas e específicas, conforme ilustra a Figura.

Representação contínua do CMMI. Fonte: adaptado de SEI (2010, p. 34)

Representação por estágio

Ao escolher a representação por estágio para a organização, o modelo CMMI:

• fornece uma sequência de melhorias, começando com práticas básicas de gerenciamento, progredindo através de um caminho de níveis sucessivos, cada um servindo como um fundamento para o seguinte.
• permite comparações entre organizações pelo uso de níveis de maturidade.
• fornece um valor simples que sumariza resultados avaliados e permite comparações entre organizações.

Há cinco níveis de maturidade, numerados de 1 a 5 (ver Tabela 1). A obtenção de um nível de maturidade permite assegurar que os fundamentos adequados de melhoria foram estabelecidos para o próximo nível de maturidade, permitindo a melhoria incremental dos processos na organização. Esta representação indica a ordem de implementação de cada área de processo, de acordo com o nível de maturidade, que define o caminho associado à melhoria dos processos de uma organização (desde o nível de maturidade inicial até ao nível de maturidade em otimização), conforme ilustra a Figura.

Representação contínua do CMMI. Fonte: baseado em SEI (2010, p. 34)

Representações do CMMI

O CMMI possui duas representações: contínua ou por estágios. Estas representações permitem à organização utilizar diferentes caminhos para a melhoria de seus processos de acordo com seu interesse. O CMMI divide cada estágio em áreas de processo e para cada uma delas são definidos dois conjuntos de metas: as específicas (specific goals) e as genéricas (generic goals). A essas metas, a definição do modelo recomenda práticas genéricas divididas em um conjunto de características comuns.

As metas específicas na maioria das vezes estão focadas no negócio da empresa e buscam alinhar o método CMMI às necessidades próprias. As metas genéricas focam em aspectos inerentes a qualquer empresa e devem ser consideradas para uma melhor implementação da metodologia, de forma a garantir a maximização dos resultados.

O método CMMI não é um processo simples de ser realizado. Exige uma mudança de cultura voltada para o planejamento, a qualidade e o controle dos processos de desenvolvimento de software.

Seleção de uma representação do modelo CMMI

O propósito do CMMI é fornecer um guia para melhorar processos de organizações e sua habilidade de gerenciar o desenvolvimento, aquisição e manutenção de produtos ou serviços de software. O CMMI, através de sua estrutura, ajuda a organização a avaliar sua maturidade organizacional ou sua capacidade na área de processos, estabelecendo prioridades para melhoramentos e sua implementação.

Como vimos, o modelo CMMI apresenta dois caminhos a serem seguidos:

• Contínuo: permite que a organização evolua de forma incremental os processos correspondentes a uma PA (individual) ou a um grupo de área de processos selecionado pela empresa.
• Por estágios (estagiado): a evolução é feita em um grupo deprocessos relacionados que são endereçados ao se implementar grupos de áreas de processo pré-determinados sucessivos.

As representações são importantes, pois são elas que vão determinar o tipo de nível que será usado na organização.

“As duas representações estão associadas com dois tipos de níveis de melhoria: níveis de capacidade e níveis de maturidade. A representação contínua habilita a organização a alcançar níveis de capacidade. A representação por estágios habilita a organização a alcançar níveis de maturidade.”

Fonte: SEI (2010, p. 34, tradução nossa)

Para alcançar um nível em particular, a organização deve satisfazer todas as metas da PA ou todas as metas do conjunto de PAs que estão definidas para serem aprimoradas, independentemente do nível ser de capacidade ou de maturidade. Ambas as representações fornecem maneiras de aprimorar os processos para se alcançar os objetivos corporativos e ambas proveem o mesmo conteúdo em sua essência e usam o mesmo modelo de componentes.

Assim, caro aluno, é importante frisar que são duas formas de se chegar aos mesmos objetivos. Independentemente da representação adotada, os níveis caracterizam a melhoria e a evolução de um estado desorganizado ou imaturo até um estado que usa informações quantitativas para determinar e gerenciar as melhorias a serem implementadas e que irão satisfazer as necessidades de negócios da organização.

Há muitas razões para se selecionar uma representação ou outra. Talvez a organização escolha usar a representação com a qual é mais familiarizada. Se usadas para melhoria de processos ou avaliações, ambas as representações são projetadas para oferecer resultados equivalentes. Vamos listar os critérios de escolha com algumas das possíveis vantagens e desvantagens de como selecionar a adoção de uma entre as duas representações. Para este comparativo, a Tabela deve ser consultada.

Tabela - Níveis de capacidade x Níveis de maturidade do CMMI

Level	Continuous Representation Capability Levels	Staged Representation Maturity Levels
Level 0	Incomplete
Level 1	Performed	Initial
Level 2	Managed	Managed
Level 3	Defined	Defined
Level 4		Quantitatively Managed
Level 5		Optimizing

Fonte: adaptado de SEI (2010, p. 35).

Componentes do modelo CMMI

O modelo (ou constelação) CMMI apresenta conceitos e práticas do CMMI e outros serviços com foco em padrões e modelos consagrados como:

• ITIL - Information Technology Infrastructure Library
• ISO/IEC 20000: Information Technology Service Management
• CobiT - Control Objectives for Information and related Technology
• ITSCMM - Information Technology Services Capability Maturity Model

 

 

 

 

Componentes do modelo CMMI

Fonte: Profit_Image / shutterstock.com

De acordo com SEI (2010, p. 20), o CMMI-SVC cobre as atividades para estabelecer, entregar e gerenciar serviços. Neste contexto, serviço é um produto intangível e que não pode ser armazenado. As práticas e metas do modelo são relevantes para organizações que atuam na entrega de serviços, incluindo a área de TI, defesa, saúde, finanças e transportes.

“Embora as PAs e os processos do modelo descrevam comportamentos considerados como melhores práticas para a maior parte dos provedores de serviços, estes devem ser interpretados e adaptados às restrições e ao ambiente da organização que os utilizam.”

Fonte: SEI (2010, p. 20, tradução nossa)

Conforme ilustra a Figura, o CMMI-SVC, da mesma maneira que os outros modelos CMMI, reúne os componentes:

Componentes do modelo CMMI. Fonte: baseado em SEI (2010, p. 22)

• Áreas de processos (process areas – PAs): é um cluster de práticas relacionadas de uma área que, quando implementadas coletivamente, satisfazem um conjunto de metas consideradas importantes para a melhoria desta área.
• Objetivo da PA (purpose statement): descreve o propósito da PA, sendo um componente informativo.
• Notas introdutórias (introductory notes): seção da PA que descreve os principais conceitos cobertos pela PA, sendo um componente informativo.
• Áreas de processos relacionadas (related process areas): seção da PA que lista referências às PAs relacionadas e reflete os relacionamentos entre as PAs, sendo um componente informativo.
• Metas genéricas (generic goals - GG): são chamadas genéricas porque a mesma meta pode ser aplicada a múltiplas PAs. Descrevem as características que devem estar presentes nos processos institucionalizados que implementam uma PA.
• Prática genérica (generic practice - GP): é chamada genérica porque a mesma prática pode ser aplicada a múltiplas PAs. É associada com uma meta genérica e descreve as atividades que são consideradas importantes para que se possa atingir uma meta genérica de uma PA, contribuindo para a institucionalização dos processos associados à PA.

• Metas específicas (specific goals - SG): ou objetivos específicos, descrevem as características únicas que devem estar presentes para satisfazer a PA.
• Prática específica (specific practice - SP): é a descrição de uma atividade que é considerada importante para que se possa atingir uma meta específica de uma PA.
  • Subprática (subpractice): é uma descrição detalhada que provê diretrizes para que se possa interpretar e implementar uma prática específica ou genérica, sendo um componente informativo.

Visão geral do modelo CMMI

O CMMI (Capability Maturity Model Integration), como outros modelos CMM, fornece um guia a ser usado para o desenvolvimento de processos. Os processos usados em uma organização dependem de muitos fatores, incluindo domínios de aplicação e estrutura e tamanho da organização. O CMMI está organizado em três modelos chamados de constelação, cada um contendo práticas para áreas de desenvolvimento (CMMI-DEV), serviços (CMMI-SVC) e de aquisição (CMMI-ACQ):

• CMMI for development (CMMI-DEV): voltado ao processo de desenvolvimento de produtos e serviços.
• CMMI for acquisition (CMMI-ACQ): voltado aos processos de aquisição e terceirização de bens e serviços.
• CMMI for services (CMMI-SVC): voltado aos processos de empresas prestadoras de serviços.

 

 

 

 

CMMI - Capability Maturity Model Integration

Fonte: <cmmiinstitute.com>

A organização pode usar os modelos CMMI para ajudar a estabelecer objetivos e prioridades do melhoramento de processos, obtendo um guia para garantir estabilidade, processos estáveis e maduros.

O CMMI trabalha com process areas (PAs), por isso é importante fazermos uma distinção entre processos e PAs. Um processo individual é realizado através de atividades distintas e instruções que especificam como o produto de uma atividade é obtido. Um PA especifica metas e práticas comprovadas para que atividades profissionais possam ser executadas, sem especificar como isso deva ser feito. Além disso, o produto da atividade é especificado apenas pelas suas características (PLAYS-IN-BUSINESS.COM, 2010).

Todos os modelos do CMMI 1.3 definem um conjunto de PAs. Um PA especifica metas e práticas comprovadas para que uma atividade profissional possa ser realizada.

Como mostra a figura, o modelo CMMI 1.3 contém 23 PAs, das quais dezesseis são core process areas, comuns a todas as constelações. O modelo CMMI-SVC possui sete PAs específicas e tanto o CMMI-ACQ quanto o CMMI-DEV possuem seis PAs específicas cada.

Constelações CMMI e as PAs. Fonte: Plays-in-business.com (2010).

Saiba mais

Implantação integrada do CMMI-DEV com o CMMI-SVC: desenvolvendo software como serviço

“Os modelos CMMI dividem as práticas em áreas de processo organizadas em 5 níveis. Os níveis servem como um roadmap para melhoria contínua.São 22 áreas de processo no CMMI-DEV, 24 áreas de processo no CMMI-SVC e 22 áreas de processo no CMMI-ACQ.O CMMI-DEV e CMMI-SVC podem ser usados por empresas prestadoras de serviços de desenvolvimento de software e sistemas. O CMMI-ACQ pode ser usado por empresas que contratam serviços de desenvolvimento de software e sistemas.”

Benefícios com a implantação integrada

Fonte: Promove (2016).

“No Brasil, existem 86 empresas avaliadas no CMMI-DEV e 18 no CMMI-SVC (consulta feita em janeiro/2016).”

Fonte: PROMOVE. O que é CMMI? 7 fev. 2016. Disponível em: <http://www.promovesolucoes.com/cmmi>. Acesso em 8 jun. 2017.

CMMI

Trataremos do modelo CMMI (Capability Maturity Model Integration), apresentando o modelos CMM, seus antecedentes históricos, e detalhando seu modelo de maturidade e representações.

 

Modelos CMM para qualidade de processo de software

Fonte: Profit_Image / shutterstock.com

Antecedentes históricos: modelos CMM para qualidade de processo de software

Os modelos CMM (Capability Maturity Model) são construídos a partir do conceito de processo e focam na melhoria dos processos de uma organização. Eles contêm os elementos essenciais de processos efetivos para uma ou mais disciplinas e descrevem uma abordagem evolucionária a partir de processos ad hoc, imaturos, até processos disciplinados e maduros, com melhoria na qualidade e efetividade. Assim, na medida em que a maturidade dos processos evolui em uma empresa, estes passam a ser mais definidos e efetivos.

SEI – Software Enginnering Institute. Fonte: <cmu-sei.github.io>.

O CMM é uma marca registrada do SEI (Software Engineering Institute), sediado na Universidade Carnegie Mellon, em Pittsburgh, EUA. O SEI é um centro de pesquisa e desenvolvimento patrocinado pelo Departamento de Defesa dos Estados Unidos. O SEI realiza pesquisas em software e problemas ligados à cybersecurity, cria e realiza testes com base em tecnologias inovativas e focaliza a transição para soluções maduras para uso global. De acordo com SEI (2010, p. 17), o instituto criou o primeiro modelo CMM destinado para organizações de software em 1995 e o publicou no livro “The Capability Maturity Model: guidelines for improving the software process”.

De acordo com Royce (2002), o modelo inicial CMM desenvolvido pela SEI era especificamente destinado à maturação de processo de software. No entanto, com sua bem sucedida adoção e uso em diferentes domínios, outros modelos CMM foram desenvolvidos para disciplinas e funções mais específicas como engenharia de sistemas, pessoas, desenvolvimento de produto integrado, aquisição de software, dentre outras. Apesar de muitas organizações considerarem estes modelos úteis, eles também apresentavam problemas como sobreposições, inconsistências e dificuldades de integração. Muitas organizações também encontraram conflitos em processos de auditoria e programas de melhoria de software entre os modelos CMM e as normas ISO 9001.

Além destes problemas, alguns casos de práticas CMM apresentaram semelhanças com o modelo tradicional em cascata, com processos excessivamente baseados em gerenciamento. Isto acabou associando organizações que adotavam modelos CMM aos princípios da mentalidade do modelo cascata, dando-lhes uma conotação negativa.

Em função destes problemas, das implicações econômicas a eles associados e com a disseminação de técnicas de desenvolvimento iterativo e de melhores práticas utilizadas na indústria de software, as organizações foram motivadas a adotar uma abordagem baseada em resultados. Todo este cenário impulsionou o início do projeto CMMI.

O projeto CMMI foi formado para solucionar todos estes problemas, notadamente os resultantes do uso de múltiplos modelos CMM. O CMMI buscou integrar muitas das melhores práticas da indústria, desencorajando padrões de alinhamento com a mentalidade do modelo cascata, fazendo deste um melhor padrão a ser seguido. Mas o projeto não se limitou a reunir diferentes modelos em um único. O time que trabalhou no projeto CMMI construiu um framework que acomodou diversas constelações. A Figura ilustra os modelos que foram criados até se chegar à versão 1.3.

História dos modelos CMM. Fonte: SEI (2010, p. 18).

A versão 1.3 iniciou-se em 2008 e em 2010 foram lançados: CMMI for Acquisition, CMMI for Development e CMMI for Services.

A norma ISO/IEC 15504

O início da norma 15504 remonta ao início da década de 1990, quando a ISO iniciou o projeto Spice (Software Process Improvement and Capability Determination) como resultado de um estudo chamado “Necessidades e exigências para uma norma de avaliação de processos de software”. Esse estudo concluiu que era necessária a elaboração de uma norma que fosse aplicável à melhoria de processos e à determinação da capacidade, que culminou com a norma 15504.

A ISO/IEC 15504 presta-se à realização de avaliações de processos de software com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de uma unidade organizacional. Se o objetivo for a melhoria de processos, a unidade organizacional pode realizar uma avaliação com o objetivo de gerar um perfil dos processos que serão usados para a elaboração de um plano de melhorias. A análise dos resultados identifica os pontos fortes, os pontos fracos e os riscos inerentes aos processos. No segundo caso, a organização tem o objetivo de avaliar um fornecedor em potencial, obtendo o seu perfil de capacidade. O perfil de capacidade permite ao contratante estimar o risco associado à contratação daquele fornecedor em potencial para auxiliar na tomada de decisão de contratá-lo ou não (SOFTEX, 2016).

Uma das vantagens desta norma é que ela integra padrões existentes de forma muito flexível. Mas sua aplicação na prática requer muito esforço, tempo e experiência consideráveis, o que complica sua aplicação em micro e pequenas empresas de software.

Os principais benefícios de uma organização com a adoção da norma são:

• Determinação da capacidade dos processos: esta norma é uma ferramenta que permite às empresas avaliar o estado dos seus processos em comparação com as melhores práticas, através da identificação das suas forças, fraquezas e riscos. Com base nesta avaliação, poderão decidir se têm a capacidade para empreender um determinado projeto.
• Melhoria dos processos: as empresas poderão identificar quais os processos que devem melhorar, o que deverá ser feito para este fim e deduzir onde devem investir em primeiro lugar, com vista à obtenção de retornos rápidos e significativos. De uma forma simplificada, podemos afirmar que com o resultado desta avaliação uma organização saberá onde se encontra, para onde se deve dirigir e como deve fazer.

A norma ISO/IEC 12207

O objetivo da norma ISO/IEC 12207 é estabelecer uma estrutura comum para os processos de ciclo de vida de software, com uma terminologia bem definida, que pode ser referenciada pela indústria de software. Koscianski e Soares (2009, p. 164) afirmam que a norma não define um ciclo de vida, pois foi concebida como um modelo que aponta uma meta de ciclo de vida, a partir do qual cada organização define seus próprios processos.

O escopo da ISO/IEC 12207 abrange todo o ciclo de vida de software, desde sua concepção até a sua descontinuidade, incluindo todos os envolvidos com produção, manutenção e operação do software. Os processos da ISO/IEC 12207 são agrupados de acordo com o seu objetivo principal no ciclo de vida de software, resultando em três classes de processos: processos fundamentais ou primários, processos de apoio e processos organizacionais.

Processos da norma ISO/IEC 12207. Fonte: <slideplayer.com.br>

Processos fundamentais (primários)

Os processos fundamentais (ou primários) da norma são os seguintes:

1. Processo de aquisição - define as atividades de aquisição da organização (a organização que adquire um sistema, produto de software ou serviço).
2. Processo de fornecimento - define as atividades do fornecedor da organização (a organização que fornece o sistema, o produto de software ou o serviço do software ao cliente).
3. Processo de desenvolvimento - define as atividades da equipe de desenvolvimento da organização (a organização que define e desenvolve o produto de software).
4. Processo de operação - define as atividades de operação da organização (a organização que fornece o serviço de operar um sistema).
5. Processo de manutenção - define as atividades de manutenção do software da organização (a organização que fornece o serviço de manter o produto de software; isto é, gerir as modificações do produto de software para mantê-lo atualizado e operacional).

Processos de apoio

Os processos de suporte da norma são:

1. Processo de documentação - define as atividades para registrar a informação produzida por um processo do ciclo de vida.
2. Processo de gestão de configurações - define as atividades de gestão de configuração.
3. Processo de garantia da qualidade - define as atividades para assegurar de forma objetiva que os produtos e os processos de software estão em conformidade com os requisitos especificados e conforme o planejado. As revisões conjuntas, as auditorias, a verificação e a validação podem ser usadas como técnicas da garantia de qualidade.
4. Processo de verificação - define as atividades (para o cliente, o fornecedor ou outro stakeholder) para verificar os produtos de software.
5. Processo de validação - define as atividades (para o cliente, o fornecedor ou outro stakeholder) para validar os produtos de software.
6. Processo de revisão - define as atividades para avaliar o estado e os produtos de uma atividade.
7. Processo de auditoria - define as atividades para determinar a conformidade com os requisitos, planejamento e contrato.
8. Processo de resolução de problemas - define um processo para analisar e resolver problemas (incluindo não conformidades), qualquer que seja a sua natureza ou fonte detectadas no decorrer do desenvolvimento, operação, manutenção ou outro processo. 

Processos de apoio. Fonte: Flat Design / shutterstock.com

Processos organizacionais

São quatro os processos organizacionais da norma:

1. Processo de gestão - define as atividades básicas de gestão, incluindo a gestão de projeto, durante o ciclo de vida.
2. Processo de infraestrutura - define as atividades básicas para estabelecer a infraestrutura.
3. Processo de melhoria - define as atividades básicas ligadas ao desempenho da organização (quer seja cliente, fornecedor, equipes de desenvolvimento e manutenção ou gestor de outro processo) para estabelecer a medição, controle e melhoria do ciclo de vida.
4. Processo de formação - define as atividades para proporcionar a formação adequada aos colaboradores.

A implementação da norma consiste na definição ou seleção de um modelo de ciclo de vida de software apropriado ao escopo, magnitude e complexidade do projeto e nas seguintes atividades:

1. execução de documentação dos resultados, de acordo com o processo de documentação;
2. colocação dos resultados sob o processo de gerência de configuração;
3. execução do controle de alterações;
4. documentação e resolução de não-conformidades e problemas encontrados nos produtos de software e tarefas, de acordo com o processo de resolução de problema;
5. execução dos processos de apoio, conforme especificado no contrato;
6. seleção, adaptação e utilização de padrões, métodos, ferramentas e linguagens de programação de computador;
7. desenvolvimento dos planos para conduzir as atividades do processo de desenvolvimento.

Normas ISO 25000

As normas ISO/IEC 9126, que tratam da qualidade do produto e ISO/IEC 14598, que tratam de avaliação de produto de software, estão integradas na série de normas ISO/IEC 25000, conhecida como SQuaRE (Software product Quality Requirements and Evaluation).

O projeto SQuaRE reorganizou o material existente nas duas séries de normas, mas não realizou mudanças significativas no material preexistente. Segundo Koscianski e Soares (2009, p. 206),

• a norma abrange amplamente aspectos relativos à qualidade de produto de software e define uma base para se definir tanto o modelo quanto a avaliação;
• os documentos oferecem um cunho didático, elencando exemplos;
• os documentos resultaram de um esforço e consenso de centenas de pesquisadores, representando uma soma de experiências;
• outros modelos de qualidade podem ser mapeados para o modelo SQuaRE.

SquaRE – Série de normas. Fonte:<pt.slideshare.net>.

As normas ISO/IEC 25000 têm seu núcleo principal composto por cinco divisões:

• ISO/IEC 2500n – Divisão Gestão da Qualidade
• ISO/IEC 2501n – Divisão Modelo de Qualidade
• ISO/IEC 2502n – Divisão Medição da Qualidade
• ISO/IEC 2503n – Divisão Requisitos de Qualidade
• ISO/IEC 2504n – Divisão Avaliação da Qualidade

Norma ISO 9126 – Modelo de qualidade de software

Qualidade de software

Fonte: Tashatuvango / shutterstock.com

A norma ISO 9126 define um conjunto de quesitos que visam padronizar a avaliação da qualidade de software. A norma divide-se em quatro partes (conforme ilustra a Figura abaixo), sendo a primeira uma visão geral do modelo de qualidade e as outras três os grupos de métricas definidas para este modelo:

• Parte 1: Modelo de qualidade
• Parte 2: Métricas externas
• Parte 3: Métricas internas
• Parte 4: Métricas de qualidade em uso

Visão geral do modelo de qualidade ISO 9126. Fonte: <cdn.goconqr.com>

Qualidade externa se refere ao produto final como observado pelo usuário, e qualidade interna se relaciona com a estrutura e as características do produto relativas ao seu projeto e à sua construção.

A norma ISO 14598 recomenda a utilização do modelo de qualidade proposto na norma ISO 9126, que é o mais difundido na indústria. A norma 9126 tem foco na qualidade do produto de software e propõe atributos de qualidade distribuídos em seis características principais, cada qual, por sua vez, divididas em subcaracterísticas, conforme ilustra a Figura.

Modelo de Qualidade - ISO 9126 (parte 1). Fonte: NBR ISO/IEC 9126-1:2003 (p. 7)

Conforme podemos observar na Figura acima, todas as características de qualidade apresentam uma subcaracterística em comum: a conformidade. De acordo Koscianski e Soares (2009, p. 210), com a conformidade pode-se abranger atributos como padrões internos da organização ou exigências de legislação aplicáveis. É utilizada para avaliar o quanto o software respeita requisitos legais, padronizações ou normalizações aplicáveis.

A Norma NBR ISO/IEC 9126-1:2003 (p. 8-11), na parte 1, que trata do modelo de qualidade, define assim as seis características de qualidade:

Certificação ISO. Fonte: Aquir / shutterstock.com

1. “Funcionalidade: Capacidade do produto de software de prover funções que atendam às necessidades explícitas e implícitas, quando o software estiver sendo utilizado sob condições especificadas. Suas subcaracterísticas são:
   • Adequação: capacidade do produto de software de prover um conjunto apropriado de funções para tarefas e objetivos do usuário especificados;
   • Acurácia: capacidade do produto de software de prover, com o grau de precisão necessário, resultados ou efeitos corretos ou conforme acordados;
   • Interoperabilidade: capacidade do produto de software de interagir com um ou mais sistemas especificados;
   • Segurança de acesso: capacidade do produto de software de proteger informações e dados, de forma que pessoas ou sistemas não autorizados não possam lê-los nem modificá-los e que não seja negado o acesso às pessoas ou sistemas autorizados;
   • Conformidade relacionada à funcionalidade: capacidade do produto de software de estar de acordo com normas, convenções ou regulamentações previstas em leis e prescrições similares relacionadas à funcionalidade.
2. Confiabilidade:capacidade do produto de software de manter um nível de desempenho especificado, quando usado em condições especificadas. Suas subcaracterísticas são:
   • Maturidade: capacidade do produto de software de evitar falhas decorrentes de defeitos no software;
   • Tolerância a Falhas: capacidade do produto de software de manter um nível de desempenho especificado em casos de defeitos no software ou de violação de sua interface especificada;
   • Recuperabilidade: capacidade do produto de software de restabelecer seu nível de desempenho especificado e recuperar os dados diretamente afetados no caso de uma falha;
   • Conformidade relacionada à confiabilidade: capacidade do produto de software de estar de acordo com normas, convenções ou regulamentações relacionadas à confiabilidade.
3. Usabilidade: Capacidade do produto de software de ser compreendido, aprendido, operado e atraente ao usuário, quando usado sob condições especificadas. Suas subcaracterísticas são:
   • Inteligibilidade: capacidade do produto de software de possibilitar ao usuário compreender se o software é apropriado e como ele pode ser usado para tarefas e condições de uso específicas;
   • Apreensibilidade: capacidade do produto de software de possibilitar ao usuário aprender sua aplicação;
   • Operacionalidade: capacidade do produto de software de possibilitar ao usuário operá-lo e controlá-lo;
   • Atratividade: capacidade do produto de software de ser atraente ao usuário;
   • Conformidade relacionada à usabilidade: capacidade do produto de software de estar de acordo com normas, convenções, guias de estilo ou regulamentações relacionadas à usabilidade.
4. Eficiência : capacidade do produto de software de apresentar desempenho apropriado, relativo à quantidade de recursos usados, sob condições especificadas. Suas subcaracterísticas são:
   • Comportamento em relação ao tempo: capacidade do produto de software de fornecer tempos de resposta e de processamento, além de taxas de transferência, apropriados, quando o software executa suas funções, sob condições estabelecidas;
   • Utilização de Recursos: capacidade do produto de software de usar tipos e quantidades apropriados de recursos, quando o software executa suas funções sob condições estabelecidas;
   • Conformidade relacionada à eficiência: capacidade do produto de software de estar de acordo com normas e convenções relacionadas à eficiência.
5. Manutenibilidade : Capacidade do produto de software de ser modificado. As modificações podem incluir correções, melhorias ou adaptações do software devido a mudanças no ambiente e nos seus requisitos ou especificações funcionais. Suas subcaracterísticas são:
   • Analisabilidade: capacidade do produto de software de permitir o diagnóstico de deficiências ou causas de falhas no software, ou a identificação de partes a serem modificadas;
   • Modificabilidade: capacidade do produto de software de permitir que uma modificação especificada seja implementada;
   • Estabilidade: capacidade do produto de software de evitar efeitos inesperados decorrentes de modificações no software;
   • Testabilidade: capacidade do produto de software de permitir que o software, quando modificado, seja validado;
   • Conformidade relacionada à manutenibilidade: capacidade do produto de software de estar de acordo com normas ou convenções relacionadas à manutenibilidade.
6. Portabilidade : capacidade do produto de software de ser transferido de um ambiente para outro. Suas subcaracterísticas são:
   • Adaptabilidade: capacidade do produto de software de ser adaptado para diferentes ambientes especificados, sem necessidade de aplicação de outras ações ou meios além daqueles fornecidos para essa finalidade pelo software considerado;
   • Capacidade para ser instalado: capacidade do produto de software para ser instalado em um ambiente especificado;
   • Coexistência: capacidade do produto de software de coexistir com outros produtos de software independentes, em um ambiente comum, compartilhando recursos comuns;
   • Capacidade para Substituir: capacidade do produto de software de ser usado em substituição a outro produto de software especificado, com o mesmo propósito e no mesmo ambiente;
   • Conformidade relacionada à portabilidade: capacidade do produto de software de estar de acordo com normas ou convenções relacionadas à portabilidade.”

Norma ISO 14598 - Avaliação de produtos de software

A avaliação de produtos de software é definida como uma operação técnica que consiste em elaborar um julgamento de uma ou mais características de um produto de software de acordo com um procedimento definido.

Fonte: Norma ISO 14598

Desenvolver software com qualidade tem sido um grande desafio, pois estabelecer prazos, especificar requisitos, estimar custos e recursos e cumprir todos esses quesitos não são atividades simples. É necessário um controle muito grande dos processos que envolvem a fabricação do software, desde a sua criação até a sua completa instalação no cliente. Um desafio ainda maior é conseguir identificar, ao final do desenvolvimento, se o produto de software atende aos requisitos previamente estabelecidos. Com a finalidade de auxiliar nestas complexas tarefas, processos de avaliação de produtos de software foram desenvolvidos e consolidados na Norma ISO 14598.

A norma ISO 14598 traz macroprocessos de avaliação de qualidade de produtos de software que podem ser instanciados para avaliação do produto por desenvolvedores ou agentes externos, dependendo dos objetivos e da infraestrutura da organização. A Figura mostra o processo proposto na ISO 14598-5 para avaliação por agentes externos.

Processo de avaliação de software - ISO 14598-5. Fonte: <www.goconqr.com>.

Cada fase descrita na Figura possui uma série de recomendações, porém, como toda norma, ela recomenda o que fazer mas não explica como deve ser feito. As principais etapas são:

• Estabelecimento dos requisitos da avaliação, em que os requisitos do software são recebidos e os requisitos da avaliação são definidos.
• Especificação da avaliação, no qual utiliza-se a descrição do produto e os requisitos da avaliação para definir o que será contemplado na avaliação.
• Projeto da avaliação, no qual os dados utilizados na etapa anterior são agregados ao conhecimento de métodos de avaliação e projeta-se o plano de avaliação.
• Execução da avaliação, em que são utilizadas ferramentas específicas para se colocar o plano de avaliação em prática.
• Conclusão da avaliação, quando o relatório de avaliação é gerado, todos os resultados obtidos são sintetizados e um parecer é emitido para o requisitante da avaliação.

As etapas “estabelecimento dos requisitos da avaliação” e “especificação da avaliação” são cruciais da avaliação, pois representam o momento em que é definido o que se medirá no software e os níveis aceitáveis dessas medidas.

Normas de qualidade ISO

Modelos e normas de qualidade de software

A qualidade de software é um aspecto da engenharia de software que vem evoluindo, tanto em relação à qualidade do processo (da concepção à construção e manutenção) quanto em relação à qualidade do produto (o software em si).

Qualidade de software, de acordo com Pressman (2011, p. 360) se refere a “[...] uma gestão de qualidade efetiva aplicada de modo a criar um produto útil que forneça valor mensurável para aqueles que o produzem e para aqueles que o utilizam”.

Qualidade não é uma fase do ciclo de desenvolvimento de software, mas um integrante fundamental de todas as fases. Portanto, é necessário um planejamento adequado para que metas de qualidade de software sejam atingidas. Para isso são necessários modelos, padrões, procedimentos e técnicas para atingir as metas de qualidade propostas. Assim, todas as etapas do ciclo de vida de engenharia de software devem ser contempladas com atividades que visam garantir a qualidade tanto do processo quanto do produto.

Um dos primeiros modelos de qualidade de software é o que James A. McCall (2002) propõe como métricas para qualidade de software. Conhecidos como fatores da qualidade, eles avaliam o software em três pontos distintos: operação do produto, transição do produto e revisão do produto, conforme ilustra a figura.

Fatores de qualidade do software de McCall. Fonte: baseado em Pressman (2011, p. 362)

• Operação: refere-se às características relativas ao uso do produto. Envolve os critérios de qualidade correção, confiabilidade, eficiência, integridade e usabilidade.
• Revisão: refere-se à capacidade do produto ser modificado e evoluído. Envolve os critérios de qualidade manutenibilidade, flexibilidade e testabilidade.
• Transição: refere-se à adaptabilidade a novos e diferentes ambientes. Envolve os critérios portabilidade, reusabilidade e interoperabilidade.

Naturalmente surgiram outros modelos e normas para avaliação da qualidade do produto de software, notadamente as homologadas pela ISO (International Organization for Standardization) juntamente à IEC (International Electro-Technical Commission). A abordagem das normas da série ISO fundamenta-se na documentação do sistema de qualidade, estabelecendo a visão da empresa com relação aos interesses e necessidades dos clientes e, por isso, resulta na percepção deles. A abordagem da ISO para qualidade é considerada uma das mais antigas e bem estabelecidas para a indústria em geral e tem ampliado seu espaço nas empresas de software.

Além do objetivo principal de alcançar a qualidade, as organizações podem almejar a obtenção de certificações de qualidade que são adquiridas por meio da utilização destas normas e modelos.

De acordo com Koscianski e Soares (2009, p. 156), as normas da família ISO 9000 foram desenvolvidas para aplicação em qualquer organização em qualquer ramo de atividade, notadamente do setor produtivo, que deseja realizar o controle de qualidade dos produtos ou serviços oferecidos.

Curiosidade

ISO (International Organization for Standardization)

Fonte: <www.iso.org>

A ISO (International Organization for Standardization ou, em português, Organização Internacional de Normalização) é formada por representantes de diversos países, cada um representado por um organismo de normas, testes e certificação. O ANSI (American National Standards Institute) é o representante ISO dos Estados Unidos e no Brasil a ISO é representada pela ABNT (Associação Brasileira de Normas Técnicas). A ABNT é uma organização que apoia o desenvolvimento de normas consensuais e providencia estrutura e mecanismos a fim de que grupos industriais ou de produtos se juntem para estabelecer um consenso e desenvolver diretivas de qualidade.

Fonte: KOSCIANSKI, André; SOARES, Michel S. Qualidade de software. São Paulo: Novatec, 2009.

“A família das normas ISO 9000 nasceu em 1987 e evoluiu nos anos de 1994, 2000, 2005 e 2008 incorporando as melhores práticas, lições aprendidas, inovações e evolução requeridas pelas empresas e mercado.

A NBR ISO 9001:2008 Sistemas de Gestão da Qualidade faz parte da família de normas ISO 9000 e estabelece requisitos que auxiliam a melhoria dos processos internos, a maior capacitação dos colaboradores, o monitoramento do ambiente de trabalho, a verificação da satisfação dos clientes, colaboradores e fornecedores, em um processo contínuo de melhoria do sistema de gestão da qualidade. Aplica-se a campos distintos dentre eles: materiais, de produtos, de processos e serviços.”

Fonte: ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO (SOFTEX). MPS.BR - Melhoria de Processo do Software Brasileiro. Brasília: Softex, 2016. p. 15. Disponível em: <www.softex.br>. Acesso em: 8 jun. 2017.

Garantia da qualidade

A garantia da qualidade (quality assurance) pode ser definida como “[...] o conjunto de atividades de apoio para fornecer confiança de que os processos estão estabelecidos e são continuamente melhorados para produzir produtos que atendam as especificações e que sejam adequados para o uso pretendido”.

Fonte: Hernaski (2010, s/p).

De acordo com Hernaski (2010), para garantir a qualidade é necessário obtê-la tanto no processo quanto no produto. A qualidade no processo pode ser quantificada através de métricas e no produto pode ser obtida através de técnicas de verificação e validação. Para isso podem ser utilizadas avaliações normatizadas, como a ISO 9000, auditorias, inspeções formais, testes, revisões, análise estatística de controle do processo etc.

De acordo com Campos (2008), os conceitos e a aplicação dos termos controle da qualidade (quality control) e garantia da qualidade (quality assurance) costumam ser confundidos. Embora usados como sinônimos, ambos os termos têm propósitos diferentes. Vejamos o Quadro, que mostra a diferença entre estas duas atividades.

QUADRO – Garantia da qualidade x controle da qualidade

Garantia da qualidade

Controle da qualidade

a) Garante que o processo é definido e apropriado. b) Metodologia e padrões de desenvolvimento são exemplos de garantia da qualidade. c) É orientada a processo. d) É orientada à prevenção. e) Foco em monitoração e melhoria de processo. f) As atividades são focadas no início das fases no ciclo de vida de desenvolvimento de software. g) Garante que você está fazendo as coisas certas e da maneira correta.

a) As atividades focam na descoberta de defeitos em itens específicos. b) Um exemplo de controle da qualidade poderia ser: “Os requisitos definidos são os requisitos certos?”. c) É orientado a produto. d) É orientado à detecção. e) Inspeções e garantia de que o produto de trabalho atenda aos requisitos especificados. f) As atividades são focadas no final das fases no ciclo de vida de desenvolvimento de software. g) Garante que os resultados do seu trabalho são os esperados conforme requisitos.

Fonte: Campos (2017).

Pode-se afirmar que o teste de software é uma das atividades de controle da qualidade, ou seja, ele é orientado a produto e está dentro do domínio do controle da qualidade.

Qualidade e o ciclo de vida do produto

O conceito de ciclo de vida do produto está vinculado ao aspecto satisfação das necessidades do cliente. A qualidade de um produto é o resultado das características por ele adquiridas ao longo de todo o seu ciclo de vida, podendo, de forma resumida, envolver:

Ciclo de vida do produto e seus pontos importantes

Fonte: Siqueira (2011)

• Qualidade de projeto, que indica se o produto atende aos critérios de qualidade exigidas pelo consumidor e está em conformidade com os requisitos especificados no projeto.
• Qualidade de serviços, que se refere às facilidades a serem oferecidas ao consumidor do produto durante o período em que estiver em uso ou operacional, como assistência técnica, orientação de uso etc.
• Qualidade de uso, que se refere à soma da qualidade do projeto com a de serviços.

No processo de desenvolvimento de produtos, é importante que se promova o trabalho em equipe de forma concorrente, simultânea e colaborativa, reduzindo o ciclo de desenvolvimento do produto. Através da disseminação de poderes e responsabilidades aos indivíduos e às equipes, e da visibilidade plena de cada passo por trás do ciclo de vida, garante-se que o propósito do produto/serviço seja mantido e esteja alinhado à estratégia organizacional.

Ao observarmos o ciclo de vida de um produto ou serviço, destacam-se o período de sua criação e o período de seu declínio, indicando a necessidade de renovação ou substituição. Mas entre estes dois pontos há um intervalo de tempo que requer ações de melhoria que afetam a qualidade, a produtividade e os custos de produção. Nesse intervalo há que se buscar soluções para problemas que eventualmente ocorrem na linha de produção e na logística. Pela inovação e pela melhoria contínua, a organização pode buscar diferenciais competitivos, prolongando e ampliando suas vantagens. A Figura 8 ilustra este processo.

Todos estes conceitos podem ser aplicados às empresas e equipes envolvidas no desenvolvimento de software. O Quadro faz uma comparação entre organizações imaturas e maturas quanto às suas tomadas de decisões em assuntos relacionados à qualidade de software.

QUADRO – Maturidade das organizações quanto à qualidade

Organização imatura	Organização madura
Processos de software improvisados pelos participantes durante o curso do projeto.	Atividades planejadas de acordo com o processo existente.
Mesmo que um processo de software tenha sido especificado, ele não é seguido.	Processo disciplinado é consistentemente seguido porque os participantes entendem o seu valor e existe a infraestrutura necessária para suportá-lo.
Gerentes focados em resolver problemas imediatos.	Gerentes monitoram a qualidade do produto e do processo.
Cronogramas e orçamentos estourados, e não baseados em estimativas realistas.	Cronogramas e orçamentos baseados em dados históricos e realísticos.
Quando prazos não realísticos são impostos à equipe de desenvolvimento, a qualidade e funcionalidade do produto ficam comprometidas.	Processo definido atualizado quando necessário. As melhorias são descobertas através de testes-piloto controlados e da análise da relação custo/benefício.
Não há base para julgar a qualidade do produto ou para resolver problemas no processo ou produto.	Base quantitativa para julgar qualidade e para analisar problemas com o produto ou processo.
Qualidade do produto imprevisível.	Capacidade de gerenciar o desenvolvimento e manutenção dos processos e projetos.
Atividades que visam garantir a qualidade dos produtos (revisões e testes) são eliminadas quando o projeto está atrasado.	Papéis e responsabilidades estão claros dentro da organização.

Fonte: Adaptado de SEI (2010).

Qualidade total

“Qualidade Total é a preocupação com a qualidade em todas as atividades da empresa, buscando sistematicamente o nível ‘zero defeito’, através da melhoria contínua dos processos de produção.” (OLIVEIRA et al., 2004; p. 94).

Total quality management (gestão de qualidade total - GQT).
Fonte: <blogspot.com>.

O termo TQM (total quality management) ou gerenciamento da qualidade total, amplamente usado nas organizações, descreve uma abordagem para a melhoria da qualidade em todos os níveis e setores. De acordo com Periard (2013), é um conceito que distribui a responsabilidade pelo alcance de patamares de qualidade para todas as pessoas envolvidas, e não apenas aos dirigentes e gestores. Desta forma, a qualidade total tem como um dos pilares o empowerment ou empoderamento das pessoas, que atribui a elas autonomia para a tomada de decisões relativas à qualidade de forma que possam solucionar questões emergentes de forma mais ágil, chegando às soluções mais rapidamente.

De acordo com Reid e Sanders (2010), TQM tem como foco a identificação das raízes dos problemas de qualidade e sua solução a partir da fonte destes problemas, ao invés de apenas inspecionar o produto depois de pronto. Os autores indicam sete princípios básicos para o TQM:

• Customer focus: Foco no cliente: a qualidade pode ser medida pela satisfação do cliente ou mesmo quando se excede esta satisfação, a partir de suas reais necessidades.
• Continuous improvement: Melhoria contínua: denominada kaizen pelos japoneses, requer esforços contínuos da organização, mesmo depois que a qualidade tenha sido satisfatoriamente atingida. Como nunca se atinge a perfeição, é necessário que o desempenho seja avaliado e medições sejam realizadas visando sua constante melhoria.
• Employee empowerment: Empoderamento dos funcionários: conceito que incentiva as pessoas a buscarem problemas de qualidade e quando os encontram – são premiadas, não punidas. Além disso, há o incentivo para que busquem aprimorar a qualidade dos processos.
• Use of quality tools: Uso de ferramentas de qualidade: como o TQM atribui grande responsabilidades às pessoas, que devem identificar e corrigir problemas de qualidade, elas precisam ser adequadamente treinadas e capacitadas. Para isso, há diversas ferramentas de qualidade que as ajudam a avaliar e medir a qualidade, mas ainda é necessário que saibam como interpretar os resultados e como fazer para corrigir os problemas.
• Product design: Projeto do produto: para que os requisitos dos clientes possam ser traduzidos para requisitos técnicos formais há as ferramentas QFD (quality function deployment). Essas ferramentas permitem visualizar as relações entre as variáveis envolvidas no projeto do produto, confrontando os requisitos técnicos com os requisitos do cliente.
• Process management: Gerenciamento de processos: de acordo com o TQM, a qualidade do produto é derivada da qualidade do processo. Desta forma, a qualidade deve estar presente nos processos.
• Managing supplier quality: Gerenciamento da qualidade dos fornecedores: TQM estende o conceito de qualidade aos fornecedores, de forma que estes devam ser selecionados caso adotem práticas de qualidade em seus processos. Isso busca assegurar que os materiais/serviços entregues tenham sido fabricados/criados com qualidade e não irão comprometer o produto.

Desta forma, uma organização moderna enxerga a qualidade como uma união de conceitos que reúnem adequação ao uso, conformidade com as especificações e qualidade total nos processos. As organizações devem buscar produzir produtos e serviços com qualidade total como uma condição de competitividade e sobrevivência, e não apenas como uma estratégia de diferenciação de mercado.

Qualidade de processo

A qualidade no processo, de acordo com Oliveira et al. (2004), procura identificar a má qualidade o quanto antes, o que é feito pelo controle da conformidade à especificação, e corrigir o problema, evitando que continue o desperdício até o fim. Os autores afirmam que, para garantir a conformidade à especificação ao longo do processo, é necessário especificar como executar atividades e seus resultados e controlar sistematicamente todo esse processo que irá atingir a qualidade.

“A qualidade de processo é a rigorosa especificação dos processos que serão realizados na produção de um bem ou serviço, incluindo as faixas de tolerância desejadas em relação aos resultados.” (OLIVEIRA et al., 2004; p. 93)

Aqui deve-se levar em consideração a definição de qualidade como adequação ao uso, o que significa que o produto deve ter as funções necessárias à solução dos problemas do cliente e, ainda, atender aos critérios de desempenho, facilidade de uso, confiabilidade etc. Por exemplo, pode-se imaginar a existência de um cliente que vai receber o bem ou serviço, cujas necessidades de uso precisam ser satisfeitas.

É preciso ainda identificar e eliminar as fontes da má qualidade mediante alterações apropriadas no processo, ou seja, nas especificações de suas atividades.

Cliente satisfeito x cliente insatisfeito

Fonte: <qualiwork.pt>.

Oliveira et al. (2004) propõem uma lista de perguntas que realçam essa perspectiva e apontam as consequências para os processos de produção:

• Quem são os clientes visados?
• O que desejam e necessitam?
• O que tais necessidades significam para os produtos e processos?
• Quais características devem ter um produto/serviço para satisfazê-las?
• Como fabricar esse produto ou prestar esse serviço?

Com isso, vê-se que o conceito de adequação ao uso também se dirige para a qualidade no processo. A qualidade não pode ser alcançada apenas com a verificação de conformidade dos resultados parciais em pontos escolhidos do processo. A qualidade no processo é mais que isso. Exige que os processos sejam concebidos de forma a maximizar a produção de bens e serviços que atendam às especificações.

Assim nasce a qualidade total. A preocupação é garantir qualidade em cada atividade realizada no processo de produção e evitar erros, de modo a produzir certo da primeira vez até eliminar a necessidade de inspeções, as quais perdem sentido quando cada etapa entrega seus resultados sem defeitos para a etapa seguinte e se implanta um processo explícito para melhorar sistematicamente os processos, de modo a sempre aumentar a qualidade no processo.

Conceitos relacionados à qualidade de software

Qualidade do produto

Hoje sabemos que a qualidade é apreciada e desejada por todos em diversos setores, desde o atendimento na prestação de um serviço até os produtos de tecnologia amplamente utilizados. Interessante é nos perguntarmos: como chegamos a este ponto?

Fazendo um retrospecto, houve época em que a qualidade estava associada primordialmente à inspeção, que utilizava mecanismos para medir se o produto estava em conformidade com algum determinado padrão. De acordo com Garvin (2002, p. 44),

[...] posteriormente, passou-se a buscar, através de instrumentos e técnicas estatísticas, conseguir um controle estatístico da qualidade. Em uma etapa posterior, o movimento da qualidade foi mais na direção de se encontrar instrumentos que visassem assegurar a sua própria garantia. Para isso, todo o processo produtivo passou a ser coordenado, desde o projeto do produto até a sua chegada ao mercado consumidor. Finalmente, a ênfase voltou-se para o gerenciamento estratégico da qualidade, no qual a preocupação maior é poder concorrer em um determinado mercado, buscando-se não só satisfazer as necessidades do consumidor, mas também a do próprio mercado. A metodologia que vai dar sustentação a essa nova mentalidade baseia-se no planejamento estratégico, no qual, sob a liderança da direção, todos na empresa passam a ter a oportunidade de serem também agentes da qualidade.

“A qualidade de produto é a rigorosa definição das características relevantes do produto, estabelecendo os atributos e as variáveis que deve conter, cuja dimensão deve ser assegurada. A especificação é o documento que formalizará essas definições.” (OLIVEIRA et al., 2004, p. 92).

Programa Brasileiro de Avaliação de Conformidade

Fonte: <www.inmetro.gov.br>.

De acordo com Oliveira et al. (2004), há duas formas de se alcançar a conformidade de um produto à sua especificação. Uma é a inspeção final rigorosa que segrega os produtos sem qualidade. Essa é uma alternativa cara, já que espera o consumo de material, capital e mão de obra para, só ao final do processo produtivo, separar o bom produto. Gera imenso desperdício. A outra possibilidade é introduzir a qualidade ao longo do processo produtivo, desde a verificação da conformidade dos insumos até suas especificações, evitando a cada fase a má qualidade.

Ainda de acordo com os autores, o ideal é que qualidade de produto seja aplicada em conjunto com a qualidade de processo. Para tornar isso viável, surgiram os sistemas formais da qualidade, como por exemplo, a série de normas produzidas pela ISO (International Organization for Standardization).

Qualidade de acordo com o PMI/PMBOK

De acordo com o PMBoK (Project Management Body of Knowledge do PMI - Project Management Institute), os processos de gerenciamento da qualidade do projeto detêm todas as atividades da organização executora que determinam as responsabilidades, os objetivos e as políticas de qualidade, de modo que o projeto atenda às necessidades que motivaram sua realização.

Para o PMBOK 5ª edição (2013, p. 227), a área de gerenciamento da qualidade do projeto

[...] usa as políticas e procedimentos para a implementação, no contexto do projeto, do sistema de gerenciamento da qualidade da organização e, de maneira apropriada, dá suporte às atividades de melhoria do processo contínuo como empreendido no interesse da organização executora. O gerenciamento da qualidade do projeto trabalha para garantir que os requisitos do projeto, incluindo os requisitos do produto, sejam cumpridos e validados.

O guia trabalha com três processos para o gerenciamento da qualidade:

1. Planejar o gerenciamento da qualidade, que tem como objetivo identificar os requisitos e/ou padrões da qualidade do projeto e suas entregas, além de documentar como o projeto fará a demonstração de conformidade com os requisitos e/ou padrões de qualidade.
2. Realizar a garantia da qualidade, que visa realizar a auditoria dos requisitos de qualidade e dos resultados das medições do controle de qualidade, de forma a garantir o uso dos padrões de qualidade e das definições operacionais adequadas.
3. Realizar o controle da qualidade, que tem como meta monitorar e registrar os resultados da execução das atividades de qualidade para realizar a avaliação do desempenho e recomendar as mudanças que se fizerem necessárias.

A abordagem do gerenciamento da qualidade do PMBOK apresenta compatibilidade com os padrões de qualidade da ISO. Todos os projetos devem ter um plano de gerenciamento da qualidade e as equipes devem segui-lo, mantendo dados que sejam capazes de comprovar a conformidade com este plano.

Ainda de acordo com o PMBOK (2013, p. 229), para alcançar a compatibilidade com a ISO, as abordagens de gerenciamento da qualidade buscam reconhecer a importância dos itens listados a seguir.

• Satisfação do cliente: devem ser realizadas ações corretas ao longo do projeto para que as expectativas e os requisitos do cliente sejam atendidos. Essas ações incluem uma combinação de conformidade com os requisitos e adequação ao uso, de forma que o projeto crie o produto especificado e que este atenda às necessidades reais.
• Prevenção ao invés de inspeção: a qualidade deve seguir um planejamento e não passar por inspeções no gerenciamento ou nas entregas do projeto. “O custo de prevenção dos erros é geralmente muito menor do que o custo de corrigir tais erros quando eles são encontrados pela inspeção ou durante o uso.”
• Melhoria contínua: o ciclo PDCA pode ser usado como base para a melhoria da qualidade, mas outras abordagens como o gerenciamento da qualidade total (GQT), Seis Sigma e Lean SeisSigma podem contribuir para o aprimoramento da qualidade do gerenciamento do projeto e do produto. Além disso, modelos de melhoria de processos como Malcolm Baldrige, OPM3 e CMMI podem ser utilizados.
• Responsabilidade da gerência: embora o sucesso do projeto dependa do envolvimento de todos os membros da equipe do projeto, o comprometimento da alta direção é essencial para o suprimento dos recursos adequados, nas capacidades adequadas.
• Custo da qualidade (CDQ): este custo está relacionado ao custo total do trabalho de conformidade e do trabalho de não conformidade, já que há a possibilidade de que parte do trabalho requerido não seja realizado ou não seja executado corretamente. Os custos da qualidade do trabalho estão implícitos às atividades ao longo de todo o ciclo de vida da entrega. Os patrocinadores podem decidir investir na melhoria da qualidade do produto, nas áreas de trabalho de conformidade que atuam para impedir defeitos ou mitigar os custos através da inspeção de itens não-conformes. Além disso, o CDQ pós-projeto deve ser considerado de forma que revisões e modelos apropriados possam ser aplicados, com recursos financeiros previstos para tal.

Curiosidade     

Como tudo começou

Em 1983, na tentativa de documentar e padronizar as práticas que são normalmente aceitas na gerência de projetos, foi publicado o artigo “Ethics, Standards, and Accreditation Committee Final Report”. A primeira edição do “A Guide to the Project Management Body of Knowledge (PMBOK Guide)” foi publicada em 1996 pelo Project Management Institute (PMI), seguida pela segunda edição em 2000.

Em 2004, o Guia PMBOK Terceira Edição foi publicado com maiores mudanças, considerando as edições anteriores. A quarta edição (lançada em 2008) é normatizada pelas normas ANSI/PMI 99-001-2008 e IEEE 1490-2011.

A última versão do Guia PMBOK é a quinta edição, que foi publicada em 2013 em inglês. Traduções estão disponíveis em árabe, chinês, francês, alemão, italiano, japonês, coreano, português, russo e espanhol.