UNIVERSIDADE DO ESTADO DE SANTA CATARINA CENTRO DE CIÊNCIAS TECNOLÓGICAS DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO E SISTEMAS THAYSE MALU GADOTTI

Transcrição

1 UNIVERSIDADE DO ESTADO DE SANTA CATARINA CENTRO DE CIÊNCIAS TECNOLÓGICAS DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO E SISTEMAS THAYSE MALU GADOTTI PROJETO DE UM NOVO SISTEMA DE INFORMAÇÃO PARA SUPORTE A USUÁRIOS Joinville - SC 2010

2 UNIVERSIDADE DO ESTADO DE SANTA CATARINA CENTRO DE CIÊNCIAS TECNOLÓGICAS DEPARTAMENTO DE ENGENHARIA DE PRODUÇÃO E SISTEMAS THAYSE MALU GADOTTI PROJETO DE UM NOVO SISTEMA DE INFORMAÇÃO PARA SUPORTE A USUÁRIOS Trabalho de Graduação apresentado à Universidade do Estado de Santa Catarina, como requisito parcial para obtenção do título de Engenheiro de Produção e Sistemas. Orientador: MSc. Gerson Volney Lagemann Joinville - SC 2010

3 THAYSE MALU GADOTTI PROJETO DE UM NOVO SISTEMA DE INFORMAÇÃO PARA SUPORTE A USUÁRIOS Trabalho de Graduação aprovado como requisito parcial para a obtenção do título de Engenheiro do curso de Engenharia de Produção e Sistemas da Universidade do Estado de Santa Catarina. Banca Examinadora: Orientador: MSc. Gerson Volney Lagemann Membro: Dr. Régis Kovacs Scalice Membro: Dr. Adalberto José Tavares Vieira Joinville, 19/11/2010

4 Dedico este trabalho a Deus que me ajudou a chegar até aqui, a minha mãe e ao meu irmão pelo incentivo, a todos os meus amigos que são a minha família e em especial a todos da equipe ETIM.

5 A força não provém de uma capacidade física e sim de uma vontade indomável. Gandhi

6 AGRADECIMENTOS Agradeço primeiramente a Deus que me proporcionou essa oportunidade que considero única em minha vida, a qual dou muito valor que é cursar um curso superior e poder realizar mais um sonho em minha vida. A minha família: ao meu pai Luiz Gadotti (in memorian), minha mãe Mary que me incentivou nos momentos mais difíceis e meu irmão Thyago que foram a minha base assim como o meu padrasto Reginaldo Ruediger. A toda equipe do ETIM em especial o meu orientador de estágio Edson Biancato Bagio, que não só demonstrou ser um excelente profissional, como também um amigo e incentivador desse trabalho. A todos os meus amigos que me apoiaram e me incentivaram nos momentos de desânimo, são muitos para citar nomes por isso e por eles serem de tão enorme qualidade me sinto mais uma vez agraciada por Deus. A Thalita B. Pahl, Sergio Rosa, Rosangela Hartmann, Felippe José, Volmir Bianchini, Felipe Schadek, esses na verdade foram verdadeiros anjos de Deus enviados para não deixar eu olhar para traz. Ao professor Gerson Volney Lagemann que mesmo com o tornozelo machucado mostrou o valor do comprometimento, não deixando em nenhum momento que o seu afastamento interferisse na sua orientação, ao invés disso abriu as portas de sua casa juntamente com sua família para a incansável orientação e concretização desse trabalho. A todos os Professores do Departamento de Engenharia de Produção e Sistemas que não só me ensinaram o conhecimento técnico, como conhecimento pessoal, conhecimento esse que levo para a vida.

7 THAYSE MALU GADOTTI PROJETO DE UM NOVO SISTEMA DE INFORMAÇÃO PARA SUPORTE A USUÁRIOS RESUMO O principal objetivo desse trabalho é entregar um projeto de um novo sistema a um sistema de informação (SI) já existente na empresa estudada. Esse sistema é utilizado pelo usuário para gerar pedidos de atendimento, ou seja, de acordo com a necessidade o usuário informa que precisa do suporte de um analista especializado naquele tipo de problema, logo um código de chamado é gerado pelo sistema. Um levantamento bibliográfico foi realizado para implementar o SI. Foram definidas quais as fases de desenvolvimento e como implementá-las. Foi também analisado o sistema atual para compreender seus principais pontos de melhoria. Para a proposta foram realizadas técnicas de levantamento dos requisitos dos usuários, pois se entende que verdadeiramente eles são o motivo dessa melhoria, ou seja, esse sistema existe para facilitar a comunicação entre analista e usuário e é nesse contexto que o novo modelo foi proposto. PALAVRAS-CHAVE: Melhoria, Sistema de Informação, Suporte.

8 LISTA DE FIGURAS Figura 1 Ciclo de vida em cascata...16 Figura 2 Ciclo de vida em cascata com realimentação...17 Figura 3 Ciclo de vida em espiral...18 Figura 4 Exemplo de processo...22 Figura 5a Exemplo de Fluxo...22 Figura 5b Exemplo de um Fluxo em um processo...22 Figura 6 Representação de Depósito...23 Figura 7 Exemplo de Representação Gráfica de Entidades Externas...23 Figura 8 Exemplo de diagrama de fluxo de dados...24 Figura 9 Exemplo de uma entidade...25 Figura 10 Exemplo de Entidade e Atributos...25 Figura 11 Áreas que o ETIM fornece suporte...31 Figura 12 Fluxograma de abertura de chamados atual...33 Figura 13 Página da Intranet ETIM...34 Figura 14 Página do ETIM Call para abertura de chamados...35 Figura 15 Tela de visualização da abertura do chamado...36 Figura 16 Tela de visualização de busca...36 Figura 17 Página de chamados ETIM...37 Figura 18 Detalhes do chamado...38 Figura 19 Mudança de status do chamado...38

9 Figura 20 Visão do Administrador...39 Figura 21 Fluxograma do sistema futuro...49 Figura 22 Diagrama do Fluxo de dados...50 Figura 23 MER Modelo de Entidade e relacionamento...51

10 LISTA DE TABELAS Tabela 1 Fatores de insucesso de um sistema...19 Tabela 2 Requisitos dos Usuários...42 Tabela 3 Requisitos do Sistema...43 Tabela 4 Requisitos dos Usuários com priorização...44 Tabela 5 Requisitos do Sistema com ranking...46 Tabela 6 Requisitos dos usuários adiados...47 Tabela 7 Dicionário de Dados...51 Tabela 8 Comparação entre os SI...52

11 LISTA DE ABREVIATURAS SI ACM IEEE/EIA DPMA QFD LDAP ETIM MER DFD P&D PTC PRO/E AHP Sistema de Informação Association for Computing Machinery Industry Implementation of International Standard Data Processing Management Association Quality Function Deployment Lightweight Directory Access Protocol Engineer Technology Information Management Modelo de Entidade e Relacionamento Diagrama de Fluxo de Dados Pesquisa e Desenvolvimento Product Development Company Pro Engineer Analytic Hierarchy Process

12 SUMÁRIO 1 INTRODUÇÃO FUNDAMENTAÇÃO TEÓRICA SISTEMAS DE INFORMAÇÃO (SI) CICLO DE VIDA DO SISTEMA AS FASES DO CICLO DE VIDA Levantamento dos requisitos Detalhamento e priorização dos Requisitos Inspeção dos requisitos Verificação dos requisitos adiados Análise Desenho Implementação Testes PROCEDIMENTOS METODOLÓGICOS MÉTODO DE PESQUISA COLETA E PROCEDIMENTOS PARA ANÁLISE DOS DADOS DESENVOLVIMENTO DO NOVO SISTEMA A EMPRESA A Whirlpool no Brasil A Whirlpool em Joinville Apresentação da área do estudo de caso O SISTEMA DE INFORMAÇÃO ATUAL Interface Gráfica visualização dos usuários Interface Gráfica visualização dos analistas Interface Gráfica visualização do Líder Regional MELHORIAS PARA O SISTEMA ATUAL O PROJETO DO NOVO SISTEMA Requisitos Levantamento dos requisitos Priorização dos requisitos Validação dos requisitos Verificação dos requisitos adiados Análise RESULTADOS CONSIDERAÇÕES FINAIS REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE... 56

13 1 INTRODUÇÃO A comunicação segundo Albertin (2009) é o ato ou efeito de emitir, transmitir e receber mensagens por meio de métodos e/ou processos convencionados, quer através da linguagem falada ou escrita, quer de outros sinais, quer de aparelho técnico especializado, sonoro e /ou visual. A informática é a ciência que tem como objetivo viabilizar, garantir e suportar o tratamento e a comunicação das informações de uma organização, pois é a ciência do processamento racional, principalmente por computadores eletrônicos, da informação considerada como suporte do conhecimento humano e das comunicações nos domínios técnicos, econômicos e sociais. Na comunicação sempre existe a parte do emissor que emite a mensagem e a do receptor que capta a mensagem. O que mais as empresas necessitam hoje em dia é traduzir as necessidades dos clientes para produzir aquilo que eles realmente desejam, quando isso acontece podemos dizer que a comunicação entre cliente e empresa é eficaz. Normalmente dentro das organizações existem emissores e receptores, pois ouvi-se e fala-se diversas vezes. Este trabalho terá como tema uma proposta de melhoria para um sistema de atendimento de chamados de usuários. Esse sistema propõe-se a ser um elo de comunicação entre os usuários e a área que será o campo de estudo desse trabalho. O software será programado para que os usuários comuniquem suas necessidades e os analistas receberão estas informações e se utilizem delas para atender as expectativas dos usuários, compartilhando informações com eles. O objetivo geral deste trabalho consiste em projetar um novo sistema a partir da análise de um sistema já existente, dentro de uma metodologia de desenvolvimento de projeto conforme sugerem os teóricos da área. Os objetivos específicos desse trabalho são: Levantar pontos falhos do sistema atual; Levantar, junto aos usuários, requisitos imprescindíveis no sistema futuro; Propor melhorias técnicas para o novo sistema. Nas organizações atualmente tem-se visto o quanto a informação é importante, o quanto as empresas têm investido para manter as informações dos seus clientes e fornecedores atualizadas. Sabe-se, todavia que uma informação que não agrega valor para a organização só demandará tempo e dinheiro.

14 14 Nesse contexto através de reuniões com usuários e gerentes o trabalho se justifica, pois foi observado que as informações colocadas nesse sistema podem ser melhor utilizadas e alguns recursos voltados aos usuários podem ser implementados. O estudo delimitar-se-á a empresa Whirlpool S.A unidade de eletrodomésticos de Joinville. O sistema selecionado para esse estudo foi elaborado na área do ETIM Engineer Tecnology Information Management onde será realizado uma análise do sistema atual para elaboração de uma proposta de sistema que atenda as necessidades dos usuários e administradores da empresa. O trabalho está estruturado em capítulos, sendo que, o primeiro é composto pela introdução ao assunto a ser estudado, são apresentados o tema abordado, o objetivo geral e os específicos, a justificativa do trabalho, como também a delimitação do estudo. O segundo capítulo é dedicado à fundamentação teórica do tema, que pode ser dividido em duas partes, a primeira objetiva referenciar o que são sistemas de informação e o segundo discorre sobre a teoria de ciclo de vida para a implantação de um sistema, sendo que mostra vários conceitos de ferramentas que ajudam a formalizar etapas do ciclo de vida. A metodologia aplicada neste trabalho será apresentada no terceiro capítulo. Nesta etapa serão apresentados: o tipo de pesquisa e método e em seguida os métodos para coleta e análise de dados. No quarto capítulo é realizada uma breve descrição da empresa, os produtos e serviços que destacam sua atuação no mercado, e a seguir é desenvolvido o estudo de caso. No quinto capítulo, são apresentadas as considerações finais. Para finalizar, as referências bibliográficas utilizadas na pesquisa e os anexos que compõem o trabalho.

15 2 FUNDAMENTAÇÃO TEÓRICA 2.1 SISTEMAS DE INFORMAÇÃO (SI) Segundo Albertin (2009) sistemas de informação (SI) é um conjunto de procedimentos organizados que, quando executados, provêem informação para suportar a tomada de decisão e o controle numa organização. Os SI apóiam os procedimentos operacionais de controle administrativo, os processos de tomada de decisão e a estratégia competitiva da empresa, pelo uso da informática e de sua tecnologia. Os sistemas de informação de acordo com Filho (2009) são formados pela interação do software, base de dados, hardware e redes, ou seja, o sistema é a interação dessas partes para trazer um beneficio aos usuários. Para o desenvolvimento de um SI, existem procedimentos para tornar o processo de criação menos complexo e que fornecerá a equipe um horizonte de projeto planejado. 2.2 CICLO DE VIDA DO SISTEMA De acordo com Pfleeger (2004) o ciclo de vida descreve a vida do produto de sistema desde a concepção até a implementação, entrega, utilização e manutenção. O ciclo de vida é um procedimento que combina ferramentas e técnicas para produzir um produto. Existem vários modelos de ciclo de vida para ajudar os analistas a desenvolverem um sistema. Pode se citar o modelo cascata, cascata com realimentação e o ciclo de vida em espiral. No modelo de ciclo de vida em cascata (figura 1) os principais subprocessos são executados em estrita seqüência, de acordo com Pfleeger (2009) o desenvolvimento de um estágio deve terminar antes do próximo começar o que permite demarcá-los com pontos de controle bem definidos. Esses pontos de controle facilitam muito a gestão dos projetos, o que faz com que o processo seja, em princípio confiável e utilizável em projetos de qualquer escala. Por outro lado, se interpretado literalmente, é um processo rígido e burocrático, em que as atividades de requisitos, análise e desenho tem de ser muito bem definidas, pois, teoricamente, o processo não prevê a correção posterior de problemas nas fases anteriores. Na prática, é sempre necessário permitir que, em fases posteriores, haja revisão e alteração dos resultados das fases anteriores. Um modelo que permite a realimentação é o de

16 16 cascata com realimentação. Por exemplo, os modelos e documentos de desenho podem ser alterados durante a implementação, à medida que problemas vão sendo descobertos. Figura 1 Ciclo de vida em cascata Fonte: Filho, Uma variante que permite superposição entre fases e a realimentação de correções é um modelo mais realista, com realimentação entre fases, chamada então de cascata com realimentação, (figura 2). No ciclo de vida em espiral o produto é desenvolvido a partir de uma série de iterações (figura 3). Cada nova iteração corresponde a uma volta na espiral. Por liberação entende-se um estágio parcialmente operacional de um produto, que é submetido à avaliação de usuários em determinado marco de projeto. Liberações escolhidas podem ser designadas como versões oficiais do produto, e colocadas em uso. Isso permite construir produtos em prazos curtos, com novas características e recursos que são agregados à medida que a experiência descobre sua necessidade. As atividades de manutenção são usadas para identificar problemas; seus registros fornecem dados para definir os requisitos das próximas liberações. É, atualmente, a abordagem mais realística para o desenvolvimento de software em grande escala, pois usa uma abordagem que capacita o desenvolvedor e o cliente a entender e reagir aos riscos em

17 17 cada etapa evolutiva, porém pode ser difícil convencer os clientes que uma abordagem "evolutiva" é controlável e exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso. Figura 2 Ciclo de vida em cascata com realimentação Fonte: Filho (2009) De acordo com Filho (2009), o projeto de desenvolvimento mais caótico é aquele que pode ser chamado de codifica remenda. Partindo apenas de uma especificação, os desenvolvedores começam imediatamente a codificar, remendando à medida que os erros vão sendo descobertos.

18 18 Figura 3 Ciclo de vida em espiral Fonte: Filho (2009) 2.3 AS FASES DO CICLO DE VIDA Levantamento dos requisitos Segundo Filho (2009) requisitos são: Condição ou potencialidade de que um usuário necessita para resolver um problema ou atingir um objetivo. Condição ou potencialidade que um sistema, componente ou produto deve possuir para que seja aceito (isto é, satisfaça a um contrato, padrão, especificação ou outro documento formalmente imposto). Com a análise dos requisitos o objetivo é obter um enunciado completo, claro e preciso daquilo que os usuários esperam que o sistema de informação realize.

19 19 De acordo com Standish (apud PFLEEGER, 2004, p.112), o Standish Group pesquisou mais de 350 empresas sobre os seus mais de projetos de softwares, para descobrir como eles estavam se saindo. Os dados obtidos foram que 31% dos projetos de softwares foram cancelados antes de serem concluídos. Além disso, em grandes empresas, somente 9% dos projetos foram entregues dentro do prazo. Os fatores principais são relatados a seguir: Tabela 1 Fatores de insucesso de um sistema Fatores que levam ao insucesso de um sistema Porcentagem Requisitos incompletos 13,1% Falta de envolvimento por parte do usuário 12,4% Falta de recursos 10,6% Expectativas não realizadas 9,9% Falta de apoio dos executivos 9,3% Modificações nos requisitos e especificações 8,7% Falta de planejamento 8,1% O sistema não era mais necessário 7,5% Fonte: Adaptado de Pfleeger, Observa-se que algumas partes do processo de identificação, definição e gerenciamento de requisitos estão envolvidas em quase todas essas causas. A falta de cuidado com o entendimento, a documentação e o gerenciamento dos requisitos podem levar a uma grande quantidade de problemas. Os requisitos devem ser levantados pela equipe de projeto, em conjunto com representantes do cliente, usuários e possivelmente, especialistas de aplicação. Existem várias formas de levantarmos os requisitos. Segundo Yourdon, (1990) os requisitos podem ser levantados através de: Entrevistas Questionários Coleta de dados Pesquisa externa Protótipo de requisitos

20 Detalhamento e priorização dos Requisitos Depois de realizado o levantamento dos requisitos é necessário detalhá-lhos e priorizálos para que a equipe de projeto possa entender quais as verdadeiras necessidades dos usuários, como o sistema poderá atender esses requisitos e quais deles o sistema não atenderá. De acordo com Pfleeger (2004) os requisitos serão consultados durante o desenvolvimento e a manutenção do sistema, por isso devem ser escritos de maneira compreensível não somente para os clientes, mas também para o pessoal da equipe de desenvolvimento. Para a priorização dos requisitos existem muitas ferramentas que podem ser utilizadas, desde ferramentas da qualidade e planilhas com pontuações para usuários até reuniões com os analistas e o time do projeto. De acordo com Cheng (2007) a decisão sobre qual atributo incluir ou excluir na especificação dos requisitos é realizada pelo bom senso, que é uma prática aceitável e pode dar bons resultados, principalmente quando há histórico de projetos relacionados. No entanto um método formal aumenta a precisão dos resultados. A aplicação do método QFD Quality Function Deployment permite identificar os requisitos que melhor reflitam a voz dos usuários. De acordo com Cheng (2007) o método QFD foi formulado pelos professores Akao e Mizuno no final da década de 60. O QFD tem sido direcionado a etapa inicial do ciclo de vida de desenvolvimento de produto. No passado as aplicações eram na maioria das vezes sobre produtos tangíveis, ultimamente tem crescido o uso sobre produtos menos tangíveis, como serviços e software. O QFD pode ser conceituado como uma forma de comunicar sistematicamente informação relacionada com a qualidade e de explicitar ordenadamente o trabalho relacionado com a obtenção da qualidade. A qualidade de um produto de sistema é definida por suas funções, características intrínsicas e pela percepção de seus usuários em um contexto de uso. A usabilidade trata das características não funcionais, ou seja, das características externas relativas à interação do usuário com o produto, podendo ser especificada e medida. Para a elaboração do QFD é necessário primeiramente fazer juntamente com os usuários o levantamento das características não funcionais para ter conhecimento daquelas que o sistema precisa entregar ao usuário, ou seja, definir a real necessidade do novo sistema por meio do conhecimento dos objetivos da empresa, demandas de mercado e necessidades específicas dos usuários. Depois de realizado o levantamento com os usuários é necessário calcular o grau de importância de cada requisito. Para isso pode-se utilizar o método Analytic Hierarchy Process (AHP) e comparação por pares. Quando o desenvolvimento do sistema

21 21 está em estágio mais avançado, com protótipos, por exemplo, ou quando existem produtos similares, os usuários representativos podem fazer uma avaliação de satisfação relativa ao atendimento dos requisitos. Para definir as características ou requisitos do sistema é elaborada uma reunião com os analistas e desenvolvedores onde os requisitos dos usuários dispostos no QFD na coluna vertical são desdobrados em requisitos do sistema na coluna horizontal. Calcula-se então para cada requisito do sistema o produto do grau de importância do requisito do cliente pelos valores numéricos das correlações e somam-se estes produtos verticalmente Inspeção dos requisitos Após a priorização e o detalhamento dos requisitos a inspeção dos requisitos consiste em de acordo com Filho (2009) perceber se os requisitos estão em conformidade com o respectivo padrão e com outros padrões aplicáveis ao projeto, fornecer informações suficientes para a avaliação do produto pelo cliente e pelos usuários. Para isso pode ser feito uma reunião com os usuários e com os analistas e responsáveis pelo projeto, para validar os requisitos Verificação dos requisitos adiados Alguns requisitos que os usuários sugerem algumas vezes não são atendidos pelo sistema por muitos motivos, contudo é de extrema importância que esses requisitos fiquem documentados e na fase de inspeção dos requisitos os analistas esclareçam, para que ambos possam ter as mesmas expectativas com a entrega do sistema Análise De acordo com Filho (2009) a fase de análise tal qual a fase de requisitos, visa descrever o problema, mas de uma forma orientada não mais para usuários, e sim para os desenvolvedores. A análise visa detalhar, estruturar e validar os requisitos de um produto, em termos de um modelo conceitual, para Youdon (1990) o principal propósito da atividade de análise é transformar as duas principais entradas requisitos dos usuários e requisitos do sistema, em

22 22 uma especificação estruturada. Para isso é utilizado algumas ferramentas como o Diagrama de Fluxo de Dados (DFD) e o Modelo de Entidade Relacionamento (MER). Segundo Gane (1988) o Diagrama de fluxo de dados é a principal ferramenta de planejamento para um sistema de informação, pois o DFD mostra a fronteira do sistema, é o único documento que mostra todas as relações entre os dados. O DFD é composto por quatro componentes: 1- Processo: O processo conforme figura 4, mostra uma parte do sistema, a que transforma entradas em saídas isto é, mostra como uma ou mais entradas são convertidas em saídas. O processo pode ser representado graficamente por um círculo com os cantos arredondados, porém alguns autores preferem um círculo, ou um retângulo isto é apenas uma questão de convenção, o importante é que uma vez adotado um modelo seja seguido do inicio da execução do DFD ao final para que o diagrama seja desenhado de forma clara. Calcular imposto sobre vendas Figura 4 Exemplo de processo Fonte: Gane, O processo é denominado ou descrito com uma única palavra ou sentença simples. Na maioria dos modelos DFD o processo descreverá o que o processo faz, o símbolo deve ter uma descrição da função do processo, começando com um verbo, seguido por uma clausula do objeto, conforme exemplo Calcular (verbo), impostos sobre vendas (clausula do objeto). 2- Fluxo: é graficamente representado por uma seta que entra ou sai de um processo e é utilizado para mostrar o movimento de pacotes de informação de um ponto a outro do sistema, representa os dados em movimento. Consulta de Cliente Número de Telefone Validar Número de Telefone Figura 5a Exemplo de Fluxo Fonte: Gane, Figura 5b Exemplo de um Fluxo em um processo

23 23 Como pode ser observado no exemplo o fluxo recebe um nome que representa o significado do pacote que se move pelo fluxo. O fluxo também possui direção: uma seta em uma das extremidades do fluxo ou em ambas indica se os dados entram ou saem do processo. 3- Depósito: é utilizado para demonstrar uma coleção de pacotes de dados em repouso. O depósito existe por causa de um requisito do usuário ou por um aspecto prático da implementação do sistema. A representação gráfica do depósito é um retângulo com uma abertura na direita conforme exemplo visto na figura 6, o nome escolhido para identificar o depósito é o plural do nome dos pacotes transportados pelo fluxo para dentro e para fora do depósito. Pedido Pedidos Figura 6 Representação de Depósito Fonte: Gane, Entidades Externas: as entidades externas (figura 7) são origens e/ou destinos de fluxos de dados para dentro e/ou para fora do sistema, os dados entram e saem do sistema apenas por entidades externas. Pode ser representado por um grupo de pessoas, como clientes, ou também pelo usuário. Sua representação gráfica é um quadrado, porém podem existir outros modos de representar. Clientes Figura 7 Exemplo de Representação Gráfica de Entidades Externas Fonte: Gane, Um exemplo de DFD mostra que cliente (uma entidade externa, algo fora do sistema) envia um fluxo de pedidos no sentido da seta de fluxo de dados, (figura 8). O processo, processar pedidos, utiliza informações do armazém de dados de produto e coloca informações a respeito de vendas dentro do armazém de dados denominado vendas.

24 24 Figura 8 Exemplo de diagrama de fluxo de dados Fonte: Gane, De acordo com Machado (2001) o modelo de entidade e relacionamento foi definido por Peter Chen em 1976, baseia-se na percepção do mundo real, como constituído por um conjunto de objetos básicos chamados Entidades e Relacionamentos. A estrutura lógica global de um banco de dados pode ser expressa graficamente por um diagrama de Entidades e por Relacionamentos. Apesar de ser uma forma gráfica de representar um banco de dados relacional, o MER possui um elevado grau de semântica, que o torna mais simples, além de permitir uma comunicação otimizada entre os usuários e os profissionais de informática, desenvolvedores de sistema. De acordo com Youdon (1990) o MER é um modelo em rede que descreve a diagramação dos dados armazenados de um sistema em alto nível de abstração. Geralmente as estruturas de dados e os relacionamentos podem ser tão complexos que é necessário um diagrama para examiná-los independentemente do processamento que ocorrerá. Para a elaboração do MER é necessário o entendimento de alguns conceitos: 1- Entidade: é a principal classe de objetos sobre a qual são coletadas informações. É todo objeto concreto ou abstrato que tem existência própria. São coisas sobre as quais se deseja arquivar informações. Exemplo de entidade podem ser alunos, clientes, funcionário. A representação gráfica para entidade é um quadrado que possui o nome da entidade, conforme figura 9.

25 25 Funcionário Figura 9 Exemplo de uma entidade Fonte: Gane, Relacionamentos: é a representação das associações existentes entre entidades. O mais comum dos termos associados a um relacionamento é a indicação da cardinalidade, que nada mais é do que a conectividade entre duas entidades. Essa conectividade pode ser de um para um, de um para muitos e de muitos para muitos, o nome relacionamento normalmente é um verbo, pois ele é resultante de um fato que associa as entidades. 3- Atributos: são as características de uma entidade que a descrevem detalhadamente. Uma ocorrência especifica de um atributo em uma entidade é denominado de valor do atributo. Os atributos são os dados das entidades que se quer armazenar. Entidade ALUNO Atributos Nome Número da Matrícula Endereço Figura 10 Exemplo de Entidade e Atributos Fonte: Kern, Cada entidade no Modelo de Entidade e Relacionamento possuirá atributos específicos, conforme figura 10, a entidade ALUNO, possui os atributos Nome, Número da Matricula e Endereço. Para melhor visualização esses atributos são descritos no dicionário de dados que relaciona numa tabela o nome das entidades, atributos específicos, formato e tamanho do atributo.

26 Desenho Segundo Filho (2009) a fase do desenho tem por objetivo definir uma estrutura implementável para um produto de software / sistema que atenda os requisitos especificados para ele. A testabilidade é um objetivo chave no desenho de sistema. Os engenheiros de software devem desenhar os componentes de um produto pensando em como esses componentes serão testados, sempre que possível, o desenho deve ser feito de modo a reduzir a necessidade de componentes de teste. Conceitualmente, o desenho é feito antes da respectiva implementação, na prática isso pode acontecer ou não, estipula-se que, antes de qualquer implementação, o produto a ser construído sofra um desenho completo e minucioso. O objetivo principal desse estilo de desenho é chegar a uma estrutura elegante e econômica, diminuindo o esforço para a implementação. Entretanto, corre-se o risco de produzir estruturas genéricas demais, cuja reutilização pode não se materializar, ou mesmo estruturas que não sejam implementáveis dentro das restrições aplicáveis.. O desenho deve usar uma abordagem progressiva e iterativa, através da construção de versões operacionais parciais que sirvam como ponto de controle e permitam a avaliação por parte dos usuários. Essas versões parciais são as liberações, sendo que o objetivo das liberações é possibilitar a validação e realimentação por parte dos usuários Implementação A implementação consiste em selecionar todas as etapas anteriores requisitos, análise e desenho e traduzir isto em forma de código, porém as estruturas e relações facilmente descritas por meio de tabelas e gráficos nem sempre são diretamente escritas como código como afirma Pfleeger (2004). Existem muitas maneiras de implementar um projeto e muitas linguagens, mas as diretrizes são geralmente aplicáveis a qualquer implementação. Entre essas diretrizes podemos citar: utilização de padrões, estruturas de controle, algoritmos e estruturas de dados.