A análise de problema

 Nesse artigo, eu quero retomar a discussão sobre os caminhos que a equipe de desenvolvimento de software e usuários encontram para a construção de um novo sistema ou aplicação. Muitos sistemas são construídos para resolver um problema em particular, então, para isso usamos a técnica de análise de problema para estarmos seguros de que estamos, realmente, entendendo o problema.

Devemos também reconhecer que nem todo o desenvolvimento de aplicação visa a solução de um problema; algumas vezes, constrói-se sistemas para tirar proveito de situações e oportunidades que se fazem presentes, sem que necessariamente exista um problema a ser resolvido.

Concordamos, que problemas e oportunidades são apenas lados opostos de uma mesma moeda; seu problema é a minha oportunidade pregam os livros de auto-ajuda. Isso é, portanto, apenas um perspectiva diferente para se observar essa questão.

A elicitação de requisitos é uma arte complexa.

Desta feita, por estar sujeita aos humores do detentor das 'Necessidades' que muitas vezes não sabe exatamente o que quer, torna a fixação dessa informação, um processo complicado. É comum, depararmos com analistas de requisitos desesperados com a falta de definição por parte de quem deveria definir. Não é incomum, também, um stakeholder (usuário) que não tenha noção exata do que está acontecendo ao seu redor e que, simplesmente, caiu de pára-quedas num projeto e ainda não tem domínio dos processos ao seu redor. Outro problema envolvido nesse espectro é a quantidade de processos e artefatos que os processos obrigam, ao analista de requisitos, construir.

Pare, respire e analise...

Chega de espera!

O cliente merece respeito!

Quero utilizar-me dessas assertivas para defender as metodologias ágeis no desenvolvimento de software. Quando o cliente resolve fazer um investimento de qualquer monta, para aquisição de um produto de software ele o deseja para 'ontem' e não devemos deixá-lo esperando. Pois, a melhor forma de se desenvolver um produto de software é testando e testando,.. Até a  exaustão! Já verificamos, nessa década, que projetos orientados por processo unificado como o RUP (Rational Unified Process), tem tido custos elevados e, ainda, não dão garantias de que, cheguem  a bom termo. Normalmente, perde-se muito tempo e dinheiro com a construção de documentação que não servirá para nada, pois, esta estará desatualizada em breve (digo: documentação desatualizada, melhor não tê-la!). Normalmente, as equipes que trabalham orientadas por tais processos não mantém uma rotina eficiente de atualização de artefatos. Fato esse, que faz com que esses artefatos estejam desatualizados em muito pouco tempo, dependendo do nível de evoluções e manutenções do projeto.