análise estruturada de sistemas -...

Prof. Marcel Neves [email protected]

Análise estruturada de sistemas

Prof. Marcel


O que é Engenharia de software

� Engenharia de software é uma área do

conhecimento da computação voltada para a

especificação, desenvolvimento e

manutenção de sistemas de software

aplicando tecnologias e práticas de gerência

de projetos e outras disciplinas, objetivando

organização, produtividade e qualidade.


Engenharia de Software

� Atualmente, essas tecnologias e práticas

englobam linguagens de programação, banco

de dados, ferramentas, plataformas,

bibliotecas, padrões, processos e a questão

da Qualidade de Software.



� Os fundamentos científicos para a

engenharia de software envolvem o uso de

modelos abstratos e precisos que permitem

ao engenheiro especificar, projetar,

implementar e manter sistemas de software,

avaliando e garantindo suas qualidades.



� A engenharia de software deve oferecer

mecanismos para se planejar e gerenciar o

processo de desenvolvimento de um sistema

de informação e Sistema computacional, pois

ambos se confundem!

Necessidades

� Necessidades em análise de sistema é

caracterizada por um conjunto de coisas que

uma organização precisa para resolver um

determinado problema.

� A necessidade deve ser levantada pelo

analista de forma precisa e com o maior

número de detalhes possíveis.


Análise de sistemas estruturada

� A análise estruturada nada mais é como um

método de análise de requisitos de software,

é uma atividade de construção de modelos.

� O sistema é dividido em partições funcionais

e comportamentais e assim descrever a

essência daquilo que será construído.



� Esse método é um dos processos de

engenharia de software que mais destaca-se

dentre os profissionais de T.I.

� Na análise estruturada o analista de sistemas

utiliza por uma representação gráfica

formada por símbolos que permitem criar

modelos de fluxo de informação.



� Quando falamos em análise estruturada de

sistemas é de grande importância

conhecermos o ciclo de vida básico que

rege tal metodologia.



� O ciclo de vida básico da análise estruturada

é composta por:� Concepção do software� Estudo de viabilidade� Projeto lógico� Projeto físico� Implantação� Manutenção



� Concepção de software

Uma vez que o analista de sistemas levantou

todas as necessidades da organização, sua

principal função é criar soluções que

atendem diretamente aos problemas obtidos

no levantamento de dados.



� Por tratar-se de uma fase de grande

importância para o analista, podemos utilizar

três passos que devem nortear as atividades

do analista de sistemas.

1. O que há de errado com a situação atual?

2. Que melhorias são possíveis ser realizadas?

3. Quem serão as partes afetadas pelo sistema?



Em termos gerais o fato que obriga a uma

organização a sentir a necessidade de ter um

sistema de informação em seu ambiente é por 2

motivos principais:

�Necessidades de estratégias gerenciais,

ou seja, melhoria em seus processos internos

afim de ganhos de mercado.



� A existência de “Frankensteins”

espalhados em seus ambientes, ou seja,

tecnologias diferentes para resolver

problemas diferentes.

Esse é um dos principais problemas que nós

Analistas de sistemas podemos encontrar em

uma organização.



� Estudo de Viabilidade

O estudo de viabilidade é o processo de

comparação e escolha entre soluções

previamente elaboradas, sendo baseadas nos

levantamento de requisitos.



O estudo de viabilidade divide-se em três

etapas:

�Análise de Viabilidade Técnica – serão

avaliados os recursos técnicos disponíveis,

próprios ou não, que podem viabilizar as

soluções que estão sendo analisadas.

(hardware, software, peopleware)



� Viabilidade Econômica – para as possíveis

soluções, tecnicamente disponíveis e

utilizáveis, será verificado o montante

financeiro a ser empregado.



� Viabilidade Operacional – aspectos das

soluções que implicarão mudanças de rotinas

existentes ou a serem criadas e seus

impactos na organização e sociedade.



� O estudo de viabilidade deve ser apresentado

e discutido com o cliente. Partindo do

principio que o projeto será colocado em

prática cabe ao analista de sistemas ou

responsável pelo projeto iniciar a próxima

etapa.



� Projeto Lógico

No processo lógico é o momento de redefinir e

confirmar alguns processos já levantados em

fase anterior, através de tal etapa o analista

inicia o processo de detalhamento utilizando

como ferramenta de auxílio o DFD (Diagrama

de Fluxo de Dados).



� Na construção do DFD é de grande

importância que o contato analista e usuário

seja frequente, afim de esclarecer detalhes e

conhecer melhor o processo da organização.



� No processo de analise podemos elencar três

tipos de usuários, onde cada qual tem uma

certa atuação perante o processo, são eles:

� Usuário que põe a mão na massa;

� Usuário chefe;

� Usuário dono.



� DFD tem por finalidade retratar todos os

processos existentes na organização,

transformar algo abstrato em solução que

deverá resolver algum tipo de problema da

empresa.

� O diagrama de fluxo de dados será estudado

mais a fundo em outra etapa da matéria.



Projeto Físico

�Após o estudo e desenvolvimento do projeto

lógico o analista passa a se preocupar com o

hardware e software que serão utilizados, no

decorrer do projeto.



� Nessa etapa também tem que se preocupar

em transformar todo o planejamento

realizado pelo DFD em algo real e concreto,

ou seja, criar o banco de dados, desenvolver

o programa, testar, implementar, implantar,

etc.



Implantação

�É uma das fases mais complexas além da

programação, pois é neste momento em que a

tecnologia deverá ser implantada no ambiente

da empresa, permitindo assim ao usuário

começar a utilizar parte da solução.



� A fase de implantação deve ser muito bem

gerenciada, já que trata-se de um momento

onde o usuário poderá solicitar, ou até

mesmo estar faltando coisas que o mesmo

não visualizou no momento do

levantamento, tal situação tem que ser

muito bem tratada para prejudicar o projeto.



Manutenção

�Fase destinada a ajustes, incrementos e

correções do projeto, tal etapa não deve ser

temida, pois é algo normal e deve acontecer

afim de melhorar e aprimorar a tecnologia,

porém deve ser gerenciada.


Processo de comunicação

� O objetivo principal é garantir a geração

adequada e apropriada, coleta,

disseminação, armazenamento e disposição

final das informações. Consiste do

planejamento da comunicação, distribuição

da informação, relatório de acompanhamento

e encerramento administrativo. (PMI, PMBok)



� Quais problemas podemos citar por falhas no

processo de comunicação em um projeto?

� Como podemos mitigar esse problema?



� A comunicação hoje é um dos principais

agentes que podem influenciar o sucesso de

um projeto. Desde o momento em que o

analista necessita levantar qualquer tipo de

dados perante o cliente até no momento em

que estamos gerenciando o processo de

trabalho e interagindo com os stakeholders.



� O momento mais crítico para o

desenvolvimento de um projeto (sistema) é

no levantamento de dados e informações.

Muitos analistas pecam por não terem

processos de comunicação bem definidos,

podendo assim gerar muitos prejuízos ao

Tempo, Custo e Escopo do projeto.



� Outro momento crítico do projeto é o

momento de gerenciar as comunicações

durante a execução do projeto, por exemplo

quando acontece uma mudança de escopo,

fato esse que precisa ser muito bem

estruturado como deverá acontecer no

decorrer do projeto.



� Reuniões são de extrema importância para a

alinhar e até mesmo levantar diagnósticos

sobre como o projeto esta com relação ao

planejado.

O bom analista ou gerente de projetos deve

sempre ter meios de comunicação bem

estruturados com os membros da sua

equipe. Prof. Marcel Neves [email protected]

Análise de Requisitos

� Fora o fato da não adoção dos critérios de

engenharia para desenvolver-se um

software, os requisitos estão associados aos

principais problemas que envolvem

atualmente a área.


� A etapa Análise de Requisitos também pode

ser conhecido por “levantamento de dados”,

“coleta de informações” e “análise de

domínio de problema”.

� Essa etapa torna-se fundamental para o

sucesso de um projeto.


� A análise e especificação de requisitos de

software envolve atividades que

determinarão os objetivos de um software e

as restrições associadas a ele. Nesta etapa

deve-se também estabelecer o

relacionamento entre os objetivos e

restrições do software, para uma precisão.


� A análise de requisitos é uma das primeiras

atividades da analise de sistemas, podendo

se estender após a laboração do documento

de especificação do sistema e do

planejamento do desenvolvimento.


� Quando falamos em analise podemos

entender que é justamente o processo de

observação e levantamento dos

elementos de domínio no qual o sistema será

introduzido.


� Nunca devemos esquecer que a análise de

requisitos é a descrição sistemática e

abstrata do que o software deve fazer a

partir daquilo que foi analisado.


� Os requisitos compõem o conjunto de

necessidades estabelecidas pelo

cliente\usuário do sistema que definem a

estrutura e o comportamento do software

que será desenvolvido.


� Com o processo de requisitos podemos ter

dados, processos, e as restrições existentes

de acordo com o negócio, as pessoas

envolvidas e o relacionamento entre todas

essas coisas.


� Basicamente os requisitos deverão

determinar a capacidade de um software:

� Permitir que o usuário resolva problemas

inerentes ao negócio da empresa;

� Atender as necessidades ou restrições da

organização ou dos outros componentes

do sistema


� No processo de levantamento de requisitos,

observa-se que existirão duas abordagens a

serem consideradas: requisitos diretos e

requisitos indiretos.


Requisitos diretos ou Funcionais

� Basicamente referem-se a descrição das

diversas funções que clientes e usuários

querem ou precisem no software, ou seja,

define-se pela funcionalidade, funções, ações

ou operações que a tecnologia deverá

oferecer.


� A especificação de um Requisito Direto ou

Funcional deve prever o que se espera que

um software realmente execute, sem a

preocupação de como será construído.


Requisitos Indiretos ou não Funcionais

� Referem-se as qualidades globais de um

software, como a fácil manutenção que deve

ser proporcionada, a segurança, a facilidade

de uso, desempenho e o baixo custo. Em

geral é difícil conciliar dois recursos indiretos.


� A definição de requisitos torna-se

extremamente crítica à medida que o

tamanho e a complexidade do software

aumentam.


� A boa análise de requisitos deve envolver a

documentação das funções, do desempenho,

interfaces externas, internas e atributo de

qualidade do software.


Benefícios da análise de requisitos

� Entendimento comum entre

desenvolvedores, clientes e usuários sobre o

trabalho a ser feito e quais os critérios de

aceitação do sistema.

� É possível ter uma base sobre estimativas de

recursos (custo, pessoal, prazos, etc.)


Benefícios da análise de requisitos

� Melhoria na qualidade do software que será

desenvolvido.

� Objetivo traçado de maneira a gerar menor

índice de manutenção decorrente de erros de

levantamentos de informação.


Para atingir os itens acima, o levantamento de

requisitos deve ser:

� Clara e não ambígua

� Completa

� Correta

� Consistente

� Concisa

� Confortável


Principais meios para a execução do

levantamento de requisitos

� Aplicação de questionários – A uniformidade

de questões pode ser um fator negativo para

utilização de recursos, embora seja um meio

rápido e barato de obtenção de informação.




� Verificação de documentos utilizados no

processo – normalmente a inspeção de

documentos manipulados pelo processo é

uma atividade necessária, porém

complementar.


A checagem de documentos leva a constatar os

dados utilizados ou não nos processos. É

comum a existência de documentos

prevendo inúmeros campos cujo

preenchimento nunca ocorreu, porém

podemos ter o inverso. Muitas vezes os

usuários não lembram-se de alguns detalhes.




� Cenários participativos – A busca de

informação sobre requisitos envolve alguns

problemas: o usuário em geral sempre tem

uma visão parcial sobre os processos.


Muitas vezes o usuário até mesmo de forma

inocente omite informações que seriam

importantes para o projeto, por este motivo

esse processo acaba sendo árduo e

desgastante. Os cenários participativos

envolve conceitos como “brainstorme”.




� Entrevistas – A utilização de entrevistas deve

ser objetiva e sempre visar o máximo de

informações possíveis sobre o assunto de

interesse.




� Observação in loco – Estar presente

acompanhando as atividades por parte dos

clientes e conjunto da entrevistas realizadas

com os usuários ajuda e muito para

minimizar possíveis erros no sistema.


Um dos principais objetivos deste item é

verificar se tudo o que o usuário passou

realmente é verídico.


Documentação

É o fato de reunir todas as informações

levantadas nos itens anteriores em um único

documento a fim de deixar registrado as

características do projeto. (buscar

modelos)

Diagrama de Fluxo de Dados

Diagrama de fluxo de dados é uma das mais

usadas ferramentas de modelação funcional de

sistemas.

Um DFD pode ser entendido como uma rede

que ilustra como circulam os dados no interior

de um sistema.Prof. Marcel Neves [email protected]


Sinonimos:

�DFD

�Diagramas de bolhas (ou bolas);

�Modelo de processos (ou de funções);

�Diagrama de fluxo de trabalho.



Componentes de um DFD

Os DFD baseiam-se no princípio de que a

funcionalidade de um sistema pode ser

representada como uma rede que combinam 4

componentes fundamentais; a saber:



Processos (ou bolhas ou bolas)

Transforma os fluxos de entrada em fluxos de

saída. Cada processo tem um nome e um

número único.

Usar sempre um verbo

+

o seu objetivoProf. Marcel Neves [email protected]


Arquivos

Reservatórios ou contentores para os dados

existentes no sistema (ficheiros, pastas de

documentos, bases de dados).Cada arquivo tem

um nome único.



Entidades exteriores

Fornecem entradas ao sistemas (fontes) ou

recebem dados do sistema (terminadores).



Fluxo de dados

Modelam a passagem de dados. A seta indica o

sentido do fluxo e tem o nome do fluxo

associado.



Convenções adicionais

O cruzamento de linhas de fluxos deve ser minimizado.

Quando o cruzamento for inevitável, fazer o seguinte:



O mesmo arquivo poderá ser desenhado mais

do que uma vez.

A mesma entidade poderá ser desenhada mais

do que uma vez. Exemplos:



Existem algumas diretrizes adicionais necessárias para

utilizar DFD com sucesso.

Algumas dessas diretrizes o auxiliarão a não construir

DFD incorretos e algumas outras destinam-se a ajudar a

desenhar DFD agradáveis à vista e portanto com mais

possibilidade de serem examinados com atenção pelo

usuário.



As diretrizes são as seguintes:

�Escolher nomes significativos para os processos, fluxos, depósitos e

terminadores.

�Numerar os processos.

�Refazer o DFD tantas vezes quantas forem necessárias até obter uma

boa estética.

�Evitar DFD complexos demais.

�Certificar-se de que o DFD seja internamente consistente além de

manter a consistência com os outros DFD.



Exemplo de DFD 01:


Preparar

Bolo

Bolo

Mistura para

Bolos

Ovos

Leite


Exemplo de DFD 02:


Validar Número

de telefone

Número-de-

telefone-válidoNúmero de

Telefone

Número-de-

telefone-inválido


Exemplo de DFD 03:


Processar

Pedido

dados de clientePedidosCliente

Clientes

Dados do pedido

Dados dos livros

Faturas com pedidos

Livros

Pedidos

Transformação das

informações

Depositando informações

Consultando informações

Exercícios

Desenvolver um DFD para cada enunciado

abaixo:

1- Um funcionário é responsável pelo registro dos novos clientes

de sua empresa, antes de realizar a inclusão do mesmo,

verifica-se junto a receita federal a existencia de restrições em

seu CPF, caso não haja problemas o registro do novo cliente é

realizado com sucesso.


Exercícios

Desenvolver um DFD para cada enunciado

abaixo:

2- O caixa de um banco recebe cheques para ser decontados.

Ele verifica na ficha do cliente se existe saldo antes de realizar a

compensação do cheque, caso a resposta seja afirmativa o

mesmo entrega a quantia ao cliente.


Exercícios

3- Os professores de uma determinada escola realizam a

passagem das 4 notas dos alunos para a secretaria. A secretaria

realiza o cálculo da média da nota de cada um e assim

transcreve para a ficha individual de cada aluno. Quando aluno

solicita sua média junto a secretaria a mesma realiza uma

consulta em seus arquivos e através de uma papel de anotações

a nota é entregue ao aluno.


Exercícios

4- Um cliente chega em uma loja e solicita ao atendende um

determinado produto, antes que o atendente realize a venda o

mesmo desloca-se ao seu estoque principal e verifica se existe o

determinado produto, caso haja em seu ambiente, o mesmo

realiza a verificação dos dados do cliente, emite o pedido de

venda e após realizar a entrega o produto finaliza o processo

emitindo a nota fiscal da venda. Por fim realiza a baixa de seu

estoque através de um documento que controla as entradas e

saídas do setor.


Exercícios

5- O clube de vídeo ABC tem 1500 sócios. Cada vez que um

sócio quer requisitar um filme, após escolher, deve dirigir-se ao

balcão indicando o número de sócio e o(s) nome(s) do(s)

filme(s). O balconista verifica se existem as fitas disponíveis e

em caso afirmativo as entrega juntamente com uma cópia da

requisição. O original fica guardada no clube. De acordo com o

número de filmes o cliente paga a quantia respectiva. Quando o

filme for devolvido verifica-se o prazo de entrega pagando uma

multa quando for excedido.


análise estruturada de sistemas -...

Documents