Você está na página 1de 14

Análise Essencial e Estruturada

Análise Estruturada
9 ANÁLISE ESTRUTURADA

As dificuldades causadas por problemas de comunicação,


mudanças de requisitos e técnicas inadequadas de avaliação
tornam a análise estruturada uma fase crítica no desenvolvimento
de sistemas. A definição de requisitos de uma forma precisa não
5 é fácil e, além dessas dificuldades, a linguagem do usuário e a do
responsável pelo desenvolvimento são tão diferentes que uma
comunicação eficaz é praticamente impossível.
O principal objetivo da análise estruturada é resolver todos
essas dificuldades, fornecendo uma abordagem sistemática,
10 para analisar e desenvolver a especificação de sistema, nova
e melhorada. Esses objetivos são alcançados, centralizando a
análise em uma comunicação clara e concisa.
A análise estruturada visa
A análise estruturada de sistemas é composta por um conjunto resolver as dificuldades geradas
nas definições de requisitos dos
de técnicas e ferramentas que está em constante evolução.
problemas de comunicação.
15 Possui como conceito fundamental a construção de um modelo
lógico de sistema, utilizando técnicas capazes de construir uma
estrutura geral do sistema, e como suas partes irão interagir para
que seja possível atender às necessidades.
9.1 Vantagens e desvantagens da análise
estruturada

Vantagens
• O usuário adquire uma visão clara do sistema proposto
20 pelo diagrama de fluxo de dados. Essa visão é melhor do
que as obtidas pelas narrativas e fluxogramas de sistema
físico.

122
MODELAGEM DE SISTEMAS DE INFORMAÇÃO

• A apresentação por meio de fluxos lógicos consegue


mostrar mal-entendidos e pontos que são controversos.
• As interfaces entre o novo sistema e o já existente são
mostradas de modo bem mais claro.

Desvantagens

5 • O grau de detalhamento necessário, principalmente na


construção do dicionário de dados.
• Orientação dos usuários e treinamento dos analistas é
necessário, pois as “regras do jogo” são mudadas com a
introdução da análise estruturada.

9.2 Diagrama de fluxo de dados – DFD

10 O DFD é uma representação dos processos de um sistema e


dos dados que ligam esses processos. Ele é capaz de mostrar o
que o sistema faz, mas não como é feito. O DFD é considerado
a principal ferramenta de modelagem da análise estruturada,
sendo utilizado para dividir o sistema em uma hierarquia de
15 processos.
O DFD possui quatro símbolos que permitem a construção
do quadro do sistema sem o comprometimento com a
implementação. Os símbolos e os conceitos que eles representam
encontram-se no nível lógico.
Simbologia do Diagrama

Processo que Depósito de Dados


transforma os
fluxos de dados

Origem e/ou Fluxo de dados


destino dos
dados

123
Análise Essencial e Estruturada

9.2.1 Técnicas de análise estruturada de sistemas

Como foi comentado anteriormente, além das ferramentas, a


análise estruturada é formada por técnicas de construção gráfica
de modelos lógicos, para sistemas de informação gerenciais.
Com isso, usuários e analistas encontraram uma solução clara
5 para que sejam transmitidas necessidades e soluções.

É apresentado um desenvolvimento que começa com o


diagrama geral do fluxo de informações, e depois é feito um
refinamento sucessivo pela construção de fluxos compostos
por informações mais detalhadas. Com isso, é permitido definir
10 “o quê” o sistema deve fazer, tornando-se muito valioso no
momento de determinar as entradas do sistema, ficando ele
bem mais flexível.

Fatores Externos

Os fatores externos são compostos por atividades ou


pessoas que interagem com o sistema, a fonte ou o destino das
15 informações.

Ex: Clientes, fornecedores, bancos, entre outros.

Outros sistemas, que fornecem dados ou informações, podem


ser considerados fatores externos.

124
MODELAGEM DE SISTEMAS DE INFORMAÇÃO

Com o intuito de evitar várias vezes o cruzamento do fluxo


de informações, os fatores podem ser repetidos no mesmo fluxo,
representado pela simbologia abaixo.

b b

Fluxo de informações

O fluxo de informações representa no diagrama uma


5 canalização por onde as informações fluem, sendo representado
por uma flecha direcionada no sentido do fluxo das informações.
A flecha também pode ser direcionada nos dois sentidos em
determinadas ocasiões.
Fluxo de dados

É interessante observar que por um mesmo fluxo podem fluir


10 vários tipos de dados, mas necessariamente esses dados não vão
fluir todos ao mesmo tempo.

Processos

Os processos são as atividades realizadas no sistema. Sua


representação gráfica é a seguinte:

Processo que
transforma os
fluxos de dados

15 Identificação: é um número atribuído ao processo para


identificá-lo.

125
Análise Essencial e Estruturada

Descrição: é uma frase precisa formada por um verbo seguido


de um objeto. Ex: “Remete cobrança atrasada.”

Localização física: nome da unidade organizacional


responsável pela atividade.

Banco de informações

5 O banco de informações é onde são gravados os dados e as


informações, representados graficamente por um par de linhas
paralelas, fechadas em um dos lados por outras linhas, formando
um quadrado do lado esquerdo. Esse quadrado é utilizado para
colocar a referência numérica para o depósito, sendo antecedido
10 pela letra “D” , e no restante é colocado o nome atribuído no
banco de informações.

Depósitos de Dados

9.3 Críticas à análise estruturada

Existem várias técnicas estruturadas avançadas disponíveis


para a fase de codificação do desenvolvimento, enquanto,
na análise, as técnicas utilizadas são menos avançadas. Com
15 isso, a análise estruturada torna-se uma metodologia inicial
e informal. Uma das melhorias a ser implantada na análise
estruturada poderia transformar um sistema de grande porte,
que com sua utilização é quase ilegível, em um gráfico de uso
fácil e legível.

20 Os defensores da análise estruturada consideram as


especificações estruturadas como um elo entre a análise e o
projeto, sendo o DFD utilizado como base para a construção
de um projeto estruturado e, finalmente, um sistema
estruturado.

126
MODELAGEM DE SISTEMAS DE INFORMAÇÃO

9.4 Onde utilizar a análise estruturada

A análise estruturada deve ser utilizada apenas em problemas


pequenos e simples, sendo o DFD a sua parte mais importante.
Para sistemas maiores e mais complexos, o DFD pode ser utilizado
apenas para esboçar uma visão de alto nível do sistema. Devem
5 ser utilizados outros métodos mais rigorosos de análise para
desenvolver uma especificação mais precisa.

10 O TAMANHO DO SOFTWARE

Uma pergunta que pode surgir sob várias formas e é feita


freqüentemente no desenvolvimento de sistemas é: “qual o
tamanho do sistema”. Para obtermos essa informação, devemos
10 analisar:

• Preço do sistema;
• Custos do sistema;
• Esforços utilizados no seu desenvolvimento;
• Equipe necessária para desenvolver o software;
15 • Tempo total para a conclusão do sistema;

127
Análise Essencial e Estruturada

• Tamanho do sistema;
• Recursos necessários.

10.1 Preços e custos

Separando em conceitos tanto preços como custos, podemos


definir:

5 • Preço: quanto se cobra para desenvolver o sistema;


• Custo: quanto se gasta para desenvolver o sistema.

Existe uma relação entre os preços e os custos do sistema. Cabe,


pois, aos responsáveis pelo desenvolvimento prever, acompanhar
e calcular os custos envolvendo não só o desenvolvimento, mas
10 também os custos de implantação, operação e manutenção do
mesmo.

A principal pergunta que deve ser feita por um desenvolvedor


é: quanto o sistema custa para ser desenvolvido. A partir deste
valor é que pode ser pensado um preço a ser cobrado.

15 Em sistemas de informação, o principal custo está ligado


à quantidade de pessoas envolvidas no seu desenvolvimento,
abordando o tempo que elas dedicam à atividade de
desenvolvimento.

10.2 Esforços e tempo de desenvolvimento

Uma das principais dificuldades da engenharia de software


20 é determinar a quantidade de profissionais necessários ao
desenvolvimento de um software. Um conceito de ESFORÇO é
utilizado para representar a quantidade de trabalho realizado,
medido por meio do trabalho de uma pessoa durante um
mês.

25 Existem alguns modelos de predicação de esforços


necessários como o COCOMO II, composto por uma equação
matemática derivada a partir de análises estatísticas de casos

128
MODELAGEM DE SISTEMAS DE INFORMAÇÃO

reais. Nele podemos calcular os esforços necessários a partir de


uma previsão do tamanho do software.

10.3 Análise de ponto de função

O esforço necessário para o desenvolvimento de um software


é uma das informações mais importantes que podemos ter
5 sobre o produto. Esse esforço é definido pela quantidade de
profissionais necessários para o desenvolvimento, e a utilização
dessas informações tem como objetivo prever e acompanhar os
esforços gastos no desenvolvimento.
O ponto de função é uma medida
Mas como saber qual o porte de um produto de software? abstrata para avaliar o tamanho de
um sistema.
10 Para solucionar esse problema, foram criadas várias medidas
como o tamanho de linhas de código, número de horas gasto no
desenvolvimento ou o custo final do mesmo.

Antigamente não tínhamos uma medida bem definida


para se calcular o tamanho de um software, em função da
15 sua funcionalidade como vista pelo usuário. Porém, em 1979,
Albrecht apresentou uma medida conhecida como ponto de
função, que servia como avaliador e preditor do tamanho de
um sistema.

O ponto de função é uma medida abstrata e relativa, que


conta o número de funções de negócios entregue aos usuários.
Como exemplo de um ponto de função, podemos citar um
simples relatório que pode medir 3 pontos de função. O ponto
de função só faz sentido se comparado com um padrão como
20 “um litro” ou “um metro”.
10.3.1 Procedimentos para contagem de pontos de
função

Para que seja possível contar os pontos de função existentes


em um sistema, devemos primeiramente identificar as funções
de negócio que são percebidas pelos usuários.

129
Análise Essencial e Estruturada

Funções transacionais

• Saídas externas;
• Consultas externas;
• Entradas externas.

Funções de dados

• Arquivos lógicos internos;


5 • Arquivos de interface externos.

Determinar Tipo
da Contagem

Identificar Escopo
e Fronteira da Aplicação

Determinar valor Contar PF Contar PF


do fator de Ajuste Transacionais para Dados

Determinar PF
não ajustado

Calcular PF
Ajustado

130
MODELAGEM DE SISTEMAS DE INFORMAÇÃO

10.4 Identificando funções de negócios

A identificação de negócios é feita por meio de documentos


que apontam as funções aprovadas pelos usuários e são úteis aos
negócios. Nesta identificação só é cobrado o que basicamente o
usuário necessita e está disposto a pagar por ela.

5 Para identificar as funções de negócios, devemos utilizar


uma certa ordem, pois se encontramos um tipo de função
de negócio, fica fácil encontrar outras de um outro tipo.
Em sistemas novos, a ordem é saídas, consultas, entradas,
arquivos e interface; em sistemas já existentes, a ordem
10 muda: arquivos em primeiro, interface, saídas, consultas e
entradas.

10.5 Qualidade das estimativas

É importante que seja verificada a qualidade de qualquer


estimativa utilizada, cuja melhor forma é a geração de alternativas
para estimar e verificar se os resultados são compatíveis. Assim,
15 é interessante verificar a estimativa apresentada por um método
com a estimativa apresentada por um segundo método, feita
por pessoas diferentes.

11 ARQUITETURA DOS SISTEMAS DE


INFORMAÇÃO

A unificação das perspectivas desenvolvidas pelo modelo


de negócio e dos sistemas de informação formam a arquitetura
20 dos sistemas de informação. O modelo de negócios permite a
discussão e compreensão, auxiliando na definição das atividades
executadas com o intuito de atingir os objetivos de uma
organização. A modelagem de negócios é fundamental para
a especificação dos sistemas de informação com suporte aos
25 modelos de negócios.

131
Arquitetura dos Sistemas de Informação

11.1 Arquitetura da informação

O termo “arquitetura da informação” é utilizado como


uma metáfora pelos especialistas que projetam os sistemas de
informação para indicar um modelo de organização abrangente
e serve para a geração e movimentação dos dados. Seus modelos
5 e metodologias baseiam-se em documentar todas as fontes de
dados importantes dentro de uma organização.

Ex:

• Clientes;
• Funcionários;
10 • Produtos.

O desenvolvimento bem definido de uma arquitetura da


informação pode estabelecer um acordo em comum entre
as informações de forma que as partes envolvidas utilizem a
informação para a tomada de decisões. Logo, sua tarefa é a
15 organização das informações dentro de um ambiente.

Objetivos da arquitetura de informações:

• Definir o espaço das informações das organizações;


• Realizar o detalhamento das análises dos fluxos de dados;
• Definir os limites críticos do espaço das informações das
organizações;
20 • Determinar o que é informação e de onde ela vem;
• Filtrar as informações. A arquitetura dos sistemas de
informação representa a estrutura
11.2 Arquitetura dos sistemas de informação dos componentes de um sistema,
seus princípios, relações e diretrizes
A arquitetura dos sistemas de informação representa a estrutura que conduzem a sua construção e
evolução ao longo do tempo.
dos componentes de um sistema, seus princípios, relações e
diretrizes que conduzem a sua construção e evolução ao longo do
25 tempo. Segundo Zachman, 1997, “a arquitetura é um conjunto de
representações que são necessárias para a descrição de um sistema,
visando a sua construção, manutenção e evolução”. Assim, chegamos

132
MODELAGEM DE SISTEMAS DE INFORMAÇÃO

à conclusão de que a arquitetura dos sistemas de informação é


importante tanto no seu projeto, modelagem, desenvolvimento,
quanto ao longo de toda a sua vida.

Com o objetivo de representar a estrutura dos componentes


5 dos sistemas de informação, suas relações, princípios e
diretrizes, a arquitetura dos sistemas de informação apresenta
o modo como os componentes são internamente construídos
e conectados, definindo as classes e objetivos fundamentais
para a sua implementação, mas deixando para segundo plano
10 as relações existentes entre os negócios.

A arquitetura dos sistemas de informação é considerada um


fator determinante no sucesso das organizações, e, para alguns
executivos, determinados fatores trazem preocupação, como:

• Capacidade de adaptação dos sistemas de informação às


15 necessidades de negócios;
• Acesso aos dados no formato adequado no momento e local
necessário;
• Dados consistentes e corretos;
• Compartilhamento de informações pela organização;
20 • Controle de custos sob um nível de sistemas de
informação.

Para resolver todos esses problemas, deve ser feita uma boa
especificação da arquitetura e, com isso, obter os seguintes
benefícios:

25 • Redução da complexidade;
• Assegurar a construção de sistemas duráveis, flexíveis que
se adaptem às necessidades dos negócios;
• Permitir a integração e o compartilhamento dos dados em
toda a organização;
30 • Alinhar os componentes tanto da tecnologia da informação
como dos sistemas de informação;

133
Arquitetura dos Sistemas de Informação

• Evolução e introdução de novas tecnologias;


• Atender às necessidades dos clientes;
• Maior eficiência no uso da tecnologia da informação.

Uma boa arquitetura permite a obtenção do balanceamento


5 correto entre a inovação, tecnologia eficiente e as necessidades
exigidas. No entanto, a definição de uma arquitetura não
fornece qualquer garantia de alinhamento entre a tecnologia
e o negócio.

11.3 Arquitetura dos sistemas

11.3.1 Sistemas centralizados

Os sistemas centralizados são executados sobre um único


10 sistema operacional, não existindo interação com outros sistemas.
Esses sistemas podem estar localizados em um computador
pessoal, em que é acessado por um único usuário, ou localizados
em um sistema de alto desempenho, como os mainframes.

11.3.2 Sistemas clientes/servidores

Nos sistemas clientes/servidores, os computadores clientes


15 (front-end) processam as aplicações, enquanto os servidores
(back-end) fornecem os serviços aos clientes.

134
MODELAGEM DE SISTEMAS DE INFORMAÇÃO

Funções de clientes e servidores:

Funções do cliente:

• Gerenciar a interface do usuário;


• Processar a lógica da aplicação;
• Impor regras de negócios;
• Gerar solicitações;
5 • Receber os resultados que são enviados pelo servidor;
• Formatar os resultados recebidos.

Funções do servidor

• Aceitar as solicitações enviadas pelos clientes;


• Processar as solicitações;
• Formatar os resultados e transmiti-los aos clientes;
10 • Impor regras de negócios;
• Realizar verificação de integridade;
• Fornecer o controle de acesso;
• Fornecer serviços de segurança.

Na arquitetura cliente/servidor, o programa de aplicação é


15 instalado na máquina cliente, e o aplicativo existente na máquina
servidora é responsável pelo recebimento das solicitações de
processamento da aplicação.

A arquitetura dos sistemas de informação tem um papel


preponderante no alinhamento entre as realidades dos negócios,
20 da tecnologia da informação e sistemas de informação de uma
organização.

135

Você também pode gostar