aula03

Prévia do material em texto

3ºAula
Análise e Desenvolvimento 
de Sistemas
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
entender os objetivos da Análise de Sistemas;
conhecer as atribuições do profissional de análise de sistemas;
saber interpretar problemas relacionados com a análise de sistemas.
Prezados(as) alunos(as),
Continuamos nossos estudos, compreendendo, na aula 
3 os princípios da análise e desenvolvimento de sistemas bem 
como as atribuições das partes envolvidas no processo.
 
Bom Trabalho!
Bons estudos!
73
Análise de Sistemas I 18
Seções de estudo
1 - Analisar e desenvolver sistemas
1 – Analisar e desenvolver sistemas
2 - O Analista de Sistemas
3 – Problemas com a análise clássica (tradicional)
4 – Análise tradicional X análise estruturada
Analisar e desenvolver sistemas é a tarefa de criar 
novos sistemas para empresas ou modificar e melhorar os 
já existentes. Essa tarefa refere-se a todas as etapas desse 
processo que inclui desde a percepção inicial do problema a 
ser resolvido até a concepção, implantação e manutenção do 
sistema informatizado. 
O profissional de Análise de Sistemas deve fazer um 
estudo minucioso do ambiente que será ou está sendo 
informatizado dentro da empresa, analisando os processos, 
documentos relacionados àquele processo, coletando 
informações e opiniões dos funcionários ligados direta ou 
indiretamente àquela área de trabalho e buscando entender 
como funciona o fluxo destas informações no dia a dia da 
empresa.
O sistema de informação é implantado na empresa 
com o fim de resolver algum problema existente. Antes de 
qualquer coisa, é preciso detectar e entender esse problema 
detalhadamente. Sem entender completamente o problema e 
os fatores que o estão causando, será difícil criar uma solução. 
Existem casos em que o problema é causado por outro 
sistema preexistente. Diante disso, é muito importante analisar 
esse sistema junto ao usuário, para que sejam apontados os 
pontos falhos e a forma como ele gostaria que a solução fosse 
desenvolvida para cada problema detectado.
A comunicação e troca de informações com todas as 
pessoas envolvidas é constante e precisa ser bem clara. Todos 
os detalhes precisam ser expostos e sanadas todas as dúvidas 
relacionadas ao processo, pois quando isso não ocorre, 
muitos problemas poderão surgir durante o processo de 
análise e desenvolvimento do sistema, problemas, inclusive, 
de relacionamento com os usuários.
Durante a análise de um determinado sistema, deve-se 
ter como objetivos os itens a seguir:
1- identificar as necessidades do usuário;
2- fazer análise econômica e técnica, levantando a 
viabilidade do desenvolvimento do sistema;
3- atribuir funções ao hardware, ao software, às pessoas, 
ao banco de dados e aos demais componentes do sistema;
4- definir prazos e custos;
5- criar uma definição inicial do sistema que sirva como 
base para todo o trabalho de análise a ser desenvolvido, com 
o intuito de entender quais os objetivos que o sistema deve 
atender.
A principal dificuldade encontrada pela equipe de 
desenvolvimento é que, depois de coletadas e analisadas 
todas as informações referentes ao processo que está sendo 
informatizado, é preciso transformar tudo isso em algo que 
o computador possa entender e processar, ou seja, todas 
as ideias, conceitos e informações abstratas precisarão ser 
transformadas em programas de computador e elementos 
de banco de dados que consigam representar fielmente o 
procedimento adotado no mundo real.
Outro problema que surge com frequência é que ao 
passo que a análise do sistema vai se desenvolvendo e as 
informações vão sendo coletadas e analisadas, novos detalhes 
vão surgindo para as tarefas que estão sendo informatizadas 
em um setor da empresa. Com isso, existe o risco de anular 
algumas percepções que tinham sido captadas antes. Em 
virtude desse novo detalhamento, novas regras podem surgir 
e certamente novas necessidades também, o que pode fazer 
com que uma solução informatizada deva ser desenvolvida de 
uma forma diferente da que havia sido pensada anteriormente, 
tornando o trabalho inicial inválido.
Fonte: Acervo pessoal
O Sistema começa com um usuário:
em especificações técnicas necessárias aos programadores;
processo de desenvolvimento do sistema
2 - O Analista de Sistemas
Nos primeiros anos da análise de sistemas, entre 1970 
e 1980, a preocupação principal dos analistas de sistemas 
era com os equipamentos das empresas (hardware). Eles 
geralmente se preocupavam apenas com questões técnicas 
relacionadas ao software, já que nessa época os sistemas se 
resumiam a desenvolver tarefas de cálculos e trabalhos 
repetitivos, como emissão de Holerites, imensos relatórios de 
difícil compreensão e substituição de trabalhos manuais por 
trabalhos automáticos, pois os próprios equipamentos não 
forneciam recursos suficientes para que se pudesse pensar em 
algo mais dinâmico e que desse um maior apoio ao processo 
de tomada de decisões.
Cada empresa possuía seu próprio CPD, que são os 
Centros de Processamento de Dados, com seus profissionais 
contratados especificamente para essa empresa. 
Nessa época, o trabalho do Programador era visto com 
mais importância do que o do Analista, pois as questões 
técnicas dos equipamentos existentes na época exigiam um 
grande conhecimento sobre o seu funcionamento interno e 
não apenas das atividades rotineiras que seriam substituídas 
pelos “pesados” computadores.
A partir da década de 1990, os computadores começaram 
a ficar mais acessíveis para as empresas. O aparecimento de 
novas linguagens que utilizavam menos códigos de máquina 
e mais linguagem próxima da humana, facilitou o trabalho 
74
19
de programação e, consequentemente, a possibilidade de 
criação de sistemas que não fossem apenas substituidores de 
trabalhos de digitação. A necessidade da criação de sistemas 
mais completos passou a se tornar cada vez mais evidente. A 
empresa não queria apenas substituir trabalhos braçais, mas 
começou a perceber que seria uma excelente ferramenta de 
manipulação de informações das organizações, o que ajudaria 
no processo de tomada de decisões. 
Consequentemente, os Analistas de Sistemas se viram 
na obrigação de conhecer melhor os negócios da empresa 
e entender suas necessidades, deixando de focar apenas nas 
necessidades já existentes, pensando também nas necessidades 
futuras e nas possibilidades de expansão da organização dos 
procedimentos e dos controles da empresa.
Hoje, os analistas de sistemas devem ser capazes de 
lidar com os usuários da empresa, que são as pessoas mais 
importantes, principalmente nas etapas iniciais dos trabalhos 
em que se está conhecendo as necessidades do novo sistema, 
com os profissionais técnicos que cuidarão das instalações e 
com a administração da empresa.
Os usuários, de início, estão preocupados em como será 
sua participação na empresa quando o sistema for implantado, 
pois mesmo com toda a informação disponível e com a 
“popularização” dos sistemas de informação, ainda existem 
situações em que os usuários veem o sistema como um 
concorrente direto, disputando o seu emprego. Essa questão 
é bastante delicada e deve ser esclarecida pelo analista de 
sistemas logo no início dos trabalhos, pois se o usuário sentir 
que existe algum risco para a sua permanência na empresa, 
ele fará algum esforço para que esse sistema não funcione, 
seja omitindo informações importantes, seja passando 
informações erradas. 
A partir do momento em que o usuário não enxergar mais 
o sistema como um risco para o seu emprego, a preocupação 
dele passará a ser com relação à facilidade de utilização e 
com as mudanças provocadas na sua rotina de trabalho. O 
usuário fará uma comparação da sua rotina de trabalho entre 
o processo manual e o processo informatizado. Se o segundo 
lhe exigir mais tempo e atenção, essa solução não será vista 
como adequada para ele. 
A administração da empresa está mais preocupada com 
os resultados obtidos com o novo sistema do quecom o 
seu funcionamento propriamente dito. A proporção custo/
benefício é o que importa e a recuperação do valor investido é 
prioridade. A preocupação do usuário com relação à facilidade 
de utilização do sistema não tem tanta importância para a 
administração. Isso só será levado em conta algum tempo 
depois, quando os trabalhos de informatização estiverem 
normalizados e quando os usuários já estiverem familiarizados 
com a nova rotina de trabalho. Para a administração, que 
optou pela informatização, o usuário deve, a qualquer custo, 
se adaptar às novas rotinas porque essa é a nova “cara” da 
empresa.
2.1
Sistemas
O Analista de Sistemas é responsável por atuar 
diretamente com os responsáveis pelas áreas de negócios da 
empresa, com os usuários do nível mais operacional, com 
os integrantes da equipe que irá desenvolver o sistema, além 
de ter uma constante interação com a alta administração, 
apresentando propostas de solução, andamento dos trabalhos 
e recebendo informações sobre os objetivos do sistema na 
visão gerencial. 
Deve atuar na análise das informações coletadas, projetar 
os sistemas, fazer levantamento de dados, compreender regras 
de negócios dos diversos setores da empresa, além de saber 
lidar com pessoas que, a princípio, não veem a informatização 
com ar de parceria. Além do mais, as pessoas que já trabalham 
na empresa, principalmente as que têm mais tempo, tem 
visões completamente diferentes umas das outras, já vêm 
com as ideias todas enraizadas em virtude da experiência de 
trabalho e da visão muitas vezes limitada do que é, possível 
fazer e, o mais importante, se sentem incomodados quando 
algo vem para perturbar seu “sossego” no trabalho do dia a 
dia.
O Analista de Sistemas deve ser capaz de:
levantamento de serviços, identificando suas principais 
características e estudando a viabilidade econômica e 
técnica das soluções possíveis, propondo consequentemente 
alterações, visando à melhoria no desempenho;
novos sistemas;
documentação em nível de sistema;
a realização de testes;
referentes a sistemas, visando à segurança, precisão e rapidez 
das diversas formas de registros e tratamento de informações.
Figura 3.2 – Qualidades esperadas de um Analista de Sistemas
Fonte: Acervo pessoal
3 - Problemas com a análise clássica 
(tradicional)
Alguns fatores podem contribuir para que apareçam 
problemas durante a análise clássica de sistemas. Esses fatores 
precisam ser identificados pela equipe de informática a fim 
de que não atrapalhem o andamento do processo de análise e 
desenvolvimento do sistema.
75
Análise de Sistemas I 20
3.1 - Problemas de Comunicação
A maioria dos problemas de comunicação acontece 
por causa de mau entendimento das informações passadas. 
Quanto mais cedo esses erros acontecerem, maiores serão 
os problemas causados na concepção final do sistema, pois 
o sistema será construído sobre uma base de informações 
distorcidas e que não refletem a real necessidade da empresa.
Outro problema de comunicação é o emprego excessivo 
de termos técnicos usados tanto pelos analistas quanto 
pelos usuários. Ambos precisam ter em mente que cada um 
é especialista na sua área de atuação, mas o outro não tem 
necessariamente que conhecer todos os termos que para um 
são rotineiros. O uso de termos técnicos durante a conversação 
dificulta o entendimento de ambas as partes.
Além disso, a maior parte das informações é obtida 
através de deduções do profissional de informática, por 
excesso de confiança dele ou por omissão do usuário em 
passar informações.
3.2 - Mudanças naturais exigidas 
pelo sistema
As mudanças são uma constante durante o tempo de 
vida do sistema. Mudar o sistema é uma consequência natural 
da sua própria evolução. O sistema precisa se adaptar ao 
meio para continuar sendo utilizável. As mudanças são mais 
frequentes nas aplicações comerciais, em que as variações 
de procedimentos, normas, leis e políticas da empresa são 
maiores. 
3.3 - Falta de Ferramentas
Poucas são as ferramentas de análise que realmente 
resolvem o problema, ou, então, são ferramentas antiquadas, 
de 20 anos atrás. Além disso, grande parte das ferramentas 
não atende a todo o trabalho de análise do sistema, ajudando 
apenas em uma parte dos trabalhos.
3.4 - Documentação
A documentação é de extrema importância para o 
projeto do sistema, porém ela não é adotada pela maioria dos 
profissionais de informática, que a classificam como “perda 
de tempo”. Geralmente, grandes empresas têm uma maior 
preocupação quanto à documentação dos sistemas, mas ela 
deve ser feita em todos os sistemas, independentemente do 
tamanho ou complexidade. 
A documentação fornece informações sobre o projeto 
do sistema durante todo o seu ciclo de vida, desde as etapas 
iniciais de levantamento de dados até a fase de manutenção 
do sistema. Nela são colocados todos os dados referentes 
às necessidades do sistema, decisões tomadas, diagramas, 
estruturas de dados, manutenções solicitadas, etc. Todo o 
histórico da vida do sistema deve ficar armazenado nos 
chamados manuais do sistema.
Além do problema da falta de documentação, as 
empresas muitas vezes não adotam uma padronização 
para os manuais dos sistemas, o que dificulta o trabalho de 
identificação e entendimento. É necessário que se tenha um 
padrão de nomenclaturas utilizadas, formato dos manuais e 
procedimentos utilizados, assim, qualquer dos integrantes da 
equipe de desenvolvimento poderá entender os manuais sem 
precisar que outro integrante tenha que explicá-lo.
Manter a documentação dos sistemas atualizada 
não é uma tarefa muito comum. As alterações ou novas 
implementações acabam sendo anotadas por escrito nos 
manuais já produzidos. Essa forma também deve ser evitada, 
a fim de que os manuais tenham uma qualidade e legibilidade 
mínimas para o perfeito entendimento.
3.5 - Formação do Profissional
sistemas;
forma tradicional.
4 - Análise tradicional X Análise 
estruturada
A análise clássica foca diretamente nos detalhes para 
resolver os problemas do usuário, levantando-se os dados 
apresentados um a um pelos usuários, sem a preocupação 
com o todo. O trabalho é todo feito de uma forma sequencial 
e os problemas são analisados um de cada vez. Na versão 
da análise estruturada, o problema deve primeiramente ser 
visto como um todo, e gradativamente o problema vai sendo 
refinado e detalhado por partes, até que se chegue a soluções 
para cada uma das partes.
Na versão clássica, a empresa é analisada em uma visão 
unidimensional, pois todos os processos são analisados do 
início ao fim, em uma forma sequencial, verificando um 
ponto a cada vez e só passando para a etapa seguinte quando 
a anterior já estiverem concluída.
Na análise estruturada, a empresa é analisada, 
primeiramente, em uma visão macro, e todos os detalhes 
procedimentais vão sendo detalhados, até que se tenha uma 
visão que não possa ser mais esmiuçada. Com isso, inicia-
se uma visão geral do todo, dando maior visão de como o 
processo funciona na realidade da empresa, tornando possível 
relacionar problemas em cada área de atuação.
A análise clássica é mais trabalhosa e menos detalhada 
que a análise estruturada. Na análise clássica, encontramos as 
definições feitas através de textos e de fluxogramas. Na análise 
estruturada, é focada nos diagramas DFD (Diagrama de Fluxo 
de Dados), Diagrama de Estrutura de Dados, Normalização e 
Dicionário de dados (descrição dos dados e suas estruturas).
Dessa forma, oferece uma visão mais detalhada dos dados 
e processos e do relacionamento entre eles, deixando, assim, 
mais claro o entendimento das necessidades e do fluxo de 
informações.
A análise clássica tem seu foco principal nos detalhes, 
ignorando os aspectos da macro visão do problema. A 
perspectiva da análise é focada nas funções que o sistema 
deverá executar e nos problemas que são apresentados pelos 
usuários. Com isso, o usuário passa a ser mero espectador 
do processo de análise, contribuindo com a situação atual 
apresentada apenasde forma superficial e uma grande lista de 
problemas que ocorrem no dia a dia. A partir daí, o analista 
passa a trabalhar no desenvolvimento e o usuário fica na 
espera de aparecer uma solução para todos os seus problemas. 
Não há uma preocupação da equipe de desenvolvimento em 
76
21
PAULA FILHO, Wilson de Pádua. Engenharia de 
software: Fundamentos, métodos e padrões. Rio de Janeiro. 
LTC. 2005.
Vale a pena ler
PROFISSÕES, Brasil. Analista de Sistemas. Disponível 
por www em: <http://www.brasilprofissoes.com.br/
profissoes/academicas/ciencias-exatas-e-informatica/
>. Acesso em 
02/11/2013.
www em: <http://www.adamsilva.com.br/profissoes/
analista-de-sistemas/>. Acesso em 03/12/2013.
Vale a pena acessar
Vale a pena
refinar os procedimentos ou encontrar novos caminhos para 
a criação da solução, assim como não há uma participação 
efetiva dos usuários envolvidos. 
Na análise estruturada o andamento do processo é 
diferente, pois o analista inicia os trabalhos com uma visão 
“aérea” da empresa e dos procedimentos e, a partir daí, 
vai refinando os processos, juntamente com os usuários, 
captando informações e detalhes procedimentais a cada 
novo refinamento. Com isso, o risco de aparecerem situações 
que não foram percebidas antes é bem menor, uma vez que 
o usuário terá uma participação mais efetiva do que está 
acontecendo, e passa a ser parte integrante do processo de 
análise, contribuindo com sua experiência na área funcional 
que é de sua responsabilidade, ou seja, a responsabilidade 
do sucesso da informatização ficará distribuída ente a 
responsabilidade técnica da equipe de desenvolvimento e a 
responsabilidade operacional e de controle do usuário.
Finalmente, podemos perceber que com a análise clássica 
existe um maior desperdício de tempo, pois grande parte do 
trabalho de levantamento dos dados será inconsistente com 
o produto produzido, uma vez que o trabalho é feito de uma 
forma sequencial, gerando apenas um grande texto como 
documentação, o que não garante que o sistema gerado no final 
do processo estará realmente atendendo às necessidades que 
foram mal analisadas no início. A expectativa de manutenções 
constantes nesse sistema será grande.
Com a versão estruturada, o trabalho é todo dividido 
em módulos, cada módulo com seu nível de detalhamento, 
dando uma melhor visão de cada parte, facilitando, inclusive, 
as manutenções necessárias, pois os processos são mais 
facilmente analisados quando são separados em módulos e 
funções que têm algum relacionamento.
Retomando a aula
Na seção 1, vimos que o sistema começa a partir da 
necessidade do usuário. Perceber essas necessidades é a 
tarefa mais importante no início dos trabalhos, pois, se as 
necessidades do usuário não forem satisfeitas, o sistema não 
terá cumprido totalmente seu papel.
Além disso, é importante também ficar atento à 
dificuldade encontrada em transformar essas necessidades em 
um sistema que o computador possa entender e executar, o 
que chamamos de abstração.
2 - O Analista de Sistemas
O Analista de Sistemas é o profissional que deve ter 
capacidade de lidar com os usuários que irão passar as 
informações para o desenvolvimento do sistema, com a 
equipe de informática que irá fazer parte do processo de 
transformação das necessidades em um sistema e, também, 
com a administração da empresa, que espera por um produto 
que funcione bem e nem sempre tem as mesmas visões das 
necessidades dos usuários.
3 – Problemas com a análise clássica (tradicional)
Durante a análise de um sistema, problemas importantes 
poderão atrapalhar os trabalhos e precisam ser observados 
atentamente como: problemas de comunicação que causam 
interpretações incorretas do que os usuários esperam do 
sistema; as mudanças que o sistema precisará sofrer para que 
continue atendendo ao usuário mesmo com as mudanças das 
rotinas da empresa; falta de ferramentas para ajudar no processo 
de análise; a documentação das etapas de desenvolvimento 
do sistema, que não é muito aceita por alguns integrantes da 
equipe de desenvolvimento, e a formação profissional dos 
analistas, que pode comprometer a qualidade do processo.
4 – Análise tradicional X análise estruturada
A análise clássica foca diretamente nos detalhes para 
resolver os problemas do usuário, levantando-se os dados 
apresentados um a um pelos usuários, sem a preocupação com 
o todo. Na versão da análise estruturada, o problema deve 
primeiramente ser visto como um todo, e gradativamente o 
problema vai sendo refinado e detalhado por partes, até que 
se chegue a soluções para cada uma das partes.
77