Your SlideShare is downloading. ×
0
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
The Mythical Man-Month
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

The Mythical Man-Month

1,648

Published on

A slideShow in portuguese of the book `The Mythical Man-Month` wrote by Fred Brooks

A slideShow in portuguese of the book `The Mythical Man-Month` wrote by Fred Brooks

Published in: Technology, Travel
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,648
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Diego Santos de Andrade Pizzol
  • 2. Autor: Frederick P. Brooks
  • 3. <ul><li>Nasceu em 1931 , Carolina do Norte, USA. </li></ul><ul><li>Em 1956 obteve Ph.D . em Ciência da Computação em Harvard. </li></ul><ul><li>Ingressou na IBM em 1956 onde ficou até 1965 . </li></ul><ul><li>Foi ger ente no desenvolvimento dos computadores da IBM&apos;s System/360 e de seus sistema operacional OS/360 . </li></ul>
  • 4. <ul><li>Foi publicado em 1975 e relançado em 1995 . </li></ul><ul><li>É uma livro de gerenciamento de projeto de software escrito por Brooks. </li></ul><ul><li>Lei de Brook: </li></ul><ul><ul><li>&amp;quot;Adding manpower to a late software project makes it later.” </li></ul></ul><ul><li>Suas observaçoes foram baseadas no desenvolvimento do OS/360 na IBM. </li></ul>
  • 5. <ul><li>Chapter 1 - The Tar Pit </li></ul><ul><li>Chapter 2 - The Mythical Man-Month </li></ul><ul><li>Chapter 3 - The Surgical Team </li></ul><ul><li>Chapter 4 - Aristocracy, Democracy, and System Design </li></ul><ul><li>Chapter 5 - The Second-System Effect </li></ul><ul><li>Chapter 6 - Passing the Word </li></ul><ul><li>Chapter 7 - Why Did the Tower of Babel Fail? </li></ul><ul><li>Chapter 8 - Calling the Shot </li></ul><ul><li>Chapter 9 - Ten Pounds in a Five-Pound Sack </li></ul><ul><li>Chapter 10 - The Documentary Hypothesis </li></ul><ul><li>Chapter 11 - Plan to Throw One Away </li></ul><ul><li>Chapter 12 - Sharp Tools </li></ul><ul><li>Chapter 13 - The Whole and the Parts </li></ul><ul><li>Chapter 14 - Hatching a Catastrophe </li></ul><ul><li>Chapter 15 - The Other Face </li></ul><ul><li>Chapter 16 - No Silver Bullet—Essence and Accident </li></ul><ul><li>Chapter 17 - &amp;quot;No Silver Bullet&amp;quot;Refired </li></ul><ul><li>Chapter 18 - Propositions of The Mythical Man-Month: True or False? </li></ul><ul><li>Chapter 19 – The Mythical Man-Month after 20 Years </li></ul>
  • 6. = Vs Vs Vs
  • 7. Razão: Complexidade
  • 8. <ul><li>Positivo: </li></ul><ul><ul><ul><li>Sensação de poder </li></ul></ul></ul><ul><ul><ul><li>Sensação de utilidade </li></ul></ul></ul><ul><ul><ul><li>Desafio em fazer algo complexo </li></ul></ul></ul><ul><ul><ul><li>Compreensão de coisas novas </li></ul></ul></ul><ul><ul><ul><li>Caráter mágico </li></ul></ul></ul><ul><li>Negativo: </li></ul><ul><ul><ul><li>Complexidade </li></ul></ul></ul><ul><ul><ul><li>Necessidade de perfeição </li></ul></ul></ul><ul><ul><ul><li>Muita responsabilidade e pouca autoridade </li></ul></ul></ul><ul><ul><ul><li>Dependência de programas de terceiros </li></ul></ul></ul><ul><ul><ul><li>Criatividade </li></ul></ul></ul><ul><ul><ul><li>Testes e Depurações </li></ul></ul></ul><ul><ul><ul><li>Mutabilidade </li></ul></ul></ul>
  • 9. <ul><li>Problemas nos Projetos de Software são mais comuns </li></ul><ul><ul><ul><li>Técnicas de estimativas pouco desenvolvidas </li></ul></ul></ul><ul><ul><ul><li>Mistura-se esforço e progresso </li></ul></ul></ul><ul><ul><ul><li>Teimosia </li></ul></ul></ul><ul><ul><ul><li>Falta de monitoramento do progresso </li></ul></ul></ul><ul><ul><ul><li>Adição de mais homens em cronogramas atrasados </li></ul></ul></ul>
  • 10. <ul><li>Técnicas de estimativas pouco desenvolvidas </li></ul><ul><ul><ul><li>Otimismo infundado dos programadores </li></ul></ul></ul><ul><ul><ul><li>Processo criativo: idéia, implementação e realização </li></ul></ul></ul><ul><ul><ul><li>Subestimar testes e depurações </li></ul></ul></ul><ul><li>Exemplo de Cronograma: </li></ul><ul><ul><ul><li>1/3 – Planejamento </li></ul></ul></ul><ul><ul><ul><li>1/6 – Codificação </li></ul></ul></ul><ul><ul><ul><li>¼ - Testes de Componentes </li></ul></ul></ul><ul><ul><ul><li>¼ - Testes de Sistema </li></ul></ul></ul>½ do cronograma é reservado apenas para testes
  • 11. <ul><ul><ul><li>Mistura-se esforço e progresso </li></ul></ul></ul><ul><ul><ul><li>O custo depende dos homens e do tempo, o progresso não. </li></ul></ul></ul><ul><ul><ul><li>Unidade de esforço enganosa: homem-mês. </li></ul></ul></ul><ul><ul><ul><li>Divisão de uma tarefa: </li></ul></ul></ul><ul><ul><ul><ul><li>Não necessita-se de comunicação entre as partes </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Não pode ser divida devido a dependências </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Necessita-se de comunicação entre as partes </li></ul></ul></ul></ul>
  • 12. Sem comunicação entre as partes <ul><ul><ul><ul><li>Não pode ser divida devido a dependências </li></ul></ul></ul></ul>Com comunicação entre as partes Homens Meses Lei de Brooks: “ Adding manpower to a late software project makes it later.”
  • 13. <ul><li>Bons programadores: </li></ul><ul><ul><li>10 vezes mais produtivos </li></ul></ul><ul><ul><li>Mais caros </li></ul></ul><ul><ul><li>Mais escassos </li></ul></ul><ul><ul><li>Garantem melhor qualidade </li></ul></ul><ul><li>Programadores Comuns: </li></ul><ul><ul><li>Mais baratos </li></ul></ul><ul><ul><li>Mais difíceis de coordenar </li></ul></ul><ul><ul><li>Em abundancia </li></ul></ul><ul><ul><li>Produzem muito mais rápido </li></ul></ul>DILEMA
  • 14. <ul><li>Solução de Mill´s: </li></ul><ul><ul><li>EQUIPE CIRÚRGICA </li></ul></ul><ul><ul><ul><li>Cirurgião: Programador Chefe. Necessita de muita experiência. </li></ul></ul></ul><ul><ul><ul><li>Co-piloto: Mão direita do Cirurgião. </li></ul></ul></ul><ul><ul><ul><li>Administrador: Ajuda na gerencia da equipe. </li></ul></ul></ul><ul><ul><ul><li>Editor: Ajuda na criação da documentação. </li></ul></ul></ul><ul><ul><ul><li>Auxiliar de Programação: Responsável pela manutenção e visibilidade dos arquivos. </li></ul></ul></ul><ul><ul><ul><li>Ferramenteiro: Ajuda na elaboração de ferramentas. </li></ul></ul></ul><ul><ul><ul><li>Testador: Ajuda nos testes </li></ul></ul></ul><ul><ul><ul><li>Advogado da Linguagem: Consultoria de assuntos específicos da linguagem. </li></ul></ul></ul>
  • 15. <ul><li>Características da equipe cirúrgica: </li></ul><ul><ul><ul><li>Divisão do Trabalho </li></ul></ul></ul><ul><ul><ul><li>Subordinação </li></ul></ul></ul><ul><ul><ul><li>Especialização </li></ul></ul></ul><ul><li>Conseqüências : </li></ul><ul><ul><ul><li>Altamente eficiente </li></ul></ul></ul><ul><ul><ul><li>Padrão de comunicação muito simples </li></ul></ul></ul>
  • 16. <ul><li>Divisão das atividades do projeto geram perda de integridade conceitual . </li></ul><ul><li>O propósito de um programa é ser útil </li></ul><ul><ul><li>Utilidade = Simplicidade + Funcionalidade </li></ul></ul><ul><li>A integridade conceitual é importante, pois fornece clareza e simplicidade. </li></ul><ul><li>Para fornecer tal integridade o projeto deve ser criado por uma ou poucas pessoas. </li></ul>
  • 17. <ul><li>Desenvolvimento de Projetos de Software: </li></ul><ul><ul><li>Arquitetura = Aristocracia </li></ul></ul><ul><ul><ul><li>Monta o projeto </li></ul></ul></ul><ul><ul><ul><li>Escolhe as idéias </li></ul></ul></ul><ul><ul><li>Arquitetura = Democracia </li></ul></ul><ul><ul><ul><li>Escutam idéias de diversas pessoas </li></ul></ul></ul><ul><ul><ul><li>Os implementadores também exercem um papel criativo </li></ul></ul></ul><ul><li>Perspectiva de cada grupo: </li></ul><ul><ul><li>Arquitetura </li></ul></ul><ul><ul><ul><li>Facilidade de uso e utilidade </li></ul></ul></ul><ul><ul><li>Implementação </li></ul></ul><ul><ul><ul><li>Custo e performance </li></ul></ul></ul>
  • 18. <ul><li>Os arquitetos podem se submeter as restrições de orçamento de duas formas: </li></ul><ul><ul><li>Eliminando Componentes </li></ul></ul><ul><ul><li>Sugerindo um implementação barata. </li></ul></ul><ul><li>Os arquitetos: </li></ul><ul><ul><li>Apenas sugerem ao implementadores </li></ul></ul><ul><ul><li>Deve aceitar qualquer implementação que atinja a meta </li></ul></ul>
  • 19. <ul><li>Após construído o sistema, o arquiteto está sujeito ao segundo efeito. </li></ul><ul><ul><li>Utilização das idéias e ansiedades que antes foram deixada de lado </li></ul></ul><ul><li>Evitando o Efeito do Segundo Sistema </li></ul><ul><ul><li>Auto-disciplina </li></ul></ul><ul><ul><li>Experiência </li></ul></ul>
  • 20. <ul><li>É preciso escreve um manual contendo uma especificação detalhada e clara do sistema. </li></ul><ul><li>OS/360 foi escrito por apenas 2 pessoas, apesar de utilizar idéias de uma dezena de pessoas. </li></ul><ul><li>Tipos de Documentação: </li></ul><ul><ul><li>Linguagem Natural – Fácil compreensão e ambíguas . </li></ul></ul><ul><ul><li>Definição Formal – Precisa e de difícil compreensão . </li></ul></ul>
  • 21. <ul><li>Além da documentação é preciso ter reuniões </li></ul><ul><ul><li>Semanalmente </li></ul></ul><ul><ul><li>Anualmente </li></ul></ul><ul><li>Reuniões são importantes porque: </li></ul><ul><ul><li>Mantêm todos atualizados </li></ul></ul><ul><ul><li>Profundamente envolvidos </li></ul></ul><ul><ul><li>Atentos a inconsistências </li></ul></ul><ul><ul><li>Evita desperdício de tempo </li></ul></ul><ul><li>Grupo dos testadores </li></ul><ul><ul><li>Confratam a especificação com a implementação </li></ul></ul>
  • 22. Comunicação Organização
  • 23. <ul><li>A comunicação pode ser realizada: </li></ul><ul><ul><li>Documentação </li></ul></ul><ul><ul><li>Reuniões </li></ul></ul><ul><ul><li>Workbook </li></ul></ul><ul><li>Workbook compõe: </li></ul><ul><ul><li>Objetivos </li></ul></ul><ul><ul><li>Especificação externa, interna e das interfaces </li></ul></ul><ul><ul><li>Padrões técnicos </li></ul></ul><ul><ul><li>Memorandos administrativos </li></ul></ul><ul><li>Workbook é importante para organizar e controlar a disseminação das informações importantes. </li></ul>
  • 24. <ul><li>Workbook pode ser armazenado em: </li></ul><ul><ul><li>Papel </li></ul></ul><ul><ul><li>Microfilmagem </li></ul></ul><ul><ul><li>Meio Digital </li></ul></ul><ul><li>A organização é um fator importante: </li></ul><ul><ul><li>Reduz a quantidade de comunicação demandada </li></ul></ul><ul><ul><li>Facilita a coordenação das tarefas. </li></ul></ul><ul><li>As equipes de trabalhos devem seguir uma estrutura hierárquica. </li></ul>
  • 25. <ul><li>Cada equipe deve ter: </li></ul><ul><ul><li>Missão </li></ul></ul><ul><ul><li>Produtor </li></ul></ul><ul><ul><li>Diretor técnico ou Arquiteto </li></ul></ul><ul><ul><li>Cronograma </li></ul></ul><ul><ul><li>Divisão do trabalho </li></ul></ul><ul><ul><li>Definições de interfaces entre as partes. </li></ul></ul><ul><li>Produtor – Deve gerenciar a equipe </li></ul><ul><li>Diretor Técnico – Responsável pelo projeto </li></ul>
  • 26. <ul><li>Produtor e diretor como a mesma pessoa. </li></ul><ul><ul><li>Usado em equipes bem pequenas </li></ul></ul><ul><ul><li>Talento gerencial e Talento Técnico. </li></ul></ul><ul><ul><li>Cada cargo demanda tempo integral </li></ul></ul><ul><li>Produtor como chefe e diretor como braço direito. </li></ul><ul><ul><li>Lidar com a autoridade do diretor para que não afete o produtor </li></ul></ul><ul><ul><li>Recomendado para equipes maiores </li></ul></ul><ul><li>Diretor como chefe e produtor como braço direito. </li></ul><ul><ul><li>Recomendado para equipe pequenas </li></ul></ul><ul><ul><li>A exemplo do Surgical Team </li></ul></ul>
  • 27. <ul><li>Estimar o tempo ou o esforço necessário para um projeto não é muito fácil. </li></ul><ul><li>Estudo realizado por Nanus e Farr mostra que: </li></ul><ul><ul><li>O esforço está diretamente ligado ao tamanho do projeto </li></ul></ul><ul><ul><li>Fórmula: esforço = cnst x (n°. de instruções) 1.5 </li></ul></ul>
  • 28. <ul><li>Um estudo sobre produtividade de Portman mostra: </li></ul><ul><ul><li>Programadores passam semanalmente: </li></ul></ul><ul><ul><ul><li>50% programando e depurando </li></ul></ul></ul><ul><ul><ul><li>50% envolvidos em outras atividades diversas </li></ul></ul></ul><ul><li>Outro pesquisador, Hair classificou a produtividade em: </li></ul><ul><ul><ul><li>Programas de controle: 600 palavras por homem-ano. </li></ul></ul></ul><ul><ul><ul><li>Tradutores: 2200 palavras por homem-ano. </li></ul></ul></ul><ul><li>OS/360 obteve média de produtividade de: </li></ul><ul><ul><ul><li>600-800 instruções de programas de controle por homem-ano </li></ul></ul></ul><ul><ul><ul><li>2000-3000 instruções depuradas de tradutores por homem-ano </li></ul></ul></ul>
  • 29. <ul><li>Corbato realizou um estudo sobre a produtuvidade com uma linguagem de alto nível: PL/I </li></ul><ul><ul><ul><li>Taxa de produtividade: 1200 linhas (não palavras) por homem-ano </li></ul></ul></ul><ul><li>Podemos concluir que: </li></ul><ul><ul><li>A produtividade parece ser constante usando instruções elementares </li></ul></ul><ul><ul><li>A produtividade pode ser aumentada até 5 vezes com linguagens de alto nível. </li></ul></ul>
  • 30. <ul><li>Além do custo com o próprio software o cliente também pode ter custo com o tamanho dele. </li></ul><ul><ul><li>IBM APL - $400 de aluguel e $320 de aluguel da memória por mês </li></ul></ul><ul><li>Os construtores devem impor controles, limites e técnicas de redução de tamanhos. </li></ul><ul><li>O gerente de controle de tamanho deve ter conhecimentos gerenciais e técnicos. </li></ul>
  • 31. <ul><li>Com o OS/360 três lições foram aprendidas: </li></ul><ul><ul><ul><li>Deve-se estipular um tamanho total do sistema </li></ul></ul></ul><ul><ul><ul><li>Deve-se definir exatamente o que cada módulo deve fazer quando as restrições de tamanho forem aplicadas </li></ul></ul></ul><ul><ul><ul><li>Deve-se manter comunicação entre as partes ao realizar as reduções de tamanhos dos componentes </li></ul></ul></ul><ul><li>Geralmente, espaço é ganho com a perda de performance </li></ul><ul><li>Algumas vezes a única forma de reduzir espaço é através da engenhosidade e criatividade. </li></ul>
  • 32. <ul><li>A grande quantidade de documentos gerados durante o projeto pode atrapalhar seu desenvolvimento. </li></ul><ul><li>É preciso separar o joio do trigo e saber quais documentos são fundamentais. </li></ul><ul><li>Para o desenvolvimento de projetos de software: </li></ul><ul><ul><li>Objetivos </li></ul></ul><ul><ul><li>Manual do usuário </li></ul></ul><ul><ul><li>Especificações internas </li></ul></ul><ul><ul><li>Cronograma </li></ul></ul><ul><ul><li>Orçamento </li></ul></ul><ul><ul><li>Estrutura organizacional </li></ul></ul><ul><ul><li>Alocações de espaço </li></ul></ul>
  • 33. <ul><li>Esses documentos são importantes, tornam as falhas e inconsistências visíveis. </li></ul><ul><li>Os documentos ajudam a gerenciar e disseminar as informações. </li></ul><ul><li>Servem como um banco de dados dos avanços realizados </li></ul><ul><li>Devem se encarados como ferramenta de auxílio ao gerente e não como uma simples obrigação. </li></ul>
  • 34. <ul><li>Os engenheiros químicos utilizam uma planta piloto para implementar um processo do laboratório para a industria </li></ul><ul><li>Os engenheiros de software deveria utilizar um sistema piloto para testar o produto antes de entregar ao cliente </li></ul><ul><li>Quase em todos os projetos a primeira versão é pouco usável </li></ul><ul><li>Planeje joga um fora, você irá de uma forma ou de outra </li></ul>
  • 35. <ul><li>Ao se preparar, estará começando a aceitar o fenômeno da mudança. </li></ul><ul><li>O software tem tendência a mudar por causa de seu carater intangível. </li></ul><ul><li>Para se proteger das mudanças pode-se: </li></ul><ul><ul><li>Usar modularização </li></ul></ul><ul><ul><li>Descrever com precisão as interfaces entre módulos </li></ul></ul><ul><ul><li>Utilizar subrotinas </li></ul></ul><ul><li>Utilizando linguagens de alto nível e auto-documentação pode-se reduzir o número de erros gerados pelas mudanças </li></ul>
  • 36. <ul><li>Pode-se preparar a estrutura organizacional para mudança: </li></ul><ul><ul><li>Separando os gerentes e o pessoal técnico </li></ul></ul><ul><ul><li>Criando Carreiras Salariais equivalentes e independentes </li></ul></ul>
  • 37. <ul><li>Como software muda muito a sua manutenção é bastante cara </li></ul><ul><ul><ul><li>Chega a 40% do custo do desenvolvimento </li></ul></ul></ul><ul><li>Ao corrigir um bug existe uma probabilidade de 20-50% de ser inserido outro defeito </li></ul><ul><ul><ul><li>Após cada conserto todos os testes de casos devem ser executados </li></ul></ul></ul><ul><li>Todos os reparos tendem destruir a estrutura, aumentando a entropia e a desordem do sistema </li></ul>
  • 38. <ul><li>Várias ferramentas diferentes, realizando a mesma função atrapalham o desenvolvimento do projeto </li></ul><ul><li>O gerente do projeto precisa construir uma ferramenta de propósito geral </li></ul><ul><li>Os computadores podem ser: </li></ul><ul><ul><ul><li>Máquinas Alvos – Programa se destina a elas. </li></ul></ul></ul><ul><ul><ul><li>Máquinas Veículos – Programa são produzidos nelas. </li></ul></ul></ul>
  • 39. <ul><li>É necessária uma divisão formal e uma progressão entre as diferentes bibliotecas </li></ul><ul><ul><ul><li>Área individual (playpen) </li></ul></ul></ul><ul><ul><ul><li>Sistema de integração de bibliotecas </li></ul></ul></ul><ul><ul><ul><li>Versão pronta do sistema </li></ul></ul></ul><ul><li>As linguagens de alto nível não só aumentam a produtividade como facilitam a depuração </li></ul><ul><li>Utilização das máquinas alvos </li></ul>
  • 40. <ul><li>Para que um sistema tenha poucos bugs ele deve ter integridade conceitual e ser testado muito antes da codificação começar </li></ul><ul><li>Há um processo de desenvolvimento divido em etapas na qual cada uma delas é caracterizado por um modelo top-down que evita bugs . </li></ul><ul><li>Esse modelo top-down evita bugs por quatro motivos: </li></ul><ul><ul><li>Clareza da estrutura e da representação </li></ul></ul><ul><ul><li>Particionamento e independência dos módulos </li></ul></ul><ul><ul><li>Torna inconsistências mais visíveis </li></ul></ul><ul><ul><li>Possibilita testar a cada refinamento. </li></ul></ul>
  • 41. <ul><li>Outro mecanismo que facilita a diminuição de bugs é a programação estrutura </li></ul><ul><li>Os componentes devem ser depurados individualmente antes de serem juntados, pois juntos a depuração se torna mais complexa. </li></ul><ul><li>Esses componentes devem ser adicionados um a um de forma gradativa, eliminando as falhas paulatinamente </li></ul><ul><li>Para cada mudança ocorrida deve-se documentar, criada uma versão e armazenada na área individual de trabalho da equipe. </li></ul>
  • 42. <ul><li>Os piores atrasos são os que acontecem diariamente, pois são mais difíceis de reconhecer, de prevenir e de corrigir </li></ul><ul><li>Para controlar o cronograma de um grande projeto, deve-se ter um cronograma com metas e datas a serem alcançadas. </li></ul><ul><li>Essas metas devem ser eventos concretos, específicos e mensuráveis definidos com bastante astúcia </li></ul><ul><li>Estudos sobre estimativas de contratos de longos projetos mostram: </li></ul><ul><ul><li>Estimativas de tempo de atividade revisadas duas semanas antes não se alteram significamente até que atividade comece; </li></ul></ul><ul><ul><li>Estimativas além do prazo necessário, fazem com que durante a atividade todos relaxem para sua obtenção; </li></ul></ul><ul><ul><li>Estimativas abaixo do prazo necessário, não sofrem mudanças até que estejam perto do final. </li></ul></ul>
  • 43. <ul><li>Para saber quais pontos do projeto são mais críticos, pode-se utilizar um fluxograma de caminhos críticos </li></ul><ul><li>Quando uma tarefa atrasa, o chefe do gerente da tarefa deve distinguir informação de status e informação de ação. </li></ul><ul><li>Documentos de revisão contendo as metas e suas conclusões devem ser gerados, para manter o cronograma sempre em dia </li></ul><ul><li>Em grandes projetos é indispensável uma pequena equipe de plano e controle para manter os relatórios de metas atualizados </li></ul>
  • 44. <ul><li>Além da documentação escrita para os próprios construtores deve haver uma documentação de auxílio para os usuários </li></ul><ul><li>Diferentes níveis de documentação são requeridos de acordo com quem elas se destinam. </li></ul><ul><li>A maioria dos usuários necessita de uma descrição breve do que o programa contendo: </li></ul><ul><ul><li>Propósito </li></ul></ul><ul><ul><li>Ambiente </li></ul></ul><ul><ul><li>Domínio e alcance </li></ul></ul><ul><ul><li>Funções fornecidas e algoritmos utilizados </li></ul></ul><ul><ul><li>Formatos de entrada e saída </li></ul></ul><ul><ul><li>Instruções de operação </li></ul></ul><ul><ul><li>Opções </li></ul></ul><ul><ul><li>Tempo de execução </li></ul></ul><ul><ul><li>Precisão e checagens. </li></ul></ul>
  • 45. <ul><li>Para pessoas que irão modificar o programa uma documentação mais detalhada deve ser criada, contendo: </li></ul><ul><ul><li>Gráfico da estrutura do programa </li></ul></ul><ul><ul><li>Descrição completa dos algoritmos usados </li></ul></ul><ul><ul><li>Explicação do modelo dos arquivos utilizados </li></ul></ul><ul><ul><li>Revisão do fluxo das estruturas </li></ul></ul><ul><ul><li>Discussão sobre as alterações preferíveis e não desejáveis. </li></ul></ul><ul><li>Além de criar a documentação é preciso mantê-la </li></ul><ul><li>A auto-documentação facilita na manutenção e pode facilitar a documentação: </li></ul><ul><ul><li>Usando nomes e declarações com sentido </li></ul></ul><ul><ul><li>Usar espaçamento e endentação para facilitar a leitura </li></ul></ul><ul><ul><li>Inserir textos comentados, principalmente no cabeçalho </li></ul></ul>
  • 46. <ul><li>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 </li></ul><ul><li>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. </li></ul><ul><li>Para mensurar o desenvolvimento de software podemos dividi-lo em duas categorias: </li></ul><ul><ul><li>A essência - Dificuldades inerentes à natureza do problema </li></ul></ul><ul><ul><li>A casualidade - Dificuldades atuais de sua produção </li></ul></ul><ul><li>A essência é inerentemente abstrata formada por conceitos que se completam </li></ul>
  • 47. <ul><li>O software é difícil de ser criado devido a suas propriedades irredutíveis: </li></ul><ul><ul><li>Complexidade </li></ul></ul><ul><ul><ul><li>Cada programa é formado pro partes únicas, não iguais a outro </li></ul></ul></ul><ul><ul><ul><li>Possui diversos estados </li></ul></ul></ul><ul><ul><ul><li>Seu crescimento não se faz através da repetição dos mesmo elementos </li></ul></ul></ul><ul><ul><li>Conformidade </li></ul></ul><ul><ul><ul><li>Devem estar em conformidade com várias outras interfaces </li></ul></ul></ul><ul><ul><li>Mutabilidade </li></ul></ul><ul><ul><ul><li>Por ser intangível está susceptível a mudanças </li></ul></ul></ul><ul><ul><li>Invisibilidade </li></ul></ul><ul><ul><ul><li>Não pode ser representado no espaço </li></ul></ul></ul>
  • 48. <ul><li>Os avanços existentes foram na área da casualidade: </li></ul><ul><ul><li>Linguagens de alto nível </li></ul></ul><ul><ul><li>Time-sharing </li></ul></ul><ul><ul><li>Ambientes de programação unificados </li></ul></ul><ul><li>Apesar desses avanços não terem revelado nenhuma bala de prata, muitas pessoas tem esperança de encontra-la em: </li></ul><ul><ul><li>Linguagem Ada </li></ul></ul><ul><ul><li>Programação orientada a objetos </li></ul></ul><ul><ul><li>Inteligência artificial </li></ul></ul><ul><ul><li>Sistemas inteligentes </li></ul></ul><ul><ul><li>Programação “automática” </li></ul></ul><ul><ul><li>Programação gráfica </li></ul></ul><ul><ul><li>Programas de verificação </li></ul></ul>
  • 49. <ul><li>Embora nenhuma dessas tecnologias se tornou uma bala de prata, todas desenvolveram as propriedades da casualidade do software. </li></ul><ul><li>Alternativas possíveis de avanços na essência do software como: </li></ul><ul><ul><li>Comprar ao invés de construir </li></ul></ul><ul><ul><li>Refinamento dos requisitos e prototipagem rápida </li></ul></ul><ul><ul><li>Desenvolvimento incremental </li></ul></ul><ul><ul><li>Ótimos projetista. </li></ul></ul>
  • 50. <ul><li>FIM </li></ul><ul><ul><li> Obrigado! </li></ul></ul>

×