Qualidade do código-fonte

Uma função implementada errada sob um código-fonte bom tem exatamente o mesmo valor da mesma função implementada sob um código ruim. Da mesma (e exata forma) uma função correta (que está conforme com a especificação que a definiu) sob um código ruim tem exatamente o mesmo comportamento se implementada com código bom, ou seja, funciona em ambos os casos.
Por outro lado, nenhum desenvolvedor de software estará suficientemente satisfeito com a qualidade da implementação que ele define em um código-fonte.

A qualidade do processo afeta diretamente a qualidade do produto (como o bom Deming já definiu um dia) mas ... a discussão é quanto a qualidade da implementação (código-fonte) afetará o resultado do software (que é definido por um arquivo binário, um executável, uma biblioteca e assim por diante).

Há empresas que protegem os documentos de projeto (design) a "7 chaves" (o que sugere que, para eles, no projeto de definição daquele software está embutido o valor daquele produto) e, em contraponto, a comunidade open-source entende que o código-fonte é a documentação mais importante de um software: Aqui está embutida uma idéia de que o software, por exemplo, não precisa ser versionado porque ele estará na versão "beta" para sempre (e isso sugere que nunca há o que entregar definitivamente porque ... nenhuma versão é definitiva).

Por mais que se simplifique a forma de definir o software nunca será possível caracterizar como produto o que nunca se entrega. Mesmo o criticado "modelo Microsoft" embute nele questões amplamente consagradas pela dita "indústria tradicional": preço, entrega, lucro, contrato de licença de usuário, suporte e garantia.

Abstraindo-se o aspecto "romântico" (e, às vezes, utópico) das novas tecnologias seria saudável que as novas perspectivas sejam mais analisadas não sob o ponto de vista de quem fornece (a exemplo das iniciativas da IBM com o Linux e a comunidade open-source) mas sob o uso e, aí sim, ouvindo mais o lado de quem tem comprado, usado e, claro, tem tido que se relacionar com as entidades de quem adquiriram tais produtos.

Que tanto a indústria como o "mercado" tenham de estar suscetíveis às novas demandas de inovação e tecnologia, o fato é inegável, mas mudar o paradigma sem o sustentáculo da análise de um contexto mais abrangente que mitigue riscos, gastos e prejuízos não passa de irresponsabilidade.

http://www.artima.com/weblogs/viewpost.jsp?thread=96154

Porque qualidade de software?

Graças ao invento de Ted Hoff, um jovem engenheiro da Intel, em 1969 foi possível inserir num pequeno pedaço de silício os elementos necessários para o processamento computacional. O feito de Hoff ajudou a produzir a primeira calculadora (projeto da Intel para a empresa japonesa Busicom) capaz de executar inúmeras funções inovadoras, além do que ajudou a mudar radicalmente a abordagem original do projeto. Dois anos mais tarde a Intel lançou o 4004, o primeiro microprocessador, que se constituiu do empacotamento de todos os elementos necessários ao funcionamento de um computador num pequeno pedaço de material que geralmente é o silício. Os avanços da tecnologia da informação, extrapolados da iniciativa de Hoff, como os computadores, as redes e os avanços produzidos com software, fizeram com que as Organizações passassem a abordar os recursos de TI como sendo críticos para atingir o sucesso dos negócios.
Em uma primeira abordagem, o software parece não ter uma forma tangível, pode assumir um número infinito de formas para, pelo menos teoricamente, atender a um cem número de aplicações. Graças a essas características e ao seu alto padrão de abstração e maleabilidade, pode-se considerar que a inovação tecnológica em software não conhece limites. Contudo, esta não representa a realidade. Para a maioria das pessoas usuárias do software ele não existe como uma “idéia”, ou qualquer tipo de abstração. A realidade mostra que o software tem sido abordado como um produto tangível, comprado com dinheiro e espera-se dele a aplicabilidade de resultados práticos reais. Desta feita, também, o produto de software está sujeito ao efeito de regras econômicas, mercados e competição, tanto quanto qualquer outro produto físico.
A manufatura iniciou a abordagem da qualidade procurando a medida da qualidade no produto acabado e, depois sob a influência de Deming, Juran e Shewhart, passou a considerar todo o processo de produção e, em seguida, extendeu a abordagem para a Organização como um todo. É inegável, ainda, o consenso em torno da engenharia que amparou as premissas da não-adeqüação na manufatura, o que não se tem observado em Organizações envolvidas com a construção de software. Estas tem se deparado com dificuldades específicas como a necessidade de alta e complexa tecnologia, a dificuldade de se testar o software e problemas de gerenciamento específicos. A tentativa de repetição do modelo da manufatura para a indústria de software, assim, revelou o impacto da peculiaridade da construção de um produto intangível. Os envolvidos com a construção do software criaram normas, métodos, metodologias e práticas com a abordagem centrada no desenvolvimento do produto de software. Mas que qualidade de software temos com tudo isso?