O Sofisma do Plano do Projeto
Detalhado em Desenvolvimento de
Software – Visões da Prática

    Prof. Rogério Atem de Carv...
Objetivo deste Documento

●   Mostrar, por argumentação lógica que a
    construção de planos de projeto detalhados no
   ...
O Plano do Projeto na Indústria
●   Trataremos inicialmente da indústria que trabalha
    por encomenda e não a que produz...
O Plano do Projeto na Indústria
●   O planejamento se baseia em técnicas de
    estimativa de alocação de recursos bem
   ...
O Plano do Projeto na Indústria
●   Com estimativas precisas e um produto totalmente
    projetado, faz sentido programar ...
O Plano do Projeto na Indústria
●   Resumindo: por que o ciclo em cascata é aceito e
    muito usado nas Engenharias?
    ...
Primeiro Encadeamento Lógico
  Planejamento detalhado precisa de → estimativas
    detalhadas (para definição do prazo = r...
Primeiras conclusões
●   A argumentação poderia parar aqui já que cairia
    numa discussão de uso ou não do Ciclo em
    ...
A Dura Realidade do Software
●   Infelizmente, o software é um produto intangível,
    produzido por trabalhadores do conh...
A Dura Realidade do Software
●   Em termos práticos, de onde vem a incerteza no
    software?
    – Rápidas mudanças tecno...
Segundo Encadeamento Lógico
  Software → bem intangível, produto não físico
  Software → produção baseada no conhecimento,...
Primeiras conclusões
●   Os planejamento do projeto detalhado funciona na
    indústria de bens materiais, porém foi trans...
Primeiras conclusões
●   Um diálogo possível (digamos em dezembro de 2009):
     – Preciso do planejamento detalhado para ...
Primeiras conclusões
●   Então, quem poderá intervir?
    Spectroman?
    Super Mouse?
    Chapolin Colorado?
    Mais con...
Produzindo com Incerteza na
Demanda
●   A indústria de bens de consumo produz bens
    tangíveis, com tempos de produção r...
Produzindo com Incerteza na
Demanda
●   Na contramão do Ocidente, os japoneses criaram
    um sistema simples, de controle...
Produzindo com Incerteza na
Demanda
●   Esse sistema se baseia em:
    –   Valorização do trabalhador
    –   Qualidade du...
Produzindo com Incerteza na
Demanda
●   Para quem duvida como métodos simples podem
    ser a solução para problemas compl...
Produzindo com Incerteza na
Demanda
●   Resposta:
    –   Subordinando o processo ao produto e não o contrário!
    –   Su...
Produzindo com Incerteza na
Demanda
●   Por que então utilizar métodos de produção sob
    demanda e não de produção sob e...
Terceiro Encadeamento Lógico
  Do segundo encadeamento:
  Produção baseada no conhecimento E bem intangível →
    não exis...
Conclusões
        A estimativa de esforço é necessária, porém só terá
         uma precisão razoável se feita em janelas...
Próximos SlideShares
Carregando em…5
×

Ger proj 4_sofismappd_v1.0_semnsi

610 visualizações

Publicada em

Argumentação contrária às técnicas tradicionais de estimativa de esforço de software.

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
610
No SlideShare
0
A partir de incorporações
0
Número de incorporações
36
Ações
Compartilhamentos
0
Downloads
6
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Ger proj 4_sofismappd_v1.0_semnsi

  1. 1. O Sofisma do Plano do Projeto Detalhado em Desenvolvimento de Software – Visões da Prática Prof. Rogério Atem de Carvalho, D. Sc. Prof. Rodrigo Soares Manhães, M. Sc.
  2. 2. Objetivo deste Documento ● Mostrar, por argumentação lógica que a construção de planos de projeto detalhados no âmbito de desenvolvimento de software na prática: – Forçam o seguimento de um ciclo em cascata e/ou – São muito imprecisos, levando a altos custos da função controle e de constantes mudanças no processo e no próprio planejamento. – V 0.9: 21/10/2008 – V 1.0: 02/03/2009
  3. 3. O Plano do Projeto na Indústria ● Trataremos inicialmente da indústria que trabalha por encomenda e não a que produz por previsão de demanda, já que desenvolvimento de software é também produção por encomenda. ● A indústria, no geral, segue um processo de projeto em cascata: – Elicitar os requisitos do produto junto ao cliente. – Projetar o projeto por completo (Engenharia do Produto). – Apresentar o projeto ao cliente. – Sendo aceito, partir para o planejamento e posterior execução e controle do projeto.
  4. 4. O Plano do Projeto na Indústria ● O planejamento se baseia em técnicas de estimativa de alocação de recursos bem dominadas. ● Assim, as estimativas funcionam a contento, devendo apenas eventos aleatórios (como quebra de máquina) causar desvios do curso planejado. ● O uso dos recursos é bastante padronizado. Por exemplo: “para colocar 50 metros de dutos térmicos na plataforma P-XYZ precisaremos de um técnico em dutos, trabalhando durante 3 dias...”
  5. 5. O Plano do Projeto na Indústria ● Com estimativas precisas e um produto totalmente projetado, faz sentido programar detalhadamente as atividades futuras. ● Diga-se de passagem, quando regulação e/ou recursos escassos se fazem presentes, o projeto completo do produto deve ser feito a priori. ● Exemplo clássico e vivenciado na prática são obras offshore: são reguladas por normas ambientais e de Engenharia e a necessidade de planejar a alocação de recursos é central ao problema, como por exemplo, vaga em helicóptero e na plataforma.
  6. 6. O Plano do Projeto na Indústria ● Resumindo: por que o ciclo em cascata é aceito e muito usado nas Engenharias? – Porque as técnicas de projeto do produto são estabelecidas há décadas (as vezes séculos) e são padronizadas, o que facilita enormemente as estimativas. Assim, a demanda por HH é conhecida a priori. – Porque a regulação exige que o projeto do produto esteja completo antes de iniciar sua execução. – Porque os produtos são tangíveis e as atividades envolvem relativamente pouco de criatividade e muito de “seguir o manual”.
  7. 7. Primeiro Encadeamento Lógico Planejamento detalhado precisa de → estimativas detalhadas (para definição do prazo = recurso tempo) Estimativas detalhadas precisam de → projeto do produto detalhado (para definição das atividades) Então Planejamento detalhado precisa de → projeto do produto detalhado Temos que Projeto do produto detalhado no início → ciclo em cascata Então Planejamento detalhado leva a → ciclo em cascata!
  8. 8. Primeiras conclusões ● A argumentação poderia parar aqui já que cairia numa discussão de uso ou não do Ciclo em Cascata, que já é sabidamente ineficiente em desenvolvimento de software. ● Ainda assim, poderia ser sugerido que em alguns casos é necessário fazer o projeto do produto a priori, como por exemplo, em licitações do Governo. ● Assim, agradavelmente forçados pela Lei, os “detalhistas” partiriam para o projeto (integral) do produto e tudo estaria bem...
  9. 9. A Dura Realidade do Software ● Infelizmente, o software é um produto intangível, produzido por trabalhadores do conhecimento. ● Intangível: não é possível mensurar suas características físicas (como material necessário), simplesmente porque ele não é físico! ● Trabalho baseado no conhecimento: difícil de mensurar também (como o tempo das operações), pois além de não físico, é artesanal e dependente da criatividade. ● Adicionalmente, é quase totalmente dependente das pessoas e consequentemente de todas suas especificidades.
  10. 10. A Dura Realidade do Software ● Em termos práticos, de onde vem a incerteza no software? – Rápidas mudanças tecnológicas – Algumas tarefas consideradas simples se mostram complexas – Trabalho não repetitivo e baseado em criatividade – Mudanças nos requisitos – Necessidade de aprender sobre o problema ao qual o sistema está relacionado – Etc (os argumentos acima são empregados justamente em favor de ciclos iterativos-incrementais e contra cascata)
  11. 11. Segundo Encadeamento Lógico Software → bem intangível, produto não físico Software → produção baseada no conhecimento, recurso não físico Produção baseada no conhecimento E bem intangível → não existem medidas físicas (por definição!) Falta de medidas físicas → estimativas imprecisas Juntando com o primeiro encadeamento: Planejamento detalhado precisa de → estimativas detalhadas Software → estimativas imprecisas Então Não é possível fazer estimativas precisas em software, mesmo pagando o preço do ciclo em cascata!!!!!!!!!
  12. 12. Primeiras conclusões ● Os planejamento do projeto detalhado funciona na indústria de bens materiais, porém foi transplantado para a Engenharia de Software sem os devidos cuidados... ● Algumas organizações insistem nesse modelo falho, trazendo altos custos de controle e de replanejamento. ● Surgem absurdos como por exemplo, forçar o cronograma a se encaixar na estimativa de esforço (aumentando as horas extras = aumentando custos) ou forçar estimativas para cima, de maneira a deixar folgas. ● Ao fim, o objetivo se torna não um melhor processo produtivo, mas criar uma ilusão de controle (“o rabo abana o cachorro”).
  13. 13. Primeiras conclusões ● Um diálogo possível (digamos em dezembro de 2009): – Preciso do planejamento detalhado para 2010... – Como vou saber o que estaremos fazendo na semana 3 de outubro de 2010, por exemplo? – Faça uma estimativa! – Mas as estimativas são grosseiras! – Apresente o planejamento detalhado em função das estimativas e então quando estiver mais próximo, replaneje e atualize toda a documentação do cronograma... – Se eu com certeza vou ter que replanejar, por que fazer o planejamento detalhado? – Para mostrar que você sabe planejar...
  14. 14. Primeiras conclusões ● Então, quem poderá intervir? Spectroman? Super Mouse? Chapolin Colorado? Mais controle gerencial? Mais burocracia? Constante replanejamento detalhado? Proibir mudanças nos requisitos? ● Talvez a solução seja olhar para as experiências da indústria que trabalha sob demanda e não sob encomenda...
  15. 15. Produzindo com Incerteza na Demanda ● A indústria de bens de consumo produz bens tangíveis, com tempos de produção razoavelmente determinísticos. ● O maior fator de incerteza se encontra na demanda. ● Maior demanda pode gerar perdas de vendas. ● Menor demanda pode gerar estoque. ● Como se adaptar às flutuações de demanda? – Durante décadas usou-se o planejamento detalhado, que na realidade virava um loop de replanejamento constante e controle da produção caro e complexo. E ainda assim, FALHO.
  16. 16. Produzindo com Incerteza na Demanda ● Na contramão do Ocidente, os japoneses criaram um sistema simples, de controle manual mas ... essencialmente dinâmico! ● Esse sistema é conhecido por vários nomes, como Just In Time, Kanban, Toyota... ● Toyota foi onde surgiu, JIT é a filosofia como um todo e Kanban o sistema de programação e controle da produção. ● Atualmente, junto com outras práticas, usa-se o termo genérico Lean Manufacturing.
  17. 17. Produzindo com Incerteza na Demanda ● Esse sistema se baseia em: – Valorização do trabalhador – Qualidade durante todo o processo (e não após!) e como responsabilidade de cada um. – Programação simples. – Controle simples. – Decisão descentralizada. ● Como resultado esse sistema trouxe um dinamismo maior aos sistemas produtivos, fazendo com que os níveis de produção acompanhassem a demanda, ao invés de tentar (em vão) se antecipar a ela.
  18. 18. Produzindo com Incerteza na Demanda ● Para quem duvida como métodos simples podem ser a solução para problemas complexos: – Os japoneses dominam a venda de automóveis nos EUA desde os anos 70. – “Como eles fazem carros melhores, mais baratos, em menos tempo, se não usam nossos detalhadíssimos mecanismos gerenciais que vêm evoluindo há décadas?”.
  19. 19. Produzindo com Incerteza na Demanda ● Resposta: – Subordinando o processo ao produto e não o contrário! – Subordinando as atividades de gestão às de chão de fábrica e não o contrário! – Trazendo quem faz para o centro da discussão de como e quando se faz. – Em suma, chega do rabo abanar o cachorro!!!!!! ● A indústria ocidental, após se recuperar do choque, passou a adotar as mesmas técnicas, bem como mesclar com outras, levando ao surgimento do Lean Manufacturing (Produção Enxuta).
  20. 20. Produzindo com Incerteza na Demanda ● Por que então utilizar métodos de produção sob demanda e não de produção sob encomenda se o software é encomendado? ● Porque a questão não está no modo de colocação do pedido de produção, mas nas incertezas no processo produtivo. ● Assim, embora o software seja encomendado, por ser um bem intangível não é possível determinar com precisão as quantidades de recursos a serem alocados à sua produção, levando a incertezas no processo produtivo.
  21. 21. Terceiro Encadeamento Lógico Do segundo encadeamento: Produção baseada no conhecimento E bem intangível → não existem medidas físicas (por definição!) Falta de medidas físicas → estimativas imprecisas Temos que: Estimativas imprecisas → alta incerteza no processo produtivo E também Produção sob encomenda → baixa incerteza no processo produtivo Então Não é razoável empregar métodos que esperam baixa incerteza no processo produtivo para construir software!!!!!!!!!
  22. 22. Conclusões  A estimativa de esforço é necessária, porém só terá uma precisão razoável se feita em janelas de tempo pequenas.  A velocidade de produção muda com o tempo, a produtividade não é linear.  Você ainda acredita em técnicas de estimativa de esforço “tradicionais”???  Você ainda acha que desenvolvedores são como trabalhadores “apertadores de botão”? 22

×