16. Alguns Caminhos Para Melhorar a Qualidade de Software
Desde o avanço japonês no mercado mundial, com seu famoso Programa de Qualidade Total,
melhorar a qualidade de um produto tornou-se a palavra de ordem das empresas com intuito de
conquistar uma fatia maior do mercado consumidor.
Conquistar o cliente passou a ser a principal arma para vencer o cada vez mais crescente e
concorrido mercado capitalista global, utilizando-se para isso de inúmeras técnicas para “melhorar
a qualidade” sem aumentar, com isso, o custo do produto, garantindo assim uma boa margem de
lucro.
Mas, antes de sabermos como melhorar a qualidade, precisamos responder a uma pergunta: o que
é qualidade?
Checando o dicionário Aurélio, verifica-se que qualidade significa “Propriedade, atributo ou
condição das coisas capaz de distingui-las das outras e de lhes determinar a natureza” ou “Numa
escala de valores, aquilo que permite avaliar e, conseqüentemente, aprovar, aceitar ou recusar
qualquer coisa”.
Uma possível interpretação para o significado de qualidade seria: conjunto de características (que
caracteriza ou distingue, particularidade – definição do Aurélio) de uma coisa ou pessoa que
determina seu valor (qualidade, propriedade ou atributo pela qual determinada coisa ou pessoa é
estimável em maior ou menor grau – definição do Aurélio). Para o desenvolvimento de software,
portanto, qualidade pode ser entendida como o conjunto de características que determina seu
valor. Mas que características são essas?
As recomendações ISO 9000 se tornaram sinônimo de qualidade, sendo compostas basicamente
por ISO 9001, ISO 9002 e ISO 9003 (outras recomendações existem, mas são voltadas ao controle
da qualidade atingida, como auditoria, etc.). Tais recomendações são voltadas para empresas de
um modo geral, indústrias e comércio. Apesar de tais recomendações serem de grande utilidade
na produção de computadores, pouco auxiliam a produção de software, um dos mercados mais
crescentes atualmente.
Verificando tal necessidade, o órgão responsável pela elaboração dos requisitos dos certificados
ISO 9000 resolveu criar um ramo especial para o mercado de software, conhecido como ISO 90003. Tal iniciativa não foi uma exclusividade, pois uma empresa americana (Software Engineering
Institute) também criou o Capability Maturity Model (CMM) com o mesmo objetivo. Entretanto, o
mercado mundial adotou o certificado ISO 9000 como padrão, ficando o CMM mais restrito às
empresas americanas, que acabaram adotando os dois padrões por questões de mercado
internacional.
As recomendações ISO 9000 baseiam-se na identificação e controle de qualidade dos processoschave da empresa.
Em geral, as recomendações de controle de qualidade de software baseiam-se em quatro pontoschave do desenvolvimento de software: facilidade de uso, segurança, documentação e facilidade
de adaptação. O grau de importância de tais parâmetros depende do tipo de software desenvolvido
ou do mercado ao qual se destina. Por exemplo, o item Segurança é um dos mais importantes em
software de controle de tráfego aéreo ou controle de usinas nucleares – já imaginou um software
parando quando diversos aviões tentam decolar e/ou aterrissar? Já em um controle de
videolocadora, o item Segurança pode não ser o mais importante.
Essas preocupações, contudo, podem e devem ser aplicadas tanto à área de desenvolvimento
quanto à área de produção, com o intuito de se obter melhor qualidade nos serviços prestados aos
usuários. Um ambiente de desenvolvimento sem planejamento gera um pesadelo para a área de
produção. Uma área de produção malplanejada tende a comprometer um trabalho bemdesenvolvido.
A facilidade de uso é normalmente medida pela facilidade que o software apresenta para o
primeiro contato com o usuário, portanto está intimamente ligada à interface do software com o
usuário. Um sistema é considerado fácil quando usuários de níveis diversos conseguem aprender
a utilizá-lo em pouco tempo.
Normalmente o software deverá apresentar uma interface semelhante àquela utilizada pelo
ambiente operacional em que o mesmo é executado. Dessa forma, o usuário conseguirá aprender
mais facilmente a trabalhar com um determinado software se ele já tiver conhecimentos básicos do
ambiente adotado.
A interface ainda deverá ser voltada ao usuário, em vez de voltada aos processos do computador.
É muito comum desenvolvedores definirem estrutura de opções baseando-se no que o computador
executa internamente. Tais opções devem ser modificadas para refletir a realidade do usuário, e
não do computador.
Um problema muito comum no desenvolvimento de software é a busca incessante pelo uso da
mais avançada tecnologia. Evidentemente, isso é ótimo do ponto de vista técnico, mas nem
sempre a mais avançada tecnologia traz o melhor resultado para o usuário. Por isso mesmo, a
necessidade do usuário deve ser colocada em primeiro lugar, fazendo com que ele participe da
elaboração de partes do projeto (principalmente as telas do sistema) e evitando-se o uso de
tecnologias ainda não dominadas pela equipe (cujos problemas são de soluções demoradas pela
falta de conhecimento).
A interface do usuário deverá, ainda, ser simples, conter poucas informações e buscar semelhança
com o dia-a-dia do mesmo. Uma certa evolução (ou revolução?) na interface do usuário aconteceu
recentemente, gerando uma nova onda na informática: a Web. A interface dos browsers Web é
bastante simples, com poucas opções disponíveis, e não utiliza os difíceis termos técnicos e
abstratos como diretórios e arquivos.
Antes que as grandes empresas percebessem, essa nova interface tomou conta dos usuários. A
adesão dos usuários foi tão sensível que grandes empresas como Microsoft, Oracle, IBM, Sun e
outras mudaram radicalmente sua linha de atuação frente ao usuário. A nova ordem mudou:
softwares “leves” (lights) e telas simples com o padrão do browser tornaram-se obrigatórios. A
própria Microsoft, uma das mais famosas empresas de software para usuário final, já está
mandando seu pacote principal, o Office, para uma temporada em algum spa: espera perder
aqueles “quilinhos” a mais para poder se manter como um dos principais pacotes do mundo.
Isso mostra que a corrente de evolução anterior não agradava aos usuários como se pensava, e
bastou uma boa opção diferente para que os usuários automaticamente a elegessem como
preferida. Essa nova interface é tão importante que mudou o rumo da informática deste final de
década: novos sistemas operacionais são desenvolvidos com a cara de um browser, a linguagem
mais badalada do momento está intimamente ligada à interface do browser, e muitos aplicativos
famosos estão sofrendo alterações para se adaptarem ao mundo do browser, condição para que
não corram o risco de perder seu mercado.
Acredito que isso demonstra claramente o poder de uma interface que atende aos anseios dos
usuários.
A segurança corresponde, na realidade, a dois subparâmetros: estabilidade do sistema e
segurança de acesso ao sistema. Diz-se que um sistema é estável/confiável quando o mesmo
pode ser executado pelo usuário sem intervenção de um profissional de informática e sem
interromper seu trabalho de forma anormal.
Isso nos leva a pensar duas vezes antes de utilizar a última versão deste ou daquele aplicativo. A
equipe precisa de treinamento adequado para conhecer os prós e contras (qual a qualidade do
novo software a ser utilizado?) da nova ferramenta.
Um sistema é seguro, do ponto de vista de acesso, quando tem mecanismos confiáveis de acesso
às informações do usuário. Atenção especial deve ser dada a esse caso, já que a utilização da
informática abre um mundo novo e diferente com relação à segurança. Mas não se pode deixar
levar pela “síndrome da segurança do computador”.
Atualmente é muito comum ouvirem-se longas discussões sobre a segurança do computador,
debatendo-se sobre as mais remotas possibilidades de acesso indevido às informações nele
mantidas. Devemos lembrar, entretanto, que o papel é burocrático o bastante para exigir, em
diversas situações, sua assinatura perante um representante de algum cartório e de testemunhas.
E, mesmo assim, diversos (não são poucos) casos de fraudes não envolvendo computadores são
muito comuns, tão comuns que às vezes nem percebemos. A possibilidade de “acesso indevido”
às informações mantidas em papéis é mais simples ainda que no computador.
É necessário estudar as situações nas quais o computador é inseguro e preveni-las, em vez de se
preocupar com possibilidades remotas. De acordo com a SAFEWARE Loss Statistics (http://www.
pc-security.com/info/report.html), tem-se a seguinte tabela para os principais motivos de perda ou
roubo de informações em microcomputadores (insegurança):
29,5% Acidentes
25,3% Roubos
18,5% Problemas de
energia elétrica
16,5% Outros
4,7% Raios
Deve-se lembrar ainda que boa parte dos roubos (25,3%) se deve a pessoas insatisfeitas internas
à organização, ou a “ladrões” que descobrem facilmente as senhas de funcionários que utilizam
data de nascimento ou nomes de parentes como sua “assinatura eletrônica”.
Enfim, uma boa política de educação em informática, a segurança básica de aparelhos
eletroeletrônicos (aterramento, estabilização de energia, etc.) e uma política coerente de recursos
humanos (Por que alguns funcionários estão descontentes?) resolveriam não só muitos dos
problemas de segurança em informática, mas também outros problemas inerentes à baixa
qualidade de produtos e ao alto grau de insatisfação de funcionários em muitas empresas.
Documentação refere-se à existência e qualidade da(s) documentação(ões) disponível(is) ao
usuário. A qualidade da documentação é medida através da clareza com que aquele apresenta as
informações e da importância e relevância das informações apresentadas.
A documentação é um processo difícil, pois não é tratada com a devida atenção e o software
acaba não sendo documentado ou então acaba gerando muitos parágrafos contendo pouca
informação.
Um grande problema atualmente é a falta de matéria voltada à documentação nos cursos de
informática/computação de nível universitário. Uma grande parte dos atuais analistas foi treinada
para o projeto técnico do sistema, mas não para a documentação do mesmo.
Empresas diversas utilizam equipes completamente diferentes para tratar a documentação, pois
precisam evitar a dificuldade que o desenvolvedor possui para documentar (ele sabe como o
sistema funciona, tornando difícil a tarefa de pensar nas possíveis dificuldades dos usuários), e a
utilização de jargão técnico.
Uma saída para empresas pequenas é a utilização de pessoas que não fazem parte da informática
como “cobaias”. A essas pessoas seriam apresentadas versões “beta” ou protótipos dos sistemas
com o objetivo de avaliar as dúvidas e o comportamento dos usuários, definindo assim a estrutura
da documentação necessária.
É preciso que se definam corretamente as informações necessárias à documentação e como
apresentá-las. Apesar de ser perda de tempo a documentação do óbvio, é muito comum encontrar
esse tipo de situação em diversos softwares. O texto de auxílio “Informar o nome” em um campo
com a indicação Nome é mais comum do que se pensa e não auxilia em nada.
A apresentação das informações também é muito importante, sendo a utilização do padrão HTML
uma excelente opção no momento. A escolha de um padrão como esse é bastante útil, já que a
maioria dos usuários sabem utilizar a Web e não terão maiores problemas para manipular a
documentação nesse formato.
Uma boa documentação não deve ser por demais detalhada: ela fica extensa, portanto difícil de
ser lida por ser enfadonha. Fica também difícil de ser mantida devido às constantes manutenções
que o sistema virá a sofrer. A documentação precisa ser objetiva e clara, garantindo assim sua
estabilidade (necessidade de poucas manutenções) e, principalmente, que o trabalho de
desenvolvê-la não seja em vão.
A facilidade de adaptação corresponde à agilidade com que o software pode ser alterado de
acordo com as necessidades dos usuários, acompanhando o dinamismo necessário às empresas
no concorrido mercado existente nos dias atuais. Isso depende diretamente da qualidade da
concepção do sistema.
A modelagem de dados traz um benefício enorme nesse campo, pois uma base modelada
sobrevive às diversas mudanças que ocorrem durante a vida de um sistema em produção. Essa
vantagem paga o menor rendimento (devido ao maior overhead) inerente às bases normalizadas.
Já os processos dependerão da correta utilização de módulos e sub-rotinas, que permitem a
centralização do código em apenas um lugar, garantindo facilidade e agilidade de manutenção e
evitando a recodificação de rotinas. Um dos maiores problemas é montar uma biblioteca de rotinas
antes do início do desenvolvimento dos sistemas. Mas, se o primeiro sistema for bem planejado, e
for estimado um prazo um pouco mais longo para o desenvolvimento da biblioteca, as
probabilidades de se obter sucesso são grandes. A correta documentação da biblioteca de rotinas
(ou funções) é a chave para obtenção de sucesso na reutilização do código quando a equipe de
desenvolvimento é grande.
A orientação a objetos, porém, reina soberana através da abstração, que permite pensar no
problema sob um ponto de vista específico, do encapsulamento, que esconde os detalhes de
implementação, da herança, que permite a reutilização de conceitos e de códigos, e do
polimorfismo, que permite nomear os métodos (ou processos ou sub-rotinas) de acordo com sua
função real dentro do sistema (mesmo que outro objeto já utilize tal nome para alguma rotina),
facilitando o entendimento interno do sistema.
Os mesmos problemas da biblioteca de rotinas ou funções existem em objetos. É necessário que
se monte uma “biblioteca” de objetos, cuja interface precisa ser bem-definida e genérica, prevendo
o uso futuro por parte de outros “clientes”.
Nos três casos (modelagem, rotinas e objetos), é comum gastar-se mais tempo no planejamento
inicial, de forma a montar uma base sólida para o desenvolvimento. À medida que mais e mais
projetos vão sendo desenvolvidos, esse tempo inicial necessário costuma diminuir, pois a
reutilização de códigos (via bibliotecas) e dados (via bases normalizadas) aumenta bastante. A
reutilização será tanto maior quanto mais bem-planejada e bem-documentada estiver sua base de
dados, biblioteca de rotinas e/ou biblioteca de objetos.
Como resultado desse planejamento inicial e uma certa perda de rendimento dos processos
(normalmente a utilização desses conceitos exige mais processamento), ganha-se ainda maior
facilidade de adaptação do sistema às necessidades da(s) empresa(s).
O trabalho da área de informática está sujeito a um velho paradoxo conhecido por todos: prazo e
qualidade nem sempre andam juntos. Mas o mercado exige adaptação rápida de todos, e a
informática não pode ser exceção.
A área de informática está ainda sujeita aos avanços contínuos e rápidos que a indústria de
hardware e software experimenta atualmente, exigindo de todos atenção para as novas
tecnologias e suas possíveis aplicações com o intuito de atingir os objetivos dos usuários.
O desenvolvimento de um sistema é uma ação mais complexa do que simplesmente codificar
rotinas. O desenvolvimento se inicia com a idéia de um novo sistema e acaba quando os usuários
sabem utilizá-lo (e o utilizam de fato), envolvendo, por isso mesmo, muitas fases.
Ainda, o desenvolvimento precisa ser bem planejado e preparado para futuras manutenções de
acordo com as mudanças estratégicas da empresa, proporcionando ao sistema uma vida útil mais
longa com menos entraves ao suporte e maior retorno de investimento. Atender aos quesitos aqui
discutidos é uma forma de se garantir a qualidade do software desenvolvido.
Saber encontrar a melhor tecnologia para solucionar o problema atual do usuário, vislumbrando as
possíveis modificações exigidas pelo mercado, é o caminho para um software de boa qualidade.
Autor: Rodolfo Vaz
Biografia: Rodolfo Vaz ([email protected]) é Analista de Sistemas do Hospital Sarah
Kubitschek.