UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE

LEITURA COMPLEMENTAR

O MÍTICO HOMEM-MÊS

Cozinhar bem leva tempo. Se fazemos você esperar é para servi-lo melhor e deixá-
lo satisfeito. Menu do Restaurante Antoine, Nova Orleans.

Em sua maioria, projetos de software falharam mais por falta de tempo no

calendário do que em função da combinação de todas as outras causas. Porque
isso é tão comum?

Em primeiro lugar, porque nossas técnicas para estimativa são muito

pouco desenvolvidas. Na verdade, elas refletem uma premissa não verbalizada e
completamente falsa que é a de que tudo correrá bem.

Em segundo lugar, porque nossas técnicas de estimativa falaciosamente

confundem esforço com progresso, escondendo a premissa de que homens e
meses são intercambiáveis.

Em terceiro lugar, porque não temos certeza de nossas estimativas. Aos

gerentes de software costuma faltar a insistência cordial do chef do restaurante
Antoine.

Em quarto lugar, porque o cronograma de progresso é monitorado de

forma precária. Técnicas comprovadas, que são rotina em outras disciplinas de
engenharia, são consideradas inovações radicais em engenharia de software.

Em quinto lugar, porque, quando se admite um atraso no cronograma, a

resposta natural (e tradicional) é a adição de mais força de trabalho. Assim como
combater um incêndio com gasolina, essa resposta torna a situação pior, muito
pior. Mais fogo requer mais gasolina e, assim, inicia-se um ciclo de regenerativo
que termina em um desastre.

O monitoramento do cronograma será assunto de ensaio à parte. Vamos

considerar outros aspectos do problema com mais detalhes.

Otimismo

Todos os programadores são otimistas. Talvez essa feitiçaria moderna

atraia, especialmente, aqueles que acreditam em finais felizes e fadas madrinhas.
Talvez as centenas de pequenas frustrações afastem todos, menos aqueles que
se focam, habitualmente, no objetivo final. Talvez esse otimismo seja meramente
porque os computadores são jovens, os programadores mais jovens ainda e
os jovens sempre são otimistas. Mas, independentemente da forma pela qual
funciona o processo seletivo, o resultado é inegável: “Desta vez, com certeza vai
funcionar”, ou “Acabo de encontrar o último erro”.

52
 TÓPICO 3 | REQUISITOS DE SOFTWARE

Assim a primeira falsa premissa inerente é confecção do cronograma de

programação de um sistema é a de que tudo irá bem, isto é, que cada tarefa tomará
apenas o tempo que “deve” tomar.

A disseminação do otimismo entre programadores merece mais do que

uma rápida análise. Dorothy Sayers, em seu excelente livro The Mind of the Maker
(A mente do criador), divide a atividade criativa em três estágios: a ideia, a
implementação e a interação. Assim, um livro, um computador ou um programa
passam a existir primeiro com um construto ideal, feito fora do tempo e do espaço,
mas completo na mente do autor. Depois, se tornam reais no tempo e no espaço,
com caneta, tinta e papel, ou com fios, silício e ferrite. A criação está concluída
quando alguém lê o livro, usa o computador ou executa o programa, interagindo
dessa forma com a mente do criador.

A descrição que a Senhoria Sayers utiliza para esclarecer não apenas a

criatividade humana, mas doutrina cristã da Santíssima Trindade nos ajudará
em nossa tarefa presente. Como criadores humanos de coisas, a incompletude
e inconsistência de nossas ideias tornam-se claras apenas durante sua
implementação. Assim, a escrita, a experiência e o exercício são disciplinas
essenciais ao teórico.

Em muitas atividades criativas, o meio de execução é intratável. A madeira

racha, a tinta escorre, os circuitos elétricos dão choque. Essas limitações físicas do
meio cerceiam ideias que poderiam ser expressas e também criam dificuldades
inesperadas em sua implementação.

A implementação, então, consome tempo e suor, tanto em função do

meio físico como da inadequação das ideias que o utilizam. Temos a tendência
de culpar o meio físico pela maioria das dificuldades de implementação, pois o
meio não é “nosso” da mesma maneira que as ideias o são, e nosso orgulho colore
nosso julgamento.

A programação de computadores, ao contrário, dá-se em um meio

excepcionalmente tratável. O programador constrói a partir do pensamento puro,
com conceitos e representações extremamente flexíveis. Como o meio é tratável,
esperamos poucas dificuldades de implementação, daí esse otimismo dominante.

Mas, como nossas ideias têm falhas, nós temos problemas. Por isso, tanto
otimismo não se justifica.

Em uma única tarefa, a premissa de que tudo correrá bem tem um

efeito probabilístico no cronograma. Pode até acontecer que ela se dê conforme
o planejado, já que existe a probabilidade de atrasos que serão solucionados,
sendo que “nenhum atraso” tem, também, uma probabilidade finita. Um grande
esforço de programação, porém, consiste em muitas tarefas, algumas encadeadas
em dependência de outras. A probabilidade de que tudo vá bem se torna mínima.

53
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE

O Homem-Mês

A segunda falácia se manifesta na própria unidade de esforço usada em

estimativas e cronogramas: o homem-mês. O custo, de fato, varia como o produto
de números de pessoas envolvidas e da quantidade de meses. O processo não.
Dessa forma, o uso do homem-mês como unidade para medir o tamanho de um trabalho
é um mito perigoso e enganoso. Ele implica o fato de que homens e meses são
intercambiáveis.

Homens e meses são intercambiáveis apenas quando uma tarefa pode ser
dividida entre muitos trabalhadores que não se comuniquem entre si (Figura 2.1).
Isso é verdade quando se debulha trigo ou se colhe algodão, mas não é sequer
aproximadamente real quando se trata de programação de sistemas.

FIGURA 2.1: Tempo versus número de trabalhadores em uma tarefa perfeitamente divisível.

Quando uma tarefa não pode ser dividida em função de limitações

sequenciais, a aplicação de mais esforço não tem efeito algum no cronograma
(Figura 2.2). Ter um filho leva nove meses, independentemente de quantas
mulheres sejam responsáveis pela tarefa. Muitas tarefas de software têm essa
característica em função da natureza sequencial de uma depuração (debugging).

54
 TÓPICO 3 | REQUISITOS DE SOFTWARE

FIGURA 2.2: Tempo versus número de trabalhadores em uma tarefa indivisível.

Em tarefas que podem ser divididas, mas que necessitam de comunicação

entre as subtarefas, o esforço de comunicação deve ser adicionado á qualidade de
trabalho a ser realizado. Assim, o melhor que pode ser feito é algo mais ineficaz
do que a troca parelha entre meses e homens (Figura 2.3).

FIGURA 2.3: Tempo versus número de trabalhadores em uma tarefa divisível que requer
comunicação.

55
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE

O peso adicional da comunicação é composto de duas partes: treinamento

e intercomunicação. Cada trabalhador deve ser treinado na tecnologia, nos
objetivos do trabalho, na estratégia geral e no planejamento da execução. Esse
treinamento não pode ser dividido, assim, parte do esforço adicional varia
linearmente com o número de trabalhadores.

A intercomunicação é um fator mais grave. Se cada porção da tarefa deve

ser separadamente coordenada com demais, o esforço aumenta em n(n-1)/2. Três
trabalhadores requerem três vezes mais comunicação entre pares do que dois
trabalhadores; quatro querem seis vezes mais do que dois. Se, além disso, há
a necessidade de conferências entre três, quatro ou mais trabalhadores, para
resolver questões em conjunto, a situação fica ainda pior. O esforço adicional
de comunicação pode ir totalmente contra a divisão da tarefa original e levar à
situação da Figura 2.4.

Como a construção de software é, por natureza, um trabalho sistemático –

um exercício em inter-relações complexas – o esforço de comunicação é grande
e rapidamente domina a diminuição do tempo de cada tarefa individual que foi
estabelecido na sua divisão. A adição de mais homens, portanto, aumenta, e não
diminui o tempo no cronograma.

FIGURA 2.4 - Tempo versus número de trabalhadores em uma tarefa com inter-relações
complexas.

Testes de Sistema

Nenhuma outra parte do cronograma é tão profundamente afetada pelos

limites sequenciais do que a depuração dos componentes e os testes do sistema.
Além disso, o tempo requerido depende do número e da sutileza dos erros
encontrados. Teoricamente, esse número deveria ser zero. Por causa do otimismo,
o normal é esperarmos que o número de erros de programação (bugs) seja inferior
ao que é na realidade. Por isso, a fase de testes costuma ser a de pior estimativa

56
 TÓPICO 3 | REQUISITOS DE SOFTWARE

em uma tarefa de programação.

Durante alguns anos, tive sucesso usando a seguinte regra geral para
programar uma tarefa de software:

1/3 planejamento
1/6 codificação
1/4 testes de componentes e testes iniciais do sistema
1/4 testes do sistema, todos os componentes disponíveis.

Isso difere da programação convencional de um cronograma de várias formas

importantes:

1. A fração dedicada ao planejamento é maior que a normal. Mesmo assim, ela é

apenas marginalmente suficiente para produzir uma especificação detalhada
e sólida e não o suficiente para incluir a pesquisa ou exploração de técnicas
totalmente novas.
2. A metade do cronograma dedicada à depuração do código completo é muito
maior que o normal.
3. Para a parte que é fácil de estimar, ou seja, a codificação dá-se apenas um sexto
do cronograma.

Ao examinar projetos convencionalmente programados, descobri que

poucos deixavam metade do cronograma para testes, mas que de fato usavam
metade do cronograma real para esse propósito. Muitos deles estavam em dia,
até entrar na fase de testes do sistema.

A falha em permitir tempo para testes do sistema, em particular, é

peculiarmente desastrosa. Como o atraso acontece no final do cronograma,
ninguém está a par do problema até quase a data de entrega do projeto. Notícias
ruins, atrasadas e sem aviso prévio, são incômodas para clientes e gestores.

O mais grave é que, neste ponto, o atraso tem repercussões anormais

e severas, tanto financeiras quanto psicológicas. O projeto está com a equipe
completa, e o custo por dia está em seu máximo. Mais seriamente, o software deve
dar suporte a outros esforços de negócio (remessa de computadores, operação
de novas filiais etc.) e os custos secundários do atraso de tais esforços são muito
altos, pois está próximo o momento de entrega do software. De fato, esses custos
secundários podem ultrapassar bastante todos os demais. Por isso, é muito
importante permitir tempo suficiente para os testes do sistema na programação
original.

Estimativa desembasada

Observe que, tanto para o programador como para seu chefe, a urgência
do cliente pode governar a data de finalização programada para uma tarefa,
mas não pode governar sua finalização real. Uma omelete prometida para dois

57
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE

minutos pode dar a impressão de que tudo está indo bem. Mas, se a omelete não
fica pronta em dois minutos, o cliente tem duas opções: esperar ou comê-la cru.
Os clientes de software têm tido as mesmas opções.

O cozinheiro tem uma alternativa: ele pode aumentar o fogo. O resultado

não raro é algo que não pode ser salvo – queimado em uma parte, cru em outra.

Agora, eu não penso que gerentes de software têm coragem e firmeza

inerentes que sejam menores do que as de um chef, nem que as de outros gerentes
de outras áreas de engenharia. Mas o agendamento enganoso para atender ao
desejo que o cliente tem por uma determinada data é muito mais comum na
nossa disciplina do que em qualquer outra engenharia. É muito difícil fazer uma
defesa vigorosa, plausível, com risco para o nosso trabalho, de uma estimativa
que não é derivada de nenhum método quantitativo, suportada por poucos dados
e garantida principalmente por palpites de gerentes.

E claro que são necessárias duas soluções. Precisamos desenvolver e

publicar números de produtividade, números de incidência de erros, regras
para estimativas e assim por diante. Toda a profissão pode apenas lucrar com o
compartilhamento de tais dados.

Enquanto a estimativa basear-se em palpite, os gerentes individuais

precisam calejar sua pele e defender tais estimativas com a garantia de que seus
fracos chutes são melhores do que cronogramas derivados de desejos.

Desastre do Cronograma Regenerativo

O que fazer quando um projeto de software essencial está atrasado? Inclua

mais pessoas, naturalmente. Como as Figuras 2.1 até 2.4 mostram, isso pode
ajudar ou não.

Vamos considerar um exemplo. Suponha que uma tarefa é estimada em

12 homens-mês, entregue a três homens por quatro meses, e que existem pontos
mensuráveis de verificação A, B, C, D, que estão programados para ocorrer ao
final de cada mês (Figura 2.5).

Agora imagine que o primeiro ponto de checagem não é atingido até que
se passem dois meses (Figura 2.6). Quais são as alternativas que se apresentam
ao gerente?

1. Assuma que a tarefa deve ser concluída a tempo. Assuma que houve erro
apenas na estimativa da primeira parte da tarefa, assim, a Figura 2.6 informa
corretamente a situação. Dessa forma, nove homens-mês de esforços ainda
restam, e dois meses, então 4 ½ homens serão necessários. Adicione dois
homens aos três já designados.

58
 TÓPICO 3 | REQUISITOS DE SOFTWARE

2. Assuma que a tarefa deve ser concluída a tempo. Assuma que a estimativa está
uniformemente baixa. Dessa forma, a Figura 2.7 realmente descreve a situação.
Os 18 homens-mês de esforço ainda restam, e dois meses, assim, nove homens
serão necessários. Adicione seis homens aos três previamente designados.

FIGURA 2.5

FIGURA 2.6

3. Reprograme. Aprecio muito o conselho de P. Fagg, experiente engenheiro de

hardware: "Não aceite pequenos atrasos". Isso significa permitir tempo suficiente
no cronograma para garantir que o trabalho possa ser feito de forma cuidadosa
e atenta e que reprogramações não precisem ser feitas.
4. Redimensione a tarefa. Na prática, isso tende a acontecer de qualquer maneira
quando a equipe detecta um atraso no cronograma. Quando os custos secundários
do atraso são muito altos, essa é a única ação factível. As únicas alternativas do
cliente são redimensionar a tarefa formal e, cuidadosamente, reprogramar o
cronograma, do contrário ele terá de observar a tarefa sendo silenciosamente
prejudicada por um projeto apressado ou por testes incompletos.

59
UNIDADE 1 | PROCESSOS E REQUISITOS DE SOFTWARE

FIGURA 2.7

Nos primeiros dois casos, é um desastre insistir que a tarefa inalterada

esteja concluída em quatro meses. Analise os efeitos regenerativos, por exemplo,
da primeira alternativa (Figura 2.8). Os dois novos homens, mesmo competentes
e rapidamente contratados, precisarão de treinamento na tarefa com a orientação
de um dos programadores experientes. Se esse treinamento levar um mês, três
homem-meses estarão devotados a trabalhar fora da estimativa original. Além disso, a
tarefa originalmente dividida em três terá que ser redividida em cinco partes e,
assim, algum trabalho já efetuado se perderá e mais tempo terá de ser dado aos
testes do sistema. Logo, ao final do terceiro mês, substancialmente mais do que
sete homens-meses de esforços ainda restarão, e cinco pessoas treinadas e um
mês são o que está disponível. Como a Figura 2.8 apresenta, o produto estará tão
atrasado quanto já estaria se ninguém fosse adicionado ao projeto (Figura 2.6).

Para manter a esperança de terminar o trabalho em quatro meses,

considerado apenas o tempo de treinamento e não a redistribuição das tarefas
e testes extras do sistema seria necessária a adesão de quatro homens, não dois,
ao final de segundo mês. Para cobrir os efeitos da redistribuição e dos testes do
sistema, seria necessário adicionar ainda outro homem. Agora se tem, entretanto,
uma equipe de ao menos sete homens, não uma de três. Assim, aspectos
organizacionais da equipe e da divisão de tarefas são diferentes com espécie, não
apenas em grau.

60
 TÓPICO 3 | REQUISITOS DE SOFTWARE

FIGURA 2.8

Note que ao final do terceiro mês a situação parece tenebrosa. O ponto de

checagem de 1o. de março não foi atingido, apesar de todo o esforço gerencial. A
tentação de repetir o ciclo é muito forte, adicionando ainda mais homens. E aí que
se chega à fronteira da loucura.

O que foi feito a seguir baseou-se na constante presença da premissa de

que apenas o primeiro ponto de checagem foi mal estimado. Se, em 1º de março,
fosse assumida a premissa conservadora de que todo o cronograma foi otimista,
como mostra a Figura 2.7, seriam adicionados seis homens apenas para a tarefa
original. O cálculo dos efeitos do treinamento, da revisão dos testes do sistema
fica como um exercício para o leitor. Sem dúvida, o desastre regenerativo levará
a um produto mais pobre com mais atraso do que levaria a reprogramação do
cronograma com os três homens originais, sem novas adições.

Simplificando ao máximo, declaramos a lei de Brooks:

A adição de recursos humanos a um projeto de software atrasado ira atrasá-lo

ainda mais.

Eis aqui, então, a desmitificação do homem-mês. O número de meses

de um projeto depende de seus limites sequenciais. O número máximo de
homens depende do número de subtarefas independentes. A partir dessas duas
quantidades é possível deduzir cronogramas, usando menos homens e menos
meses. (O único risco é a obsolescência do produto.) Não é possível, entretanto,
ter cronogramas funcionais utilizando mais homens e menos meses. Projetos de
software falharam, em sua maioria, mais por falta de tempo no calendário do que
em função da combinação de todas as outras causas.

FONTE: BROOKS, Frederick Phillips. O mítico homem-mês: ensaios sobre engenharia de

software. Rio de Janeiro: Elsevier, 2009, p. 14-24.

61