O documento descreve a carreira e obra de Frederick P. Brooks, autor do livro "The Mythical Man-Month". O livro analisa os problemas de gerenciamento de projetos de software e propõe técnicas para melhor estimativa de tempo e controle de cronograma para evitar atrasos.

1. Diego Santos de Andrade Pizzol

2. Autor: Frederick P. Brooks

3. Nasceu em 1931 , Carolina do Norte, USA. Em 1956 obteve Ph.D . em Ciência da Computação em Harvard. Ingressou na IBM em 1956 onde ficou até 1965 . Foi ger ente no desenvolvimento dos computadores da IBM's System/360 e de seus sistema operacional OS/360 .

4. Foi publicado em 1975 e relançado em 1995 . É uma livro de gerenciamento de projeto de software escrito por Brooks. Lei de Brook: "Adding manpower to a late software project makes it later.” Suas observaçoes foram baseadas no desenvolvimento do OS/360 na IBM.

5. Chapter 1 - The Tar Pit Chapter 2 - The Mythical Man-Month Chapter 3 - The Surgical Team Chapter 4 - Aristocracy, Democracy, and System Design Chapter 5 - The Second-System Effect Chapter 6 - Passing the Word Chapter 7 - Why Did the Tower of Babel Fail? Chapter 8 - Calling the Shot Chapter 9 - Ten Pounds in a Five-Pound Sack Chapter 10 - The Documentary Hypothesis Chapter 11 - Plan to Throw One Away Chapter 12 - Sharp Tools Chapter 13 - The Whole and the Parts Chapter 14 - Hatching a Catastrophe Chapter 15 - The Other Face Chapter 16 - No Silver Bullet—Essence and Accident Chapter 17 - "No Silver Bullet"Refired Chapter 18 - Propositions of The Mythical Man-Month: True or False? Chapter 19 – The Mythical Man-Month after 20 Years

6. = Vs Vs Vs

7. Razão: Complexidade

8. Positivo: Sensação de poder Sensação de utilidade Desafio em fazer algo complexo Compreensão de coisas novas Caráter mágico Negativo: Complexidade Necessidade de perfeição Muita responsabilidade e pouca autoridade Dependência de programas de terceiros Criatividade Testes e Depurações Mutabilidade

9. Problemas nos Projetos de Software são mais comuns Técnicas de estimativas pouco desenvolvidas Mistura-se esforço e progresso Teimosia Falta de monitoramento do progresso Adição de mais homens em cronogramas atrasados

10. Técnicas de estimativas pouco desenvolvidas Otimismo infundado dos programadores Processo criativo: idéia, implementação e realização Subestimar testes e depurações Exemplo de Cronograma: 1/3 – Planejamento 1/6 – Codificação ¼ - Testes de Componentes ¼ - Testes de Sistema ½ do cronograma é reservado apenas para testes

11. Mistura-se esforço e progresso O custo depende dos homens e do tempo, o progresso não. Unidade de esforço enganosa: homem-mês. Divisão de uma tarefa: Não necessita-se de comunicação entre as partes Não pode ser divida devido a dependências Necessita-se de comunicação entre as partes

12. Sem comunicação entre as partes Não pode ser divida devido a dependências Com comunicação entre as partes Homens Meses Lei de Brooks: “ Adding manpower to a late software project makes it later.”

13. Bons programadores: 10 vezes mais produtivos Mais caros Mais escassos Garantem melhor qualidade Programadores Comuns: Mais baratos Mais difíceis de coordenar Em abundancia Produzem muito mais rápido DILEMA

14. Solução de Mill´s: EQUIPE CIRÚRGICA Cirurgião: Programador Chefe. Necessita de muita experiência. Co-piloto: Mão direita do Cirurgião. Administrador: Ajuda na gerencia da equipe. Editor: Ajuda na criação da documentação. Auxiliar de Programação: Responsável pela manutenção e visibilidade dos arquivos. Ferramenteiro: Ajuda na elaboração de ferramentas. Testador: Ajuda nos testes Advogado da Linguagem: Consultoria de assuntos específicos da linguagem.

15. Características da equipe cirúrgica: Divisão do Trabalho Subordinação Especialização Conseqüências : Altamente eficiente Padrão de comunicação muito simples

16. Divisão das atividades do projeto geram perda de integridade conceitual . O propósito de um programa é ser útil Utilidade = Simplicidade + Funcionalidade A integridade conceitual é importante, pois fornece clareza e simplicidade. Para fornecer tal integridade o projeto deve ser criado por uma ou poucas pessoas.

17. Desenvolvimento de Projetos de Software: Arquitetura = Aristocracia Monta o projeto Escolhe as idéias Arquitetura = Democracia Escutam idéias de diversas pessoas Os implementadores também exercem um papel criativo Perspectiva de cada grupo: Arquitetura Facilidade de uso e utilidade Implementação Custo e performance

18. Os arquitetos podem se submeter as restrições de orçamento de duas formas: Eliminando Componentes Sugerindo um implementação barata. Os arquitetos: Apenas sugerem ao implementadores Deve aceitar qualquer implementação que atinja a meta

19. Após construído o sistema, o arquiteto está sujeito ao segundo efeito. Utilização das idéias e ansiedades que antes foram deixada de lado Evitando o Efeito do Segundo Sistema Auto-disciplina Experiência

20. É preciso escreve um manual contendo uma especificação detalhada e clara do sistema. OS/360 foi escrito por apenas 2 pessoas, apesar de utilizar idéias de uma dezena de pessoas. Tipos de Documentação: Linguagem Natural – Fácil compreensão e ambíguas . Definição Formal – Precisa e de difícil compreensão .

21. Além da documentação é preciso ter reuniões Semanalmente Anualmente Reuniões são importantes porque: Mantêm todos atualizados Profundamente envolvidos Atentos a inconsistências Evita desperdício de tempo Grupo dos testadores Confratam a especificação com a implementação

22. Comunicação Organização

23. A comunicação pode ser realizada: Documentação Reuniões Workbook Workbook compõe: Objetivos Especificação externa, interna e das interfaces Padrões técnicos Memorandos administrativos Workbook é importante para organizar e controlar a disseminação das informações importantes.

24. Workbook pode ser armazenado em: Papel Microfilmagem Meio Digital A organização é um fator importante: Reduz a quantidade de comunicação demandada Facilita a coordenação das tarefas. As equipes de trabalhos devem seguir uma estrutura hierárquica.

25. Cada equipe deve ter: Missão Produtor Diretor técnico ou Arquiteto Cronograma Divisão do trabalho Definições de interfaces entre as partes. Produtor – Deve gerenciar a equipe Diretor Técnico – Responsável pelo projeto

26. Produtor e diretor como a mesma pessoa. Usado em equipes bem pequenas Talento gerencial e Talento Técnico. Cada cargo demanda tempo integral Produtor como chefe e diretor como braço direito. Lidar com a autoridade do diretor para que não afete o produtor Recomendado para equipes maiores Diretor como chefe e produtor como braço direito. Recomendado para equipe pequenas A exemplo do Surgical Team

27. Estimar o tempo ou o esforço necessário para um projeto não é muito fácil. Estudo realizado por Nanus e Farr mostra que: O esforço está diretamente ligado ao tamanho do projeto Fórmula: esforço = cnst x (n°. de instruções) 1.5

28. Um estudo sobre produtividade de Portman mostra: Programadores passam semanalmente: 50% programando e depurando 50% envolvidos em outras atividades diversas Outro pesquisador, Hair classificou a produtividade em: Programas de controle: 600 palavras por homem-ano. Tradutores: 2200 palavras por homem-ano. OS/360 obteve média de produtividade de: 600-800 instruções de programas de controle por homem-ano 2000-3000 instruções depuradas de tradutores por homem-ano

29. Corbato realizou um estudo sobre a produtuvidade com uma linguagem de alto nível: PL/I Taxa de produtividade: 1200 linhas (não palavras) por homem-ano Podemos concluir que: A produtividade parece ser constante usando instruções elementares A produtividade pode ser aumentada até 5 vezes com linguagens de alto nível.

30. Além do custo com o próprio software o cliente também pode ter custo com o tamanho dele. IBM APL - $400 de aluguel e $320 de aluguel da memória por mês Os construtores devem impor controles, limites e técnicas de redução de tamanhos. O gerente de controle de tamanho deve ter conhecimentos gerenciais e técnicos.

31. Com o OS/360 três lições foram aprendidas: Deve-se estipular um tamanho total do sistema Deve-se definir exatamente o que cada módulo deve fazer quando as restrições de tamanho forem aplicadas Deve-se manter comunicação entre as partes ao realizar as reduções de tamanhos dos componentes Geralmente, espaço é ganho com a perda de performance Algumas vezes a única forma de reduzir espaço é através da engenhosidade e criatividade.

32. A grande quantidade de documentos gerados durante o projeto pode atrapalhar seu desenvolvimento. É preciso separar o joio do trigo e saber quais documentos são fundamentais. Para o desenvolvimento de projetos de software: Objetivos Manual do usuário Especificações internas Cronograma Orçamento Estrutura organizacional Alocações de espaço

33. Esses documentos são importantes, tornam as falhas e inconsistências visíveis. Os documentos ajudam a gerenciar e disseminar as informações. Servem como um banco de dados dos avanços realizados Devem se encarados como ferramenta de auxílio ao gerente e não como uma simples obrigação.

34. Os engenheiros químicos utilizam uma planta piloto para implementar um processo do laboratório para a industria Os engenheiros de software deveria utilizar um sistema piloto para testar o produto antes de entregar ao cliente Quase em todos os projetos a primeira versão é pouco usável Planeje joga um fora, você irá de uma forma ou de outra

35. Ao se preparar, estará começando a aceitar o fenômeno da mudança. O software tem tendência a mudar por causa de seu carater intangível. Para se proteger das mudanças pode-se: Usar modularização Descrever com precisão as interfaces entre módulos Utilizar subrotinas Utilizando linguagens de alto nível e auto-documentação pode-se reduzir o número de erros gerados pelas mudanças

36. Pode-se preparar a estrutura organizacional para mudança: Separando os gerentes e o pessoal técnico Criando Carreiras Salariais equivalentes e independentes

37. Como software muda muito a sua manutenção é bastante cara Chega a 40% do custo do desenvolvimento Ao corrigir um bug existe uma probabilidade de 20-50% de ser inserido outro defeito Após cada conserto todos os testes de casos devem ser executados Todos os reparos tendem destruir a estrutura, aumentando a entropia e a desordem do sistema

38. Várias ferramentas diferentes, realizando a mesma função atrapalham o desenvolvimento do projeto O gerente do projeto precisa construir uma ferramenta de propósito geral Os computadores podem ser: Máquinas Alvos – Programa se destina a elas. Máquinas Veículos – Programa são produzidos nelas.

39. É necessária uma divisão formal e uma progressão entre as diferentes bibliotecas Área individual (playpen) Sistema de integração de bibliotecas Versão pronta do sistema As linguagens de alto nível não só aumentam a produtividade como facilitam a depuração Utilização das máquinas alvos

40. Para que um sistema tenha poucos bugs ele deve ter integridade conceitual e ser testado muito antes da codificação começar Há um processo de desenvolvimento divido em etapas na qual cada uma delas é caracterizado por um modelo top-down que evita bugs . Esse modelo top-down evita bugs por quatro motivos: Clareza da estrutura e da representação Particionamento e independência dos módulos Torna inconsistências mais visíveis Possibilita testar a cada refinamento.

41. Outro mecanismo que facilita a diminuição de bugs é a programação estrutura Os componentes devem ser depurados individualmente antes de serem juntados, pois juntos a depuração se torna mais complexa. Esses componentes devem ser adicionados um a um de forma gradativa, eliminando as falhas paulatinamente Para cada mudança ocorrida deve-se documentar, criada uma versão e armazenada na área individual de trabalho da equipe.

42. Os piores atrasos são os que acontecem diariamente, pois são mais difíceis de reconhecer, de prevenir e de corrigir Para controlar o cronograma de um grande projeto, deve-se ter um cronograma com metas e datas a serem alcançadas. Essas metas devem ser eventos concretos, específicos e mensuráveis definidos com bastante astúcia Estudos sobre estimativas de contratos de longos projetos mostram: Estimativas de tempo de atividade revisadas duas semanas antes não se alteram significamente até que atividade comece; Estimativas além do prazo necessário, fazem com que durante a atividade todos relaxem para sua obtenção; Estimativas abaixo do prazo necessário, não sofrem mudanças até que estejam perto do final.

43. Para saber quais pontos do projeto são mais críticos, pode-se utilizar um fluxograma de caminhos críticos Quando uma tarefa atrasa, o chefe do gerente da tarefa deve distinguir informação de status e informação de ação. Documentos de revisão contendo as metas e suas conclusões devem ser gerados, para manter o cronograma sempre em dia Em grandes projetos é indispensável uma pequena equipe de plano e controle para manter os relatórios de metas atualizados

44. Além da documentação escrita para os próprios construtores deve haver uma documentação de auxílio para os usuários Diferentes níveis de documentação são requeridos de acordo com quem elas se destinam. A maioria dos usuários necessita de uma descrição breve do que o programa contendo: Propósito Ambiente Domínio e alcance Funções fornecidas e algoritmos utilizados Formatos de entrada e saída Instruções de operação Opções Tempo de execução Precisão e checagens.

45. Para pessoas que irão modificar o programa uma documentação mais detalhada deve ser criada, contendo: Gráfico da estrutura do programa Descrição completa dos algoritmos usados Explicação do modelo dos arquivos utilizados Revisão do fluxo das estruturas Discussão sobre as alterações preferíveis e não desejáveis. Além de criar a documentação é preciso mantê-la A auto-documentação facilita na manutenção e pode facilitar a documentação: Usando nomes e declarações com sentido Usar espaçamento e endentação para facilitar a leitura Inserir textos comentados, principalmente no cabeçalho

46. Devido a tantos problemas muitos buscam uma solução mágicas que resolva os problema de uma vez, como uma bala de prata faria com um lobisomen Não se vê essa bala de prata, mas, sim, uma possível melhoraria gradativa através de disciplina, esforço e exploração das técnicas empregadas. Para mensurar o desenvolvimento de software podemos dividi-lo em duas categorias: A essência - Dificuldades inerentes à natureza do problema A casualidade - Dificuldades atuais de sua produção A essência é inerentemente abstrata formada por conceitos que se completam

47. O software é difícil de ser criado devido a suas propriedades irredutíveis: Complexidade Cada programa é formado pro partes únicas, não iguais a outro Possui diversos estados Seu crescimento não se faz através da repetição dos mesmo elementos Conformidade Devem estar em conformidade com várias outras interfaces Mutabilidade Por ser intangível está susceptível a mudanças Invisibilidade Não pode ser representado no espaço

48. Os avanços existentes foram na área da casualidade: Linguagens de alto nível Time-sharing Ambientes de programação unificados Apesar desses avanços não terem revelado nenhuma bala de prata, muitas pessoas tem esperança de encontra-la em: Linguagem Ada Programação orientada a objetos Inteligência artificial Sistemas inteligentes Programação “automática” Programação gráfica Programas de verificação

49. Embora nenhuma dessas tecnologias se tornou uma bala de prata, todas desenvolveram as propriedades da casualidade do software. Alternativas possíveis de avanços na essência do software como: Comprar ao invés de construir Refinamento dos requisitos e prototipagem rápida Desenvolvimento incremental Ótimos projetista.

50. FIM Obrigado!