Aquisição de Competência

Não é possível efetuar o levantamento de fluxo de informação sem haver conhecimento do negócio da organização, o mercado onde atua, que tipo de produto comercializa, o perfil de seus clientes, concorrentes e fornecedores. Este conhecimento prévio do ambiente em que se desenvolve o sistema-problema pode ser adquirido através da leitura de livros e periódicos especializados, pesquisas em ambiente virtual, e mesmo conversando com a gerência e usuários. No entanto, é preciso ter cuidado para que este contato inicial com o ambiente de negócios do sistema não se transforme em levantamento de dados, etapa seguinte e que exige planejamento.

Planejando a Entrevista

As técnicas de levantamento do fluxo de informações precisam estar inseridas dentro do contexto de negócios da organização. esta dimensão organizacional ou de negócios é fundamental para que os sistemas a serem desenvolvidos estejam alinhados com o segmento de mercado e com os objetivos estratégicos da empresa. Neste pormenor, a primeira etapa do processo de levantamento de fluxo de informações diz respeito a identificar em qual nível organizacional se localiza o sistema-problema a ser tratado pelo analista de sistemas. Além de fornecer a visão de negócio ao qual pertence o sistema-problema, pode-se desta forma identificar o peso ou influência dos respectivos usuários no respectivo Digrama de Contexto.

Fig.2 - Planejando a entrevista

Fig.3 - Relatório de entrevista

Diagrama de Fluxo de Dados - DFD

O diagrama de fluxo de dados é uma ferramenta de modelagem que nos permite imaginar um sistema como uma rede de processos funcionais, interligados por "dutos" e "tanques de armazenamento" de dados. O diagrama de fluxo de dados é uma das mais utilizadas ferramentas de modelagem de sistemas, principalmente para sistemas operativos nos quais as funções do sistema sejam de fundamental importância. Existem algumas diretrizes necessárias para utilizar DFD com sucesso. Algumas dessas diretrizes auxiliarão a não construir DFD incorretos (isto é, incompletos ou logicamente inconsistentes) e algumas outras destinam-se a ajudar a desenhar DFD agradáveis à vista e portanto com mais possibilidade de serem examinados com atenção pelo usuário. As diretrizes são as seguintes:

1. Escolher nomes significativos para os Processos, Fluxos, Depósitos e Terminadores.

Um bom método para nomes de processos é utilizar um verbo e um objeto. Isto é, empregar um verbo que represente ação (um verbo transitivo, que exige um objeto) e um objeto adequado formando uma sentença descritiva do processo. Os nomes escolhidos para os processos (e também para os fluxos e os terminadores) devem provir de um vocabulário conhecido pelo usuário. Isto acontecerá naturalmente se o DFD for desenhado como resultado de uma série de entrevistas com o usuário e se o analista de sistemas tiver um mínimo conhecimento do sistema-problema. Eis alguns exemplos de nomes de processos:

       CALCULAR TRAJETÓRIA DO MÍSSIL

&      PRODUZIR RELATÓRIO DE INVENTÁRIO

&      VALIDAR NÚMERO DE TELEFONE

&      DESIGNAR ALUNOS PARA SALAS

2. Numerar os processos.

Como um método prático de referências os processos de um DFD, a maioria dos analistas de sistemas costuma numerar cada bolha. Não importa a maneira de fazer isso - da esquerda para a direita, de baixo para cima, ou de outra maneira qualquer - desde que se seja consistente no modo como se atribui os números.  A única coisa que se deve ter em mente é que o esquema de numeração implicará, para os eventuais leitores do seu DFD, uma determinada seqüência de execução.

3. Refazer o DFD tantas vezes quantas forem necessárias até obter uma boa estética. 

O propósito de um DFD é modelar corretamente as funções que um sistema deve executar e as interações entre elas. Porém um outro objetivo do DFD é ser lido e compreendido, não somente pelo analista de sistemas que elaborou o modelo, mas também pelos usuários que são os conhecedores do assunto. Isso significa que o DFD deve ser prontamente compreendido, facilmente absorvido e agradável aos olhos. Não crie um DFD com demasiados processos, fluxos, depósitos e terminadores. A maioria dos casos isso quer dizer que não se deve incluir mais de meia dúzia de processos e depósitos, fluxos e terminadores a eles relacionados em um único diagrama.

4. Evitar DFD complexos demais.

Em um projeto de análise de sistemas do mundo real, o DFD terá de ser feito e refeito, até que esteja (1) tecnicamente correto, (2) aceitável pelo usuário e (3) tão bem desenhado que não se fique constrangido em mostrá-lo à junta de diretores da empresa.

5. Certificar-se de que o DFD seja internamente consistente além de manter a consistência com os outros DFD.

Existem algumas diretrizes que são utilizadas para fazer com que o próprio DFD seja consistente. As principais diretrizes para a consistência são estas:

       Evite os poços sem fundo, bolhas que têm entradas mas não têm saídas.

&      Evite bolhas com geração espontânea; bolhas que têm saídas mas não entradas são suspeitas e geralmente incorretas.

&      Cuidado com os fluxos e processos sem rótulos. Isso geralmente é sinal de desatenção, mas pode revelar erros mais sérios: às vezes o analista de sistemas omite o rótulo de um fluxo ou de um processo porque simplesmente não conseguiu encontrar um nome satisfatório.

&      Cuidado com depósitos de leitura-apenas ou escrita-apenas. Esta diretriz é análoga à diretriz sobre processos de entrada-apenas ou de saída-apenas; um depósito típico deve ter entradas e saídas. A única exceção a esta diretriz é o depósito externo que serve como interface entre o sistema e o terminador externo.

Jmsr/.