A natureza do software

O software é um produto diferenciado dos demais, possuindo características que lhe dão uma natureza própria. Conhecer essas características é o primeiro passo para compreender os problemas enfrentados pelos desenvolvedores, e tentar lançar uma luz sobre as razões da existência da “crise do software”.

A partir da análise do software em estudos anteriores (BROOKS, 1995; KRUTCHTEN, 2001), enumerou-se as seguintes características:

• Grande complexidade;
• Ausência de conformidade;
• Invisibilidade;
• Ilusão de maleabilidade;

Grande complexidade

Softwares nascem das necessidades do cliente, portanto representam modelos do mundo real. Cada detalhe presente no problema que o software se propõe a resolver transforma-se num elemento a mais dentro da aplicação. Isso gera uma grande complexidade, que se torna maior a medida que o número desses elementos aumenta e exige a necessidade de interação entre si.

Sendo assim, cada nova funcionalidade acrescentada ao software exige além do esforço para construí-la, a necessidade de integrá-la com as demais. A complexidade resultante pode se estender a outros níveis se levarmos em consideração o elevado número de possíveis estados que o software pode alcançar.

Equipes de desenvolvedores tem grandes dificuldades em lidar com grandes sistemas. Ao contrário do que ocorre numa linha de montagem, o simples acréscimo de mais pessoas a uma equipe não torna o trabalho mais fácil. Com essa afirmação, remontamos a essência da lei de Brooks.

Adicionar mais pessoas a um projeto de software atrasado vai atrasá-lo ainda mais. (…) A concepção de uma criança leva nove meses, não importa quantas mulheres tenham sido designadas.

Frederick Brooks, The mythical man-month: essays on software engineering

Ausência de conformidade

A complexidade é um problema que afeta diversas áreas do conhecimento científico, entretanto a maioria delas se baseia na convicção de que existem princípios unificadores que, uma vez descobertos, facilitam sua compreensão. A física é um bom exemplo, com suas leis fundamentais ela é utilizada como sustentáculo para a engenharia civil. Sistemas de software, ao contrário disso, não costumam existir em conformidade com princípios básicos e imutáveis. Sendo assim, é impossível formar uma base sólida de conhecimento como a encontrada na engenharia tradicional. Essa inexistência de princípios básicos faz com os padrões de software costumem se basear apenas em boas práticas.

Grande parte da complexidade existente no software é arbitrária. Ela é imposta por instituições e sistemas humanos. Tal conformidade é dinâmica, visto que os sistemas humanos mudam com o tempo, as pessoas mudam e o software passa a ter que se adequar a novas realidades.

Frederick Brooks, No silver bullet: essences and accidents of Software Engineering

Não bastasse a dinâmica dos sistemas representados pelo software, a rápida evolução tecnológica gera mais uma incerteza: as próprias técnicas de desenvolvimento e ferramentas mudam em ritmo acelerado. Isso gera uma enorme pressão sobre as empresas e desenvolvedores, que devem constantemente receber novos treinamentos para se adequar as recentes tecnologias.

A medida que uma equipe de desenvolvimento passa a se atualizar, as empresas enfrentam outro problema: lidar com os sistemas legados. Tecnologias usadas em larga escala há dez ou vinte anos atrás hoje são obsoletas, e existe uma enorme dificuldade de se encontrar profissionais para mantê-las nos sistemas ainda em uso. O bug do ano 2000 já é um exemplo clássico.

Invisibilidade

Ao contrário de outros produtos o software não pode ser desenhado ou projetado de uma maneira que corresponda ao mundo real. Ele não possui natureza física e não pode ser definido geometricamente. Mesmo os diagramas criados para representá-lo na verdade não descrevem o software em si, mas fluxos de controle, fluxo de dados ou padrões de dependência. Isso dificulta o trabalho dos desenvolvedores que deve ser baseado apenas em representações abstratas.

Também a comunicação entre os membros da equipe fica prejudicada, uma vez que é difícil falar sobre um item abstrato. Dessa forma, parte do conhecimento sobre o projeto fica retido na mente de membros específicos da equipe, visto que esse conhecimento não pode ser representado de forma satisfatória.

Ilusão de maleabilidade

O software possui uma maleabilidade extremamente elevada. Por não ter natureza física, ele é notado pelas pessoas como algo de fácil adaptação. Em geral, indivíduos o acham extremamente maleável e crêem que qualquer mudança terá um baixo custo. É bastante comum o cliente mudar o escopo do projeto enquanto ele está em andamento, sem atentar para as implicações disso.

Se você constrói uma ponte, você não tem este tipo de flexibilidade. Você não pode dizer: “Hum, agora que eu já vejo os pilares, eu gostaria que essa ponte fosse colocada duas milhas rio acima”.

Philippe Krutchten, The nature of software: what’s so special about software engineering

Na situação acima, qualquer um teria a clara percepção do esforço monumental de mover uma ponte de um lugar a outro. Entretanto, no caso do software, sua invisibilidade como produto cria a ilusão de que é extremamente fácil realizar uma mudança, levando os usuário a solicitá-las com mais freqüência.

A partir da análise desses quatro pontos, podemos começar a discutir sobre as dificuldades associadas ao desenvolvimento de software. É interessante notar que essas quatro características possuem aspectos que extrapolam seus próprios limites, fazendo com que exista uma interdependência entre elas. Assim, podemos dizer que a ausência de conformidade contribui para a grande complexidade, ou que a ilusão de maleabilidade é conseqüência da invisibilidade.

De qualquer forma, possivelmente a invisibilidade é o problema central quando tratamos o desenvolvimento de software. A ausência de uma natureza física faz do software um produto intangível e por essa razão deve-se encontrar alguma maneira de tentar entender o seu funcionamento. As metáforas foram a principal ferramenta para se chegar a esse entendimento. Comparar o software a um outro elemento de mais fácil visualização ajuda a compreendê-lo melhor, e como conseqüência, a construí-lo de forma melhor. Daí o termo “engenharia de software”.

O termo “engenharia de software” foi escolhido deliberadamente para ser provocativo, cuja implicação era a necessidade de que a manufatura de software fosse baseada nos tipos de fundamentos teóricos e disciplinas práticas que são tradicionais em ramos estabelecidos da engenharia.

Pete McBreen, Software craftsmanship: the new imperative

Ao final da Conferência da OTAN sobre Engenharia de Software, em 1968, houve um consenso de que o projeto de desenvolvimento de software deveria ser estabelecido de forma análoga a outras disciplinas da engenharia. Desde então, os esforços dos engenheiros de software se concentraram na busca de um planejamento bem estruturado que unisse métodos, técnicas, ferramentas e atividades dentro de um ciclo de vida.

Comparar o desenvolvimento de um software a construção de um prédio pareceu natural nos idos da década de 60. Afinal, não existia nenhum processo estabelecido para a construção de softwares, e fundamentar seu desenvolvimento sobre os processos da engenharia tradicional seria uma escolha sensata.

Entretanto, visto que nos dias atuais a “crise do software” se faz tão presente quanto na época em que o termo foi cunhado, podemos nos perguntar: teria sido correto o uso da metáfora da engenharia quando tratamos de software?