Coisa bacana do fórum de UML. Como cobrar o preço do seu cliente:
Emmanuel

Funciona sim. Veja o que escrevi:

> Você vai lá, entende a idéia do software e usa um método
> de estimativa qualquer. Por exemplo, chutômetro. Seu
> objetivo não é fechar realmente preço e prazo, mas
> entender qual preço e qual prazo são aceitáveis para seu
> cliente.

Ou seja, um entendimento macro do sistema e do esforço. Se vc não
conhece o negócio, aumente o fator de risco.

> A adoção da abordagem iterativa do tipo "time boxed"
> determina que uma vez estipulados prazo e preço, esses
> itens tornam-se imutáveis.

Isso responde à sua pergunta: O PROJETO TEM UM PREÇO FINAL e é o
primeiro preço que vc passou, no passo anterior.

Você perguntou:
>> meio do caminho cara vai te explicar que para
>> determinado processo ele faz um monte de coisas que você
>> não tinha previsto. Mas aí como você fechou um
>> valor com o cara...

Não tem problema. Você fechou um valor e um prazo. Vejamos o que eu
disse na msg anterior a esse respeito:

> Durante as iterações, você trabalhará com escopo
> deslizante. Haverá uma lista de funcionalidades,
> priorizadas pelo cliente. Em cada iteração, serão
> implementadas tantas funcionalidades quanto a equipe
> de desenvolvimento conseguir.
>
> Ao final de cada iteração, o cliente avaliará o resultado
> e dirá as mudanças que quer.
>
> A equipe avaliará as mudanças e dirá quanto "custam"
> em termos de *TEMPO*. O cliente deverá então eleger as
> funcionalidades da lista original irão "morrer" para dar
> lugar às mudanças solicitadas. E assim por diante.
>
> A premissa é que até 40% das funcionalidades de um
> sistema nunca são usadas. Esses 40% é que morrem durante
> as iterações.
>
> No final, o cliente tem um sistema menor do que o pensado
> originalmente, mas que atende plenamente suas necessidades,
> dentro do prazo e dentro do orçamento.

Entendeu?

O segredo está em combinar a regra do jogo com o cliente. Funciona.

[]s

MT.