aula02-Introdução a AnaliseSistema e participantes do processo

(1)

Análise de Sistema

Aula 02

21-02-2013

Prof.ª Marina Laís

prof.marinalais@gmail.com

(2)

ANÁLISE DE SISTEMAS

CONCEITOS E TÓPICOS RELACIONADOS A ANÁLISE DE SISTEMAS

(3)

CONCEITO DE ANÁLISE

Exame detalhado de cada parte de um todo

(4)

CONCEITO DE SISTEMA

Combinação de elementos relacionados entre si

(5)

DESENVOLVIMENTO DE SISTEMA

Análise Estruturada

________________________________________________ Necessidade

do usuário Concepção _{do Sistema} Análise de _viabilidades Projeto _lógico

Projeto físico Implantação

(6)

NECESSIDADES DO USUÁRIO/CONCEPCÃO DO SISTEMA

Análise Estruturada – Algumas Técnicas de Levantamento de Dados ________________________________________________

(7)

CONCEPÇÃO DO SISTEMA – IDENTIFICAÇÃO DE ENTIDADES Aluno Pedro Aluna Maria Professor João Professora Rita

Entidade é um objeto distinguível de outros, cada entidade possui uma característica que lhe é peculiar, que nem uma outra possui

________________________________________________ entidades Conjunto de entidades Coleção de conjuntos de entidades

(8)

ANÁLISE DE VIABILIDADES

0 10 20 30 40 50 60 70 80 curto prazo médio prazo longo prazo gastos resultados

Análise Estruturada – Viabilidades Técnicas e Econômicas ________________________________________________

(9)

PROJETO LÓGICO

Análise Estruturada – Dicionários de Dados, DFD, MER/DER, ________________________________________________ DICIONÁRIO DE DADOS CAMPOS TIPO TAMANHO OBSERVAÇÃO DESCRIÇÃO ENTIDADE _PROCESSO ARMAZENAMENTO FLUXO DE DADOS DFD RELACIONAMENTOS Um para Um (1__1); Um para Vários (1__N); Vários para Vários (N__N).

(10)

PROJETO LÓGICO

EXEMPLO DE DICIONÁRIO DE DADOS

CAMPOS TIPO SIZE DESC OBS

CodProduto N 06 Código do produto Chave primária Nome C 50 Nome do produto

CodGrupo N 06 Código do grupo Chave estrangeira CodFornecedor N 06 Código do fornecedor Chave estrangeira Qtde N 10 Quantidade

QtdeMinima N 10 Quantidade Miníma CustoMedio N 10 Preço de custo

PrecoVenda N 10 Preço de venda DataReg C 10 Data de registro

Análise Estruturada – Dicionários de Dados de um Cadastro de Produtos ________________________________________________

(11)

PROJETO LÓGICO - EXEMPLO DE DER

vários para vários (relação indireta) um para vários

(relação direta)

um para um (relação direta)

(12)

ESTUDO DE CASO

Técnica de análise através da

qual se descreve a relação entre

usuário e sistema, onde para

cada ação do usuário existe

(13)

ESTUDO DE CASO - REGRAS

Algumas regras, se bem observadas, podem facilitar o desenvolvimento de um estudo de caso, dentre as quais destacam-se:

Para cada ação existe uma reação;

Detalhes são apenas partes de um todo;

Dados são apenas parte de uma informação; Inteiração se dá pela desfragmentação;

(14)

ESTUDO DE CASO - EXEMPLO

Um exemplo simplificado de estudo de caso:

USUÁRIO SISTEMA

Usuário clica em incluir novo registro

Sistema exibe formulário para digitação dos dados. Usuário clica em salvar

dados

Sistema salva dados e retorna mensagem “dados salvos com sucesso”

(15)

ESTUDO DE CASO - ATIVIDADE

Utilize algum jogo de raciocínio que

contenha os elementos básicos de

um estudo de caso para aprimorar

(16)

ESTUDO DE CASO

Para cada ação existe uma reação

Em um estudo de caso, não se deve

analisar ações e reações de formas

isoladas, pois cada resposta do

sistema depende de uma ação do

usuário e cada ação implica em

uma resposta

(17)

ESTUDO DE CASO (Para cada ação existe uma reação)

Assim como ocorre em nosso cérebro, sistemas computadorizados podem dar respostas indesejadas se as ações e reações não estiverem bem

(18)

ESTUDO DE CASO

Detalhes são apenas partes de um todo

Um verdadeiro analista de sistemas é

aquele que tem a capacidade de “ver a

floresta por entre as árvores”, ou seja,

aquele que consegue observar os

detalhes sem se perder neles,

conservando uma visão do todo.

(19)

ESTUDO DE CASO (Detalhes são apenas partes de um todo) A paisagem representa o todo – observe os detalhes

(20)

ESTUDO DE CASO

dados são apenas partes de uma informação

Não se pode compreender inteiramente uma informação analisando-se individualmente os dados que a compõe, a

compreensão se dá pelo entendimento conjugado dos dados e a forma como estes foram organizados.

(21)

ESTUDO DE CASO

Inteiração se dá pela desfragmentação

Um raciocínio fragmentado pode

dificultar a elaboração de um

estudo de caso, pois muitas vezes

é necessário aproximar dados

que, disjuntos, não propiciam o

entendimento necessário a

inteiração de um problema.

(22)

ESTUDO DE CASO

Inteiração se dá pela desfragmentação

Considere os seguintes fatores:

Não se pode acreditar em tudo que olhos vêem; A sistematização do conhecimento se dá por um

processo de análise;

A falta de critérios em um processo de observação pode resultar em interpretações equivocadas.

O mesmo objeto de estudo pode ser percebido de diferentes maneiras;

(23)

ESTUDO DE CASO (Inteiração se dá pela desfragmentação) Não se pode acreditar em tudo que os olhos vêm

O tabuleiro ao lado

representa um conjunto fragmentado de

informações, pois os

quadrados escuros estão separados pelos claros e vice-versa.

Analise-o e responda se existe muita diferença entre a cor do quadrado A e a cor do quadrado B

Dica: edite a imagem, recorte os dois quadrados e aproxime-os para fazer uma análise.

(24)

ESTUDO DE CASO (Inteiração se dá pela desfragmentação)

A sistematização do conhecimento se dá por um processo de analise

A falta de critérios em um processo de observação pode resultar em interpretações equivocadas Uma simples desfragmentação pode mudar a visão que se tem das

(25)

O mesmo objeto de estudo pode ser percebido de diferentes maneiras;

Observe a foto ao lado e

tente descobrir quem aparece nela:

Um cientista?

Um personagem de filme?

Lembre-se:

“Todo ponto de vista é vista de um ponto”

(26)

O mesmo objeto de estudo pode ser percebido de diferentes maneiras;

Descreva o que aparece na foto ao lado.

Lembre-se:

“Todo ponto de vista é vista de um ponto”

(27)

Participantes do Processo de

Desenvolvimento de Software

(28)

Participantes do Processo de

Desenvolvimento de Software

• Usuários • Gerentes • Auditores • Analistas de Requisitos • Arquitetos de Software • Programadores • Testadores • Analistas de Suporte • Pessoal de Operação

(29)

Usuários

• Participantes mais importantes do processo de desenvolvimento de

software.

• _{Grupo de pessoas para o qual o} sistema é construído;

– utilizará o sistema desenvolvido.

• _{Sistema surge da solicitação formal de} seus futuros usuários.

(30)

Usuários

• _{O analista de requisitos deve realizar} entrevistas/reuniões;

– diretamente com os futuros usuários do sistema;

• sob pena de não conseguir especificar

adequadamente os requisitos desse sistema.

– Intermediários podem não conhecer os verdadeiros requisitos do sistema.

• Após as entrevistas/reuniões, é aconselhável que o analista de requisitos produza

(31)

Tipos de Usuários

• Por tipo de função:

– Usuário Operacional – Usuário Supervisor – Usuário Executivo

• _{Por nível de experiência em} tecnologia da informação:

– Amador

– Novato “Arrogante” – Familiarizado com TI

(32)

Usuários Operacionais

• _{Normalmente, terão contato diário com} o sistema;

– irão operar o sistema.

• _{Preocupados com aspectos relacionados} às:

– interfaces de usuário (telas e relatórios);

• visão física do sistema;

– têm, em geral, dificuldades para realizar abstrações;

(33)

Usuários Supervisores

• _{Gerenciam um grupo de usuários} operacionais;

– sendo responsáveis por seu desempenho.

• _{Usuários de nível gerencial.}

• Muitas vezes, são os intermediários entre o analista de requisitos e os usuários operacionais.

(34)

Usuários Supervisores

• _{Nem sempre conhecem bem o trabalho} dos usuários operacionais;

– e as tarefas que o sistema deve contemplar.

– Podem ou não ter visão local do sistema.

• _{Supervisores e usuários operacionais} podem ter objetivos diferentes.

– Supervisores podem ter como objetivo: • redução do número de usuários operacionais;

• aumento, com o sistema, da produtividade de seu setor.

(35)

Usuários Executivos

• Visão global e abstrata.

• Preocupações estratégicas;

– e de longo prazo.

• Na maioria das vezes, nunca foram usuários operacionais;

– não conhecem detalhadamente a

operação do sistema;

• não definem requisitos;

(36)

Usuários Executivos

• _{Dão suporte ao projeto.}

• Representam a autoridade financeira do projeto.

(37)

Gerentes de Projetos

– Responsáveis pelo projeto de desenvolvimento

do sistema;

» pela alocação de recursos de toda a equipe técnica no desenvolvimento desse sistema.

– Interface do projeto.

– Em geral, para cada projeto há um gerente de

projeto:

» na organização desenvolvedora de software; » e outro na organização cliente.

(38)

Outros Gerentes

• Definem: – objetivos; – prioridades; – prazo; – orçamento.

• Pode haver conflitos entre os diversos níveis gerenciais.

• _{Decidem sobre a continuidade;}

– ou interrupção do projeto de desenvolvimento do sistema.

(39)

Auditores

• _Compreendem:

– auditores internos; – auditores externos;

– grupo de garantia da qualidade.

• Identificam problemas.

• _{Devem ter postura isenta e imparcial.} • _{Garantem o desenvolvimento dos}

sistemas de acordo com padrões:

– externos;

(40)

Analistas de Requisitos

• _{Especificam o problema dos usuários.} • _{Atuam como mediadores;}

– entre os diversos participantes de um projeto.

• _{Devem possuir:}

– aptidões interpessoais;

– conhecimento de tecnologia; – raciocínio lógico e abstrato; – criatividade;

(41)

Analistas de Requisitos

• Em um projeto de desenvolvimento de sistema, os analistas de requisitos lidam com diferentes pessoas.

• _{Devem ficar atentos se:}

– a linguagem utilizada é familiar a essas pessoas;

– os modelos e documentos apresentados são familiares a essas pessoas;

(42)

Arquitetos de Software

• Recebem o resultado do trabalho do analista de requisitos.

• _{Utilizam os requisitos do usuário;}

– para criar um projeto arquitetural do sistema;

• que servirá como base para o trabalho dos programadores.

(43)

Arquitetos de Software

• _{Constante interação entre o arquiteto} de software e o analista de requisitos. • Verificam se os requisitos especificados

são viáveis.

• _{Se os requisitos não forem} tecnicamente viáveis;

– o analista de requisitos pode ter que negociar com o usuário uma mudança nos requisitos.

(44)

Programadores

• _{Codificam o sistema;}

– a partir do trabalho do arquiteto de software.

• _{Conhecem mais da tecnologia;}

– e menos do negócio do cliente.

• _{Muitas vezes descobrem erros e}

ambigüidades no trabalho do analista de requisitos.

– Interagem com o analista de requisitos quando existe a necessidade de realizar alguma correção nos modelos de análise.

(45)

Testadores

• Testam os componentes de código

desenvolvidos a procura de erros;

– inclusive erros de

não-conformidade do produto com seus requisitos.

(46)

Analistas de Suporte

• Pouco contato com o usuário.

• Às vezes, o sistema apresenta alguma restrição;

– por causa do ambiente de operação.

• _Exemplos:

– DBA;

– Analista de Desempenho;

– Analista de Redes; – etc.

(47)

Pessoal de Operação

• Técnicos responsáveis por:

– backup;

– atualizações de versões; – instalação de ferramentas;

– manutenção dos equipamentos;

– controle de impressão; – etc.

(48)

Perguntas

(49)

Referências

• Participantes do Processo de Desenvolvimento de Software – André

Luiz Moura Júnior

• Conceitos E Tópicos Relacionados A Análise De Sistemas – Prof. Roni

Márcio Fais - www.rmfais.com

• YOURDON, Edward. Análise Estruturada Moderna. Rio de Janeiro: Campus, 1992. Capítulo 3.