Adolfo Sousa

Quando o assunto é desenvolvimento de software, existem basicamente duas grandes “escolas” a se conhecer: a tradicional e a ágil. Cada uma delas enxerga e trata o processo de desenvolvimento de software e, consequentemente, qualidade de maneiras bem distintas.

Para os adeptos das metodologias tradicionais, que encaram o processo como uma cascata (primeiro alguém tem a visão do produto, depois algumas pessoas especificam o software, outras implementam, umas outras testam, a próxima coloca tudo isto em produção de uma vez para que então uma outra equipe não possa manter o software vivo, gerando algum tipo de valor), o conceito de qualidade se assemelha ao usado em processos de produção industrial: conformidade com requerimentos definidos na fase de design ou em alguma “receita”. A palavra chave que define qualidade neste cenário é conformidade. Espera-se que haja uma pré-definição clara do que é qualidade, do que é esperado, e se o software estiver “conforme” é possível dizer que o usuário dele estará lidando com um software de qualidade. Como é possível notar, variabilidade e diversificação não são desejáveis aqui.

Já os adeptos das metodologias ágeis tendem a enxergar qualidade de forma parecida com a qual prestadores de serviços a enxergam. O cliente de um software não sabe o que é ou não está preocupado com a qualidade, pelo menos não de uma forma definida, exata e clara. Ele pode estar em busca uma boa experiência ou esperando que o software lhe ajude a resolver algum problema. Talvez queira que o sistema lhe entregue algum valor mas também pode ser que diversão ou experimentação/inovação sejam o seu fim. Aqui, nenhum requerimento, documento ou receita definida previamente serve para atestar a qualidade do software. Então se não podemos definir, quer dizer que não há qualidade? De forma alguma. Neste cenário, qualidade não precisa ser exata, imutável, não precisa ter uma definição clara, não é possível lhe darmos um nome. O que buscamos, na verdade, é Qualidade Sem Nome, ou QWAN (Quality Without a Name).

Neste contexto, em que tratamos qualidade de forma não determinística, em que as expectativas mudam de usuário para usuário, alguns cuidados devem ser tomados para que, quando perguntarmos a um deles se determinado software tem qualidade, tenhamos como resposta algo do tipo: “hum, deixe-me ver… eu sinto que sim. Ele me ajuda, gosto dele, sinto confiança, ele é, como posso dizer, consistente”. Tarefa difícil, não? Difícil porém possível se entendermos dois conceitos extremamente importantes [1]:

1. Integridade Percebida - o produto como um todo alcança um equilíbrio entre funcionalidades, usabilidade, confiabilidade e economia que agrada os clientes.
2. Integridade Conceitual - os conceitos e partes centrais do sistema trabalham harmonicamente, de forma coesa, como um todo. Os componentes ou módulos se integram e trabalham bem conjuntamente.

Como você pôde notar, a Integridade Percebida e a Conceitual estão intimamente ligadas e têm papel fundamental na qualidade do software desenvolvido. Por esta razão, vou dedicar o próximo post desta série para discuti-las mais a fundo.

Até a próxima.

[1] - Os conceitos de Integridade Percebida e Integridade Conceitual foram extraídos do excelente livro Lean Software Development - An Agile Toolkit da Mary e do Tom Poppendieck. Eles, por sua vez, adaptaram os conceitos de “Internal Integrity” e “External Integrity” contidos no livro Product Development Performance de Kim Clark e Takahiro Fujimoto

Qualidade de software é um assunto pouco discutido por nós, profissionais da área. Já ouvi repetidas vezes o argumento de que este fenômeno acontece porque se trata de uma “indústria” ainda muito nova. Pode ser nova se comparada com outras como a têxtil ou a automobilística. Entretanto, não podemos aceitar argumentos conformistas como este e nem tampouco encarar desenvolvimento de software como indústria, sob pena de nos colocarmos num ambiente pouco adaptável, repetitível, prescritivo e de inovação lenta e cara. Não acredito que esta seja a natureza dos projetos de software.

Independentemente da maturidade deste nosso ofício, ou melhor, arte, qualidade deve fazer parte do seu processo de desenvolvimento e, portanto, não há motivo algum para não discuti-la com a mesma frequência que discutimos outros assuntos como linguagens, frameworks, metodologias, arquiteturas, etc.

Pretendo iniciar uma série de posts para falar de qualidade de software. Sejam bem-vindos e sintam-se livres para fazer parte da discussão.

—————

Parte 2 - http://www.adolfosousa.com.br/blog/2010/02/10/o-que-e-qualidade-de-software/