Ger proj 4_sofismappd_v1.0_semnsi

Embed Size (px)

DESCRIPTION

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

Text of Ger proj 4_sofismappd_v1.0_semnsi

  • 1. O Sofisma do Plano do Projeto Detalhado em Desenvolvimento de Software Vises da PrticaProf. Rogrio Atem de Carvalho, D. Sc.Prof. Rodrigo Soares Manhes, M. Sc.

2. Objetivo deste Documento Mostrar, por argumentao lgica que a construo de planos de projeto detalhados no mbito de desenvolvimento de software na prtica: Foram o seguimento de um ciclo em cascata e/ou So muito imprecisos, levando a altos custos da funo controle e de constantes mudanas no processo e no prprio planejamento. V 0.9: 21/10/2008 V 1.0: 02/03/2009 3. O Plano do Projeto na Indstria Trataremos inicialmente da indstria que trabalha por encomenda e no a que produz por previso de demanda, j que desenvolvimento de software tambm produo por encomenda. A indstria, 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 execuo e controle do projeto. 4. O Plano do Projeto na Indstria O planejamento se baseia em tcnicas de estimativa de alocao de recursos bem dominadas. Assim, as estimativas funcionam a contento, devendo apenas eventos aleatrios (como quebra de mquina) causar desvios do curso planejado. O uso dos recursos bastante padronizado. Por exemplo: para colocar 50 metros de dutos trmicos na plataforma P-XYZ precisaremos de um tcnico em dutos, trabalhando durante 3 dias... 5. O Plano do Projeto na Indstria Com estimativas precisas e um produto totalmente projetado, faz sentido programar detalhadamente as atividades futuras. Diga-se de passagem, quando regulao e/ou recursos escassos se fazem presentes, o projeto completo do produto deve ser feito a priori. Exemplo clssico e vivenciado na prtica so obras offshore: so reguladas por normas ambientais e de Engenharia e a necessidade de planejar a alocao de recursos central ao problema, como por exemplo, vaga em helicptero e na plataforma. 6. O Plano do Projeto na Indstria Resumindo: por que o ciclo em cascata aceito e muito usado nas Engenharias? Porque as tcnicas de projeto do produto so estabelecidas h dcadas (as vezes sculos) e so padronizadas, o que facilita enormemente as estimativas. Assim, a demanda por HH conhecida a priori. Porque a regulao exige que o projeto do produto esteja completo antes de iniciar sua execuo. Porque os produtos so tangveis e as atividades envolvem relativamente pouco de criatividade e muito de seguir o manual. 7. Primeiro Encadeamento Lgico Planejamento detalhado precisa de estimativas detalhadas (para definio do prazo = recurso tempo) Estimativas detalhadas precisam de projeto do produto detalhado (para definio das atividades) Ento Planejamento detalhado precisa de projeto do produto detalhado Temos que Projeto do produto detalhado no incio ciclo em cascata Ento Planejamento detalhado leva a ciclo em cascata! 8. Primeiras concluses A argumentao poderia parar aqui j que cairia numa discusso de uso ou no do Ciclo em Cascata, que j sabidamente ineficiente em desenvolvimento de software. Ainda assim, poderia ser sugerido que em alguns casos necessrio fazer o projeto do produto a priori, como por exemplo, em licitaes do Governo. Assim, agradavelmente forados pela Lei, os detalhistas partiriam para o projeto (integral) do produto e tudo estaria bem... 9. A Dura Realidade do Software Infelizmente, o software um produto intangvel, produzido por trabalhadores do conhecimento. Intangvel: no possvel mensurar suas caractersticas fsicas (como material necessrio), simplesmente porque ele no fsico! Trabalho baseado no conhecimento: difcil de mensurar tambm (como o tempo das operaes), pois alm de no fsico, artesanal e dependente da criatividade. Adicionalmente, quase totalmente dependente das pessoas e consequentemente de todas suas especificidades. 10. A Dura Realidade do Software Em termos prticos, de onde vem a incerteza no software? Rpidas mudanas tecnolgicas Algumas tarefas consideradas simples se mostram complexas Trabalho no repetitivo e baseado em criatividade Mudanas nos requisitos Necessidade de aprender sobre o problema ao qual o sistema est relacionado Etc (os argumentos acima so empregados justamente em favor de ciclos iterativos-incrementais e contra cascata) 11. Segundo Encadeamento Lgico Software bem intangvel, produto no fsico Software produo baseada no conhecimento, recurso no fsico Produo baseada no conhecimento E bem intangvel no existem medidas fsicas (por definio!) Falta de medidas fsicas estimativas imprecisas Juntando com o primeiro encadeamento: Planejamento detalhado precisa de estimativas detalhadas Software estimativas imprecisas Ento No possvel fazer estimativas precisas em software, mesmo pagando o preo do ciclo em cascata!!!!!!!!! 12. Primeiras concluses Os planejamento do projeto detalhado funciona na indstria de bens materiais, porm foi transplantado para a Engenharia de Software sem os devidos cuidados... Algumas organizaes insistem nesse modelo falho, trazendo altos custos de controle e de replanejamento. Surgem absurdos como por exemplo, forar o cronograma a se encaixar na estimativa de esforo (aumentando as horas extras = aumentando custos) ou forar estimativas para cima, de maneira a deixar folgas. Ao fim, o objetivo se torna no um melhor processo produtivo, mas criar uma iluso de controle (o rabo abana o cachorro). 13. Primeiras concluses Um dilogo possvel (digamos em dezembro de 2009): Preciso do planejamento detalhado para 2010... Como vou saber o que estaremos fazendo na semana 3 deoutubro de 2010, por exemplo? Faa uma estimativa! Mas as estimativas so grosseiras! Apresente o planejamento detalhado em funo dasestimativas e ento quando estiver mais prximo, replanejee atualize toda a documentao do cronograma... Se eu com certeza vou ter que replanejar, por que fazer oplanejamento detalhado? Para mostrar que voc sabe planejar... 14. Primeiras concluses Ento, quem poder intervir? Spectroman? Super Mouse? Chapolin Colorado? Mais controle gerencial? Mais burocracia? Constante replanejamento detalhado? Proibir mudanas nos requisitos? Talvez a soluo seja olhar para as experincias da indstria que trabalha sob demanda e no sob encomenda... 15. Produzindo com Incerteza na Demanda A indstria de bens de consumo produz bens tangveis, com tempos de produo razoavelmente determinsticos. 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 flutuaes de demanda? Durante dcadas usou-se o planejamento detalhado, que na realidade virava um loop de replanejamento constante e controle da produo caro e complexo. E ainda assim, FALHO. 16. Produzindo com Incerteza na Demanda Na contramo do Ocidente, os japoneses criaram um sistema simples, de controle manual mas ... essencialmente dinmico! Esse sistema conhecido por vrios nomes, como Just In Time, Kanban, Toyota... Toyota foi onde surgiu, JIT a filosofia como um todo e Kanban o sistema de programao e controle da produo. Atualmente, junto com outras prticas, usa-se o termo genrico Lean Manufacturing. 17. Produzindo com Incerteza na Demanda Esse sistema se baseia em: Valorizao do trabalhador Qualidade durante todo o processo (e no aps!) e como responsabilidade de cada um. Programao simples. Controle simples. Deciso descentralizada. Como resultado esse sistema trouxe um dinamismo maior aos sistemas produtivos, fazendo com que os nveis de produo acompanhassem a demanda, ao invs de tentar (em vo) se antecipar a ela. 18. Produzindo com Incerteza na Demanda Para quem duvida como mtodos simples podem ser a soluo para problemas complexos: Os japoneses dominam a venda de automveis nos EUA desde os anos 70. Como eles fazem carros melhores, mais baratos, em menos tempo, se no usam nossos detalhadssimos mecanismos gerenciais que vm evoluindo h dcadas?. 19. Produzindo com Incerteza na Demanda Resposta: Subordinando o processo ao produto e no o contrrio! Subordinando as atividades de gesto s de cho de fbrica e no o contrrio! Trazendo quem faz para o centro da discusso de como e quando se faz. Em suma, chega do rabo abanar o cachorro!!!!!! A indstria ocidental, aps se recuperar do choque, passou a adotar as mesmas tcnicas, bem como mesclar com outras, levando ao surgimento do Lean Manufacturing (Produo Enxuta). 20. Produzindo com Incerteza na Demanda Por que ento utilizar mtodos de produo sob demanda e no de produo sob encomenda se o software encomendado? Porque a questo no est no modo de colocao do pedido de produo, mas nas incertezas no processo produtivo. Assim, embora o software seja encomendado, por ser um bem intangvel no possvel determinar com preciso as quantidades de recursos a serem alocados sua produo, levando a incertezas no processo produtivo. 21. Terceiro Encadeamento Lgico Do segundo encadeamento: Produo baseada no conhecimento E bem intangvel no existem medidas fsicas (por definio!) Falta de medidas fsicas estimativas imprecisas Temos que: Estimativas imprecisas alta incerteza no processo produtivo E tambm Produo sob encomenda baixa incerteza no processo produtivo Ento No razovel empregar mtodos que esperam baixa incerteza no processo produtivo para construir software!!!!!!!!! 22. Concluses A estimativa de esforo necessria, porm s teruma preciso razovel se feita em janelas de tempopequenas. A velocidade de produo muda com o tempo, aprodutividade no linear. Voc ainda acredita em tcnicas de estimativa deesforo tradicionais??? Voc ainda acha que desenvolvedores so comotrabalhadores apertadores de boto? 22