Upload
paulo-cesar
View
41
Download
5
Embed Size (px)
Citation preview
UNIVERSIDADE PAULISTA – UNIP
Instituto de Ciências Exatas e Tecnologia - ICET
CIÊNCIA DA COMPUTAÇÃO INTERDISCIPLINAR
“Estudo de caso Black & Decker”
Helder da Silva Bezerra RA – A5767I-6
José Antônio Barbosa RA – A45692-9
Paulo César F. Ferreira RA – A617JD-1
Turma: CC6A13
Campus: Marques
Professor: Chau (Noboru)
São Paulo
2012
Sumário
1. Introdução 2
2. Objetivo 2
3. Desenvolvimento 2
3.1. Levantamento de Requisitos 2
3.2. DER (Diagrama Entidade Relacionamento) 3
3.3. DFD (Diagrama de Fluxo de Dados) 4
3.4. Dicionário de Dados 6
3.4.1. Entidades 6
3.4.2. Repositório de Dados 6
4. Conclusão 7
5. Bibliografia 7
1
1. Introdução
Segundo YIN (2001), os estudos de casos representam a estratégia preferida:
quando se colocam questões do tipo “como” e “porque”; quando o pesquisador tem pouco controle sobre os eventos; quando o foco se encontra em fenômenos contemporâneos inseridos
em algum contexto da vida real;
A clara necessidade pelos estudos de caso surge do desejo de se compreender fenômenos sociais complexos, ou seja, o estudo de caso permite uma investigação para se preservar as características holísticas e significativas dos eventos da vida real.
2. Objetivo
Este estudo de caso visa o desenvolvimento de um sistema de controle integrado entre todos os departamentos da empresa Black & Decker, que gerencie todas as etapas dos processos, desde a entrada da matéria-prima até a entrega do produto final de maneira rápida e eficiente.
3. Desenvolvimento
Para chegarmos no resultado esperado o primeiro passo é fazer o levantamento de requisitos.
3.1. Levantamento de Requisitos:
Demanda Sistema de Controle
Figura 1
2
BD Compaq Alphas
Matéria-primaDepartamentos
Compras
Recebimento
Financeiro
Contabilidade
Fabricas
(10 países)
Tabela Mestra
Vendedor
Lista Materiais
Roteiro
Planejamento
Pedido
Cliente
Segundo Veríssimo (2007), o levantamento de requisitos é umas das partes mais importantes do processo que resultará no desenvolvimento de um sistema. Entender aquilo que o cliente deseja ou o que o cliente acredita que precisa e as regras do negócio ou processos do negócio. Isso é o cerne que move essa importante função que faz parte da engenharia de requisitos.
A figura 1 mostra como este sistema irá integrar todas as fabricas da Black & Decker à um Banco de Dados central, no qual será acessado por todos os departamentos da empresa, através do sistema Compaq Alphas.Com o intuito de facilitar a operação foi criado uma tabela mestra que será acessada pelos vendedores, que terão o controle dos materiais, roteiro de entregas, planejamento de vendas, pedidos e dados do cliente, facilitando assim o controle do estoque, matéria-prima e vendas.
3.2. DER (Diagrama Entidade Relacionamento)
Segundo Silberschatz (2006), um diagrama E-R pode expressar graficamente a estrutura lógica geral de um banco de dados. Os diagramas E-R são simples e claros – qualidades que podem ter motivado o amplo uso do modelo E-R.Esse diagrama consiste nos seguintes componentes principais:
Retângulos, que representam conjuntos de entidades; Elipses, que representam atributos; Losangos, que representam conjuntos de relacionamento; Linhas que vinculam atributos a conjuntos de entidades e estes a
conjuntos de relacionamento; Elipses duplas, que representam atributos derivados; Linhas duplas, que indicam participação total de uma entidade em um
conjunto de relacionamento; Retângulos duplos, que representam conjuntos de entidades fracos;
Na figura 2 montamos um DER mostrando as principais entidades (Clientes, Fabricas, Estoque, Vendas e Fornecedor) e seus relacionamentos, que mostra o caminho feito pelo produto desde o fornecedor até a entrega ao cliente final.
Descrição do DER:
a entidade Cliente faz o pedido para Vendas; vendas encaminha o pedido para as Fabricas; a Fabrica solicita o produto ao Estoque; o Estoque compra do Fornecedor; o Estoque entrega para o Cliente; o Cliente faz o pagamento à Fabrica e fecha o ciclo.
3
3.3. DFD (Diagrama de Fluxo de Dados)
Segundo Yourdon (1989), o diagrama de fluxo de dados é uma ferramenta de modelagem que nos permite imaginar um sistema como uma rede de processos funcionais, interligados por "dutos" e "tanques de armazenamento" de dados. Na literatura do processamento de dados, e em suas conversas com outros analistas de sistemas e usuários, você pode usar qualquer um dos termos abaixo como sinônimo de diagrama de fluxo de dados:
Diagrama de bolhas DFD (abreviatura) Modelo de processo Diagrama de fluxo de trabalho Modelo funcional "uma representação do que está acontecendo por aqui"
4
O diagrama de fluxo de dados é uma das mais utilizadas ferramentas de modelagem de sistemas, principalmente para sistemas operativos nos quais as funções do sistema sejam de fundamental importância.
Na figura 3 foi desenvolvido um DFD que mostra o fluxo dos processos, no qual é
composto por uma entidade “Sistema”, que administra todas as movimentações dos dados
dentro deste sistema. Os processos são os de estoque de produto, de pedidos, de gerar
relatórios, de vender produto e de clientes.
Para armazenar esses dados em fluxo existem os repositórios denominados
como, D1 (Clientes), D2 (Produto) e D3 (Movimentação do produto) e finalmente são
ligados à entidade externa, que é o cliente final.
Figura 3
5
Sistema“Demanda”(Produto)
Estoque(Produto) Fornecedor
EntidadeExterna(Cliente)
PedidoVender
(Produto)
D2 Produto
D3 Mov. ProdutoD1 Clientes
Gerar(Relatórios) Clientes
comando
dados produto
dados produto
dados cliente
dados produto
dados cliente
dados produto
solicitação
dados produto
carteira
relatórios
dados venda
dados venda
recibo
doc.controle
dados produto
3.4. Dicionário de Dados
Notação
Símbolo Significado= é composto de() opcional (pode estar presente ou ausente){} iteração** comentário@ Identificador (chave) em um depósito
3.4.1. Entidades:
Sistema = * armazena dados do produto, do estoque e do pedido. * {Sistema}
Sistema = @prod + numero_pedido + tipo_produto.
Pedido = * armazena dados referentes aos pedidos. * {Pedido}
Pedido = @numero_pedido+cliente+tipo_produto+quantidade+valor_unit+valor_total.
Estoque = * armazena dados do produto. * {Estoque}
Estoque = @tipo_produto + quantidade.
Vender = * armazena dados da venda, do pedido, do cliente, do produto e dos documentos de controle. * {Vender}
Vender = @venda + cliente + numero_pedido + prod + recibo.
Clientes = * armazena dados das compras do cliente. * {Clientes}
Clientes = @cliente + ultima_compra + pag_realizado + divida aberta.
Gerar = * armazena dados do cliente, das vendas, dos pedidos e gera os relatórios. * {Gerar}
Gerar = @relatório + venda + cliente + produto + recibo.
3.4.2. Repositório de dados:
D1 Clientes = * armazena dados dos clientes. *
D1 Clientes = @cpf + nome + end + CEP + fone.
D2 Produto = * armazena dados dos produtos. *
6
D2 Produto = @cod_prod + quantidade + valor.
D3 Mov. Produto = * armazena dados das vendas dos produtos. *
D3 Mov. Produto = @quant_vendida + vlr_recebido + vlr_a_receber.
4. Conclusão
Ao final deste trabalho chegamos a conclusão que é possível criar um sistema integrado e eficiente para qualquer empresa, de qualquer ramo de atividade, independente do seu tamanho físico, quantidade de funcionários e transações utilizadas.
Para isso basta fazer um planejamento e um projeto bem elaborado, fazer um levantamento de requisitos adequado e utilizar as ferramentas corretas, como o DER e o DFD, por exemplo, pois só assim você terá uma base solida para a implementação do sistema.
5. Bibliografia
Yourdon, E. "Análise Estruturada Moderna”; Prentice Hall; 1989.
YIN, Robert K. Estudo de caso – planejamento e métodos. (2Ed.). Porto Alegre: Bookman.2001.
Veríssimo, Ricardo. Artigo no site “administradores.com”. 04 de novembro de 2007.
Silberschatz, Abraham. Sistema de banco de dados/Abraham Silberschatz, Henry F. Korth, S. Sudarshan ; tradução de Daniel Vieira. – Rio de Janeiro: Elsevier, 2006. Pagina 142.
7