Alguns tópicos de uma apresentação que encontrei hoje sobre Engenharia de Software e que muito me chamou a atenção.
A versão completa para quem quiser mais detalhes está disponível em: http://www.async.com.br/~kiko/UFSCar2004/ e foi escrita por Christian Reis (@kiko666).
* Apresentação e Introdução:
- Minha experiência com Engenharia de Software indica que:
1. É bem mais difícil do que parece.
2. É um termo que normalmente inspira bocejos.
3. Há algum problema sério nisso tudo
- Um experimento social:
- Por que se formam tantos engenheiros de software desmotivados? //http://akitaonrails.com/2009/04/17/off-topic-devo-fazer-faculdade
- Por que se formam tantos engenheiros de software mal-formados? //http://akitaonrails.com/2009/04/17/off-topic-devo-fazer-faculdade
- Por que Engenharia de Software é tão mal-vista? // Ainda existe muito amadorismo na área. Esse amadorismo que eu falo não tem nada, mais nada a ver com formação superior: O Uncle Bob explica muito bem isso aqui:
http://malditacomedia.blogspot.com/2009/06/uncle-bob-e-o-dilema-do.html
.
* O Engenheiro de Software:
- A mais difícil profissão moderna!
- Requer conhecimento técnico detalhado em uma área onde nada é estático. //
http://www.agilemodeling.com/essays/generalizingSpecialists.htm - Requer conhecimento do “domínio”; de fato, de N domínios. //
http://www.agilemodeling.com/essays/generalizingSpecialists.htm - Requer conhecimento sobre psicologia, e nesta linha, de elicitação e usabilidade. //
http://www.agilemodeling.com/essays/generalizingSpecialists.htm - Requer habilidade de comunicação, planejamento e (paradoxalmente) experiência prévia.
- É uma área para a qual seremos cronicamente mal-preparados!
* Amor, Ódio e outras Bobagens:
- Materialização de sonhos (e ilusões) em software.
- Todo mundo tem sua opinião sobre Eng.Software (e normalmente é uma opinião que contém um grande número de palavrões). A pergunta é: WHY?
- Esqueçam os conservadores e puristas: desenvolver software — em qualquer escala, e de qualquer forma — é Engenharia de Software. //
Você ainda tem alguma dúvida? http://unplugged.giggio.net/unplugged/post/Engenharia-de-software.aspx - Não se enganem: escrever código, rodar e testar é um processo de software.
- O que não explicam e que nos falta aqui é uma visão de escala: que tipo de processo o seu problema atual requer?
* Processo de Software:
- Obviamente, a preocupação com processo de software é menor quando é um projeto de 10-homens-hora!
- Processos difundidos e bem-documentados tendem a ser os que foram desenvolvidos para a Nasa e o DoD!
- Processo de Software é um nome chique para descrever quando sentamos juntos e planejamos construir ou consertar algo.
1. Descobrir o que tem para ser feito.
2. Descobrir como será feito.
3. Fazer. Fazer. Fazer. Fazer.
4. Descobrir se fizemos mesmo o que era para fazer. (enxague, repita)
* Engenharia de Software e a Universidade //Ou, porque o ensino de engenharia de software nas universidades não funciona!?
- Para aprender como construir software, precisamos de bons exemplos.
- Não nos dão muitos bons exemplos!
- Enfoque em escrever código, e não em ler código (e no entanto..)
- Tarefas de brinquedo, prazo curto, solitárias.
- Pouca ênfase em criar peças que se encaixam.
- Pouca ênfase em trabalhar com outras pessoas.
- Visibilidade nula para o trabalho dos outros, revisão de código inexistente.
- Quando de fato falamos “processo”, falamos de processos que não atendem aos alunos!
* Processo Padrão?
- Processos que não atendem a quem os estuda.
- Processos dos quais não aferimos resultados.
- Processos “desnecessariamente” burocráticos.
- Surpresa! Estes processos não são para projetos pequenos — em outras palavras, nós!
- Geralmente se passa a impressão de que existe um processo ideal, e que você deve sempre buscar atingí-lo (CMM? ISO?)
- Nenhum processo bem projetado é burocrático, inútil ou sem resultado. Mas o processo tem que se encaixar na sua realidade, na sua equipe.
- Muito mais importante do que um processo formal é um processo que sirva para as pessoas que irão executar o trabalho.
- Engenheiros de Software precisam aprender um toolkit essencial, e com este toolkit entender (e construir) um processo relevante.
* O Renascimento do Engenheiro de Software
Uma lista de 7 qualificações mínimas:
1. Sabe usar um sistema de controle de versões.
2. Sabe ler código em mais de uma linguagem.
3. Lê inglês de forma competente.
4. Já teve uma correção ou mudança aceita e integrada em um projeto de Software Livre.
5. Sabe o que é uma API, e o que quer dizer “affordance”.
6. Sabe quem são: Dijkstra, Hoare, Knuth, Ritchie, Thompson.
7. Constrói produtos dos quais é orgulhoso.
* Adios Banditi
- Engenharia de Software é um veículo pelo qual a experiência se difunde entre nós.
- Engenharia de Software é para ser divertido e interessante (e seu amigo na hora em que dá tudo errado).
- Engenharia de Software ensina ter amor pela equipe, amor pelo usuário, e sobretudo amor pelo produto.
- Engenharia de Software é um passo em direção à evolução da profissão.
- “Person who say it cannot be done should not interrupt person doing it.” –Chinese Proverb
Alguém Concorda? Discorda? Escreva a sua opinião.







