"In the 1620s, Sweden and Poland were at war. The king of Sweden, Gustavus Adolphus, was determined to put a swift end to it and commissioned a new warship the likes of which had never been seen before. The Vasa, shown in Figures above, was to be the world's most formidable instrument of war: 70 meters long, able to carry 300 soldiers, and with an astonishing 64 heavy guns mounted on two gun decks. Seeking to add overwhelming firepower to his navy to strike a decisive blow, the king insisted on stretching the Vasa's armaments to the limits. Her architect, Henrik Hybertsson, was a seasoned Dutch shipbuilder with an impeccable reputation, but the Vasa was beyond even his broad experience. Two-gun-deck ships were rare, and none had been built of the Vasa's size and armament. Like all architects of systems that push the envelope of experience, Hybertsson had to balance many concerns. Swift time to deployment was critical, but so were performance, functionality, safety, reliability, and cost. He was also responsible to a variety of stakeholders. In this case, the primary customer was the king, but Hybertsson also was responsible to the crew that would sail his creation. Also like all architects, Hybertsson brought his experience with him to the task. In this case, his experience told him to design the Vasa as though it were a single-gun-deck ship and then extrapolate, which was in accordance with the technical environment of the day. Faced with an impossible task, Hybertsson had the good sense to die about a year before the ship was finished. The project was completed to his specifications, however, and on Sunday morning, August 10, 1628, the mighty ship was ready. She set her sails, waddled out into Stockholm's deep-water harbor, fired her guns in salute, and promptly rolled over. Water poured in through the open gun ports, and the Vasa plummeted. A few minutes later her first and only voyage ended 30 meters beneath the surface. Dozens among her 150-man crew drowned. Inquiries followed, which concluded that the ship was well built but "badly proportioned." In other words, its architecture was flawed. Today we know that Hybertsson did a poor job of balancing all of the conflicting constraints levied on him. In particular, he did a poor job of risk management and a poor job of customer management (not that anyone could have fared better). He simply acquiesced in the face of impossible requirements. The story of the Vasa, although more than 375 years old, well illustrates the Architecture Business Cycle: organization goals beget requirements, which beget an architecture, which begets a system. The architecture flows from the architect's experience and the technical environment of the day. Hybertsson suffered from the fact that neither of those were up to the task before him. "

taken and adapted from "Software Architecture in Practice", 2nd edition (Len Bass, Paul Clements and Rick Kazman)

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?