Análise de problemas em engenharia de software

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.

Podemos definir a análise de problemas como:

O processo de entendimento de problemas no mundo real, suas relações com as necessidades do usuário e a proposta de soluções que vão de encontro a essas necessidades.

Assim sendo, o domínio do problema deverá ser analisado, entendido e uma variedade de soluções para o problema deve ser explorada. Usualmente, uma variedade de soluções é possível e, dentre todas essas, pelo menos, uma solução será ótima para o problema a ser resolvido. Deve-se atentar para o fato de que, algumas vezes, a solução mais simples para o problema é uma simples revisão do processo de negócio ao invés da construção de um novo sistema.

O alvo principal da análise do problema é obter um melhor entendimento sobre o problema antes de iniciar-se, efetivamente, o desenvolvimento da solução. Desta forma, cinco passos devem ser cumpridos para a efetiva aplicação da análise do problema.

Cinco passos para a análise do problema

Passo 1: Obtenção sobre a definição do problema

O primeiro passo no caminho mais simples para a obtenção das definições sobre um problema a ser solucionado é, simplesmente, registrá-lo. O simples ato de registrar um problema já nos permite vislumbrar soluções.

Como parte desse processo, esse registro freqüentemente traz benefícios para o entendimento e alguns benefícios para a fixação da solução proposta. Devemos ser cuidadosos para fazer com esses benefícios sejam claramente descritos em termos dominados também pelos stakeholders. Tendo o usuário descrito os benefícios advindos do contexto do problema no mundo real e ao verificar os benefícios, também, do ponto de vista dos usuários, também se obterá um melhor entendimento dos pontos de vista do stakeholder sobre os seus problemas.

O registro do problema

A tabela 1 ajudará a registrar o seu problema em um formato padrão. A simples utilização de um registro padronizado fará com que você esteja seguro de que todos os stakeholder estejam focados nos mesmos problemas.

Tabela 1 – formato do registro do problema

Elemento	Descrição
Identificação do problema:	Descrição do problema
Afetados pelo problema:	Identificação dos stakeholders afetados pelos problemas
Impactos do problema:	Descreva o impacto do problema sobre os stakeholders e suas atividades de negócio
Benefícios da solução:	Relação de alguns benefícios proporcionados pela solução

Passo 2: Entendendo as causas raízes – por dentro do problema

Sua equipe pode utilizar-se de uma variedade de técnicas para obtenção de entendimento sobre um problema real e suas causas reais. Uma técnica utilizada para isso e a análise “causas raízes”, que é uma sistemática para desvendar a raiz, ou identificar o sintoma provocado por um problema.

O próximo passo para identificar as causas raízes de um problema é determinar quais os fatores contribuem para a presença do problema. O Gerenciamento Total de Qualidade (TQM – Total Quality Management) nos ensina a usar o diagrama espinha de peixe (veja na Figura 1) para identificar o problema em seu âmago. Em nossa análise específica, a companhia identifica vários recursos que contribuem para a existência do problema. Toda a fonte do problema deverá ser listada com uma das “espinhas” do diagrama.

Figura 1 – diagrama espinha de peixe das causas raízes

Se o problema é mais sério, a simples indagação sobre o que é afetado por este não cria uma sensação de conforto, isto pode ser necessário para uma investigação mais detalhada de toda a contribuição do problema e da dimensão do ser impacto individual. Esta investigação pode variar de um simples brainstorm cujos participantes tenham conhecimento sobre os pontos afetados do projeto ou, potencialmente, para uma investigação científica mais rigorosa. Nesse caso, o alvo é a quantidade com que cada causa raiz contribui para o problema.

Passo 3: Identificando os stakeholders e os usuários

Efetivamente a solução de um problema complexo, tipicamente, envolve satisfazer as necessidades de um grupo diverso de stakeholders. Stakeholders têm tipicamente uma perspectiva variada do problema e uma diversidade de necessidades que devem ser satisfeitas pela solução. Define-se stakeholder como:

Alguém que pode ser materialmente afetado pela implementação de um novo sistema ou aplicação.

Muitos stakeholders são usuários do sistema e suas necessidades são facilmente fixadas, pois estão diretamente envolvidos na definição e uso do sistema. De outra forma, alguns stakeholders são apenas usuários indiretos do sistema ou são afetados, tão somente, pelos resultados do negócio que o sistema influencia. Esse stakeholders pode ser membros de Conselhos, Agências reguladoras, enfim, agentes internos ou externos ao ambiente de desenvolvimento do sistema e que, não são afetados diretamente por esse, mas sim pelos resultados gerados sob sua influência. As necessidades dos stakeholders não-usuários também devem ser identificadas e apontadas. Um entendimento de quem são os stakeholders e quais são suas necessidades, esse é um importante fator para o desenvolvimento de uma solução efetiva. A relação dos stakeholders deve seguir o formato demonstrado na tabela 2.

Tabela 2 – Usuários e stakeholders do novo sistema

Usuários	Outros Stakeholders
Vendedores	Diretor de TI e equipe de desenvolvimento
Supervisor de pedidos	Chefe do departamento financeiro
Controle de produção	Gerente de produção
Faturista

Outros stakeholders, como os vendedores e o supervisor são diretamente afetados pelo sistema, mas acessam o sistema por intermédio de diferentes interfaces de usuário e relatórios. De outro modo, o Chefe do departamento financeiro da empresa são stakeholders que podem sofrer influência no aumento da produtividade, qualidade e rendimento da empresa. Assim, se espera que o diretor de TI e os membros da equipe de desenvolvimento sejam também classificados como stakeholders, pois, esses serão os responsáveis diretos pelo desenvolvimento e manutenção do sistema.

Passo 4: Define a fronteira para a solução

Uma atividade super importante com relação ao desenvolvimento de softwares reside na delimitação do que está no interior da fronteira do sistema e do que reside fora desta. Ou seja, a delimitação clara das responsabilidades do sistema. A fronteira do sistema define a borda entre a solução e o mundo real em torno da solução (Figura 2). Em outras palavras, a fronteira do sistema descreve um cenário em que a solução do sistema está contida.

Passo 5: Identificar os constrangimentos impostos pela solução

Antes de despender milhares de reais em busca de uma solução revolucionária, o verdadeiro estado da arte em termos de comércio, por exemplo. Deveremos parar e considerar os constrangimentos que serão impostos pela solução. Definimos constrangimentos como:

A restrição sobre os graus de liberdade que será imposto sobre uma aplicação.

Todo constrangimento ocasiona uma severa e potencial restrição para o desenvolvimento de uma solução. Dessa forma, todo constrangimento deve ser cuidadosamente considerado como parte do planejamento de processo e, muitas vezes, esse constrangimento poderá fazer com que sejam reconsideradas abordagens tecnológicas que foram inicialmente consideradas.

Várias fontes de constrangimentos deve ser consideradas. Essas incluem agendas, retornos e investimentos, custo de produção e equipamentos, ambiente, sistemas operacionais, bancos de dados, servidores e sistemas clientes, insumos técnicos, política organizacional, licenças de software, procedimentos e recursos da empresa, ferramentas e linguagens, pessoal e outros recursos. Esses constrangimentos devem ser mapeados antes de darmos de tomarmos uma decisão. A lista apresentada na tabela 3 apresenta os potenciais recursos de constrangimento de um sistema.

Tabela 3 – Constrangimentos potenciais do sistema

Usuários	Outros Stakeholders
Econômicos	Quais constrangimentos econômicos são aplicáveis?
	São considerados os custos benefícios de um produto?
Quais os custos com licenças?
Políticos	As políticas internas e externas afetam potencialmente a solução?
Problemas interdepartamentais ou insumos afetam a solução?
Técnicos	Existem restrições tecnológicas?
	Estamos limitados pela plataforma existente ou limitações tecnológicas
Estamos proibidos de utilizar uma nova tecnologia?
Temos de usar um pacote tecnológico específico?
Sistema	Essa solução deverá ser construída em um sistema existente?
	Deve ser mantida compatibilidade entre sistemas existente?
Qual sistema operacional e ambiente deverá ser suportado?
Ambiente	Constrangimentos ocasionados por limitações de ambiente?
	Limitações legais?
Requisitos de segurança?
Restrições impostas por padrões de desenvolvimento?
Agendas e recursos	Definições de agenda?
	Restrições impostas por recursos existentes?
Recursos de fábrica?
Podem-se expandir recursos? Temporários? Permanentes?

Tentou-se com esse artigo dar uma idéia geral sobre a análise de risco e problemas com relação ao desenvolvimento de software. Apresentamos os tópicos principais que devem ser monitorados quando da elicitação de requisitos para a construção de um produto de software.