O MTICO HOMEM-MS

FREDERICK P. BROOKS JR.

O POO DE ALCATRO

C.R. Knight, Mural dos Poos de Alcatro de La BreaThe George C. Page Museum of La Brea Discoveries The Natural History Museum of Los Angeles County

Um navio na praia um farol para o mar (explicao breve)

O PRODUTO DA PROGRAMAO DE SISTEMAS Por que no substituir todas as equipes de programao por dedicadas duplas de garagem? O que est sendo produzido?

O PRODUTO DA PROGRAMAO DE SISTEMAS

Figura 1.1 Evoluo do produto da programao de sistemas

O PRODUTO DA PROGRAMAO DE SISTEMASProgramavalor aumenta 3x

Programa Produto

Deve ser escrito de forma generalizada; Deve ser EFETIVAMENTE testado; Deve ser CUIDADOSAMENTE documentado

O PRODUTO DA PROGRAMAO DE SISTEMASProgramaValor aumenta,no mnimo, 3x

Componente de um sistema de programas

Deve ser escrito de forma que as interfaces sejam PRECISAMENTE definidas; Deve ser determinado para uma quantidade DETERMINADA de recursos; Deve ser testado em CONJUNTO com outros componentes do sistema

O PRODUTO DA PROGRAMAO DE SISTEMASProgramaValor aumenta 9x

Produto da programao de sistemas

Diferencia-se do simples programa de TODAS as formas descritas anteriormente.

AS ALEGRIAS DA ARTE Por que divertido programar? Que alegrias o praticante dessa arte pode ter como recompensa?

AS ALEGRIAS DA ARTE 1 A satisfao de contruir algo; 2 A felicidade de se construir coisas que so teis para os outros; 3 O fascnio da montagem de objetos complexos; 4 A aprendizagem constante (natureza no repetitiva da tarefa); 5 A delcia de trabalhar em um meio to malevel.

AS TRISTEZAS DA ARTE Nem tudo, porm, deleite...

Conhecer as dificuldades intrnsecas ao trabalho ajuda a suport-las quando elas surgem.

AS TRISTEZAS DA ARTE 1 A execuo deve ser perfeita (seres humanos no esto acostumados a serem perfeitos); 2 raro o programador controlar as circunstncias de seu trabalho ou mesmo seu objetivo (o programador precisa gastar horas estudando e corrigindo coisas que, em um mundo ideal, deveriam estar prontas, disponveis e utilizveis); 3 H tambm melanclicas horas de trabalho montono e cansativo (por exemplo, encontrar um pequeno erro); 4 O produto no qual se trabalhou por tanto tempo parece obsoleto quando fica pronto (ou mesmo antes disso)

AS TRISTEZAS DA ARTE (...) a base tecnolgica na qual um programador trabalha est sempre evoluindo. A obsolncia de um uma implementao dever ser medida em relao a outras implementaes j existentes e no contra conceitos no implementados.

AS TRISTEZAS DA ARTE O que programar: um poo de alcatro, no qual muitos esforos, sucumbiram,e uma atividade criativa que traz em si alegrias e tristezas.

O MTICO HOMEM-MS Cozinhar bem leva tempo. Se fazemos voc esperar para servi-lo melhor e deix-lo satisfeito.MENU DO RESTAURANTE ANTOINE, NOVA ORLEANS

O MTICO HOMEM-MS A maioria dos projetos de software falharam mais por falta de tempo no calendrio do quem em funo da combinao de outras causas. Por que isso to comum?

O MTICO HOMEM-MS 1 Nossas tcnicas para estimativa so muito pouca desenvolvidas; 2 Nossas tcnicas de estimativa confudem esforo com progresso (homens e meses so intercambiveis); 3 No temos certeza de nossas estimativas; 4 O cronograma de progesso monitorado de forma precria; 5 Quando se admite um atraso no cronograma, a resposta natural a adio de mais fora de trabalho (apagar um incndio com gasolina).

O MTICO HOMEM MS Consideremos outros aspectos do problema com mais detalhes: Otimismo; O homem-ms; Testes de Sistema; Estimativa desembasada; Desastre do Cronograma Regenerativo;

OTIMISMO Primeira falsa premissa: tudo ir bem...cada tarefa tomar apenas o tempo que deve tomar....

A MENTE DO CRIADOR Segundo Dorothy L. Sayers: Atividade criativa:ideia

implementao interao

A MENTE DO CRIADOR Como criadores humanos de coisas, a incompletude e inconsistncia de nossas ideias tornam-se claras apenas durante sua implementao. Temos a tendncia de culpar o meio fsico pela maioria das dificuldades de implementao.

OTIMISMO Por se tratar de um meio flexvel, se espera encontrar poucas dificuldades de implementao; ento que surge o otimismo.

Esse otimismo no se justica, pois, nos esquecemos de que nossas ideias tm FALHAS.

O HOMEM-MS A segunda falcia se manifesta na unidade de esforo usada em estimativas e cronogramas: o homem-ms; O custo varia de acordo com o nmero de pessoas envolvidas e no tempo disponvel. O progresso no;

O HOMEM-MS (...) o uso do homem-ms como unidade para medir o tamanho de um trabalho um mito perigoso e enganoso. Homens e meses so intercambiveis apenas quando uma tarefa pode ser dividida entre muitos trabalhadores que no se comuniquem entre si.

O HOMEM-MS

meses

HomensFIGURA 2.1 Tempo versus nmero de trabalhadores em uma tarefa perfeitamente divisvel

O HOMEM-MS Quando uma tarefa no pode ser dividida em funo de limitaes sequenciais, a aplicao de mais esforo no tem efeito algum no cronograma. Ter um filho leva nove meses, independentemente de quantas mulheres sejam responsveis pela tarefa.

O HOMEM-MS

meses

homens FIGURA 2.2 Tempo versus nmero de trabalhadores em uma tarefa indivisvel

O HOMEM-MS Em tarefas que podem ser divididas, mas que necessitam de comunicao entre as subtarefas, o esforo de comunicao deve ser adicionado quantidade de trabalho a ser realizado.

O HOMEM-MS

meses

homens FIGURA 2.3 Tempo versus nmero de trabalhadores em uma tarefa divisvel que requer comunicao

O HOMEM-MS Comunicaotreinamento

Intercomunicao

Treinamento: este treinamento no pode ser dividido, assim, parte do esforo adicional varia linearmente com o nmero de trabalhadores.

O HOMEM-MS Intercomunicao: n(n-1)/2 3 trabalhadores requerem 3 vezes mais comunicao entre pares do que 2 trabalhadores. O esforo adicional de comunicao pode ir totalmente contra a diviso da tarefa original e levar situao da figura 2.4.

O HOMEM-MS

meses

homens FIGURA 2.4 Tempo versus nmero de trabalhadores em uma tarefa com inter-relaes complexas.

O HOMEM-MS Como a construo de software , por natureza, um exerccio em inter-relaes complexas, a adio de mais homens aumenta, e no diminui, o tempo no cronograma.

TESTE DE SISTEMA Juntamente com a depurao, a parte do cronograma mais afetada pelos limites sequenciais. O tempo requerido para essa tarefa deveria ser zero, mas devido ao otimismo, a fase de testes costuma ser a que pior estimada em uma tarega de programao.

TESTE DE SISTEMA Regra geral para programar uma tarefa de software: 1/3 planejamento; 1/6 codificao; 1/4 testes de componentes e testes iniciais do sistema; 1/4 testes do sistema, todos os componentes disponveis.

TESTE DE SISTEMA A frao dedicada ao planejamento maior que a normal; A metade do cronograma dedicada depurao do cdigo completo maior que o normal; Para a codificao (fcil de estimar), d-se apenas um sexto do cronograma.

TESTE DE SISTEMA (..)poucos deixam metade do cronograma para testes, mas de fato, usam metade do cronograma real para esse propsito; Como o atraso acontece no final do cronograma, ningum est a par do problema at quase a data de entrega do projeto.

TESTE DE SISTEMA Neste ponto, o atraso tem repercusses anormais: O projeto est com a equipe completa, o custo por dia est em seu mximo, o software deve dar suporte a outros esforos de negcio e os custos secundrios de atraso de tais esforos so muito altos. Por isso, muito importante permitir tempo suficiente para os testes do sistema na programao original;

ESTIMATIVA DESEMBASADA Tanto para o programador quanto para seu chefe, a urgncia do cliente pode governar a data da finalizao programada para uma tarefa, mas no sua finalizao real; 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.

ESTIMATIVA DESEMBASADA muito difcil fazer uma defesa vigorosa e plausvel, de uma estimativa que no derivada de nenhum mtodo quantitativo e garantida principalmente por palpites de gerentes. Precisamos desenvolver e publicar nmeros de produtividade, de incidncia de erros, regras para estimativa...

DESASTRE DO CRONOGRAMA REGENERATIVO O que fazer quando um projeto de software essencial est atrasado? Suponha que uma tarefa estimada em 12 homens-ms, entregue a 3 homens por 4 meses, e que existem pontos mensurveis de verificao A,B,C,D, que esto programados para ocorrer ao final de cada ms (Figura 2.5)

DESASTRE DO CRONOGRAMA REGENERATIVO

Figura 2.5

DESASTRE DO CRONOGRAMA REGENERATIVO Imagine que o 1 ponto de checagem no atingido at que se passem dois meses. Quais so as alternativas que se apresentam ao gerente?

DESASTRE DO CRONOGRAMA REGENERATIVO

Figura 2.6

DESASTRE DO CRONOGRAMA REGENERATIVO

Figura 2.7

DESASTRE DO CRONOGRAMA REGENERATIVO

Figura 2.8

DESASTRE DO CRONOGRAMA REGENERATIVO Lei de Brooks: A adio de recursos humanos a um projeto de software atrasado ir atras-lo ainda mais.

DESASTRE DO CRONOGRAMA REGENERATIVO O nmero de meses de um projeto depende de seus limites sequencias; O nmero mximo de homens depende do nmero de subtarefas independentes; No possvel, entretanto, ter cronogramas funcionais utilizando mais homens e menos meses.

A EQUIPE CIRRGICA

FOTO UPI/O Arquivo Bettman

A EQUIPE CIRRGICA Estes estudos revelaram grandes diferenas individuais entre aqueles de alto e baixo desempenho, no raro por uma ordem de grandeza SACKMAN, ERIKSON E GRANT

A EQUIPE CIRRGICA Como construir grandes sistemas em um cronograma significativo? Vamos averiguar os dois lado da questo:

O PROBLEMA Um estudo de Sackman, Erikson e Grant medindo o desempenho de um grupo de programadores experientes revelou que a variao entre os melhores e o piores desempenhos tinham uma mdia de 10:1 em medidas de produtividade e 5:1 em velocidade de programao e medidas de espao.

O PROBLEMA A maior parte do custo a comunicao e a correo dos efeitos da falta de comunicao(depurao do sistema). (..)na medida do possvel, o melhor o sistema ser construdo por poucas mentes. Se um projeto com 200 homens tem 25 gerentes que so os programadores mais experientes e competentes, demita os 175 outros e coloque os gerentes de volta na programao.

O PROBLEMA Essa soluo falha nos seguintes pontos:A equipe continuaria grande (no deveria exceder 10 pessoas) e precisaria ter ao menos dois nveis de gerncia, ou cerca de cinco gerentes; Precisaria de suporte em finanas, pessoal, espao, secretrios e operadores de mquinas;

Porm, 200 homens no o suficiente para construir sistemas realmente grandes por mtodos de fora bruta(e.g. OS/360).

O PROBLEMA Eis ento o problema do conceito de uma equipe pequena e afiada: ela muito lenta para sistemas realmente grandes. Em funo da eficincia e da integridade conceitual, prefervel umas poucas e boas mentes trabalhando no projeto e construo; Mas para grandes sistemas preciso uma forma de trabalhar com um nmero considervel de pessoas para o produto surgir no tempo correto.

A PROPOSTA DE MILLS Como as suas necessidades podem ser conciliadas? Mills prope que cada segmento de um grande trabalho seja atacado por uma equipe mas que ela seja organizada como uma equipe cirrgica. Poucas cabeas esto envolvidas no projeto e na construo e, ainda assim, muitas mos so trazidas para o trabalho.

A PROPOSTA DE MILLS O Cirurgio; O Copiloto; O Administrador; O Editor; Dois Secretrios; O Escriturrio de programao; O Ferramenteiro; O Testador; O Advogado da Linguagem;

A PROPOSTA DE MILLS Como funciona: 10 pessoas (7 profissionais), trabalham no problema, mas o sistema produto de no mximo duas mentes, atuando como apenas uma pessoa.

A PROPOSTA DE MILLS As diferenas entre uma equipe de programadores e a equipe piloto-copiloto:A diviso do problema; Relao superior-subordinado;

dois

Todavia, a especializao das funes da equipe a chave para sua eficincia, j que ela permite um padro de comunicao radicalmente mais simples entre seus membros.

A PROPOSTA DE MILLS

A PROPOSTA DE MILLS Escalando: Como pode o conceito de equipe cirrgica ser utilizado em grandes trabalhos, quando vrias centenas de pessoas esto envolvidas? O sucesso da escala do processo reside no fato de que a integridade conceitual de cada pea foi radicalmente melhorada; Todo o sistema deve ter tambm integridade conceitual e um arquiteto de sistemas, que deve confinar-se apenas na arquitetura e no na implementao.

ARISTOCRACIA, DEMOCRAVIA E O PROJETO DE SISTEMAS

Fotografia de Emmanuel Boudot-Lamotte

ARISTOCRACIA, DEMOCRAVIA E O PROJETO DE SISTEMAS

INTEGRIDADE CONCEITUAL o ponto mais importante no projeto de sistemas. A maioria dos sistemas de programao refletem uma falta de unidade conceitual, decorrente da separao do projeto em muitas tarefas executadas por muitos homens.

INTEGRIDADE CONCEITUAL Como atingir a integridade conceitual? Esse raciocnio no pressupe uma elite, ou aristocracia de arquitetos, e uma horda de implementadores plebeus cujos talentos e ideias criativas so suprimidos? Como possvel evitar que os arquitetos se distanciem da realidade a ponto de apresentarem especificaes caras ou impossveis de serem implementadas? Como garantir que cada simples detalhe de uma especificao seja comunicada ao implementador, e que esta seja corretamente entendida por ele e incorporada ao produto em sua forma exata?

ATINGINDO A INTEGRIDADE CONCEITUAL O propsito de um sistema tornar um computador mais fcil de usar. O usurio percebe que mais fcil especificar qualquer funo em particular, mas h muitas mais entre as quais podem escolher e muito mais opes e formatos a serem lembrados.

ATINGINDO A INTEGRIDADE CONCEITUAL A facilidade de uso melhorada apenas se o tempo ganho na especificao funcional exceder o tempo gasto na aprendizagem, memorizao e busca em manuais.

Atualmente, a razo entre o ganho e o custo parece ter diminudo, j que funes cada vez mais complexas tm sido adicionadas.

ATINGINDO A INTEGRIDADE CONCEITUAL Nem a funcionalidade ou a simplicidade, isoladamente, definem um bom projeto. Ser simples e direto resultado da integridade conceitual. Cada componente deve refletir a mesma filosofia e o mesmo equilbrio da desiderata, o conjunto de aspiraes do sistema.

ARISTOCRACIA E DEMOCRACIA A integridade conceitual determina que o projeto deve avanar a partir de uma mente, ou de um nmero muito pequeno de mentes concordantes e consoantes. Porm, presses no cronograma estabelecem que a construo do sistema precisa de muitas mos.

ARISTOCRACIA E DEMOCRACIA H duas tcnicas para resolver esse impasse: Estruturar as equipes de implementao dos programas;

Diviso de trabalho entre a arquitetura e a implementao;

A separao dos esforos de arquitetura e a implementao uma maneira poderosssima de obter a integridade conceitual em projetos muito grandes

ARISTOCRACIA E DEMOCRACIA Arquitetura de um sistema especificao completa e detalhada da interface do usurio. e.g. Manual de programao, manual da linguagem, manual do usurio;

O arquiteto o AGENTE DO USURIO; Segundo Blaauw: Enquanto a arquitetura diz o que acontece, a implementao diz como ir acontecer e.g. Relgio ;

ARISTOCRACIA E DEMOCRACIA No so os arquitetos uma nova aristocracia, uma elite intelectual, concebida para dizer ao pobres e burros implementadores o que fazer?

No teramos um melhor produto se pudssemos obter boas ideias de todos os integrantes da equipe, seguindo uma filosofia democrtica, em vez de restringir a poucos o desenvolvimento de especificaes?

ARISTOCRACIA E DEMOCRACIA No apenas os arquitetos tm boas idias sobre arquitetura, porm a integridade conceitual de um sistema determina sua facilidade de uso. Devem existir poucos arquitetos. Se um sistema deve ter integridade conceitual, algum deve controlar os conceitos. Porm, a determinao de especificaes externas no um trabalho mais criativo do que o projeto das implementaes; apenas um trabalho criativo diferente .

ARISTOCRACIA E DEMOCRACIA A disciplina boa para a arte: A forma libertadora. Da mesma forma, a disposio externa de uma arquitetura valoriza, e no prejudica, o estilo criativo do grupo de implementao. Em um grupo de implementao sem limites, a maior parte do pensamento e debate vai para decises de arquitetura, e a implementao propriamente dita recebe pouca ateno.

O QUE FAZ O IMPLEMENTADOR ENQUANTO ESPERA? Quando se prope que uma pequena equipe de arquitetura realmente escreva todas as especificaes externas para um sistema de programao, os implementadores apresentam trs objees: As especificaes sero muito ricas em funcionalidade e no iro refletir as consideraes prticas de custo; Os arquitetos tero todo o prazer criativo e silenciaro o poder criador dos implementadores; Os muitos implementadores ficaro sem fazer nada, enquanto as especificaes passam pelo estreito tnel representado pela equipe de arquitetura;

O QUE FAZ O IMPLEMENTADOR ENQUANTO ESPERA? 1 objeo prximo captulo; 2 objeo a implementao tambm uma atividade criativa;

3 objeo no contratar implementadores antes que a especificao esteja completa e.g. Prdio sendo construdo

O QUE FAZ O IMPLEMENTADOR ENQUANTO ESPERA? A integridade conceitual realmente exige que um sistema reflita uma filosofia nica e que a especificao, do ponto de vista do usurio, venha de algumas poucas mentes.

O EFEITO DO SEGUNDO SISTEMA

Casa giratria para trfego areo. Litografia, Paris, 1882 De Le Vingtime Sicle, A.Robida

O EFEITO DO SEGUNDO SISTEMA

Adde parvum parvo magnus acervus erit. [Adicione um pouco a pouco e surgir um grande amontoado.] OVDIO

O EFEITO DO SEGUNDO SISTEMA Se separarmos a responsabilidade para a especificao funcional da responsabilidade para construir um produto rpido e barato, qual disciplina limita o entusiasmo criativo do arquiteto?Comunicao meticulosa, cuidadosa e simptica entre arquiteto e construtor e...

DISCIPLINA INTERATIVA PARA O ARQUITETO O arquiteto tem duas respostas possveis quando confrontado com uma estimativa que muito alta: 1: fazer cortes no projeto; 2: desafiar a estimativa, sugerindo implementaes mais baratas;

Nessa ltima, normalmente, o construtor ir retrucar, apresentando sugestes para a arquitetura: no raro, ele estar correto.

AUTODISCIPLINA O EFEITO DO SEGUNDO SISTEMA Durante o primeiro trabalho de um arquiteto, ele sabe que no sabe o que est fazendo, ento, ele o faz com muito cuidado e rigor. Detalhes de refinamento e requintes de beleza vo lhe surgindo a mente, porm esses elementos so guardados. Assim que o sistema concludo, o arquiteto est pronto para construir um segundo sistema.

AUTODISCIPLINA O EFEITO DO SEGUNDO SISTEMA O segundo sistema o mais perigoso j projetado por algum. Suas experincias anteriores iro embasar uma a outra.

A tendncia geral a de superprojetar o segundo sistema, usando todas as ideias e enfeites que foram cuidadosamente postos de lado no primeiro. um grande amontoado, segundo Ovdio. e.g. OS/360, TESTRAN, Scheduler

AUTODISCIPLINA O EFEITO DO SEGUNDO SISTEMA Como o arquiteto evita o efeito do segundo sistema? Ele deve estar consciente dos perigos peculiares de tal sistema, exercitando uma autodisciplina fora do comum. Dar a cada pequena funo um determinado valor. Esses valores guiaro decises iniciais e serviro como um guia durante a implementao e um alerta para tudo.

AUTODISCIPLINA O EFEITO DO SEGUNDO SISTEMA Como o gerente de projeto evita o efeito do segundo sistema? Tendo um arquiteto snior que tenha ao menos dois outros sistemas construdos. Fazer as perguntas certas para garantir quer os conceitos filosficos e objetivos estejam plenamente refletidos no detalhamento do projeto.

TRANSMITINDO A MENSAGEM

Inclua em Seus Planos o Verbo Descartar

Colapso da ponte de Tacoma Narrows,aerodinamicamente mal projetada,1940 UPI Photo/Arquivo Bettman

Inclua em Seus Planos o Verbo Descartar Engenheiros qumicos aprenderam com a experincia que,antes de se levar um experimento bem sucedido do laboratrio para a fbrica,deve se ter uma etapa intermediria(planta-piloto). Em sistemas de software ,tambm h o sistema-piloto ,mesmo sabendo que o mesmo ser descartado em breve.

O nico Fator Constante a Prpria Mudana De acordo com as respostas do cliente em relao ao software ,so feitas as alteraes ,pois sem os devidos refinamentos no se chega ao produto final ideal para o cliente. Logo descartar faz parte do processo evolutivo do software,e essa ao constante,ao contrrio do software.

Planeje o Sistema para Mudanas Todas as verses devem ser devidamente numeradas(versionamento),e documentadas . Para que cada mudana seja implementada corretamente ,deve se manter o reuso e o baixo acoplamento.

Planeje a Organizao para Mudanas Deve ser manter uma organizao flexvel de todos envolvidos nos projetos,por tanto organizar utilizando o exemplo da equipe cirrgica. Permite que pessoas com mais experincia no deixem de dar boas solues a problemas no projeto ,apenas por pertencer a um cargo mais alto.

Dois Passos Adiante e Um Passo Atrs O custo de manuteno de um programa de 40% ou mais o custo de seu desenvolvimento. Quanto mais usurios ,maior a chance de encontrar erros,por tanto maior o custo de manuteno. Todas as correes de um software, aumentam as chances de trazer novos problemas.Porque quem conserta no quem implementa o projeto.

Ferramentas Afiadas

A.Pisano, Lo Scultore,da Capela de Santa Maria del Fiore, Florena, circa 1335 Scala/Art Resource, NY

Ferramentas Afiadas As ferramentas utilizadas pelos desenvolvedores tendem a cair em desuso ,por conta do surgimento de novas tecnologias. E as mesmas ferramentas,utilizadas individualmente,no tem papel decisivo porque o processo de desenvolvimento criativo e necessita da comunicao entre os componentes da equipe.

Mquinas-alvo As mquinas envolvidas nos processos de software so dividias em duas categorias: Maquinas-viculo:do apoio a construo dos sistemas. Maquinas-alvo:onde sero instalados e testados o sistemas.

O Todo e as Partes

O Todo e as Partes Sistemas que fazem o impossvel ,ou mgica,podem ser programados ,porm no funcionaro.

Projetando sem Bugs Integridade conceitual reduz bugs , torna o sistema mais fcil de usar e construir. Antes da implementao a especificao deve ser testada ,em busca de completeza clareza. Procedimento de Niklaus Wirth,1971,utiliza tnica que comea a apresentar a soluo em uma viso macro .E aps a cada refinamento ,apresenta uma viso mais micro.

Projetando sem Bugs Segundo Bohmm e Jacopini,o uso de GO TO nos sistemas leva a erros lgicos.Ou seja outras estruturas de controle, devem ser usadas.

Depurao de Sistema Utilize componentes depurados:os componentes devem ser testados a ponto de encontrar todas as falhas.E mesmo todas a falhas j corrigidas ,erros durante a unio dos componentes causar erros. Construa degraus suficientes:programas e dados que auxiliam na depurao ,mas no fazem parte do projeto.

Depurao de Sistema Controle de mudanas:devem existir cpias distintas do software(verses),e documentos para cada. Adicione um componente por vez:a cada componente adicionado,deve se testar o conjunto,e os componentes antigos j adicionados.

Depurao de Sistema Quantifique as atualizaes:alteraes dos componentes por verses atualizadas,devem ser feitas com espaos longos de tempo.Para no causar instabilidade,por conta de um grande nmero de alteraes em um curto espao de tempo.

Incubando uma Catstrofe

A.Canova,Ercole e Lica,1802.Hrcules leva morte o mensegeiro Licas,que inocentemente lhe entregara a tnica fatal. Scala/Art Resource,NY

Incubando uma Catstrofe O atraso de um projeto pode se dar por causas pequenas ou grandes e desastrosas,a ltima facilmente notada e por tanto gerencivel.Mas a primeira, quase que imperceptvel ,pois o atraso oriundo da soma dos atrasos de cada dia.

Pontos de Checagem ou Pedras no Caminho? O cronograma auxilia a manter o projeto em dia,junto com os pontos de checagem.Que de tempos em tempos ,atravs de algo concreto,pode se saber se os pontos importantes do projeto foram atingidos. J ponto de checagem confuso, a pedra no caminho,pois no possvel obter uma real idia se as etapas foram atingidas.

Debaixo do Tapete Quando projetos atrasam,os gerentes pode ou no comunicar seus chefes,porm por receio no o fazem.Como chefe duas tcnicas so possveis frente a este problema: Reduzindo o conflito de papis e Levantando o Tapete.

Debaixo do Tapete Reduzindo o conflito de papis:o chefe deve dar autonomia ao gerente,para que os problemas sejam resolvidos sem que a autoridade do gerente seja esquecida. Levantando o Tapete:em intervalos curtos de tempo , necessrio um relatrio que mostre ao gerente se naquele perodo o ponto de checagem foi alcanado.

A Outra Face

Stonehenge,Gr-Bretanha

Qual Documentao Necessria? Para usar um programa: 1-Propsito.Razo do programa. 2-Ambiente.Configuraes de hardware e sistema operacional em que ser executado. 3-Domnio e variaes.Tipos de dados vlidos e tipos de sada. 4-Funes.O que cada algoritmo faz. 5-Opes.As possveis escolhas e respostas das funes.

Qual Documentao Necessria?6-Tempo de Execuo.Tempo gasto para obter a soluo de um certo problema. 7-Preciso e Verificao.Qual preciso pode se esperar das respostas?

Qual Documentao Necessria? Para acreditar em um programa:alm da documentao de como funciona um programa, necessrio casos de teste para garantir ao usurio que o sistema funciona. 1-Casos principais,testam as principais funes. 2-Casos de legitimidade,testes com diferentes tipos de dados vlidos ,dentro dos limites. 3-Casos de ilegitimidade,testes com tipos de dados invlidos .

Qual Documentao Necessria? Para modificar um programa: necessrio uma boa quantidade de informao ,pois pode ser que a pessoa que implementou no ser a mesma que modificar,ou que depois de muito tempo esquea o papel de cada funo.

Qual Documentao Necessria? Diagrama de Fluxos:mostram as decises possveis com base nas estruturas,deve ser enxuto para facilitar o entendimento.Diagramas muito poludos dificultam o entendimento,perdendo o propsito da documentao.

Qual Documentao Necessria?

Figura 15.1 O grfico de estrutura de um programa(Cortesia de W.V.Wright)

Qual Documentao Necessria? Programas Autodocumentados: aps a alterao do software ,sua documentao pertinente no alterada como deveria,pois ambos no esto unificados.Uma soluo seria utilizar autodocumentao,que consiste em utilizar comentrios nas linhas de cdigo,utilizar nomes de partes do programa que faam meno ao verdadeiro papel da funo e indentar o cdigo do programas.

No Existe Bala de Prata-Essncia e Acidente em Engenharia de Software

O Lobisomem de Eschenbach,Alemanha:litografia, 1685. Cortesia de The Grainger Collection,Nova York.

No Existe Bala de Prata-Essncia e Acidente em Engenharia de Software Projetos so comparados com lobisomens,pois algo familiar pode tornar-se um monstro para o gerente,problemas com oramento,cronograma e falhas no sistema.E no existe algo que resolva de forma miraculosa!

No Existe Bala de Prata-Essncia e Acidente em Engenharia de Software Essncia:dificuldades inerentes a natureza do software. Acidente:dificuldades na produo ,mas no so inerentes.

No Existe Bala de Prata-Essncia e Acidente em Engenharia de Software Complexidade: uma propriedade essencial que gera dificuldade de entendimento e deficincias no produto. Conformidade:a complexidade adicionada aos projetos sem seguir algum padro para isso ,por tanto no h conformidade para sistemas complexos.

No Existe Bala de Prata-Essncia e Acidente em Engenharia de Software Mutabilidade:softwares esto sempre expostos a mudanas,tanto por culpa do usurio como por surgimento de novas tecnologias ou atualizao das mesmas. Invisibilidade:por ser algo abstrato ,naturalmente o software algo difcil de se representar.

No Existe Bala de Prata-Essncia e Acidente em Engenharia de Software Linguagens de alto nvel:o uso de linguagens em que o programador no necessita operar em um nvel mais baixo de programao,elimina parte da complexidade. Ambientes de programao unificados:diminuem a complexidade ,por contar com grande nmero de ferramentas.

No Existe Bala de Prata-Essncia e Acidente em Engenharia de Software Programao Orientada a Objetos: uma grande aliada na soluo da complexidade,porm no a bala de prata. Inteligncia Artificial:ganhos na produtividade e qualidade do software ,mas no uma soluo definitiva.

No Existe Bala de Prata-Essncia e Acidente em Engenharia de Software Excelentes projetistas:desenvolvimento de software necessita de criatividade,por tanto ,mtodos de desenvolvimento nem sempre so teis.Desenvolvimento feito de modo criativo ,produzem com menor esforo e de forma mais rpida,diminuindo a complexidade.

No Existe Bala de Prata-Mais um Tiro

Montando uma estrutura a partir de peas pr-fabricadas,1945 Arquivo Bettman

No Existe Bala de Prata-Mais um Tiro Neste captulo,o autor defende seu artigo (captulo 16) de argumentos contra sua opinio e apia alguns que so a favor do ponto central do artigo.Que cita a impossibilidade de algo que possa tornar-se a bala de prata(soluo definitiva) contra o lobisomem(problemas no projeto).