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.
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, ...
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
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
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.
88.
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
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, ...
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.
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
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.
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.