Como desenvolver-software
1 gostou•533 visualizações
O documento discute os processos, métodos e ferramentas para desenvolvimento de software, enfatizando a importância de se seguir um processo estruturado e contínuo de melhoria. Aborda os modelos tradicionais como Waterfall e os mais modernos como ágeis, além de questões como gerência de requisitos, configuração e planejamento para garantir o sucesso dos projetos.
Como desenvolver-software
- 1. Como desenvolver software? Tecnologias, Ferramentas e Processos
- 2. Esta palestra fornece “visões”
- 3. Por que software? Porque a sociedade precisa Virtualmente quase tudo faz uso de software O que não usa software? Diretamente ou não?
- 4. Motivação Dinheiro (grandes empresas do planeta) Microsoft
- 5. IBM
- 6. Oracle
- 7. CA, ... Microsoft Empresa de maior valor de mercado do mundo
- 9. Mais de 1000 aplicam + de $1.000.000 em bolsas http://www.forbes.com/
- 10. Abordagens de construção http://www.swebok.org
- 11. Desnecessário Obrigatório ES se aplica a todos os casos?
- 12. Quando se aplica, o objetivo é... Engenharia de Software Produzir software economicamente que atende necessidades dos usuários
- 13. É difícil construir software? Modelar construções conceituais é a essência.
- 15. Propriedades inerentes: Complexidade (não linear com o tamanho)
- 16. Modificabilidade (infinitamente maleável)
- 17. Invisibilidade Esperanças: Comprar versus construir
- 18. Construção de protótipos (def. de requisitos é difícil)
- 19. Desenvolvimento incremental (crescer, não construir)
- 20. Bons projetistas No Silver Bullet: Essence and Accidents of Software Engineering Frederick P. Brooks, Jr. IEEE Computer, vol 20 (4), april, 1987, pp. 10-19.
- 21. Pense sobre isto! Ouvir
- 22. Ver
- 23. Cheirar
- 24. Lamber
- 25. Cortar
- 26. Matar
- 27. Desgastar
- 28. Encolher
- 29. Segurar ... O que é impossível de se fazer com um software:
- 30. Construir software é jogo de equipe Stakeholder: Pessoa que é afetada pelo sucesso ou não de um projeto (de software) Clientes, usuários (operadores), analistas, projetistas, programadores, ...
- 31. É possível construí-los sozinho? Operating System SLOC (Million)
- 32. Red Hat Linux 7.1 30
- 33. Debian 3.1 213
- 34. Sun Solaris 7.5
- 35. Linux kernel 2.6.0 6.0
- 36. Windows XP 40
- 37. Windows Vista 50 http://blogs.zdnet.com/web2explorer/?p=148
- 38. Software em construção Quais os problemas?
- 39. Cumprimento de prazos Insatisfação de clientes Baixa produtividade Erros Custos Complexidade Pessoas Desempenho Mudanças
- 40. Como resolver os problemas? Processos
- 41. Métodos
- 42. Ferramentas Maior relevância para o sucesso
- 43. Processo de software Processo é uma seqüência de tarefas que, executada adequadamente, produz o resultado desejado. Characterizing the Software Process: A Maturity Framework Watts S. Humphrey, IEEE Software, mar/1988, 73-79
- 44. Para se construir uma casa... É preciso um processo!
- 45. Processo Objeto desejado Mapa de tarefas (orientação) O que fazer? Quando? Quem? Qual ferramenta? Qual procedimento? Qual tecnologia?
- 48. Primeiro processo de software Code and fix
- 49. Implícito
- 50. Dinâmica Obter poucos detalhes
- 53. Corrigir problemas Ferramenta mais antiga encontrada. Usada há mais de 2 milhões de anos (provavelmente para cortar alimentos) http://news.bbc.co.uk/1/hi/sci/tech/336555.stm Processo caótico
- 54. Processo “mais famoso” Waterfall (fim de 1960)
- 55. Grandes projetos
- 57. Um estágio após outro
- 58. Idéia Produzir especificações detalhadas
- 59. Construir o objeto especificado Foz do Iguaçu (Iguaçu waterfalls) Análise Projeto Codificação Testes Instante do desenvolvimento
- 60. Construção de Itaipu Complexidade, custos, fases previsíveis,...
- 61. Modelos evolucionários Exemplos Modelo incremental, espiral, espiral WINWIN, ... Quando empregar? Produto evolui ao longo do tempo
- 62. Requisitos mudam ao longo do desenvolvimento
- 63. Versão deve ser introduzida (pressão de mercado)
- 64. Essência é compreendida (extensões indefinidas) Exemplo: Anti-vírus, ...
- 66. Princípios bem-aceitos Selecting a Project's Methodology Alistar Cockburn, IEEE Software, 2000, 64-71 Formalidade Comunicação
- 67. Preguiçoso social (social loafer) Pessoas que “não se preocupam muito com o grupo”, possuem um desempenho pior em grupo do que isoladamente. Max Ringelmann (1913): Grupos de homens puxando uma corda, fazem menos esforço do isolados. Quanto maior o grupo, mais se afasta de um comportamento linear. Preguçoso social (sozinho) Preguçoso social (em equipe)
- 68. Processos “conhecidos” IBM(r) Unified Process (UP) Incorpora “melhores práticas” (incremental)
- 69. Microsoft(tm) Synch-and-Stabilize Sincronizar equipes paralelas diariamente Estabilizar os incrementos (nightly build process)
- 70. Métodos ágeis eXtreme Programming ( XP )
- 71. SCRUM , DSDM , ... Waterfall Progressos visíveis continuamente!
- 72. Para melhorar é preciso ... Exige modelo de qualidade para avaliar e orientar o melhoramento Diagnosticar Modelos mais conhecidos: ISO 9000, CMM, SPICE, Bootstrap, IDEAL, ...
- 73. Melhoria de processo de software É difícil
- 74. Envolve mudanças na organização
- 75. Exige recursos e habilidades
- 76. Há grande risco de falha Software Process Improvement: Blueprints versus Recipes Ivan Aaen, IEEE Software, oct/2003, 86-93.
- 77. O que você deve fazer Trade-offs between Productivity and Quality in Selecting Software Development Practices Alan MacCormack et al, IEEE Software, oct/2003, 78-85 Criar uma versão logo no início Maior produtividade e menor taxa de defeitos
- 78. Não confunda ... Formigas são muito disciplinadas
- 79. Formigas não são formais Processos ágeis como XP (eXtreme Programming) “abandonam” formalidade sem perder disciplina
- 80. Processo é uma questão de fé? Especificações detalhadas de projeto Índia: 100%
- 81. US: 32% Projetos divididos em subciclos Índia e Europa: 64%
- 82. Waterfall like: Japão e US Taxa de defeitos Japão: 0.020
- 83. Índia: 0.263
- 84. Europa: 0.225
- 85. US: 0.4 Produtividade Europa e Japão (450 LOC por homem-mês) quase o dobro de Índia e US
- 86. Todos empregam revisões de software (código e projeto) Mais produção quando descrição funcional é mais completa. Software design mais completo antes de codificar correlaciona com menor número de defeitos. Waterfall Software Development Worldwide: The State of the Practice Michael Cusumano et al., IEEE Software, dez/2003, págs. 28-34 Requirements Engineering: The State of the Practice C. Neill et al., IEEE Software, dez/2003, 40-45 Mais de 1/3 usa o
- 87. Status quo de pesquisas Muitas tecnologias disponíveis não são usadas pela indústria Descrição de processo usa dossiê em vez de PML
- 88. Não são empregadas ferramentas O número de artigos e trabalhos em conferências e jornais está reduzindo
- 89. A comunidade encontra-se “travada” e incapaz de produzir contribuições efetivas Software Process: A Roadmap Alfonso Fuggetta , Conference on the Future of Software Engineering, 2000
- 90. Tecnologias de processo Process Modeling Languages (PMLs) Spade, Funsoft net, Sentinel, APPL/A, JIL, ... Ferramentas CSCL ( http://www.cscl.com/ )
- 92. PSP (time tracking) Hourglass ( http://hourglass.sourceforge.net/ )
- 95. Timetrack ( http://timetrack.sourceforge.net/ ) Omega-pi ( Development Case ) ( http://omegapi.sourceforge.net/ ) Por que não se usa? Relação custo-benefício não é satisfatória Why Software Process Innovations are not Adopted Stan Rifkin, IEEE Software, aug/2001, 110-112 CMM mais de 15 anos!
- 96. Importância de fases Requisitos Projeto Codificação Testes Implantação Ei, aqui! Qualidade do produto
- 97. O que é fundamental? Baseado em dados empíricos Process Maturity Profile: CMMI V1.1 SCAMP V1.1 Class A Appraisal Results 2004 Mid-Year Update (technical report CMU-SEI) é fundamental para o sucesso: Gerência de requisitos
- 100. Monitoramento e controle de projeto
- 101. Como me sinto? A Software Development Process for Small Projects Russ & McGregor, IEEE Software, oct/2000, 96-101 Equipe de desenvolvimento Teletubies Pequeno e perdido sugestão
- 102. Pense Todo produto é fruto de um processo Uma teoria: Controlar a qualidade do processo introduz qualidade no produto Software é fruto de pessoas (peopleware) Uma teoria: Melhorar as habilidades de comunicação, colaboração, pensamento e de métodos
- 103. Método Método é “como” construir Grego méthodos: caminho para chegar a um fim Análise, projeto, codificação, testes, ...
- 104. Padrões de bits
- 105. Macros
- 106. Assembly
- 107. Procedimentos
- 108. Tipos abstratos de dados Objetos, objetos de negócio, ... Orientação a objetos estende abstração de métodos clássicos Abstração crescente Abordagem estruturada
- 110. Métodos OO não são mais fáceis Métodos orientados a objetos Bibliografia – Object-Oriented Analysis and Design: A Comparative Review, Brinkkemper, S.
- 111. Problemas não resolvidos pela OO
- 112. Onde prefere morar?
- 113. Modelos Modelo e objeto modelado não se confundem
- 114. Mais um exemplo (o último!?) ∞
- 115. Fábula (sucesso)
- 116. Modelos, realidade e processo Repositório de Modelos “ Concreto” Abstrato Processo
- 117. Línguas de software Acerca de processo de software se fala Acerca da modelagem de software se fala
- 118. Ferramentas
- 119. Plataforma Java versus .Nada
- 120. Facilitar o aprendizado Universidades precisam fazer mais pelo ensino de processos de software! Software Process in the Classroom: The Capstone Project Experience David A. Umphress et al., IEEE Software, oct/2002, 78-85 Se treinamos engenheiros de software, então treinamos a programar para depois pensar acerca de modelagem, design, processo. Após hábitos ruins já estarem em uso. What Software Engineering Can Lear from Soccer Shari Lawrence Pfleeger, IEEE Software, nov/2002, 64-65
- 121. Construção de software ocorre em mentes! Prepare-se!
Notas do Editor
- #2: Não estou aqui para dizer como fazer, não se trata de uma prescrição, mas uma descrição. Em artigo de dezembro da IEEE Software o editor coloca muito bem esta questão. Muitos pesquisadores não conhecem realmente o que se passa na prática e o que é pior, eles pensam que sabem. A idéia é simples. Praticantes estão imersos. É preciso emergir e verificar o que se passa ao redor. Visto que imergir é uma tarefa na qual os praticantes são imbatíveis. Por outro lado, coloco-me aqui na posição de pesquisador e assumo a postura de que “não sei o que se passa na prática”. Com esta postura, esta apresentação, ao menos conceitualmente tenta ser livre de preconceitos e aberta a qualquer tipo de debate.
- #47: CONTA A HISTÓRIA QUE O MAUSOLÉU MAIS BONITO DO PLANETA É FRUTO DO AMOR DE UM GRANDE GUERREIRO PELA SUA MULHER. FÁBULA É INVENÇÃO MINHA: ESTE GUERREIRO TEVE QUE CONTAR COM ALGUÉM QUE CONSTRUI O MAUSOLÉU, OU SEJA, SUAS IDÉIAS TIVERAM QUE SAIR DA MENTE DELE E, DE FORMA FORMAL OU NÃO, SER TRANSFERIDA PARA A DE OUTRAS PESSOAS. ENTRE ELES, UM MODELO. NESTA FÁBULA, ELE IMAGINOU ASSIM O MAUSOLÉU, QUE FOI ASSIM INTERPRETADO PELA CONSTRUTORA DA ÉPOCA E FOI ASSIM REALIZADO. ESTA É UMA FÁBULA QUE SERVE COMO METÁFORA DE SUCESSO PARA ER.