Aula 5 – Análise de Projetos de Sistemas

1

Curso de Gestão da TI

Análise de Projetos de Sistemas

Prof. Flávio Barbosa

02/09/2009

2

Módulo 4.1

Aula 5

Análise Estruturada de Sistemas

3

AGENDA• Técnicas para levantamento de

requisitos ou Técnicas de Elicitação

(aula 4)• Modelo Ambiental• Modelo Comportamental• Dicionário de Dados

4

O processo de definição de requisitos pode ser definido, resumidamente, por três atividades: elicitação, modelagem e análise.

PROCESSO DE DEFINIÇÃO DE REQUISITOS

(Leite, 1988)UdI = Universo de Informações

5

TÉCNICAS PARA LEVANTAMENTO DE REQUISITOS

ANÁLISE DE REQUISITOSANÁLISE DE REQUISITOS

R1

R2R3 R4

R5Rn

Elicitar: é o nome usual dado às atividades envolvidas na descoberta dos requisitos de um sistema. Kotonya e Sommerville (2000)

6


R1

R2R3 R4

R5Rn

COMO LEVANTAR (ELICITAR) REQUISITOS?


7


R1

R2R3 R4

R5Rn

RESPOSTA: UTILIZANDO TÉCNICAS!


8

TECNICAS DE ELICITAÇÃO ENTREVISTA FECHADA:

O analista de sistemas (engenheiro de requisitos)

busca respostas para um conjunto pré-

determinado de questões.

ENTREVISTA ABERTA:

O analista de sistemas discute

livremente, sem ter questões pré-determinadas,

o que o usuário precisa (espera).

Kotonya, 1998

9

NO MOMENTO DA ENTREVISTA:

“Cabeça aberta”, aceitar os requisitos, estar

livre de pré-conceitos.

Explicar o motivo da entrevista, de onde e

para onde ela será conduzida.

Possuir conhecimento da política

organizacional para que os requisitos

realmente possam ser aceitos.

TECNICAS DE ELICITAÇÃO

10

QUESTIONAMENTOS PRINCIPAIS:

- O que?

- Por quê?

- Para quem?

- Como?

- Quando?

- Onde?

HUMILDADE É IMPORTANTE

HUMILDADE É IMPORTANTE


11

QUESTIONÁRIOSDeve ser usado quando um conjunto de

questões deve ser dirigido a um conjunto de

usuários (clientes).

Permitem analisar estatisticamente

as respostas formando a percepção

de um Universo de Informações (UdI).

A desvantagem é a diminuição de

interação com o usuário (cliente).


12

JAD (Joint Application Development ):

Reunir (utilizadores) autoridades representativas e

gerenciais juntas dentro de um workshop

estruturado para promover decisões.

Embora as sessões de JAD sejam proveitosas existe

a dificuldade em reunir os participantes devido a

importância dos mesmos

para organização.

Bastante formal.


13

Constituição de um JAD (Joint Application

Development ):

FACILITADOR AGENDA DETALHADA

FACILIDADES VISUAIS DOCUMENTADOR

SESSÃO DE JAD COM OS USUÁRIOS SESSÃO DE JAD COM OS USUÁRIOS (tático e estratégico)(tático e estratégico)

SESSÃO DE JAD COM OS USUÁRIOS SESSÃO DE JAD COM OS USUÁRIOS (tático e estratégico)(tático e estratégico)

RELATÓRIO COM DECISÕES FINAIS DOCUMENTADAS


14

CRC (Cooperative Requiriments Capture): É uma sessão de grupo, similar ao JAD, onde os

usuários não são apenas do nível tático e estratégico ou representantes significativos da organização, mas sim, usuários operacionais e outros envolvidos com o sistema.

Formalidade mínima

(ata da reunião e os

requisitos elencados,

basicamente)


15

CENÁRIOS: Projeções de como o sistema poderia

funcionar ou ser utilizado. Deve existir uma descrição do

funcionamento e uso atual do sistema

antes de se propor o novo cenário

(projeção) Formalidade mínima (ata da reunião

e os requisitos elencados,

basicamente)


16

OBSERVAÇÃO:

Algumas vezes os utilizadores não conseguem

definir como é a sua rotina de trabalho, para esses

casos, é necessário ir até o local e observar a

rotina de trabalho.

Adicionalmente, é possível haver uma

inversão de papéis, onde o analista

assume a rotina do utilizador para

identificar os problemas (requisitos).


16

17

REUSO DE REQUISITOS:

É a reutilização de um requisito que

está bem especificado (definido),

documentado e validado como

requisito em outra parte do SI.

Analistas de negócio utilizam

bastante essa técnica, mesmo

que informalmente.


18

PROTOTIPAGEM:

Protótipos descartáveis são os mais utilizados para

o levantamento de requisitos.

Eles proporcionam para o

usuário a visão do sistema.

Não é raro ajudarem no

descobrimento de requisitos

muitas vezes ocultos até

mesmo do usuário.


19

O processo de definição de requisitos pode

ser definido, resumidamente, por três

atividades: elicitação, modelagem e análise.

PROCESSO DE DEFINIÇÃO DE REQUISITOS

(Leite, 1988)UdI = Universo de Informações

20

É um conjunto de técnicas e ferramentas

que tem por objetivo ajudar na análise e

na definição dos SI. Sua finalidade é construir um modelo do

SI utilizando técnicas gráficas (círculo,

retângulo, losango, etc). Utiliza metodologia “top-down” por

refinamentos sucessivos.

ANÁLISE ESTRUTURADA DE SISTEMAS

21

Do processo de levantamento de

requisitos anterior até um análise

estruturada o Modelo Essencial ou Lógico

deverá ser constituído.

O modelo lógico indica “o que” o sistema

deve fazer para satisfazer os requisitos dos

utilizadores;


22

Neste nível o mínimo possível sobre

“como” ele deve ser construído e

implementado deve ser mencionado.

Existem ferramentas (CASE) que “olham”

o modelo lógico e geram o modelo físico

(banco de dados).


23

O modelo lógico se divide em:

Modelo ambiental

Modelo comportamental

Dicionário de Dados


24

O modelo lógico se divide em:

Modelo ambiental: Define a fronteira entre o

sistema e o seu ambiente externo.

Dicionário de Dados: É uma listagem

organizada de todos os elementos (termos)

de dados do SI.


25

Modelo comportamental:

É composto por uma descrição detalhada

dos propósitos do SI. Exemplos:

Diagramas de fluxos de dados (DFD);

Especificações de processos ;

Diagramas de entidades-relacionamentos

(DER);

Diagramas de transição de estados (DTE).


26

Os Diagramas de Fluxo de Dados (DFD) são

constituídos de:

Processos;

Fluxo (entrada, saída, diálogo e

divergente);

Depósito;

Terminador.

DIAGRAMA DE FLUXO DE DADOS - DFD

27

Processos:

Representado por uma elipse.

Possui um nome associado

Nome: verbo mais objeto associado

Representa uma tarefa a ser realizada

Exemplos de processos:

Calcular Salário

Receber Pedidos

Emitir Relatório


28

Fluxo:

Representado por uma seta

A seta entra ou sai de um determinado

processo.

Representa como dados

fluem entre processos;

Rotulados com o tipo da

informação que levam.

Período do

Relatório

Ler Período

Emitir Relatório


29

Consulta SituaçãoResposta sobre situação

Fluxo de Saída:

Ler Período

Verificar Pedido

Fluxo de Diálogo:

VerificarSituação

Período do Relatório


30

Fluxo Divergente:

Endereço docliente

CEP

Cidade

Rua

VerificarRua

VerificarCidade

VerificarCEP


31

Depósito:

Representa um conjunto de dados

armazenado;

Nome: Plural do valor armazenado

Exemplos:

Livros Leitores


32

Terminador:

Representam entidades externas ao SI.

Sistema Financeiro

Recepcionista


33

Diretrizes para elaborar um DFD:

Escolha nomes significativos;

Refazer DFD’s até obter boa estética;

Evitar DFD’s complexos

Uso de níveis em DFD’s

Diagrama de contexto

Verificar consistência interna e externa.


34

Reunam-se em duplas!

Construam o seguinte DFD para um Hotel:

ATIVIDADE

Requisitos:

Clientes podem reservar e cancelar reservas

Cancelar reserva caso cliente não venha

Registrar um cliente que fez uma reserva

Totalizar a conta de um cliente

Liberar o quarto para novas reservas após a saída

35

RESPOSTA

Algo semelhante ao DFD abaixo:

http://www.din.uem.br/~itana/esi-informatica/exemplo%20DFD-Thelma.pdf

36

DFD em nível 0:

RESPOSTA


37

Refinamento do processo P1

RESPOSTA


38

Refinamento do processo P1.1

RESPOSTA


39

Tema 6 – ANALISE ORIENTADA A OBJETOS

Modelo funcional

Modelo estrutural

Modelo Comportamental

O que veremos na próxima aula:

Não se esqueçam de:

Ler o material didático

Participar das atividades do portal

40

Curso de Gestão da TI

Obrigado!

Nos vemos em nossa plataforma.

Prof. Flavio Barbosa

41

Visite o site e avalie a aula.

Utilize seu código e senha de aluno.

http://www.inepad.org.br/interativacoc/

Documents

Aula 5 – Análise de Projetos de Sistemas