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.