Ruan Carvalho

Qual é o Problema?

Esta é a pergunta-chave que terá de ser respondida durante a definição do problema; não faz muito sentido tentar resolver um problema que você não sabe qual é. Embora a necessidade da definição do problema possa parecer óbvia, este talvez seja o passo mais freqüentemente omitido em todo o processo de análise e projeto de sistemas.

Qual é a fonte da definição do problema?

Obviamente alguém terá de reconhecer que ele existe. Muitas vezes o usuário vai se defrontar com dificuldades, solicitando ajuda. Talvez a administração identifique uma área de desempenho fraco dentro da função do usuário; freqüentemente o analista de sistemas apontará o problema. As discussões iniciais a ele relativas muitas vezes são bastante informais. Contudo, eventualmente essas discussões atingem o ponto em que o usuário, a administração, e o analista de sistemas concordam: "Sim, realmente há um problema".

O sistema começa com um usuário. O usuário tem necessidades de apoio técnico, mas não sabe o suficiente a respeito do computador para fazer ele o próprio trabalho. Em outro ponto da organização ficam os programadores. Eles sabem muita coisa a respeito do computador, mas muitas vezes não compreendem exatamente quais são as necessidades do usuário. O usuário conhece o problema, mas não o pode resolver. Os programadores talvez fossem capazes de solucioná-lo, caso o compreendessem. Para complicar, há um intervalo de comunicação: às vezes tem-se a impressão de que os programadores e suários falam línguas diferentes. (Fig. 1.1)

Imagem:Analise 1.1.png

Entra em cena o analista de sistemas, profissional cuja responsabilidade básica é traduzir as necessidades do usuário em especificações técnicas necessárias aos programadores (Fig. 1.2). O analista de sistemas começa desenvolvendo uma descrição lógica das necessidades do usuário.

Os programadores e usuários tendem a se concentrar em um único programa. O programador vê um trabalho específico a ser realizado, enquanto o usuário vê um problema específico a ser resolvido. Obtendo uma visão um pouco mais ampla desse programa, fazem-se algumas perguntas: Por que esse programa foi feito? Os programas não surgem por acaso.

Obviamente alguém o desejava, senão ele não teria sido feito; mas, por que esse programa? E por que o programa foi projetado do jeito que foi? Por exemplo, alguns programas são interativos, enquanto ouros exigem qe usuário prepare um conjunto completo de comandos e dados e os apresente ao computador. Por quê? Finalmente, e quanto aos elementos de apoio - hardware, software, procedimentos e operadores, por exemplo - que cercam o programa? Como todos esses elementos se reúnem para assisti-lo na elaboração ou execução do seu programa?

Embora a abordagem puramente criativa de "projetar à medida em que se progride" possa funcionar para projetos pequenos ou relativamente simples, ela pode ser um desastre para um sistema grande e complexo. A análise de sistemas é uma área relativamente nova; sua metodologia ainda está evoluindo e muitas diferentes versões da abordagem "correta" existem. No entanto, podemos definir um processo amplamente aceito conhecido como análise e projeto estruturado de sistemas.