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.

O que é qualidade de software

Para definirmos qualidade de software vamos começar com uma definição de qualidade de uma forma mais geral indicada por Pressman (2011, p. 359):

Qualidade é um conceito complexo e multifacetado que pode ser descrito segundo cinco pontos de vista diferentes:

• A visão transcendental sustenta que qualidade é algo que se reconhece imediatamente, mas não se consegue definir explicitamente.
• A visão do usuário dimensiona a qualidade em termos de metas específicas de um usuário final. Se um produto atende a essas metas, ele apresenta qualidade.
• A visão do fabricante define qualidade em termos da especificação original do produto. Se o produto atende às especificações, ele tem qualidade.
• A visão do produto sugere que a qualidade pode ser ligada a características inerentes (por exemplo função e recursos) de um produto.
• A visão baseada em valor mede a qualidade tomando como base o quanto um cliente estaria disposto a pagar por um produto.

Mas... na realidade, qualidade engloba todas essas visões e outras mais. (PRESSMAN, 2011, p. 359).

Há, ainda, diversas outras definições de qualidade de software. Vamos considerar as principais delas:

Norma ISO/IEC 9126 (1991)

Fonte: <www.iec.ch> e <worldvectorlogo.com>.

• De acordo com o glossário padrão de terminologia em Engenharia de Software do IEEE 610.12 (1990) (disponível em: <standards.ieee.org>), qualidade pode ser definida como “o grau no qual um sistema, componente, ou processo atende aos requisitos especificados e às necessidades ou expectativas do cliente ou usuário”.
• A norma ISO/IEC 9126 (1991) define qualidade como “a totalidade de funcionalidades e características de um produto ou serviço que atendem à sua capacidade de satisfazer necessidades específicas ou implícitas”. Além disso, o padrão identifica seis atributos fundamentais de qualidade que um produto de software deve atender: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade.

• No contexto de desenvolvimento de software, qualidade
  

  [...] é o resultado de um bom gerenciamento de projeto e uma prática consistente de Engenharia de Software. O gerenciamento e a prática são aplicados no contexto de quatro grandes atividades que ajudam uma equipe de software a atingir alto padrão de qualidade de software: métodos de engenharia de software, técnicas de gerenciamento de projetos, ações de controle de qualidade e garantia da qualidade de software. (PRESSMAN, 2011; p. 370, grifo nosso).

O termo qualidade pode assumir diferentes significados, em função de estar ligado à percepção das pessoas, que têm gostos e formas de pensar distintos. Isso pode nos permitir concluir que a definição de qualidade de software também esteja ligada à percepção subjetiva dos seres humanos. Desta forma, a qualidade de software, assim como a qualidade de outros produtos, está sujeita à opinião das pessoas que, neste caso, assumem o papel de clientes, usuários e demais envolvidos com o projeto do software.

No entanto, ainda não há regras definitivas que indiquem claramente como desenvolver produtos de software de qualidade, embora a qualidade do produto seja considerada fortemente dependente da qualidade e adequação de seu processo de desenvolvimento. Mas podemos elencar as seguintes características para a qualidade de software:

• Está fortemente relacionada à conformidade com os requisitos.
• Caracteriza o grau de satisfação do cliente.
• Não é responsabilidade de apenas uma área da empresa, e sim de todos.
• Deve estar presente desde o planejamento do software.

Guia PMBOK

Fonte: <mefair.com >.

Além disto, a qualidade deve satisfazer um conjunto de diferentes pontos de vista:

• Usuário:
• Qualidade consiste na capacidade de satisfazer desejos.
• Qualidade é a adequação ao uso.
• Valor:
• Qualidade é o grau de excelência a um preço aceitável e o controle da variabilidade a um custo aceitável.
• Entrega:
• Um produto ou serviço produzido de acordo com as especificações, com custo competitivo, mas entregue fora do prazo, pode ser considerado de qualidade?

As empresas de desenvolvimento de software vêm valorizando bastante a qualidade dos sistemas e aplicações, pois tornou-se claro que os gastos com qualidade não são um dispêndio financeiro, mas um importante investimento. Além disso, os clientes estão cada vez mais exigentes, o que também exige dos desenvolvedores muito mais cuidado na criação dos produtos de software.

Saiba mais

Modelo de Qualidade no Contexto SPB – Software Público Brasileiro

“A Qualidade de Produto de Software está passando por uma evolução, antes estava ligada à funcionalidade e agora está ligada à confiabilidade.A Qualidade de um Produto de Software pode ser percebida por várias visões, como:

• Pela visão do desenvolvedor.
• Pela visão do responsável pelo desenvolvimento.
• Pela visão do usuário final.

Para o usuário final, o interesse está, por exemplo, na utilização, no desempenho, ou seja, em medidas externas de qualidade como:

• Funções específicas estão disponíveis?
• Qual é a confiabilidade do software e sua eficiência?
• É facil de usar?
• É facil para transferir para outro ambiente operacional?

Para o desenvolvedor, o interesse está na qualidade de produtos intermediários, ou seja, verificando, se estão coerentes com as expectativas do usuário final.

Para o responsável pelo desenvolvimento, o interesse está nos objetivos da comunidade, está em fazer o equilíbrio de melhoria de qualidade usando critérios como prazo e custo.

A definição de Qualidade de Produto de Software está baseada na definição de características de interesse em função da área de aplicação desse produto. De acordo com a área de aplicação do produto, certas características são mais desejáveis como:

• Para aplicações de missão critica, a confiabilidade.
• Para aplicações em tempo real, o desempenho.
• Para aplicações interativas com o usuário não especializado, a usabilidade.
• Para aplicações que mantêm informações sigilosas, a segurança.”

Fonte: CTI (2013).

Desenvolvimento de Casos de Uso

Na geração do documento preliminar dos requisitos extraídos em qualquer técnica, podem-se utilizar os diagramas de Caso de Uso da UML, que fornecem uma descrição de como o sistema será utilizado, através de cenários.

Essencialmente, um caso de uso conta uma história sobre como um usuário final (desempenhando diversos papéis) interage com o sistema sob um conjunto de situações diferentes. O primeiro passo ao se escrever um caso de uso é definir o conjunto de atores, que representam as diferentes pessoas ou dispositivos que usam o sistema no contexto.

Fonte: PRESSMAN (2011, p. 138)

De acordo com Pressman (2011, p. 138), o levantamento de requisitos é uma atividade evolucionária, portanto, nem todos os atores são identificados durante a primeira iteração. Atores primários são identificados na primeira iteração e atores secundários surgem quando mais conhecimento é obtido do sistema. Os atores primários trabalham de forma mais direta e frequente com o sistema e os secundários oferecem suporte ao sistema, de forma que os primários possam realizar o seu trabalho.

Booch, Rumbaugh e Jacobson (2006) sugerem diversas perguntas que podem ser respondidas por um caso de uso, dentre as quais se encontram:

• Há precondições que devem existir antes de uma história iniciar?
• Quem são os atores primários e secundários?
• Quais são os objetivos dos atores?
• Que tarefas ou funções são realizadas pelos atores?
• Que exceções devem ser consideradas à medida que a história se desenvolve?
• Quais são as possíveis variações na interação de cada ator?
• Que informações de sistema cada ator solicita, adquire, produz ou modifica?

Sommerville (2011, p. 74) afirma que o conjunto de casos de uso representa todas as possíveis interações que serão descritas nos requisitos de sistema. Os casos de uso identificam as interações individuais entre o sistema e seus usuários ou entre o sistema e outros sistemas. Cada caso de uso deve ser documentado com uma descrição textual e esta, por sua vez, pode ser ligada a outros diagramas da UML que desenvolverão o cenário com mais detalhes.

A figura apresenta os principais elementos de um diagrama de caso de uso da UML: ator (actor), caso de uso (use case), relacionamento (relationship) do tipo <<extend>> e <<include>>.

Elementos de um diagrama de caso de uso. Fonte: uml-diagrams.org (2016)

Caro aluno, as dicas que podemos lhe dar para quando você estiver tentando descobrir o que o seu cliente quer do seu novo software são:

• Em primeiro lugar, evite perguntar ao cliente o que ele quer que o novo sistema faça.
• Entenda, primeiro, como são atualmente os processos do seu cliente.
• Pergunte ao cliente quais processos que ele sabe que funcionam bem no sistema atual. Faça o cliente explicar porque ele acha que funcionam bem. Faça o mesmo com os processos que existem e funcionam mal.
• Descubra quais são os processos atuais que existem, mas que ninguém usa, e por que não são usados.
• Baseado nessas informações, utilize uma das técnicas de coleta de requisitos. Quanto mais claramente os requisitos puderem ser compreendidos pelo cliente, melhor. Por exemplo, se for um cliente da área técnica você poderá lhe mostrar os casos de uso ou usar diagramas mais técnicos. Se for um cliente de negócios, você vai precisar de algo mais visual, então faça desenhos ou crie um protótipo.
• Faça o cliente analisar seu protótipo ou sua lista, mesmo que seja difícil para ele. Procure estar sempre face a face com seu cliente.
• Assinale os requisitos com os quais o cliente concorda e aqueles com os quais ele discorda. Baseado nessas informações, descubra se ainda existem pontos do processo que você não entendeu corretamente.
• Refine e detalhe mais os requisitos. A partir daqui, o processo se repete até que o cliente concorde com a maioria dos requisitos do sistema. Ter 100% de concordância não é fácil, mas deve haver uma sensação de comprometimento e de entendimento entre você e seu cliente após esse processo.

Prototipação

Técnica que tem como objetivo extrair, entender e validar os requisitos. É baseada no conceito do processo de desenvolvimento de software de prototipação, já estudado anteriormente. Um protótipo do produto pode ser construído. Por meio do protótipo os usuários podem descobrir quais são as suas reais necessidades. É benéfica somente se o protótipo puder ser construído de forma mais rápida que o sistema real. É especialmente útil para superar dificuldades de comunicação de necessidades por parte dos usuários.

Etnografia

Etnografia é uma técnica de observação que pode ser utilizada para a compreensão de processos operacionais e ajudar na coleta de requisitos. A técnica inicia-se a partir da imersão de um engenheiro de software ou analista no ambiente de trabalho em que o sistema será usado. Todas as tarefas reais que ocorrem na rotina de trabalho dos futuros usuários é observado e anotado.

Esta técnica ajuda no levantamento de requisitos implícitos do sistema que refletem o trabalho real realizado pelas pessoas ao invés dos aspectos formais dos processos definidos pela organização. Além disso, fatores sociais e comportamentais que afetam o trabalho, e que não são notados pelos envolvidos, podem ser percebidos por um observador imparcial.

Caro aluno, as técnicas apresentadas visam superar as dificuldades inerentes ao processo de extração dos requisitos. Nenhuma técnica é suficiente por si só. Você, como desenvolvedor, deve escolher um conjunto de técnicas que melhor se adaptem ao produto a ser desenvolvido. Mas podemos elencar alguns procedimentos gerais que podem fazer parte de qualquer processo de coleta de requisitos e ajudá-lo neste processo:

• Você deve perguntar e identificar as pessoas apropriadas para responder quais são os requisitos.
• Você deve observar o comportamento dos usuários de um produto existente e inferir suas necessidades a partir de seu comportamento.
• Você deve discutir com os usuários suas necessidades e, junto com eles, formular um entendimento comum dos requisitos.
• É importante você negociar com os usuários, a partir de um conjunto-padrão de requisitos, quais serão incluídos, excluídos ou modificados.
• Você deve estudar e identificar os problemas; isso ajuda a identificar os requisitos que podem melhorar o produto.