Por que as empresas de engenharia de software não contratam apenas desenvolvedores de garagem?

Referência: Dilbert.com

A metáfora do desenvolvedor de garagem pode ser muito mais norte americana do que brasileira ou de outros países, mas a pergunta é válida e nós todos já a ouvimos de formas diferentes no início de projetos de tecnologia da informação:

- Por que vocês, que são profissionais de informática, vão levar 8 meses pra desenvolver esse sisteminha? Eu faço isso em um mês com excel aqui na minha área mesmo?

- Vai custar tudo isso? Com meu excel seria de graça...

Ou a minha forma preferida desta pergunta:

- Oito meses? Meu filho disse que faz isso pra mim em poucas semanas...

Todas estas perguntas são variações da pergunta: por que as empresas de tecnologia não mandam embora todos os seus engenheiros de software, analistas de sistemas, gerentes de projetos, etc, e contratam dois ou três adolescentes trabalhando em casa?

No livro The Mythical Man-Month, Frederick Brooks propõe uma resposta interessante a esta pergunta. O livro reuni uma série de ensaios sobre engenharia de software desenvolvidos ao longo da vida em corporações (ele foi o gerente do projeto do IBM System/360) e acadêmica. Vários dos ensaios são bem interessantes, sendo o melhor o que dá nome ao livro, mas alguns são bem datados e só servem como curiosidade histórica.

O que o Brooks argumenta sobre a questão deste post é que o desenvolvedor de garagem constrói o programa, ainda que bem feito e testado pelo próprio desenvolvedor (teste unitário), enquanto a engenharia de software entrega um produto de sistema, que deve incluir, além do programa inicial:

• O código deve ser generalizável e manutenível;
• Os testes devem ser, além do inicial, o integrado, o de aceitação pelo usuário e o de regressão (no mínimo, além de outros quando aplicáveis), com os scripts e evidências de execução e sucesso;
• Documentação completa e "viva" tanto para o usuário final quanto para a equipe técnica; e
• As interfaces devem estar construídas, testadas e documentadas.

Todas estas atividades e produtos elevarão, tipicamente (número do Brooks) em nove vezes o tempo e custo do programa desenvolvido originalmente, mas deverão trazer uma contraparte em qualidade.

Achei a resposta do Brooks interessante, mas nos leva a pensar se temos entregado todos estes produtos de forma clara e com qualidade, para que o cliente consiga ver o que compõe o tempo e o custo a mais.

Qualidade de software: importância da revisão de requisitos e de código

A dificuldade na obtenção dos requisitos. Referência: Dilbert.com

A fase de desenho em um projeto de engenharia de software é quando os requisitos iniciais do cliente - que é, ou representa, o futuro usuário do software - se transformam no modelo detalhado do que será construído, testado, implantado e suportado nas etapas seguintes do ciclo de vida de uma solução de software.

Os engenheiros de software sabem que uma fase de desenho bem sucedida é determinante para um bom resultado do projeto, para uma quantidade pequena de mudanças nos requisitos e, posteriormente, no código construído ou reusado (pois pode garantir, neste caso, que o código reutilizado atende, de fato, às necessidades do usuário).

Considerando como qualidade na fase de desenho a mínima quantidade possível de erros e mudanças no software que virá a ser construído, vamos explorar algumas estatísticas sobre quantidade de erros em projetos de software. É importante ressaltar que esse parâmetro, no entanto, é apenas uma faceta da qualidade de software, pois se percebe claramente que ele não tem influência na usabilidade da interface de um aplicativo, por exemplo, e a clareza na interface é um parâmetro essencial da qualidade percebida pelo usuário.


Conforme estatísticas do mercado norte americano de desenvolvimento de software, para cada ponto de função construído, encontraremos, tipicamente, 5 erros. No momento que este aplicativo for disponibilizado para uso, em torno de 3% destes erros ainda estarão presentes (97% de eficiência na remoção dos erros) se forem empregadas técnicas de revisão de requisitos, revisão de código e análise estática (static program analysis). Se estas técnicas não forem empregadas, em torno de 15% dos erros no código ainda estarão presentes no software (85% de eficiência na remoção dos erros).


Para exemplificar, um software de 2.000 pontos de função, que seria um aplicativo de porte médio, terá, no mínimo, 300 erros no seu código (eficiência de 97% na retirada dos erros gerados), podendo chegar a 1.500 (eficiência de 85% na remoção dos erros).


Se considerarmos que em torno de 15% dos erros são críticos, teremos de 45 a 225 erros críticos no momento do início do uso do nosso software. Isso é muito. Entregamos aos nossos usuários, segundo esta estatística, em um software de porte médio, até 225 erros que o farão parar o seu processo de negócio e lhe trarão impacto financeiro de algum tipo.


Se refizermos as contas para um software grande (10.000 pontos de função) chegaremos a uma expectativa de encontrar entre 1.500 e 7.500 erros no momento da entrega do software, sendo de 225 a 1.125 erros críticos.


Fica bem evidente que perseguir a qualidade no processo da engenharia de software é um esforço primordial. A revisão dos requisitos capturados e do código desenvolvido se torna fundamental para que o projeto se aproxime do máximo de eficiência na remoção dos erros (97%), mas estas práticas não são, infelizmente, comuns no mercado de software hoje em dia. 


Uma alternativa é estabelecer uma revisão informal entre os analistas de requisitos e programadores envolvidos em um projeto, de forma que eles revisem mutuamente os requisitos e códigos uns dos outros. Com isso não será atingido o máximo de eficiência que a revisão formal permitiria (97%), mas será atingido mais que os 85% medianos.




Referência:

Software Engineering Best Practices by Capers Jones.

Engenharia de software, gurus e evangelizadores.

Estranha a nossa engenharia de software que tem gurus.

Sempre me chamou a atenção em eventos de tecnologia da informação o fato de que novas tecnologias são defendidas por gurus e evangelizadores.

Se um engenheiro civil desenvolve uma nova técnica para construir pontes, ele precisa apresentá-la para os seus pares com dados empíricos, estatísticas e pesquisas bem embasadas que comprovem a superioridade da nova técnica sobre as que estão em uso. Desta forma, ele pode convencer outros engenheiros a empregá-la. Não adianta que ele seja persuasivo, fale bem ou dê excelentes palestras. Os outros engenheiros não vão arriscar o uso de algo novo baseado nisso.

Na engenharia de software, no entanto, temos o título formal - e algumas empresas tem mesmo esses cargos em seus quadros - de guru, ou evangelizador, como alguém responsável por disseminar uma nova tecnologia. É comum irmos a palestras e um guru nos explicar porque o twitter ou o Facebook, por exemplo, vão revolucionar a forma de comunicação entre pessoas e sistemas dentro das corporações e porque eles devem ser incorporados de imediato ao dia a dia das empresas. Raramente, no entanto, nos é apresentado qualquer dado ou fato que comprove que esta mudança ocorrerá ou revolucionará para melhor os processos e negócios das corporações. Não tenho nada contra twitter e Facebook e a revolução que eles vêm causando fora das corporações. O meu ponto é: se queremos que a engenharia de software seja uma engenharia, precisamos suportar as nossa técnicas e tecnologias com dados empíricos.

Os gurus e evangelizadores são profundos conhecedores das novas tecnologias, metodologias e técnicas que apresentam, mas a metáfora voltada pra fé, e não fatos, acaba por depor contra a engenharia de software como uma verdadeira engenharia.

Sei da dificuldade de se obter dados empíricos e estatísticos sobre desenvolvimento de software, mas um bom começo no dia a dia do engenheiro de software seria usar as estatísticas do próprio profissional envolvido. Um gerente de projetos, por exemplo, pode se apresentar ao início de uma empreitada detalhando o seu portfólio: quantos projetos já tocou, quantos relacionados ao que ele está começando, qual sua taxa de sucesso e insucesso e o quê, com base em dados empíricos, ele percebeu que pode ser feito em um projeto para levá-lo ao sucesso ou reduzir ao máximo a possibilidade de problemas.

Se agirmos com este espírito, os nossos clientes se sentirão mais seguros e, um dia, a nossa disciplina pode deixar de ser vista com tanta desconfiança pelas corporações. Ou nunca aconteceu de você ser olhado de lado, no início de um projeto, por um cliente desconfiado que já tem uma lista de projetos de TI traumáticos no seu passado?