Análise de Sistemas e Projetos: uma abordagem

Análise de Sistemas e Projetos: uma abordagem aos
pontos chave.
AUTOR:
Resumo
Análise de sistemas e projetos consiste no estudo de processos, levantamento de
necessidades e informações para encontrar a melhor forma de resolução de
problemas. Designado a cumprir esta função o analista de sistemas a partir dos
conceitos adquiridos durante a análise efetuada, fornecera as melhores possibilidades
no desenvolvimento do sistema. De acordo com as competências necessárias a um
analista para que este desempenhe um bom trabalho, explanaremos um pouco os
pontos considerados mais importantes na analise de sistemas, passando pelas formas
de colher informações necessárias ao desenvolvimento do sistema, verificando o
porquê de muitos sistemas entregues não serem o que o cliente desejava, e chegando
a estruturação e documentação do sistema.
Como principais métodos abordados estão as três principais formas de normalização,
está também o diagrama de fluxo de dados onde será exibido os relacionamentos
funcionais de um sistema, incluindo valores de entrada e de saída e depósitos internos
de dados, ele nos mostrará o fluxo dos valores de dados desde suas origens, através
dos processos que os transformam até seus destinos, também será apresentado o
dicionário de dados onde será realizada a documentação de um sistema e permite
fazer a verificação de consistência do projeto.
Palavras-chave:
análise de sistemas, projetos de sistemas, metodologia de
desenvolvimento de sistemas, fluxo de dados.
Analise de sistemas e projetos consiste no estudo de processos, a fim de realizar o
levantamento das necessidades, de como funciona, e do ambiente organizacional,
para desta forma descrever os processos de resolução de problemas, a fim de
encontrar o melhor caminho para que a informação possa ser processada. Os
métodos e técnicas de investigação levarão a elaboração e desenvolvimento de um
conjunto de programas integrados (sistema), designado a suprir as necessidades da
organização. É função do analista de sistemas conduzirem o processo de obtenção de
informações, estudar os processos da organização e definir a partir dos conceitos
adquiridos as melhores possibilidades no desenvolvimento do Sistema.
Segundo Gane; Sarson (2009):
Análise de sistemas é, sob vários aspectos, a parte mais difícil do
desenvolvimento de um sistema de processamento de dados. Não é
simplesmente a dificuldade técnica do trabalho, embora muitos projetos
exijam que o analista seja um profundo conhecedor da tecnologia atual
de PD (processamento de dados). Nem são apenas as dificuldades
políticas que surgem, especialmente em projetos maiores em que o
nosso sistema atenderá a muitos grupos, cujos interesses são às vezes
conflitantes. Nem tampouco são os problemas de comunicação que
surgem em situações em que pessoas com experiências diferentes,
com diferentes pontos de vista e vocabulário diverso tenham de
trabalhar juntos. É a combinação dessas dificuldades que torna a
Análise de Sistemas tão difícil e exigente [...].
Ao elaborar a análise do sistema, uma lista de características é necessária ao analista
para que este obtenha sucesso em seu desenvolvimento: concentração, ação
conciliadora, saber trabalhar em grupo, persistência, determinação, flexibilidade a
adversidades, clareza de raciocínio, comunicar se bem, iniciativa e criatividade, são
algumas das características mais importantes e essenciais.
Tendo isto em mente e partindo para a análise, destaco que as técnicas de
levantamento de requisitos será fator fundamental para a elaboração de um projeto
consistente e com alto grau de qualidade.
De acordo com Kendall; Kendall (1992):
Perceber e capturar conhecimentos e requisitos dos usuários é uma das
tarefas mais importantes a serem efetuadas, diversas técnicas podem
ser utilizadas: Amostragem, investigação, entrevistas, questionários,
observação e prototipação, o que examinar, quem e de que maneira
questionar ou observar.
Não é fácil aprender o bastante sobre uma organização para conseguir determinar os
requisitos e funções do sistema, e é comum que na entrega de um sistema, (onde as
técnicas mencionadas não foram seguidas com disciplina e atenção), escutarmos
dizer que o sistema está perfeito no que se propõe a fazer, mas que não era
exatamente o que a organização desejava.
Conforme Gane; Sarson (2009):
[...] o analista não tem o direito de esperar dos usuários uma
explanação lúcida dos requisitos do sistema; ele precisa ajudá-los a
determinar suas necessidades. Por outro lado, os analistas não
possuem o dom da telepatia; eles não podem saber sobre aquilo que
não lhes foi dito. Este fato desagradável surge, particularmente, em
termos da importância relativa que os usuários dão aos vários aspectos
do sistema. Suponhamos que um determinado gerente deseja um
relatório do ativo disponível todas as manhãs. O que será mais
importante? Que ele o receba até as oito e meia, mesmo que alguns
itens não tenham sido resolvidos, ou que ele receba com uma precisão
de centavos, mesmo que, em alguns dias, ele o receba às onze da
manhã? O gerente sabe muito bem e poderia exclamar: “bolas,
qualquer idiota que conheça algo a respeito do negocio da empresa
saberia isto”. Mas adquirir tal nível de sentimento intuitivo sobre as
vantagens/desvantagens para os negócios da empresa é difícil.
O analista terá a capacidade de ajudar os usuários a determinar suas necessidades e
explanar suas visões do que espera ou necessita do sistema, apenas se ele houver
também se inteirado com o ambiente em que a organização se encontra, ou seja, que
ramo de atividade desenvolve, quais os objetivos a curto, médio e longo prazo, qual a
visão da organização e o que ela como um todo espera deste sistema.
Ward (1987) nos diz que:
Os grandes sistemas falham porque os padrões organizacionais não
são fielmente refletidos na implementação. As pessoas envolvidas em
desenvolvimento de sistemas, tanto os usuários quanto os projetistas,
não compreendem os padrões de forma suficientemente clara; de outro
modo, se a coordenação em grande escala não for cuidadosamente
refletida, o sistema implementado não funcionará bem. Na melhor das
hipóteses, ele estará propenso a erros e, na pior das hipóteses,
impraticável. Apesar da tecnologia ser poderosa, ela não pode atender
eficientemente as propostas das empresas, sob tais condições.
Para evitar que problemas como este não venham a ocorrer, ou pelo menos diminuir
as possibilidades de que ocorram, podemos utilizar uma técnica de analise
estruturada, o diagrama de fluxo de dados. O ponto positivo em utilizar está técnica
está em permitir a integração dos usuários na avaliação do modelo, de forma a
encontrar falhas no sistema. O diagrama de fluxo de dados (DFD) exibe os
relacionamentos funcionais de um sistema, incluindo valores de entrada e de saída e
depósitos internos de dados. É um gráfico que mostra o fluxo dos valores de dados
desde suas origens, através dos processos que os transformam até seus destinos. Um
DFD pode ter vários níveis de acordo com a necessidade de detalhamento do sistema.
A figura 1.0 a seguir é um exemplo de DFD, como nos mostra Gane; Sarson (2009).
LIVROS
EDITORAS
Detalhes de livros
CLIENTES
Pedidos
Verificar
validade
do
pedido
Situação de
crédito
Endereço
Pedidos
válidos
Pedidos
Agrupados
Preparar
requisição
para a
editora
Ordem de
compra
PEDIDOS PENDENTES
CLIENTES
Figura 1.0 Expansão do DFD. (GANE; SARSON – 2009)
EDITORAS
Segundo Gane; Sarson (1983 apud JOÃO, 1993, p. 30), “o propósito de um DFD é
mostrar para uma área de negócios ou um sistema ou parte dele, de onde os dados
surgem, para onde vão, quando são armazenados, que processos os transformam e
as iterações entre armazenamento de dados e processos”.
Os objetos do sistema em um DFD podem ser descritos da seguinte forma:
Entidades externas – pessoas, grupo de pessoas ou subsistema/sistema fora do
sistema em estudo que recebem dados do sistema e/ou enviam dados para o sistema.
As entidades externas funcionam sempre como origem/destino de dados;
Fluxo de dados – dados que fluem entre processos e arquivos de dados ou ainda
entre processos e entidades externas, sem nenhuma especificação temporal (por
exemplo, ocorrência de processos simultâneos, ou que ocorre semanalmente);
Arquivo de dados – meio de armazenamento de dados para posterior consulta e/ou
atualização por um processo;
Processo - recebe dados de entrada e transforma estes dados num fluxo de saída.
À medida que ampliamos os detalhes dos conteúdos de fluxos de
dados, de depósitos de dados, e de processos, torna-se necessário um
local estruturado para manter todos estes detalhes. O dicionário de
dados proporciona tal local. O nome dicionário de dados adquire um
significado mais amplo quando começamos a incluir detalhes sobre
processos que, estritamente falando-se referem a lógica e não a dados.
Talvez devesse ser realmente chamado diretório de projeto. Entretanto,
como dicionário de dados é um nome amplamente empregado, vamos
adotá-lo, e usá-lo, sem nenhum constrangimento, para qualquer coisa
que precisemos descrever (GANE; SEARSON, 2009).
O dicionário de dados é uma ferramenta muito importante na documentação de um
sistema, pois esta descreve todas as informações usadas na construção deste.
Permite fazer a verificação de consistência do sistema. Na figura a seguir 2.0 é
exposto um modelo com as descrições mais básicas que um dicionário de dados deve
conter.
Dicionário de Dados
Projeto
Tabela
Descrição da
Tabela
Nome do
Campo
Descrição
Tipo do Campo Tamanho
Figura 2.0 Dicionário de dados
Observação
Gane; Sarson (2009), acrescenta que:
Grande parte do valor de um dicionário de dados deve-se ao fato dele
ser um depósito central de dados para todos os analistas projetistas e
programadores que trabalham num dado projeto, ou numa dada área de
aplicação, ou ainda, para toda a organização (empresa). Como o
dicionário é um depósito central, deve ser controlado por uma pessoa
ou um grupo. Em nível de projeto, tal pessoa pode ser chamada de
administrador de dados ou administrador de elementos de dados. (No
nível organizacional o dicionário de dados é controlado pela
administração de banco de dados.) O administrador de dados é
responsável pelo controle das entradas e mudanças no dicionário,
tornando-o o mais fácil possível, para que todos no projeto tenham
acesso a versões atualizadas e, geralmente, ajudando a evitar “a
reinvenção da roda”, que ocorre quando um grupo de análise está
trabalhando sem coordenação nas definições de dados.
Um dicionário de dados pode ser manual seguindo a criação de formulários ou pode
ser um dicionário de dados automatizado, muitas vezes um software deste tipo tornase indispensável para dar suporte a análise e agilizar o processo de desenvolvimento.
De maneira a simplificar o conteúdo do depósito de dados tanto para sistemas
manuais como para os automatizados, quanto mais simples e mais geral for a
estrutura de um depósito de dados mais fácil será efetuar mudanças nos dados. Para
tal são consideradas três formas de normalização. Estas procuram identificar nos
arquivos, estruturas complexas a serem simplificadas e redundâncias que possam ser
eliminadas.
Os objetivos das normalizações são segundo Matin (1991): “Organizar os dados de
modo que eles possam ser representados em tabelas onde cada posição de linhacoluna tenha um único item de dado (sem grupos de repetições)”.
De acordo com João (1993), as três principais formas normais são:
Primeira forma normal (1FN): dizemos que uma relação está na primeira
forma normal quando não contém grupos repetitivos, ou quando a
relação não contém outras relações. Refere-se a qualquer tabela que
tenha apenas um valor por célula, ou intersecção linha/coluna. Uma
relação que não esteja na primeira forma normal pode ser subdividida,
sem perda de informação, em mais de uma relação na primeira forma
normal retirando-se as relações embutidas.
Segunda formal normal (2FN): uma relação está na segunda forma
normal, quando os valores de cada domínio dependem de cada chave
da relação e não da parte da chave. Uma tabela na primeira forma
normal está também na segunda forma normal se toda coluna não
chave depender da chave inteira.
Terceira forma normal (3FN): uma relação está na terceira forma normal
se todos os domínios não chave são dependentes exclusivamente da
chave. Uma tabela em segunda forma normal está também em terceira
forma normal se não há nenhuma coluna não chave, dependendo de
outra coluna não chave.
Muitas outras ferramentas e técnicas poderão e deverão ser consideradas durante a
análise de sistemas e projetos, aqui foram abordados os assuntos considerados
relativamente mais importantes ao desenvolvimento da analise.
Considerações finais
A conclusão deste artigo vem ao encontro da busca por novos conhecimentos,
agregados aos conhecimentos adquiridos nas cadeiras da universidade. Essa
experiência de pesquisa nos revela que a fonte de conhecimentos é inesgotável para
aquele que a buscam.
Durante o período de pesquisa foi averiguado a grande quantidade de informações
disponíveis a respeito do assunto relacionado a analise de sistemas e projetos, e quão
complexo ele é, foi constatado que a pericia nas etapas de desenvolvimento da
analise é essencial para um resultado satisfatório, e a interação do analista com a
organização (sistema) é parte fundamental no processo.
Este estudo deverá ser abrangido de forma mais eficiente, visando apresentar um
documento de referência para estudos posteriores. Este por sua vez deverá ser
entregue em forma de trabalho de conclusão de curso.
Referências Bibliográficas
GANE, Chris; SARSON, Trish. Análise estruturada de sitemas. 24. ed. Rio de
Janeiro: Livros Técnicos e Científicos, 2009.
JOÃO, Belmiro do Nascimento. Metodologias de desenvolvimento de sistemas.
São Paulo: Érica, 1993.
KENDALL, K. E.; KENDALL, J. E. Sistems analysis and design. 2. Ed. New Jersey:
Prentice-Hall, 1992.
WARD, Paul T. Desenvolvendo sistemas sem complicação: guia do usuário para a
modelagem de padrões organizacionais. Rio de Janeiro, 1987.