Desenvolvimento do Sistema de Informação Contábil: Enterprise, Database e Interface Modules

Desenvolvimento de Sistema de Informação Contábil: Enterprise, Database e Interface Modules!

Vários pacotes de software de contabilidade estão disponíveis, oferecendo uma variedade de recursos. Eles custam muito menos do que custaria o software de contabilidade personalizado. No entanto, esses pacotes de software oferecem apenas a estrutura para sistemas de informações contábeis. No máximo, reduzem o esforço de programação para sistemas de informação contábil.

Imagem Cortesia: bestsmallbizhelp.com/wp-content/uploads/2011/07/1018910261.jpg

O desenvolvimento de sistemas de informação contábil é muito mais do que o software para lançamento de registros contábeis e formação de relatórios. Envolve também o estabelecimento de procedimentos para captura de dados e distribuição, bem como a análise de informações contábeis.

O desenvolvimento de um sistema de informação contábil é explicado com referência especial aos requisitos de uma empresa de médio a grande porte. No entanto, essas etapas seriam comuns à maioria dos outros sistemas de informações em uma empresa.

1. Módulo Empresarial:

O módulo empresarial de desenvolvimento de sistemas de informação envolve a identificação de entidades básicas e suas inter-relações, a identificação de atividades básicas e o reagrupamento dessas atividades em subsistemas. Então, as prioridades são decididas com base na análise de custo-benefício para a empresa.

Entidades Identificadoras:

Um grande número de entidades existe em uma empresa e a lista é tão variada quanto as atividades de negócios. No entanto, nesse estágio, a principal preocupação é identificar as entidades amplas, cada uma delas contendo um grupo de entidades elementares. Kerner ⁵ aponta seis entidades básicas em uma empresa.

Eles são clientes, produtos, fornecedores, pessoal, instalações e dinheiro. Em um sistema de informação contábil, existem três entidades básicas, a saber, transações, conta e período de processamento. As inter-relações entre essas entidades podem ser expressas usando os diagramas ER, como mostrado na Fig. 8.2.

As transações devem ser de diferentes tipos, tais como recibos, pagamentos, vendas, compra, aquisição de ativos ou pagamento de obrigações, etc., e cada uma delas pode ser chamada de entidade de nível inferior. Da mesma forma, as contas podem ser de diferentes tipos, como ativos, passivos, receitas e despesas.

Cada uma dessas cabeças pode ter entidades de nível inferior, como ativos fixos e ativos atuais. Essas entidades podem ser ainda mais divididas em entidades de nível ainda inferior, tais como terra e edifício, fábrica e maquinaria, etc. No entanto, neste estágio, as entidades amplas precisam ser identificadas. Os detalhes são trabalhados no momento de projetar os bancos de dados.

As entidades são identificadas à luz e com o objetivo de definir o escopo e o foco do sistema de informação. Por exemplo, se o sistema de informação está sendo visto como um sistema de informação estratégica, as entidades amplas devem ser identificadas à luz dos impulsos estratégicos que a empresa planeja oferecer às suas atividades com a ajuda do sistema de informação.

Esses impulsos podem ser minimização de custos, atendimento ao cliente, diferenciação de produtos e alianças estratégicas. As entidades básicas em tal caso seriam clientes, canais, empresas concorrentes, produtos etc.

Análise de atividade:

Outro aspecto importante do módulo corporativo é a identificação das atividades associadas às entidades. Essas atividades são amplamente identificadas na forma de relacionamentos nos diagramas de ER. No entanto, os detalhes são obtidos com a ajuda da análise de atividade. A estrutura organizacional existente é uma fonte importante de informações sobre as atividades amplas realizadas pela empresa.

Mas, para desenvolver sistemas de informação independentes da estrutura organizacional atual, é essencial basear a análise da atividade nas entidades básicas já identificadas acima. O próximo nível de análise de atividades envolve a identificação das atividades do ciclo de vida. No caso de 'transações' serem uma das entidades básicas em um sistema de informações contábeis, existem quatro atividades de ciclo de vida abrangentes, a saber:

1. Ciclo de vida de compras

2. ciclo de vida de produção

3. ciclo de vida da receita

4. Ciclo de vida dos investimentos

Da mesma forma, o período de processamento tem duas atividades básicas do ciclo de vida, a saber:

uma. Planejamento e controle do ciclo de vida

b. Ciclo de vida de relatórios internos e externos

Essas atividades do ciclo de vida são atividades em andamento e são realizadas continuamente. Cada uma dessas atividades pode ser sequencialmente relacionada a algumas outras atividades. O terceiro nível de análise de atividades envolve a divisão das atividades do ciclo de vida em funções.

Por exemplo, cada tipo de transação deve ser iniciado e reconhecido; então os dados referentes à transação devem ser capturados, codificados para futura classificação, classificados, resumidos e reportados. Essas funções devem ser executadas de forma diferente para diferentes tipos de transações. O processo de definição das funções se concentra apenas nas atividades que criam, atualizam ou usam informações no banco de dados da empresa.

Nesse nível de análise de atividades, as atividades são autônomas, têm eventos ou nós iniciais e finais claramente definidos e uma pessoa identificável ou um grupo de pessoas responsáveis ​​pela execução da função.

Essas funções podem ser divididas em subfunções até que as funções sejam específicas o suficiente para definir o módulo para programas de computador. A divisão das atividades do ciclo de vida em funções e subfunções auxilia na identificação de funções que se repetem em mais de uma atividade do ciclo de vida.

Por exemplo, a função de classificação dos dados capturados pode ser realizada em ciclos de vida de compras e marketing. Essa análise de atividades ajuda a identificar oportunidades para melhorar o design existente por:

1. eliminando as funções redundantes

2. combinando as funções duplicadas

3. simplificar e melhorar os métodos de processamento

A redundância pode ser identificada por uma análise cuidadosa das atividades. As atividades que provavelmente oferecerão oportunidades para melhorar o processamento incluem atividades:

uma. Que são executados em outros lugares também

b. Isso pode ser combinado com outras atividades

c. Isso pode ser tratado por outra pessoa também

d. Isso pode ser feito em algum outro estágio do ciclo de vida que não agregue nenhum valor ao produto ou serviço do sistema de informação.

Uma palavra de cautela aqui é que nem todas as redundâncias são ruins. De fato, alguma redundância ou duplicação pode ser intencionalmente permitida no sistema. Isso pode ser feito para melhorar o desempenho e a confiabilidade do sistema.

Por exemplo, parte da duplicação pode ser necessária para garantir a simplicidade dos procedimentos e melhorar a velocidade do processamento. A eliminação da redundância pode resultar em “colocar todos os ovos em uma cesta” e, portanto, afetar a confiabilidade. O risco de implicações inesperadas e os baixos retornos do novo método ou procedimento proposto são outros fatores que merecem atenção antes que as mudanças sejam propostas no sistema de informação.

Agrupando Atividades em Sub-Sistemas:

Depois que as atividades são definidas usando a abordagem top-down adotada acima, elas são reagrupadas para formar sub-sistemas. Uma decisão importante a ser tomada nesta fase refere-se à base do agrupamento. Pode não existir um único critério objetivo para decidir a qual sub-sistema uma atividade pertence.

A estrutura organizacional atual pode fornecer uma das bases para o agrupamento de atividades. Mas, a estrutura organizacional atual pode sofrer mudanças e a utilidade do sistema de informação pode ser perdida.

Para agrupar as atividades no sub-sistema, recebemos ajuda da teoria da organização. Uma das características essenciais de qualquer boa estrutura organizacional é que ela visa facilitar a coordenação de atividades.

Um sistema eficaz de comunicação é requisito essencial para uma melhor coordenação. É essencial, portanto, agrupar as atividades de tal maneira que a comunicação seja facilitada dentro do grupo e a necessidade de comunicação entre os grupos seja minimizada.

Para fins de representação e documentação do agrupamento de atividades em sub-sistemas, são utilizados gráficos de estrutura ou diagramas de blocos hierárquicos. A Figura 8.3 fornece um gráfico de estrutura mostrando os componentes do ciclo de receita.

Gráficos de estruturas similares podem ser preparados para outros grupos de atividades e, finalmente, esses sub-sistemas são integrados entre si, fornecendo os blocos de construção para um sistema de informações contábeis.

Os sub-sistemas assim identificados pelo agrupamento de atividades são sérios concorrentes por serem entidades na estrutura da organização. A vantagem do método de agrupamento para agrupamento de atividades é que o agrupamento é baseado em funções e recursos, e não em regiões geográficas.

Tal agrupamento com base em funções garante a homogeneidade entre os membros do grupo de pessoas associadas a cada um dos sub-sistemas. O impacto da organização do sistema de informação na estrutura organizacional não é incomum.

Muitas vezes, a introdução de sistemas de informação tem sido acompanhada por mudanças nas estruturas da organização, devido ao fato de que os novos sistemas de informação mudam a forma como as pessoas trabalham em uma organização.

É, portanto, ainda mais importante que os projetistas de sistemas de informação trabalhem em associação ativa com o pessoal de desenvolvimento da organização, enquanto o agrupamento de atividades em clusters e sub-sistemas está sendo feito. Isso garante não apenas que a nova estrutura seja mais pragmática, mas também mais aceitável para as pessoas. Nesses casos, a transição do sistema antigo para o novo é menos dolorosa e menos dispendiosa.

Definindo prioridades:

Uma vez que os sub-sistemas tenham sido identificados e integrados como um todo, as prioridades precisam ser determinadas entre os vários sub-sistemas e recursos de cada sistema. O sistema de informação exigiria comprometimento de recursos financeiros.

Além disso, pode haver custos implícitos do novo sistema em termos de mudanças necessárias no processo de operações. É, portanto, essencial ponderar os prós e contras de cada subsistema e sub-subsistema antes que eles sejam projetados e implementados.

Cada sub-sistema é avaliado com base em critérios de avaliação bem definidos definidos em termos dos fatores críticos de sucesso (CSF). Esses fatores já foram identificados na Seção 8.2.

O outro método é, brainstorming, em que as pessoas relevantes na organização se reúnem para identificar os fatores que merecem consideração na determinação das prioridades. O fluxo livre de idéias é incentivado no primeiro estágio.

O princípio subjacente, aqui, é que nenhuma idéia é tola ou irrelevante neste estágio. Durante a segunda etapa, o processo de eliminação começa e depois das discussões, as sugestões são finalizadas.

Quando a lista de fatores é finalizada, pesos relativos são atribuídos e uma função de critério é definida para avaliar cada componente do sistema de informação contábil proposto.

2. Módulo de Banco de Dados:

Sistema de informação contábil processa grande volume de dados. A gestão dos dados é, portanto, uma das principais considerações no processo de seu desenvolvimento. Existem duas abordagens básicas para o design de dados, a saber:

uma. A abordagem tradicional orientada para aplicativos e

b. A abordagem do banco de dados.

Abordagem tradicional:

A abordagem tradicional do design de dados é orientada para aplicativos, no sentido de que, para cada aplicativo, um conjunto separado de arquivos de dados é gerado de acordo com seus requisitos. Em outras palavras, os arquivos de dados são dedicados a um determinado aplicativo e são, de certa forma, 'propriedade' do aplicativo.

Por exemplo, um aplicativo de contas a receber deve ter o arquivo de dados mestre do cliente, um arquivo de transação de vendas e um recibo do arquivo de transações do cliente. Esses arquivos de dados são usados ​​apenas para o aplicativo de contas a receber.

Essa abordagem é adequada para sistemas de informações contábeis menores devido à sua simplicidade. No entanto, à medida que o sistema de informação cresce em termos de volume de dados e complexidade de análise, também surgem alguns problemas.

O problema fundamental da abordagem tradicional é que os programas aplicativos dependem dos arquivos de dados que eles usam e manipulam. Como conseqüência, qualquer alteração no arquivo de dados (em termos de adição ou exclusão de item de dados) exige alterações em todos os programas usando o arquivo de dados.

Essa dependência de dados desestimula as alterações nos arquivos de dados, levando à inflexibilidade. Na ausência de qualquer ferramenta para executar atividades de gerenciamento de dados de tipo de rotina nos dados, essas instalações devem ser incluídas nos programas usando o arquivo de dados. Isso complica o programa. Outro problema está relacionado ao atendimento da consulta ad hoc.

Para um tipo inesperado de consulta, programas especiais precisam ser gravados. Esses programas especiais levam tempo para se desenvolver e têm apenas um uso de tempo e, portanto, são caros. Há muita duplicação na gravação de itens de dados.

Por exemplo, os itens de dados como nome do cliente, número da fatura, preço etc. podem ser incluídos nos arquivos de transação para o aplicativo de processamento de pedidos de vendas, bem como no aplicativo de contas a receber. Isso causa redundância nos dados.

A redundância de dados resulta no uso ineficiente de mídia de armazenamento. Também afeta a qualidade dos dados, pois a atualização de um dado item de dados pode não ocorrer em todos os arquivos em que esse item de dados está armazenado.

Abordagem de banco de dados:

A abordagem moderna ao design de dados é a abordagem de banco de dados. Essa abordagem baseia-se nas suposições de que vários aplicativos exigem conjuntos de dados que têm muito em comum. É, portanto, melhor ter um repositório comum de dados que atenda aos requisitos de dados de cada aplicativo no sistema de informação.

O repositório comum é chamado de banco de dados e é gerenciado por um sistema de gerenciamento chamado Database Management System (DBMS). O SGBD é um software especialmente projetado para gerenciar os dados em bancos de dados de acordo com as solicitações dos programas aplicativos, bem como daqueles provenientes diretamente dos usuários. O projeto conceitual do ambiente de banco de dados é mostrado com a ajuda da Figura 8.5.

A abordagem de banco de dados cuida dos problemas da abordagem de aplicativos. Ele garante a independência de dados, já que o SGBD cuida do fluxo de dados do banco de dados para os programas aplicativos. O aplicativo do usuário não precisa se preocupar com a localização dos dados no banco de dados. Um dicionário de dados é mantido e os dados podem ser chamados usando as palavras especificadas no dicionário de dados.

A abordagem de banco de dados também reduz o tamanho e a complexidade dos programas de aplicativos, pois o tipo de rotina de operações de processamento de dados, como a classificação, é feita pelo DBMS. O DBMS também é usado para atender às necessidades da consulta ad hoc. O DBMS usa SQL (Structured Query Language) como a linguagem de comunicação entre o usuário e o banco de dados.

A linguagem é muito simples e muito próxima do inglês. Isso garante que o usuário possa obter informações do banco de dados como e quando necessário. A quantidade de treinamento exigida pelos gerentes para fazer consultas ad hoc é mínima e poucas horas de treinamento podem fornecer as habilidades elementares para usar o idioma. Talvez, a vantagem mais importante da abordagem de banco de dados seja a redução da redundância em bancos de dados.

Existem muitos modelos que são comumente usados ​​no design de bancos de dados. No entanto, a abordagem moderna é seguir o modelo ER de design de banco de dados. Essa abordagem é de cima para baixo e os gráficos ER desenhados anteriormente no Enterprise Module se tornam o ponto de partida.

Para cada entidade e relacionamento, os atributos são identificados e documentados nos diagramas de ER estendidos (diagramas de EER). Em um sistema de informação contábil, o EER pode ser desenhado para cada entidade (transação e contas) e o relacionamento (efeito) para as contas de transação é mostrado no diagrama ER. Por exemplo, para uma transação de vendas, os atributos podem ser especificados e documentados como mostrado na Fig. 8.6.

Esses atributos se tornam os itens de dados (campos) em um registro no arquivo de dados para cada entidade (nesse caso, arquivo de transação de vendas). Da mesma forma, para outras entidades e relacionamentos, são desenhados diagramas de Extended ER (EER).

Depois que esses atributos forem identificados, é provável que alguns dos atributos sejam comuns em diferentes gráficos EER. Para evitar a duplicação de tais atributos comuns, a normalização dos dados é realizada.

3. Módulo de Interface:

Um módulo de interface define as fontes de itens de dados e os formatos de telas de entrada / saída e diálogo que devem ser usados ​​no sistema. Ele também define os formatos de relatório e as telas de navegação de uma parte dos sistemas de informação para a outra.

Em outras palavras, o módulo se preocupa em definir a interface entre o usuário e a máquina. A importância do módulo de interface aumentou devido ao aumento da comunicação entre o usuário e os sistemas de informação.

Tanto a entrada de dados quanto a consulta de dados se tornaram interativas. Em muitos casos, os formulários de entrada são eliminados do processo e a entrada de dados ocorre diretamente. Os requisitos variáveis ​​da consulta de dados tornam vários formulários de relatório muito rígidos. Telas de relatórios interativos fornecem maior flexibilidade na consulta de dados e permitem formatos de relatórios definidos pelo usuário para visualização e impressão.

Telas de entrada:

As telas de entrada são definidas à luz do processo natural da atividade empresarial. Portanto, eles dependem principalmente dos formulários usados ​​para registrar manualmente os dados quando eles são recebidos pela empresa pela primeira vez. Esses formulários, em um sistema de informações contábeis, podem incluir fatura, pedido de compra, pedido de venda, comprovante de despesa, etc.

Assim, no módulo de interface, os formulários também são revisados; telas redesenhadas e de entrada são definidas à luz dos formulários utilizados pela empresa. Em um sistema de informações contábeis, é preciso ter mais cuidado com relação ao design da tela.

Uma pequena melhoria na tela de entrada que salva a entrada de dados pode resultar em economias substanciais, porque o número de vezes que a tela de entrada de dados é usada é muito grande. Os seguintes fatores podem ser mantidos em mente ao projetar a tela de entrada:

(a) Correspondendo com formulários:

O formato da tela de entrada deve corresponder aos formulários de entrada. Às vezes, vale a pena adotar o mesmo formato usado pelo formulário de entrada. Na medida do possível, até mesmo a cor do plano de fundo da tela pode ser combinada com a cor do formulário de entrada.

(b) Interativo:

A tela de entrada deve ser interativa. Deve indicar erros na entrada de dados no momento da entrada e correções de permissão. Cada item de dados deve ter alguma condição de validação de dados e qualquer violação de tal condição de validação de dados deve ser destacada automaticamente no momento da entrada de dados.

Por exemplo, uma tela de entrada de dados para entrada de fatura deve indicar erro na entrada de data se a data for inválida. A data pode ser inválida porque está fora do período contábil ou o mês informado é maior que doze.

(c) Consistência:

As telas de entrada devem ser consistentes na definição de termos e locais para determinados tipos comuns de itens de dados. Ajuda na redução do tempo de treinamento, pois melhora a familiaridade; por exemplo, a data da transação pode sempre ser colocada no canto direito de cada documento da transação.

d) Simplicidade:

Uma das características básicas de uma boa tela de entrada é a simplicidade. Muitas seções destacadas, piscadas de valores ou atributos, ou colocar muitas caixas e sublinhados apenas aumentam a complexidade e a confusão. Às vezes, bipes são usados ​​para apontar erros de entrada de dados. Deve haver um uso criterioso de tais bips e, geralmente, estes devem ser evitados.

e) Flexibilidade:

A tela de entrada deve ser passível de modificações. Ele deve permitir que os usuários façam modificações em termos de adição ou exclusão e realocação do item de dados. O procedimento para modificação deve ser simples. Atualmente, os Screen Generators disponíveis em vários fabricantes de software oferecem recursos como arrastar e corrigir / soltar qualquer item de dados da tela usando um dispositivo apontador comum como o mouse.

(f) Custom Made:

As telas devem ser personalizadas para cada categoria de usuário. Isso reduziria os procedimentos indevidamente longos de partida e entrada.

Telas de relatório:

Os relatórios podem ser preparados para análise posterior por algum outro programa de computador ou pelo próprio usuário. Os dados direcionados para processamento por programas de computador, como planilhas, pacotes estatísticos, processadores de texto, são mantidos em arquivos de dados.

É melhor colocá-los no formato de dados padrão para que possam ser acessados ​​facilmente. Os relatórios destinados aos usuários são normalmente mantidos na forma de texto, tabelas e gráficos. Esforços devem ser feitos para garantir que os relatórios sejam elaborados e comunicados de forma oportuna, precisa, clara e a baixo custo.

Telas de diálogo:

As telas de diálogo são aquelas usadas para identificar e executar as tarefas no sistema de informação. Eles definem o que pode ser feito com a ajuda do sistema de informação, como navegar de uma tarefa / procedimento para outra e como executar várias tarefas que o sistema de informação permite.

Essas telas devem ser simples e não ambíguas. A simplicidade pode ser introduzida fornecendo Interface Gráfica do Usuário (GUI) e tendo número limitado de itens de menu em uma tela. O procedimento para navegação de um menu para o outro deve ser simples, na seqüência correta e fácil de seguir. Ele também deve apontar erro no exercício de opções e ser pronto para corrigir o procedimento.

Ferramentas CASE para design de tela:

Uma variedade de ferramentas CASE está disponível para projetar formulários, telas e relatórios. Essas ferramentas têm a vantagem de oferecer um ambiente de projeto flexível e simples de entender, mesmo para um novo usuário.

Como essas ferramentas possuem recursos de prototipagem de tela, é possível ter um maior envolvimento dos usuários no processo de criação de telas. É claro que essas ferramentas permitem mudanças rápidas e melhoram a produtividade dos programadores, gerando códigos para a implementação final. Isso resulta em tempo de desenvolvimento reduzido.

Quando os formulários, as telas de entrada / saída e as telas de diálogo estiverem prontos, eles deverão ser testados e modificados de acordo. Os formulários e telas projetados usando as ferramentas CASE podem ser facilmente modificados. Portanto, esforços devem ser feitos para melhorar a aceitabilidade do sistema por meio de testes adequados e modificação de formulários e telas.

4. Módulo de Aplicações:

Este módulo estende os sub-sistemas já identificados no módulo corporativo. Para cada sub-sistema identificado no gráfico de estrutura, procedimentos detalhados de processamento são definidos neste módulo.

Em outras palavras, o módulo de aplicação está principalmente preocupado com os processos envolvidos na conversão dos dados de entrada em valores que devem formar parte dos relatórios, conforme definido no módulo de interface. Pode-se notar que apenas esses processos devem ser definidos

(a) Altere os valores nos bancos de dados ou

(b) Não são partes do banco de dados, mas são necessárias nos relatórios definidos no módulo de interface.

Os valores que já existem no banco de dados podem ser acessados ​​usando a linguagem de consulta DBMS conforme a exigência de usuários sem desenvolvimento de programas para este fim. Assim, a tarefa do módulo aplicativo é reduzida pelo trabalho já realizado no design do banco de dados e no design da tela.

Diagrama de fluxo de dados:

O papel do gerente neste módulo é basicamente identificar o procedimento básico de processamento. Os algoritmos detalhados são geralmente definidos e documentados pelo sistema de informação profissional, com ajuda ativa do gerente.

A ferramenta usada para expressar os processos a serem executados para converter os dados de entrada em saída é o diagrama de fluxo de dados (DFD). Descreve o fluxo de dados. Ele define o que deve ser feito e ignora como deve ser feito ou como está sendo feito anteriormente. Essa abordagem permite alterações no sistema e os pontos fracos do sistema existente podem ser removidos seguindo essa abordagem.

Símbolos DFD:

Existem quatro símbolos básicos usados ​​nos DFDs. Eles são:

(i) Terminador:

Terminador é uma fonte externa de fluxo de dados ou coletor de dados externo. É uma entidade ou objeto externo, como cliente, fornecedor, acionistas, etc. Como os terminadores são entidades externas, a comunicação entre os terminadores é excluída do sistema. O terminador é simbolizado por um retângulo (geralmente sombreado) e o rótulo é colocado no retângulo.

ii) fluxo de dados:

O fluxo de dados transporta uma série de itens de dados relacionados ao evento que é iniciado pelo terminador. É simbolizado por uma seta no DFD e a direção do fluxo é indicada pela direção da seta. As setas são, geralmente, rotuladas, a menos que sejam direcionadas para ou a partir de arquivos de dados. Como apontado anteriormente, os fluxos de dados entre dois terminadores não são incluídos no DFD e, portanto, os dados não podem fluir diretamente entre dois terminadores.

(iii) Processo:

O processo transforma os dados recebidos para redirecionamento para o armazenamento de dados ou terminador. É simbolizado por um retângulo com cantos arredondados ou um círculo. É rotulado com um verbo, é claro.

(iv) armazenamento de dados:

Os arquivos são os armazenamentos de dados nos sistemas de informação e são representados nos DFDs na forma de retângulos abertos. Geralmente, eles correspondem a tabelas em bancos de dados. Uma visão parcial do diagrama de fluxo de dados para o processamento de pedidos de vendas é apresentada na Figura 8.7.

Pode-se notar que alguns símbolos suplementares e pequenas variações nos símbolos que representam vários componentes do DFD também estão em uso. Os símbolos acima são os mais usados ​​e estão de acordo com a convenção gráfica sugerida por Gane e Sarson.

Muitas vezes, um gerente acha que o desenho do DFD é uma experiência muito difícil e frustrante. Cada vez que se desenha um DFD, verifica-se que ignorou um ou outro aspecto do fluxo de dados. Felizmente, as ferramentas CASE disponíveis possuem recursos para criar e modificar DFDs. No entanto, os iniciantes são aconselhados a seguir os seguintes passos para superar esse problema:

(a) Identifique todos os fluxos de dados de entrada e os fluxos de dados de saída separadamente junto com os terminadores, colocando os fluxos de dados de entrada no lado esquerdo e o fluxo de dados de saída no lado direito.

(b) Etiquete os terminadores usando o nome do fluxo de dados ou nomes adjetivos.

(c) Identifique os processos a partir dos fluxos de dados de entrada e retornados dos fluxos de dados de saída até se encontrarem no meio.

(d) Etiquete os processos usando nomes de verbos.

Um gerente deve estar preparado para redesenhar o DFD porque, muitas vezes, os fluxos de dados ficam claros para o gerenciador somente após o desenho do DFD. O envolvimento do usuário neste estágio é muito útil não apenas em reduzir o esforço por parte do gerente, mas também em melhorar o DFD.

Teste de DFD:

Sugere-se que o DFD deve ser testado exaustivamente antes de ser finalizado. A seguir estão alguns dos erros comuns no design de DFD:

uma. O rótulo do terminador pode ser o nome de uma pessoa ou de uma empresa em vez de uma classe. Por exemplo, um terminador pode ser rotulado como M / s. BR Ltd. em vez de fornecedor único. Outro erro pode ser que a operadora seja colocada como terminador em vez da entidade externa diretamente associada ao fluxo de dados.

b. Os dados podem fluir diretamente de um terminador para outro terminador.

c. Nenhum fluxo de dados pode ser indicado para ou de um processo.

d. O fluxo de dados é indicado do terminador para um armazenamento de dados (arquivo) ou de um arquivo para o terminador ou entre dois arquivos sem processamento.

e. Os processos são rotulados como objetos, como fatura ou um substantivo, como atendente de reserva.

Depois que os DFDs são desenhados para cada sub-sistema, os futuros detalhes de processamento podem ser descritos e descritos em inglês estruturado (códigos psedo). Esses códigos psedo são usados ​​posteriormente para codificar os aplicativos. O papel do gestor neste processo está limitado apenas a auxiliar o profissional de sistemas de informação na identificação e compreensão dos algoritmos envolvidos no processamento.

5. Módulo de Implementação:

Este módulo está principalmente preocupado com o teste do sistema, treinamento dos usuários e instalação do sistema.

Testando o sistema:

O teste de vários módulos é feito em vários estágios do processo de desenvolvimento. A regra de ouro a ser lembrada durante o teste é que o teste deve ser feito com o objetivo de identificar as maneiras pelas quais o sistema provavelmente falhará. Não deve ser com o objetivo de provar que o sistema funcionará de acordo com a especificação do projeto. Teste de sistema é o processo de buscar respostas para duas questões básicas:

1. Se o sistema de informação atende às necessidades de informação da empresa? O processo que busca resposta a essa pergunta é denominado pelos profissionais do sistema de informação como processo de validação do sistema.

2. O sistema de informação funciona corretamente? O processo de verificação busca responder a essa questão.

Como a natureza e o grau de gravidade dos erros são diferentes nos diferentes estágios de desenvolvimento do sistema, testes diferentes são administrados em módulos diferentes e no sistema como um todo.

Teste de unidade:

Os testes usados ​​no nível do módulo podem ser chamados de testes de unidade. Esses testes são realizados para detectar erros em interfaces, bancos de dados, operações aritméticas e lógica de controle. Eles são executados executando um módulo do sistema de informação em dados de teste especialmente projetados para testar se o sistema:

uma. Aceita tipo incorreto de dados (por exemplo, aceita valor numérico para nome);

b. Aceita dados fora do intervalo válido (por exemplo, aceita data com mês maior que 12);

c. Causa salto incorreto de um procedimento para outro procedimento.

Teste do sistema:

Como os testes de unidade são conduzidos isoladamente, é essencial que os testes de integração sejam realizados para verificar se essas unidades funcionam corretamente como um grupo. Devido à diversidade de natureza dos erros, diferentes estratégias de teste devem ser seguidas para verificar a validade e verificar o sistema. A Fertucks sugere três estratégias para testar o sistema de informação:

(a) Teste de caixa clara:

Nesta estratégia, os testes são projetados para estabelecer se os procedimentos seguidos para o processamento correspondem aos requisitos do aplicativo. Isso pode ser conseguido com a ajuda de revisão por outros profissionais do sistema de informação que não estavam diretamente associados ao estágio de desenvolvimento.

Alternativamente, o método de explicação estruturada pode ser usado. Nesse método, um grupo de pessoas revisa os procedimentos, primeiro examinando as partes propensas a erros e identificando as correções que precisam ser feitas. Em seguida, os membros do grupo avaliam a saída que o sistema oferecerá para um determinado tipo de entrada e testa se a saída do sistema está correta ou não.

b) Ensaio de caixa preta:

Nesta estratégia, o sistema é testado para dados ou dados inválidos que podem causar erros no funcionamento do sistema. A saída é verificada para determinar se ocorreu algum erro. Por exemplo, os dados podem conter um valor negativo para quantidade encomendada ou um valor fracionário para uma variável que pode receber apenas o valor total.

c) Ensaio da caixa de verificação:

Esta estratégia pressupõe que nunca é possível fornecer um sistema de informação totalmente livre de erros. Assim, após todos os testes e modificações, é necessário estimar o número de erros que ainda permanecem no sistema. Para estimar este número, alguns erros podem ser deliberadamente introduzidos no sistema. Em seguida, os testes são novamente realizados para detectar erros.

A proporção de erros introduzidos detectada é tomada como uma estimativa da proporção de erros reais detectados durante os testes anteriores. Assim, se 90% dos erros introduzidos foram detectados durante o teste da caixa de seleção enquanto um total de 450 erros foram detectados originalmente durante o teste de caixa transparente e teste de caixa preta, isso significa que 50 erros reais continuam não detectados no sistema.

Instalação:

A instalação é um processo de substituir o sistema antigo por um novo sistema. Em geral, existem quatro abordagens para a instalação. A instalação 'fria' é feita quando o sistema antigo é imediatamente descontinuado e é substituído por um novo sistema.

Tal instalação tem a vantagem de um ajuste psicológico mais rápido com o fato de que o novo sistema deve ser usado. No entanto, essa abordagem pode não ser adequada se os dados antigos do sistema anterior forem valiosos ou o novo sistema tiver alguns problemas. Para a instalação de sistemas de informação contábil, essa abordagem não foi considerada aceitável. As abordagens alternativas incluem:

a) Instalação piloto:

Um sistema pode ser instalado para uso somente por um grupo de usuários representante selecionado que testa o sistema usando-o de fato. Outros usuários continuam usando o sistema antigo. Quando os problemas no sistema são resolvidos, outros usuários também começam a usar o sistema. Essa abordagem também não é muito popular para os sistemas de informações contábeis porque o banco de dados contábil inteiro deve ser atualizado antes de poder ser usado pelos usuários.

Os requisitos de informações do usuário ultrapassam os limites do departamento e das divisões no organograma. No entanto, essa abordagem pode ser usada para entidades contábeis completas, como filial, escritório regional, etc. Assim, um sistema de informações contábeis pode ser usado por filiais selecionadas. Uma vez que eles são encontrados para ser livre de erros, eles podem ser usados ​​por outros ramos também.

(b) instalação fase a entrada:

Sob esta abordagem, a instalação ocorre em etapas. Esses estágios são componentes independentes do sistema de informação. Assim, o ciclo de vida da receita de um sistema de informação contábil pode ser instalado primeiro e outros ciclos de vida podem seguir um após o outro. Essa abordagem ajuda a se concentrar em uma parte selecionada do sistema. Isso ajuda a melhorar a aceitabilidade do sistema entre os usuários porque permite que o usuário lidere facilmente com a mudança.

c) Instalação paralela:

A instalação paralela significa executar o sistema antigo e o novo simultaneamente por um determinado período até que a utilidade do novo sistema seja comprovada. Este método é mais popular para o sistema de informação contábil, porque este é o mais seguro de todos os outros métodos. A única dificuldade, aqui, é o custo da corrida paralela e a tendência de estender o período de corrida paralela por aqueles que resistem à mudança.

Revisão pós-implementação:

Cada sistema deve ser revisado após a conclusão da implementação. Essa revisão não só ajuda a identificar as fraquezas do sistema, mas também prepara uma agenda de modificação para o futuro. É, na verdade, um processo de aprendizado. A auditoria do sistema também pode ser realizada para examinar o sucesso do sistema, em termos de custo, prazo de entrega, integridade e qualidade.