Engenharia de Software ‘Custo da Mudança’

Saudações intrépidos programadores, hoje quero começar com uma piada:

Logo que viu o código do ‘sistema legado’ que seria a sua primeira tarefa o programador Jr olha para o imediato direto e diz:

– Vocês não precisam de um programador e sim de um paleontólogo!

Bom vamos adiante :)!

Vocês já se perguntarem o que levou os primeiros engenheiros de software a organizar a metodologia tradicional de desenvolvimento da forma como ela é?

Planejamento -> Design -> Codificação -> Testes

A resposta não é muito obvia mas acho que cheguei a uma teoria no mínimo interessante!

A metodologia tradicional foi organizada dessa forma pois quando não se usava nenhuma metodologia o custo de uma mudanças é tão maior quanto mais próximo do fim do projeto, sendo assim, quando se bolou a primeira metodologia a idéia foi centralizar no inicio do processo toda a análise para que NÂO fossem necessário/permitido realizar mudanças em fases posteriores, o problema é que esta forma de pensar leva o software a:

1. Ter um valor de desenvolvimento mais alto;
2. Possuir funções que nunca serão utilizadas;
3. Torna o cliente um inimigo durante a codificação.
4. etc …

Com o advento das metodologias ágeis alguns desses pontos foram revistos e agora a coisa pode ser feita de uma maneira mais adequada.

[]’s Anselmo Battisti

10 Armadilhas da Análise de Requisitos

Confusão sobre requisitos: requisitos mal elicitados;

Envolvimento inadequado do cliente: o cliente não é envolvido ou não tem interesse pelo processo do desenvolvimento, isso geralmente acarreta em distorções da visão do que o cliente imagina e o que ele recebe;

Requisitos vagos ou ambíguo: por serem mal elicitados vários requisitos podem descrever a mesma tarefa ou serem ambíguos quanto ao que devem realmente significar;

Requisitos sem prioridades: cada requisito deve ser categorizado quanto ao seu nível de prioridade, isto norteara os desenvolvedores sobre quais requisitos devem ser implementados primeiro além da atenção especial para pontos críticos do sistema;

Requisitos inúteis: construção de requisitos que estão fora do domínio do problema, são funções que o cliente imagina serem necessárias, a política de criação de um requisito deve ser: tudo o que não é necessário é desnecessário;

Paralisação na análise: um projeto deve avançar mesmo que toda a análise não tenha sido concluída pois os erros somente irão aparecer quando o projeto estiver sendo efetivamente desenvolvido;

Alteração do escopo: adição de novos requisitos durante a faze do projeto ou codificação é sinal de problemas na análise, em metodologias ágeis a alteração do escopo deixou de ser um problema para ser uma necessidade;

Processo de mudanças: quais os procedimentos devem ser feitos quando mudanças devem acontecer;

Análise de impacto: quais serão os reais efeitos de uma mudança dentro do software, o que ela afetará;

Controle de Versões: sistemas de controle de versão adequados evitam refazer trabalho perdido ou sobrescrito por um colega, no desenvolvimento de aplicações para Web este conceito é ainda mais importante.

Livro Indicado pelo Battisti

Gerenciamento de Projetos com DotProject