Qualidade de Software: Um Compromisso da Empresa Inteira

Qualidade de software é um assunto que muito se discute e pouco se pratica. Temos a

impressão, às vezes, que o discurso da qualidade não passa disso mesmo: discurso.
Desde o início dos tempos do desenvolvimento de software temos problemas de
qualidade que não só ainda não foram resolvidos como ainda parece que se agravam a
cada nova geração tecnológica. Prazos estourados, baixa produtividade, custos altos e
qualidade deficiente parecem ser um fantasma que novas tecnologias não são nunca
capazes de exorcizar.

Para abordarmos o problema da qualidade, é necessário, evidentemente, que tenhamos

claro em primeiro lugar o que entendemos por qualidade de software. Utilizando uma
simplificação, poderíamos dizer que todos os problemas de qualidade de software caem
em uma das seguintes duas categorias: falhas na Qualidade de Conformidade e falhas na
Qualidade de Desempenho.

Qualidade de Conformidade diz respeito à aderência do produto à finalidade para a

qual foi construído. No nosso caso, estamos falando de software que dá ao seu usuário a
funcionalidade de que ele precisa. Como é amplamente sabido, este tipo de qualidade é
mosca branca na nossa área. Por sua vez, Qualidade de Desempenho refere-se à
capacidade do produto em apresentar consistentemente a funcionalidade desejada. Em
termos de software, isto quer dizer boa performance, ausência de bugs, tolerância a
falhas de infra-estrutura (hardware), tolerância a erros do usuário etc.

Por quê deveríamos nos preocupar com a qualidade de software? Existem algumas
razões óbvias. Ninguém gosta de software com bugs. Bugs podem causar prejuízos que
variam desde a mera necessidade de reiniciar o sistema operacional até à perda de
satélites de milhões de dólares (como o Clementine, um satélite construído para
designar alvos, no projeto Guerra nas Estrelas, o qual, quando recebeu um comando
para mirar um ponto na superfície lunar, ativou os foguetes direcionais e ficou girando
até acabar o combustível...). Bugs podem fazer um banco perder milhões e perder a
confiança dos clientes ou parar por horas uma companhia telefônica, impedindo a
realização de telefonemas interurbanos (como já ocorreu com a AT&T). Os problemas
de qualidade tendem a aumentar com o uso maciço das tecnologias de processamento
distribuído, onde é muito mais difícil prever o que pode dar errado...

Mas não é só isso. Os esforços pela qualidade na indústria automobilística provaram a

tempos que a qualidade não tem custo. Ao contrário do que muita gente pensa, os
investimentos em qualidade pagam-se em pouco tempo. O aumento de qualidade
sempre é acompanhado por aumento de produtividade e redução de custos na forma de
menos retrabalho e menor índice de refugo. Isto sem falar na maior satisfação do
cliente, que pode ser refletida muitas vezes em maior participação no mercado. Assim, o
axioma que diz que investimentos em qualidade dão lucro é plenamente aceito pela
indústria de manufatura. Infelizmente, não é fácil encontrar quem acredite nisto na área
de software.

No entanto, as empresas que entenderam que não existem razões para acreditar que este
axioma não funciona com software, puderam experimentar os benefícios da aplicação
das técnicas de qualidade -presentes na Engenharia de Produção- na Engenharia de
Software (leia a entrevista com Watts Humphrey nesta edição). Em um artigo na edição
de março, apresentei e discuti o modelo CMM de qualidade de software, desenvolvido
pela SEI (Software Engineering Institute). Comentei, naquela ocasião, que os esforços

1
http://qualidade-de-software.blogspot.com
 Qualidade de Software: Um Compromisso da Empresa Inteira

em melhoria da qualidade não podem ter seu foco no produto apenas (fazer software
melhor), mas principalmente no processo (fazer melhor o software).

A SEI apresentou, em um estudo recente, alguns números impressionantes relativos a

melhorias de desempenho em empresas que investiram em qualidade seguindo os
passos do CMM. O aumento médio de produtividade foi em média 35% por ano,
enquanto o número de bugs encontrados em software após a entrega foi reduzido em
39% ao ano, chegando em algumas empresas a 95%! A relação custo/benefício,
comparando os investimentos em qualidade com o retorno financeiro em termos de
redução de custos via aumento de produtividade e redução de retrabalho e manutenção,
ficou em média em 5 para 1, chagando a 9 para 1 em alguns casos. Isto é, para cada
dólar investido em qualidade, estas empresas economizaram 5 dólares em média.
Qualquer pessoa que conheça o Retorno sobre o Investimento (ROI) típico no mercado
poderá confirmar que um ROI de 5:1 não se encontra todo dia...

Por quê, então, existe tão pouco investimento em qualidade nas organizações típicas de
desenvolvimento de software? Existe aí um problema cultural de grandes dimensões e
difícil de superar. Infelizmente, a cultura atual de desenvolvimento de software baseia-
se em crenças absurdas que se espalham por todos os níveis da organização. Nos níveis
mais altos, isto é, na administração de informática, acredita-se que os investimentos
típicos em qualidade de software (uso de processos padronizados de gerência de
projetos, uso de metodologias de desenvolvimento, treinamento contínuo dos
desenvolvedores, uso de métricas, estabelecimento de procedimentos eficazes de
controle de qualidade de software etc.) são caros demais, são mera burocracia e,
principalmente, causam o alongamento dos prazos de desenvolvimento. Esta crença
errônea é agravada pela limitada cultura de informática dos usuários e clientes, que
tendem a pressionar por prazos completamente fora da realidade. Não passa pela cabeça
de um alto executivo da GM ou da Volkswagen exigir de seus engenheiros a construção
de uma nova fábrica de caminhões em três meses. Em nossa área, porém, é mais ou
menos a isto que estamos submetidos dia após dia. No dizer de DeMarco e Lister
(Peopleware, 1987), "regularmente pondo o processo de desenvolvimento sob extrema
pressão de tempo e depois aceitando produtos de baixa qualidade, a comunidade dos
usuários de software mostrou seu verdadeiro padrão de qualidade".

O desenvolvedor, por outro lado, além de acreditar nestas mesmas coisas, não aceita que
ninguém lhe diga como deve fazer seu trabalho, afirmando que padronização de
procedimentos e uso de best practices seriam uma violência à sua "criatividade". Se
levarmos em conta que a maioria dos desenvolvedores não foi formada em Engenharia
de Software e aprendeu tudo o que sabe "na marra", fica difícil acreditar nesta
afirmação. Afinal, quem de nós confiaria sua saúde a um "médico" que aprendeu
sozinho a profissão (fora da faculdade) e que têm solene desprezo pelos manuais de
medicina? O caso é que a maioria de nós desenvolvedores não sabe desenvolver
software, e deveríamos ter a humildade de aprender com quem já aprendeu.

Existem erros graves de percepção subjacentes a estas crenças. O primeiro deles é em

relação aos prazos. O executivo de informática costuma falhar em perceber que o tal
"aumento nos prazos" é geralmente relativo aos prazos prometidos, e não aos
efetivamente cumpridos. Como raramente são registrados os prazos reais, ao final dos
projetos, o que fica no inconsciente do gerente como regra de referência são os prazos
que ele costuma prometer, não os que ele cumpre! E não é preciso ter décadas de

2
http://qualidade-de-software.blogspot.com
 Qualidade de Software: Um Compromisso da Empresa Inteira

experiência na área para se saber que o cumprimento de cronogramas é a exceção, e não

a regra.

É claro que a introdução de procedimentos visando o aumento da qualidade pode

causar, num primeiro momento, uma pequena redução de produtividade, devido à curva
de aprendizado. Isto acontece com a introdução de qualquer nova tecnologia em um
ambiente de produção. De forma geral, a introdução de novas tecnologias segue o
gráfico da figura 1. O grande problema é que estes projetos acabam sendo abandonados
no ponto mínimo da curva, fazendo com que os recursos investidos se percam e
baixando o moral dos envolvidos. Mesmo assim, na prática, tenho observado (e
conversado com colegas também) que em ambientes de desenvolvimento caóticos (a
grande maioria), qualquer esforço de melhoria, por simples que seja, causa rapidamente
melhorias de produtividade. A "barriga" da curva é mínima ou mesmo inexistente. O
simples esforço por melhorar a documentação do projeto e as verificações de qualidade
desde o início reduzem significativamente o tempo gasto em testes e retrabalho, fazendo
com freqüência com que mesmo o primeiro projeto em que se aplicam estas técnicas
acabe sendo completado antes do que teria terminado sem estas mesmas técnicas, além
manter alto o moral dos envolvidos.

A médio prazo, então, não há o que se discutir. Software com mais qualidade sofre
menos manutenção, e as manutenções necessárias são feitas muito mais rapidamente.
Isto libera recursos para o desenvolvimento de software novo, reduzindo o backlog e
acelerando o desenvolvimento; mais software pode ser reutilizado; e o processo de
desenvolvimento pode ser continuamente melhorado para aumentar sua eficiência (leia-
se prazos menores).

Para um esforço de melhoria de qualidade de software em uma organização funcionar,

toda a organização deve estar comprometida. Especificamente, são fundamentais o
compromisso da alta administração (de informática e usuária) e dos desenvolvedores,
incluindo aí seus gerentes imediatos.

Compromisso da alta administração não é apenas uma expressão bonita. Este

compromisso tem que se materializar em ações concretas. São necessários recursos para
processos de melhoria (dinheiro e pessoas). É necessário "bancar" o esforço quando
surgem crises. É necessário colocar em prática processos que garantam que pressões
irrealistas dos usuários não esfumacem a iniciativa. É necessário treinamento e ampla
comunicação. Enfim, são necessárias ações que somente executivos em nível de
diretoria ou acima podem realizar.

Em um esforço de melhoria da qualidade, o primeiro ponto é colocar em ordem o

processo de planejamento e estimativas realistas de prazos. Assim, se o gerente de
equipe não souber ou não quiser fazer este planejamento, nada vai acontecer. Para
garantir uma negociação realista com os usuários, a alta administração tem que garantir
que os prazos estimados pelo gerente sejam aceitos pelos usuários. Os desenvolvedores,
por usa vez, tem que comprometer-se a cumprir estes prazos, para que a credibilidade
das estimativas junto aos usuários cresça.

Dado que a alta administração garante prazos realistas e dá condições para que os
desenvolvedores melhorem suas práticas, é responsabilidade destes últimos aplicarem
no seu trabalho diário os conhecimentos adquiridos em treinamentos. Também precisam

3
http://qualidade-de-software.blogspot.com
 Qualidade de Software: Um Compromisso da Empresa Inteira

comprometer-se em buscar continuamente mais conhecimentos, através de leitura de

revistas técnicas, livros, pesquisa na Internet etc. Afinal de contas, trata-se de melhorar
o processo de engenharia e, se os próprios engenheiros não melhorarem suas práticas de
trabalho, nada acontecerá. Em suma, os desenvolvedores devem melhorar seu trabalho,
e a administração deve dar as condições para que isto aconteça.

Para ilustrar o que entendo por comprometimento gerencial, apresento um caso real
onde estes conceitos foram aplicados.

Em uma empresa em que trabalhei, do setor financeiro, a questão de qualidade era

crítica. Existia uma carga noturna de processamento batch em mainframe que era
volumosa e sensível a problemas. Um programa que parasse, durante a noite, no
caminho crítico da produção levava a atrasos enormes no final do processamento batch,
entrava pelo dia adentro e não permitia a entrada dos sistemas on-line, impedindo ou
dificultando muito a operação normal e o atendimento aos clientes. A maioria dos
abends durante a noite era causa por falhas de planejamento, testes mal feitos ou falta de
coordenação entre a equipe de desenvolvimento/manutenção e outra áreas chave tais
como a produção ou a administração de bancos de dados. Para resolver o problema, foi
instituído um processo de controle de manutenções, que exigia da equipe um
planejamento detalhado, teste e coordenação com as áreas envolvidas. Nenhum
programa poderia entrar em produção sem que todos os passos estabelecidos fossem
cumpridos. Havia uma área especialmente encarregada de verificar o cumprimento do
planejamento, cujo gerente respondia diretamente para o diretor de informática,
evitando que pressões do gerente de desenvolvimento pudessem fazer com que se
"passasse por cima" do processo estabelecido. Os desenvolvedores foram treinados no
processo e foram-lhes mostrados os benefícios esperados. A solicitação de manutenção
de prioridade normal tinha de ser apresentada com quase duas semanas de antecedência
à entrada em produção dos programas alterados. Existia também a possibilidade de
implantações de maior prioridade acontecerem em um período inferior a estas duas
semanas.

Apesar de todas estas providências, este processo não funcionou num primeiro
momento. Os usuários continuaram pressionando os analistas por prazo e estes também
não tinham o hábito de planejar as manutenções. Quando o usuário pedia algo, a equipe
simplesmente sentava e fazia. As exceções eram a regra e o processo praticamente não
era cumprido. Solicitações de manutenção para o mesmo dia ou o dia seguinte eram
aceitas sem maiores problemas e, freqüentemente programas eram alterados no
ambiente de produção sem mesmo passarem pela formalidade do processo. Não será
surpresa para o leitor saber que os problemas de abends em produção continuaram
ocorrendo com a mesma freqüência.

Percebendo este problema, o diretor de informática, com suporte explícito do vice-

presidente administrativo e tácito do presidente da empresa, estabeleceu que
absolutamente todas as manutenções deveriam passar pelo processo. Além disso, os
desenvolvedores e seus gerentes imediatos foram informados de que teriam de explicar
muito bem cada abend em produção. Por outro lado, também foram encorajados a
resistir às pressões dos usuários. Estes últimos foram educados a respeito do novo
processo, e se deixou claro que eles, usuários, teriam que explicar muito bem por quê
suas solicitações exigiam os prazos curtos pedidos. A área de administração de
mudanças recebeu poder para barrar qualquer solicitação de manutenção que entendesse

4
http://qualidade-de-software.blogspot.com
 Qualidade de Software: Um Compromisso da Empresa Inteira

estar fora dos padrões de qualidade, adiando as implantações em uma semana. Qualquer
confronto de prazo entre esta gerência e a de desenvolvimento/manutenção seria levado
para a decisão do próprio diretor de informática, que ouviria as razões do usuário. Todo
abend em produção passaria a ser documentado por escrito, tendo a equipe de
desenvolvimento que explicar suas causas e o que seria feito para evitar a recorrência.
Estatísticas começaram a ser coletadas provando uma correlação positiva entre abends e
manutenções "urgentes", isto é, ficou comprovado que a maioria dos problemas em
produção eram causados por programas alterados em manutenções "de um dia para o
outro". Níveis de erros em produção e de manutenções de prioridade "urgente" versus
prioridade normal (duas semanas) eram coletados e divulgados, separados por equipe.
Gerentes de equipes com altas taxas de erros e manutenções "urgentes" tinham que
explicar as razões. Usuários de nível médio (um gerente na área de contabilidade, por
exemplo) tinha de explicar ao seu diretor por que a sua manutenção era urgente, para
que este pudesse por sua vez explicar ao diretor de informática, que liberaria a
manutenção se esta fosse realmente necessária.

É claro que, no início, houve uma chiadeira geral. Ouviam-se gritos de "terrorismo" e
"burocracia" por todos os corredores. Usuários queixavam-se da "urgência" de suas
manutenções (na maioria não tão urgentes assim, ou tornadas urgentes por não se ter
feito planejamento no momento certo, com a devida antecedência). Desenvolvedores e
seus gerentes imediatos não gostaram de ter a qualidade de seu trabalho medida e
divulgada publicamente. Mas a alta administração foi em frente e não se deixou
intimidar pela gritaria.

Qual foi o resultado? Com o tempo, usuários e desenvolvedores aprenderam a separar o

"urgente" do urgente. Tanto os usuários quanto os desenvolvedores aprenderam a
planejar melhor as manutenções. Prazos realistas passaram a ser estabelecidos.
Alterações em programas passaram a ser melhor testadas. Todas as áreas técnicas e
funcionais passaram a ser sistematicamente envolvidas em cada manutenção, evitando
problemas de coordenação. Em pouco tempo, as manutenções planejadas passaram a
apresentar taxas baixíssimas de erros em produção. Os atrasos de processamento, que
aconteciam em mais da metade dos dias do mês, passaram a ocorrer apenas em dois ou
três dias por mês. A médio prazo, a relação entre manutenções urgentes e planejadas foi
ficando cada vez menor.

5
http://qualidade-de-software.blogspot.com
 Qualidade de Software: Um Compromisso da Empresa Inteira

Afinal, diante das evidências, todo mundo teve de concordar que a coisa tinha
melhorado muito. A empresa como um todo beneficiou-se com a maior disponibilidade
dos sistemas e melhor serviço ao cliente. A cultura nascente de planejamento levou ao
aumento de produtividade e a um gerenciamento de prioridades muito mais eficaz. Os
usuários descobriram que o "day after" de cada manutenção não precisava ser a roleta-
russa a que estavam acostumados. E os desenvolvedores aprenderam que trabalhar de
forma planejada lhes rendia mais noites de sono não-interrompido (havia programadores
que eram acordados à noite três vezes por semana, na maioria das vezes exigindo sua
presença imediata para consertar programas "abendados") e a possibilidade de ir para
casa no final do expediente, ao invés de às 11 horas da noite, como era a regra.

Observe-se que a empresa em questão é uma multinacional da área financeira, isto é,

está imersa em um ambiente onde as mudanças acontecem muito depressa e a toda hora.
Mudanças de mercado, mudanças de legislação, mudanças em diretrizes da matriz
surgem o tempo todo. Mesmo assim, o processo descrito foi um sucesso total, e chegou-
se a um nível de serviço invejável, sendo que verificou-se que apenas algo em torno de
10% das manutenções realmente necessitavam ser implementadas com urgência (prazo
inferior duas semanas). Desta forma, se um processo como este pôde funcionar em uma
organização com estas características, pode funcionar em qualquer ambiente
empresarial.

Este exemplo deveria fazer com que gerentes de informática e usuários percebessem
que o aumento da qualidade do software depende muito menos do uso de novas
tecnologias do que do uso de práticas gerenciais adequadas. Treinar desenvolvedores e
dar-lhes tempo para absorver o que aprenderam é fundamental. Impedir os usuários de
colocar prazos absurdos para seus pedidos é fundamental. Alocar recursos (tempo,
dinheiro e pessoas em dedicação integral) para trabalhar na melhoria dos processos de
software é fundamental. É obvio que os desenvolvedores que estão construindo
software não terão tempo para definir processos, metodologias, medir qualidade, definir,
coletar e analisar métricas etc. Atribuir esta responsabilidade a quem está
desenvolvendo software é a melhor garantia de que nada vai acontecer. Se queremos
qualidade, temos que investir nela. Mas tendo a certeza de que este é um investimento
que se paga muitas vezes. E em pouco tempo.
1

1
Publicado em Junho de 1997 na Developers Magazine.

Este artigo está apresentado aqui tal como foi enviado ao editor, podendo, devido ao processo de revisão
da revista, estar ligeiramente diferente de sua versão publicada.

Ó Copyright por Átila Belloquim. Este documento pode ser reproduzido no todo ou em parte, desde que
citada a fonte.

6
http://qualidade-de-software.blogspot.com