FACULDADE DE TECNOLOGIA DA AMAZÔNIA
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS
ANÁLISE DE SISTEMAS DE INFORMAÇÃO I
Unidade II
Análise de Sistemas de Informação
Prof. Edson Brito
Pág. 1
Análise de Sistemas
1. Introdução
Por Análise de Sistemas (AS) entende-se a atividade inicial do processo de
desenvolvimento de sistemas em que se determina e especifica o que um sistema deve fazer
bem como as circunstâncias sob as quais deve operar, envolvendo geralmente um esforço
colaborativo entre analistas de sistemas e utilizadores1, no qual os primeiros procuram obter a
partir dos segundos, num processo gradual e cumulativo, o maior conhecimento possível acerca
do domínio do discurso do sistema e respectivo ambiente.
Atualmente o termo análise de sistemas é por vezes substituído pelo termo engenharia
de requisitos. A adoção do novo nome deve-se à preocupação de se pretender incorporar uma
orientação de engenharia, adicionando-lhe mais rigor e disciplina. O uso do termo engenharia
implica que técnicas sistemáticas e repetíveis devam ser usadas para assegurar que os requisitos
dos sistemas são relevantes, consistentes e completos.
Análise de Sistemas tem o objetivo básico de, através da aplicação adequada da
tecnologia de informação (informática), aumentar a qualidade das informações que fluem nos
processos operacionais e decisórios das organizações. O Analista de Sistemas utiliza-se de
técnicas, métodos e ferramentas para a construção de modelos informacionais, para sua
implantação em tecnologia disponível e para sua manutenção sistemática. Para tanto, deve estar
apto a exercer as atividades de levantamento, estudo, análise, planejamento, projeto,
implementação, simulação e teste de soluções computacionais para tratamento das informações.
Os benefícios resultantes do trabalho realizado pelo Analista de Sistemas podem ser percebidos,
entre outros, pela racionalização de processos administrativos e produtivos, por ausência de
desperdício tecnológico e pelo aumento do grau de organização, controle, segurança e qualidade
do acervo informacional das organizações. As inovações na área de informática exigem que o
Analista de Sistemas seja um constante pesquisador de novas tecnologias e ferramentas de
trabalho. Numa perspectiva moderna o Analista de Sistemas busca, através da aplicação de
tecnologias emergentes, gerar novas oportunidades de negócios para a empresa.
2. Níveis de Intervenção da Análise de Sistemas
No desenvolvimento de sistemas de informação, o desenvolvimento de software ou
sistemas informáticos ocupa um grande espaço.
A introdução de um sistema informático numa situação real de trabalho afeta sempre a
estrutura e os arranjos organizacionais, assim como o sistema de informação. Por conseguinte, a
Análise de Sistemas é susceptível de se organizar e intervir em dois níveis principais, tantos
quantos os impactes provocados pelos sistemas informáticos, como ilustra a figura 2.1.
O primeiro - organizacional - diz respeito ao entendimento e definição dos processos
básicos, dados e normas requeridas para atingir o estado desejado da organização. O segundo sistema de informação - diz respeito à definição de requisitos para um sistema de informação
que satisfaça o estado desejado da organização, sendo a análise de sistemas de aplicações ou
sistemas informáticos uma (sub)-preocupação deste último nível.
Do processo de análise de sistemas devem então resultar requisitos para sistemas
informáticos, em conseqüência de necessidades detectadas no desenvolvimento do sistema de
informação ou na redefinição organizacional.
1
Os utilizadores são quer os futuros/potenciais utilizadores finais dos SI quer os gestores responsáveis pela unidade organizacional
onde o SI será implementado ou clientes que necessitam desenvolver um SI.
Pág. 2
Figura 2.1: Componentes e níveis principais da análise de sistemas.
3. Processo de Análise de Sistemas
Todo o processo de análise de sistemas engloba uma teia de sub-processos, sendo
muito difícil fazer uma distinção clara entre eles. A um nível de abstração grande, um processo
de análise de sistemas pode ser descrito como a obtenção/definição, análise e negociação,
documentação e validação de requisitos, como ilustra a figura 2.2.
Figura 2.2: Modelo do processo de análise de sistemas [adaptado de Kotonya e Sommerville (1998)].
Obtenção/definição. Os requisitos dos sistemas são descobertos ou definidos por meio
de consultas aos utilizadores, a documentos de sistemas, ao conhecimento do domínio e a
estudos de mercado.
Carvalho (1996) diz que os requisitos são descobertos ou identificados quando o
objetivo é unicamente construir sistemas informáticos (visão próxima da engenharia de
software) e que são definidos quando o objetivo é desenvolver o SI (visão de engenharia de
sistemas). Tentando explicar melhor, Carvalho afirma que: "… Identificar ou descobrir
requisitos corresponde a uma postura em que se pressupõe que os requisitos existem na
organização. Esta atitude é compreensível se atendermos a que o objetivo é a construção de um
sistema informático que satisfaça as necessidades expressas pelos futuros utilizadores do
sistema informático. O sistema informático é um fim em si. Pelo contrário, definir
deliberadamente os requisitos dos sistemas informáticos corresponde a uma postura em que os
sistemas informáticos são vistos como um meio para atingir um fim".
Pág. 3
Análise e negociação. Os requisitos são analisados em detalhe e negociados com
utilizadores diferentes de modo a decidir quais os requisitos aceitos. Este processo é necessário
porque há inevitavelmente conflitos entre requisitos de origens diferentes, a informação pode
estar incompleta ou os requisitos expressos podem ser incompatíveis com o orçamento
disponível para desenvolver o sistema. Usualmente há alguma flexibilidade nos requisitos e é
necessário negociar para decidir sobre o conjunto de requisitos a acordar para o sistema.
Documentação. Os requisitos acordados são modelados e documentados a um nível de
detalhe apropriado. Geralmente, há a necessidade de ser um documento de requisitos entendido
por todos os utilizadores do sistema. Usualmente entende-se que isto deve ser documentado
usando linguagem natural e gráfica.
Validação. Deve ser uma verificação cuidada da coerência e totalidade dos requisitos.
Este processo pretende detectar problemas no documento dos requisitos, antes de ser usado
como base nas fases seguintes do desenvolvimento.
A figura 2.2 mostra que as diferentes atividades na análise de sistemas devem ser
repetidas até que seja tomada a decisão de aceitação do documento de requisitos. Se for
encontrado um problema no rascunho do documento de requisitos, reentra-se na espiral
obtenção/definição, análise e negociação, documentação e validação. Isto continua até ser
produzido um documento aceitável ou até fatores externos tais como pressões de prazo de
entrega ou falta de recursos forçarem o término do processo de análise de sistemas. Um
documento final de requisitos deve então ser produzido. Quaisquer mudanças adicionais aos
requisitos farão então parte de um processo de gestão de requisitos.
A gestão de requisitos é o processo de gestão das mudanças dos requisitos de um
sistema. Os requisitos de um sistema mudam sempre como reflexo das mudanças das
necessidades dos utilizadores, do ambiente onde o sistema vai funcionar, do negócio, das leis,
etc.
4. Importância da Análise de Sistemas
A análise de sistemas é uma atividade crítica no processo de desenvolvimento de
sistemas, por ser uma etapa inicial e cujas falhas terão efeitos em cadeia nas etapas subseqüentes
assim como no produto final. A determinação incorreta dos requisitos levará à obtenção e
disponibilização de sistemas informáticos inadequados ao sistema de informação e ao sistema
organizacional.
Desde há bastante tempo que tem aumentado a consciência do impacto desta atividade
na qualidade/sucesso dos SI, mas os problemas ainda não foram resolvidos. Documentos ou
especificações de requisitos incompletas, pouco claras ou incorretas provocam dificuldades
significativas durante as etapas de desenvolvimento seguintes, levando à produção de sistemas
com pouca qualidade - por não cumprirem as necessidades reais dos utilizadores - e fora do
cronograma e orçamento previstos.
De fato, a introdução de falhas no desenvolvimento de sistemas ocorre a maior parte das
vezes durante a fase da análise de sistemas e, é importante eliminar estas falhas o mais cedo
possível porque se torna muito mais caro corrigi-las posteriormente. O custo relativo de reparar
problemas de requisitos detectados durante a fase de testes finais ou operacionais pode ser 100
vezes superior àqueles que são detectados durante a fase da análise de sistemas.
Em suma, a determinação dos requisitos parece ser a tarefa mais importante do
desenvolvimento de SI, porque é aí que o problema é definido, o âmbito da análise é
estabelecido e os requisitos de software são alocados. Assim, se a determinação dos requisitos é
incorreta o sistema resultante será incorreto porque, apesar de podermos chegar a sistemas
Pág. 4
informáticos elegantes, não existirá nenhum relacionamento com o que os utilizadores querem
ou necessitam.
5. Importância dos Utilizadores
O envolvimento dos utilizadores é um tópico crítico em todo o processo de
desenvolvimento de sistemas de informação. O seu nível de participação tem um impacto
direto, positivo e significativo na satisfação dos utilizadores. Quanto maior for a sua
participação no projeto, maior a sua satisfação como utilizador final.
No que respeita à análise de sistemas, a participação dos utilizadores aumenta a
aceitação do SI pelo desenvolvimento facilitador de expectativas realistas acerca do sistema
proposto, aumentando assim a qualidade e o sucesso do sistema pela melhoria do entendimento
deste por parte dos utilizadores, fornecendo requisitos mais completos e exatos, evitando o
desenvolvimento de um sistema inaceitável, e fornecendo conhecimento acerca da organização
e processos de negócio que serão suportados pelo sistema.
Na análise de sistemas deve então haver uma equipe onde, além dos analistas de
sistemas, esteja também presente um grupo representativo de utilizadores, para o problema a ser
resolvido, desempenhando um papel ativo na determinação dos requisitos. Contudo esta não
parece ser a política mais seguida na prática.
Um dos pressupostos da AS é que tem vindo a ser conduzida por analistas informáticos.
Estes geralmente nada sabem sobre o negócio. Assim o envolvimento dos utilizadores torna-se
ainda mais fundamental. Mas mesmo sendo realizada por analistas de negócio, a sua presença é
pelo menos útil na facilitação futura do processo de negócio.
6. Dificuldades na Análise de Sistemas
A análise de sistemas deve, como se viu na seção anterior, ser um esforço colaborativo
entre analistas de sistemas e utilizadores, onde os primeiros documentam e representam os
requisitos usando técnicas de modelação e então apresentam as especificações resultantes aos
segundos para a sua confirmação. Mas estas tarefas geralmente encontram muitos obstáculos.
A maior barreira na obtenção ou definição de requisitos com qualidade é a lacuna de
cultura existente entre utilizadores e analistas de sistemas. Duas características dos analistas de
sistemas que contribuem para essa lacuna são: (1) fraco conhecimento do negócio e (2) um
ponto de vista de análise de sistemas excessivamente técnico/tecnológico. Como as abordagens
tradicionais de análise de sistemas são desenvolvidas à luz destas características influenciam o
processo significativamente.
Um exemplo de um problema resultante da primeira característica é que os requisitos
não são entendidos completamente ou podem nunca ser descobertos pelos analistas de sistemas
quando o nível de comunicação entre utilizadores e analistas de sistemas acerca do domínio do
discurso é baixo.
Para a segunda característica, os problemas são: (1) os métodos e os analistas de
sistemas tendem a assumir que os requisitos são completamente conhecidos no início do
processo de análise de sistemas e que nunca mudam; (2) os utilizadores podem não entender os
modelos de requisitos construídos pelos analistas de sistemas, devido a diferenças de pontos de
vista entre analistas de sistemas e utilizadores e, ao fato dos modelos serem expressos com
notações de modelagem que os utilizadores não simpatizam ou não entendem (isto pode resultar
em decisões tomadas pelos analistas de sistemas usando os seus modelos, só que os modelos
finais do sistema refletirão a perspectiva dos analistas de sistemas em vez da dos utilizadores); e
Pág. 5
(3) a pouca atenção prestada ao contexto social e organizacional dentro do qual funciona o
sistema, o que levará eventualmente a muitas falhas nos sistemas.
As técnicas tradicionais de obtenção de requisitos usadas na prática geralmente não
suportam a natureza colaborativa do processo de análise de sistemas. Tipicamente envolvem
dedução de "fatos" por analistas de sistemas acerca dos requisitos dos utilizadores usando uma
série de entrevistas nas quais os utilizadores jogam um papel relativamente passivo e
secundário.
Estas técnicas também não suportam adequadamente a natureza emergente dos
requisitos, ou seja, nem todos os requisitos são pré-definíveis e os utilizadores talvez não
conheçam as suas necessidades completamente. Os requisitos emergem a partir de interações
entre analistas de sistemas e utilizadores e são refinados ao longo do processo de análise de
sistemas.
Mais: estas técnicas dão pouca atenção ao fato do contexto do sistema proposto afetar os
requisitos, desenvolvimento e evolução dos mesmos. O contexto de um sistema é o ambiente do
mundo real no qual o sistema opera, incluindo a estrutura social e organizacional bem como as
pessoas que fazem parte dela.
Alguns dos constrangimentos referidos podem, todavia, ser ultrapassados pela adoção
de métodos e técnicas que permitam chegar a melhores modelos, tendo em conta características
tais como: incerteza, volatilidade, contexto e grau de objetividade dos requisitos; valores,
crenças, aspectos cognitivos e pontos de vista dos utilizadores; poder, estrutura e cultura
organizacional; etc.
7. Desenvolvimento de Pontos de Vista
Um dos problemas da definição de requisitos é a existência de requisitos diferentes e
conflituosos nos múltiplos utilizadores, dado que cada um tem certas razões para os seus
requisitos. Uma das formas de resolver este problema é usar o desenvolvimento de pontos de
vista.
O desenvolvimento de pontos de vista é o processo de identificação, compreensão e
representação dos diferentes pontos de vista dos múltiplos utilizadores. Isto pode ajudar a que o
sistema definido satisfaça as necessidades e expectativas de todos os utilizadores envolvidos
pela facilitação do entendimento dos seus vários pontos de vista e requisitos suportando a gestão
de conflitos e inconsistências entre eles. O conceito de pontos de vista fornece um veículo para
discussão, elaboração e refinamento de requisitos, encorajando assim a comunicação e interação
entre os participantes do desenvolvimento. Desta forma harmoniza-se a natureza emergente dos
requisitos suportando a elaboração gradual e refinada dos pontos de vista do conhecimento dos
requisitos.
O desenvolvimento explícito de modelos dos pontos de vista dos utilizadores é
destinado a ajudar a construir um entendimento partilhado de requisitos e do ambiente
organizacional no qual um sistema e seus utilizadores coexistem. Isto é essencial para o sucesso
dos projetos de desenvolvimento de sistemas.
Os modelos de pontos de vista dos utilizadores expressam requisitos e perspectivas
individuais ou locais. O processo de desenvolvimento de pontos de vista, se envolver todos os
utilizadores e usar os seus pontos de vista como um meio de realçar a discussão e ativar a
participação pode ajudar a dominar como um todo o que se descreve, onde cada grupo de
utilizadores entende e assume responsabilidades somente na parte do domínio do problema que
lhe diz especificamente respeito, sendo incapaz de avaliar a "imagem" global. A integração de
perspectivas e requisitos individuais ou locais num conjunto de requisitos coerente e global
Pág. 6
pode prosseguir sobre uma base mais informada, se eles forem explorados e bem entendidos
(figura 2.3).
Figura 2.3: Desenvolvimento e resolução de pontos de vista.
A base de requisitos ainda pode ser melhorada ao ter-se em conta que diferentes
analistas de sistemas também podem chegar a diferentes modelos quando modelam o mesmo
universo do discurso, o que exige que se preste atenção aos pontos de vista dos diferentes
analistas de sistemas de um processo de análise de sistemas.
8. O Analista do Sistema
Analistas de sistemas de computador melhoram sistemas de computador existentes. Eles
também planejam e desenvolvem novos sistemas e ajudam organizações a redesenhar os
sistemas de computador.
Às vezes apenas sugerem e implementam alguns softwares para aprimorar o uso dos
computadores. Também projetam sistemas de software. Analistas de Sistema se especializam
freqüentemente em administração de sistemas, ciência, ou engenharia.
Analistas de sistemas começam projetos colhendo informação, discutem as necessidades
de uma organização com seus gerentes e funcionários. Uma vez as metas estão claras, os
analistas determinam se eles precisarem projetar um novo sistema de software.
Os analistas preparam relatórios que mostram quanto valerão as mudanças. Estes
relatórios também discutem como as organizações podem se beneficiar e o que podem esperar
dessas mudanças, e os gerentes usam estes relatórios para ajudar decidirem se o sistema
proposto valerá o custo.
Uma vez que estes planos são aprovados, os analistas de sistemas coordenam a
atualização ou instalação do sistema de computador. Alguns analistas de sistemas escrevem o
código de programação. Quando eles tiverem um sistema quase concluído, os analistas os
testam com seus usuários.
Eles observam a interação dos funcionários com o sistema e como eles o usam,
buscando saber se o sistema implantado atende as necessidades da empresa como planejado.
Eles também vasculham o computador em busca de problemas existentes e em potencial e
procuram corrigi-los.
Pág. 7
Quando o sistema estiver pronto e implantado, os analistas promovem o treinamento
dos funcionários, para que estes possam utilizá-lo de forma satisfatória. Eles também escrevem
manuais que descrevem como usar o sistema. Estes manuais devem ser escritos em condições
que os gerentes e outros usuários podem entender.
Além disso, analistas escrevem documentação para as pessoas que farão a manutenção
do sistema. Alguns analistas são os empregados de organizações. Estes analistas também
ajudam os funcionários a resolver problemas com seus computadores.
8.1 Atividades Desenvolvidas
O analista de sistema analisa as exigências de sistemas em um contexto empresarial e
técnico e determina as melhores soluções.
Analisa e testa o sistema para identificar erros e assegurar o bom funcionamento.
Consulta os funcionários e usuários identificar problemas de procedimento
operacionais, formulando e revisando planos que exigem muitas informações para desenvolver
sistemas que satisfazem as exigências empresariais ou dos usuários.
Desenvolve fluxogramas e diagramas para ilustrar passo a passo e descrever o fluxo
operacional lógico do sistema.
Escreve manuais que descreve e desenvolve a instalação e procedimentos operacionais
do sistema.
Coordena a instalação do sistema.
Lê manuais, periódicos, e relatórios técnicos para aprender a desenvolver sistemas para
satisfazer exigências do usuário.
Escreve e revisa programas e procedimentos de projetos de sistemas, procedimentos de
teste, e padrões de qualidade.
Revisa e analisa material impresso sobre o sistema com indicações de desempenho para
localizar problemas de código.
Modifica e corrige os erros dos códigos do sistema.
9. Texto de Apoio
Análise do sistema existente
Prof. Fernando Salles Claro
Introdução
No estudo da viabilidade de se construir um novo sistema ou melhorar o que está em
funcionamento, é imprescindível conhecer com detalhes como são obtidas as informações para a
empresa, bem como estas são distribuídas e como é conduzida a sua utilização.
Este estudo visa avaliar até que ponto as necessidades da empresa estão sendo satisfeitas
com o sistema existente e quais são os principais pontos que podem e devem ser melhorados.
Para que essa avaliação seja a mais completa possível, o analista de sistemas deverá
subdividir o seu estudo nas seguintes etapas:
Pág. 8
Análise da organização como um todo;
Verificação dos principais objetivos do sistema em funcionamento;
Análise de toda a documentação utilizada pelos setores em estudo;
Análise de procedimentos.
Análise da Organização como um todo
O conhecimento da organização como um todo é de fundamental importância porque
dentro da cada componente organizacional, existe a necessidade de informações específicas.
Para se fazer o estudo da organização, é necessário conhecer os objetivos do sistema
existente e sua relação com o sistema maior que é a própria organização.
Esse estudo deve ser iniciado pelo organograma geral da empresa, que por sua vez
mostra a estrutura organizacional “formal” existente.
O analista de sistemas deve também conhecer a organização informal da empresa,
obtendo dessa forma uma visualização real do sistema em estudo e de toda a companhia.
Outro item importantíssimo que deve ser observado pelo analista de sistemas é não
confundir fatos com opiniões dos usuários.
Nessa etapa, o analista de sistemas, deve acompanhar as rotinas de trabalho dos
funcionários dos setores envolvidos, não no sentido de auditorar suas funções, mas observando
somente o que lhe interessa como profissional de processamento de dados. É bom deixar essa
posição bastante clara para os funcionários envolvidos, evitando-se assim constrangimentos
desnecessários.
Ainda nessa fase, o analista de sistemas terá que verificar o que o sistema faz, seus
arquivos, seus relatórios, procedimentos, e analisar a eficiência e confiabilidade das informações
por ele geradas.
Verificação dos Principais Objetivos do Sistema Existente
Se um sistema de processamento de dados e informações está operando em uma
determinada organização, significa que ele é útil em algum aspecto. A ineficiência de um
sistema numa dada empresa, tem origem em uma série de fatores, muitas vezes não muito
visíveis para alguns profissionais.
Descobrir os objetivos “reais” de um sistema e determinar até que ponto ele atende às
necessidades de seus usuários, não é tarefa fácil. Esse estudo deve ser realizado, fazendo
consultas aos usuários, levantamento de arquivos, análise das documentações, inclusive manuais
e regulamentos internos.
Além disso, deverá ser estudado o fluxo de dados na empresa, localizando com isso a
origem e o destino de dados e informações, bem como, a inter-relação do sistema em estudo
com toda a organização.
Quando for analisada a origem de um documento ou informação, devem ser vistos
também os respectivos destinos, isto é, ver e analisar os dois lados para se tirar conclusões mais
seguras e sérias.
Pág. 9
Análise de Documentação
A documentação utilizada por um determinado setor é constituída por relatórios e
arquivos. Esses relatórios são emitidos pelo setor e têm grande utilidade no seu dia-a-dia, ou
então servem de suporte de informações para outros setores.
De forma análoga, um arquivo mantido por um setor pode servir-lhe de consulta e,
portanto tem grande valor.
Na prática, todo documento emitido pelo setor envolvido no estudo pode influir de
forma direta ou indiretamente no funcionamento do sistema existente.
Essa documentação toda deve ser analisada de forma detalhada e com o máximo
cuidado possível. É bom lembrar que é comum existirem informações importantes em relatórios
aparentemente desprezíveis e por isso nenhum deve ser excluído.
Para ser feita a análise da documentação envolvendo o sistema em estudo, o analista de
sistemas deve dividi-lo em duas etapas, que são:
Análise de relatórios e
Análise de arquivos
Análise de relatórios
Esta etapa consiste em descobrir quais os relatórios emitidos pelo setor em estudo bem
como, levantar os principais dados e informações que podem influir no desempenho do sistema
existente.
Conceitua-se relatório, como sendo todo e qualquer documento emitido pela empresa,
portanto cheques, notas fiscais e duplicatas são relatórios, além de uma infinidade de outros que
poderão ser verificados na prática.
Para se fazer esse levantamento, o analista de sistemas deve solicitar preferencialmente
duas cópias de cada relatório. Caso o impresso de um relatório seja procedido em formulário
pré-impresso, é útil conseguir uma cópia do respectivo formulário em branco e preenchido.
Além disso, deverão ser feitas anotações a respeito de cada relatório para facilitar a sua
análise.
Para que a análise dos relatórios seja feita de forma bem clara e completa, é
indispensável estudar os seguintes aspectos:
Objetivos de cada relatório;
Seu conteúdo;
Número de cópias e o destino de cada cópia;
Periodicidade de emissão - se é diário, semanal, quinzenal, mensal, etc.;
Quais as informações mais utilizadas;
Controle de validade das informações, índices de erros, etc.;
Se existem relatórios semelhantes e se é possível agrupá-los em apenas um;
Se após o recebimento, o usuário faz algum tipo de complementação, cálculos,
subtotais, etc.;
Qual o total de pessoal que participa da sua elaboração;
Quem é o responsável pela elaboração do relatório.
Pág. 10
Análise de Arquivos
Para a análise dos arquivos de cada setor envolvido no sistema existente em operação,
deverão ser coletados os seguintes itens:
Nome do responsável pela manutenção e conservação do arquivo;
Objetivos do arquivo;
Principais informações nele contidas;
Método de atualização e periodicidade;
Prazo de permanência dos dados no arquivo;
Relatórios que dependem dele para a sua confecção;
Número de fichas ou registros que compõem o arquivo;
Ordem de classificação de suas fichas ou registros;
Funções das pessoas que manipulam o arquivo e;
Tamanho do arquivo.
Análise de Procedimentos
Normalmente, os procedimentos operacionais de um sistema de processamento de
dados, são orientados por manuais que especificam como os trabalhos devem ser realizados.
Essa regra não é geral para todas as empresas, pois depende muito de sua estrutura e
organização.
Para iniciar a etapa de análise de procedimentos, o analista de sistemas deve verificar se
existem manuais, diagramas ou outros documentos que mostram como os processos são
realizados ou deveriam ser realizados.
Após essa verificação, é imprescindível saber se essa documentação está atualizada ou
apenas mostra uma imagem distorcida do que realmente acontece.
Se os processos não estiverem devidamente documentados, o analista de sistemas
deverá acompanhar os trabalhos dos funcionários envolvidos, e inclusive ajudá-los a realizar
tarefas que possam lhes ser úteis para a sua análise.
Esse trabalho requer bastante profissionalismo e, portanto deve ser levando de forma
totalmente documentada, mesmo que seja necessário um grande esforço de pesquisa,
entrevistas, avaliações e montagens de diagramas de fluxos de materiais e de dados.
Finalizando essa fase, o analista de sistemas deverá ter montado um relatório detalhado
dos levantamentos e análises efetuadas, contudo deverá tomar cuidado para que o seu trabalho
não se prenda simplesmente em documentar o sistema existente em operação na empresa.
10. Referências Bibliográficas
1. Análise Estruturada de Sistemas Chris Gane - Trish Sarson - Editora LTC
2. Projeto e Desenvolvimento de Sistemas Nelson Peres Silva - Editora Érica
3. Manual de Desenvolvimento de Sistemas Estruturados David Bellin - Susan Suchman Editora Makron Books
4. Desenvolvimento Rápido de Sistemas Chris Gane - Editora LTC
5. Análise Estruturada e Especificação de Sistema Tom DeMarco - Editora Campus
6. Manual de Análise de Sistemas John E. Bingham - Garth W. P. Davies - Editora InterCiência
7. Análise Essencial de Sistemas Sthephen M. McMenamim - John F. Palmer
8. O Essencial da Análise de Sistemas Álvaro Rocha – UFP 2008.
9. Apostila de Análise de Sistemas Fernando Salles Claro – IEDSA 2007.
Pág. 11