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