Ptg - [dp] - Tec. Analise e Desenv. Sist. - Produção Textual Grupo - [dp]

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Sistema de Ensino Presencial Conectado
ANALISE E dESENVOLVIMENTO DE SISTEMAS
UBIRATAN FERREIRA DA SILVA
[DP] ATIVIDADE INTERDICIPLINAR DE GRUPO
Gestão do Processo de Desenvolvimento I
Feira de Santana BA
2015.2
UBIRATAN FERREIRA DA SILVA
[DP] ATIVIDADE INTERDICIPLINAR DE GRUPO
Gestão do Processo de Desenvolvimento I
Trabalho apresentado ao Curso Tecnologia Em Análise e Desenvolvimento De Sistemas da UNOPAR - Universidade Norte do Paraná, para as disciplinas: Projeto Orientado a Objetos, Engenharia e Projeto de Software e Programação para Web II.	
Orientador: Prof. Márcio Roberto Chiaveli, Luis Claudio Perini, Marco Ikuro Hisatomi e Veronice de Freitas.
 
	
Feira de Santana BA
2015.2
SUMÁRIO
51	INTRODUÇÂO	�
62	DESAFIO 1 - PROPOSTA DE PROJETO	�
123	DESAFIO 2 - BASEADO NO PMBOK	�
164	DESAFIO 3 - PROGRAMAÇÃO JAVA WEB	�
185	DESAFIO 4 - DIAGRAMAS DA UML	�
23CONSIDERAÇÕES FINAIS	�
23REFERÊNCIAS	�
�
�
INTRODUÇÂO
A produção textual interdisciplinar grupo tem como base os assuntos abordados no eixo temático, envolvendo todas as disciplinas do semestre. Neste semestre é dada continuidade em alguns temas tratados no semestre anterior, além de abordar a viabilização do desenvolvimento de sistema de informação analisado, incrementar o conhecimento em engenharia de software, gestão de projetos e programação para Web. Ao projetar uma arquitetura de sistemas, você precisa decidir o que seu sistema e classes mais amplas de aplicação tem em comum, e decidir quanto conhecimento dessas arquiteturas de aplicação você pode reusar. O principal problema é que ele necessita ser um formato comum para transferir dados que possa ser reconhecido por todas as transformações. Hoje, uma empresa, com em um ambiente tecnologicamente preparado torna-se mais competitiva no cenário atual, se diferenciando dos demais e atendendo seus clientes com excelência. Cada vez mais as empresas buscam alternativas para facilitar o gerenciamento de suas atividades, visando aumentar o controle e obter informações precisas que possam de fato agilizar a tomada de decisões e, consequentemente, melhorar o nível de serviço prestado.
DESAFIO 1 - PROPOSTA DE PROJETO
O Projeto de arquitetura tem por decisão estabelecer uma organização de sistema que satisfaça os requisitos funcionais e não funcionais do sistema. Durante o processo de projeto de arquitetura, os arquitetos de sistema precisão tomar uma série de decisões fundamentais que afetam profundamente o sistema e o seu processo de desenvolvimento. O Sistema de Gerenciamento de Call Center - SGC, otimiza todas as atividades operacionais e administrativas dentro do processo de atendimento ao cliente incluindo todo o fluxo de operações dentro do serviços prestados pela empresa. O SGC operacional significa que a empresa depende menos da experiência das pessoas, uma vez que o sistema tem inteligência e seguem padroes e cronograma para solucionar problemas no atemdimento ao cliente.A utilização de um sistema SGC é fundamental para o bom funcionamento operacional com qualidade no controle de soluções de problemas do clinte sendo assim processado todos os protocolo de atendimento.
 Embora cada sistema de software seja único, pode ocorrer de ter domínio de aplicação de arquitetura similares que refletem os conceitos fundamentais de domínio. 
Foco no Cliente
Liderança
Envolvimento das Pessoas
Aproximação dos Processos
Sistema de Aproximação com a Gerência
Melhoria ContínuaAproximação Casual para Tomada de Decisão
Relacionamento Mutuamente Benéfico com Fornecedor
	Essa arquitetura de aplicação pode ser bastante genérica como a arquitetura de sistemas de gerenciamento de informações, ou muito mais específicas.
Finalidade
A finalidade do Plano de Desenvolvimento de Software é reunir todas as informações necessárias para controlar e gerenciar o protótipo de projeto de Gerenciamento de Navegação e Controle – GNC. Ele descreve a abordagem dada ao desenvolvimento do software e é o plano de nível mais alto gerado e usado pelos gerentes para coordenar o esforço de desenvolvimento.
O Plano de Desenvolvimento de Software é usado por estas pessoas:
O gerente de projeto utiliza-o para planejar o cronograma do projeto e as necessidades de recursos e para acompanhar o andamento do projeto em relação ao cronograma. 
Membros da equipe do projeto utilizam-no para entender o que precisam fazer, quando precisam fazê-lo e quais são as outras atividades das quais eles dependem. 
Escopo 
Este Plano de Desenvolvimento de Software descreve o plano geral a ser usado pelo protótipo de projeto GNC incluindo a implantação do produto. Este projeto reúne e sintetiza as seguintes Unidades de Softwares: PCD’s – Plataforma de Coleta de Dados. Os detalhes de iterações individuais serão descritos nos Planos de Iteração. Os planos, conforme especificado neste documento, baseiam-se nos requisitos do produto definidos no Documento de Visão. 
Este Plano de Desenvolvimento de Software contém as seguintes informações:
Visão Geral do Projeto — apresenta uma descrição da finalidade, do escopo e dos objetivos do projeto.  Também define os produtos que se espera que o projeto libere.
Organização do Projeto — descreve a estrutura organizacional da equipe do projeto.
Processo de Gerenciamento — explica o custo estimado e o cronograma, define os principais marcos e fases do projeto e descreve como o projeto será monitorado.
Planos e Diretrizes aplicáveis — apresentam uma visão geral do processo de desenvolvimento do software, abrangendo métodos, ferramentas e técnicas a serem seguidos.
Gerenciamento de Requisitos
Os requisitos desse sistema são capturados no Documento de Visão. As mudanças solicitadas nos requisitos são capturadas nas Solicitações de Mudança e são aprovadas como parte do processo de Gerenciamento de Configuração. 
Controle de Cronograma e Orçamento
As despesas são monitoradas pelo gerente de projeto, e reportadas e avaliadas mensalmente. (Consulte Relatórios e Métricas abaixo).
O gerente de projeto mantém uma programação mostrando a data esperada de cada marco. Os itens de linha na programação incluem pacotes de trabalho atribuídos a pessoas. Cada pessoa a quem é atribuído um pacote de trabalho fornece ao gerente do projeto informações sobre o percentual de conclusão das tarefas semanalmente. As mudanças na programação ficarão a cargo dos patrocinadores do projeto, que decidirão se o escopo será alterado a fim de preservar as datas-alvo de conclusão.
Controle de Qualidade
Os defeitos serão registrados e monitorados como Solicitações de Mudança, e as métricas de defeito serão coletadas (consulte Relatórios e Métricas abaixo).
Será necessário que todos os produtos liberados sejam submetidos ao processo de revisão adequado, conforme está descrito no Caso de Desenvolvimento. A revisão é necessária para assegurar que cada produto liberado seja de qualidade aceitável, usando as orientações descritas nos pontos de verificação e nas diretrizes de revisão do RUP para Projetos Pequenos.
Todos os defeitos encontrados durante a revisão que não forem corrigidos antes da liberação para integração deverão ser capturados como Solicitações de Mudança para que não sejam esquecidos.
Um exemplo disso são as linhas de produtos de aplicações que são criadas com base em um núcleo de arquitetura com variações que satisfazem os requisitos específicos do cliente.
Ao se projetar uma arquitetura de sistema, necessita-se decidir o que seu sistema e classes mais amplas de aplicação têm em comum, e decidir quanto conhecimento dessas arquiteturas de aplicação pode-se reusar.
	A arquitetura de um sistema de software pode ser baseada em um modelo ou estilo de arquitetura específico. Um estilo de arquitetura
é um padrão de organização de sistema (Garlan e Shaw, 1993). Como uma organização cliente-servidor ou uma arquitetura em camadas.
O sistema possibilita ao cliente atualizar seus dados cadastrais acessando o site na internet.
A organização de um sistema requer uma estratégia básica utilizado para estruturá-lo e necessita-se tomar decisões sobre o modelo geral organizacional de um sistema com antecedência no processo de projetos de arquitetura.
A organização do sistema pode refletir-se diretamente na estrutura do subsistema. É freqüente que o modelo de subsistema inclua mais detalhes que o modelo de organização, nem sempre há um mapeamento simples dos subsistemas para a estrutura organizacional. 
Arquitetura de sistemas distribuídos - 	Sabe-se que quase todos os sistemas baseados em grandes computadores atualmente são sistemas distribuídos.
O desafio é projetar o software e o hardware para fornecer os recursos de sistema distribuído desejáveis e ao mesmo tempo, minimizar os problemas inerentes a esses sistemas.
Arquitetura cliente-servidor: funciona como um conjunto de serviços fornecidos aos clientes que fazem uso desses serviços. De modo que os servidores e clientes são tratados de maneira diferente nesses sistemas.
Os clientes e servidores são processos separados, que é um modelo lógico de uma arquitetura cliente-servidor distribuída. A arquitetura cliente-servidor mais simples é chamada de arquitetura cliente-servidor de duas camadas, na qual uma aplicação é organizada como um servidor ou vários servidores idênticos e um conjunto de clientes. As arquiteturas cliente-servidor podem ter duas formas: modelo cliente-magro e modelo cliente-gordo.
Uma arquitetura cliente-magro de duas camadas é a abordagem mais simples a ser usada quando sistemas legados centralizados evoluem para uma arquitetura cliente-servidor. A interface com o usuário desses sistemas migra para PCs, e a aplicação em si atua como um servidor e cuida de todo o processamento da aplicação de do gerenciamento de dados.
O modelo cliente-gordo faz uso dessa capacidade de processamento disponível e distribui o processamento lógico de aplicação e a apresentação ao cliente. O servidor é essencialmente um servidor de transações que gerencia todas as transações de banco de dados. Um exemplo desse tipo de arquitetura são os sistemas de caixas eletrônicos de bancos, nos quais o caixa eletrônico é o cliente e o servidor é um mainframe que realiza operações sobre o banco de dados de contas dos clientes.
Arquitetura de Aplicações - Sistemas de aplicações são criados para atender algumas necessidades de negocio ou organizacionais. Todos os negócios têm muito em comum, eles necessitam contratar pessoas, emitir faturas, administrar as contas e outros. Um dos vários modelos de aplicações é a aplicações de processamento de dados: que é voltada a dados: 
Elas processam dados em lotes sem intervenções explicitas do usuário durante o processamento. As ações específicas tomadas pela aplicação dependem dos dados que são processados.
Os sistemas de processamento em lotes são normalmente usados em aplicações de negócios nas quais as operações similares são realizadas sobre uma grande quantidade de dados.
Tratam de uma grande variedade de funções administrativas.	Escolhi esse tipo de sistema especifico pelo fato de representarem a maioria dos sistemas em uso atualmente. Sistemas de negócios são em geral sistemas de processamento de dados ou transações, e a maioria dos softwares de computadores pessoais é construída em torno de uma arquitetura de processamento de eventos. Sistema de tempo real também conta com sistemas de processamento de linguagem, como os compiladores.
Gerenciamento de configurações - O plano de gerenciamento de configurações descreve os padrões e procedimentos que devem ser usados para o gerenciamento. o ponto de partida para o desenvolvimento do plano deve ser um conjunto de padrões de configuração, que deve ser adaptados para se atender aos requisitos e as restrições de cada projeto especifico. 
Como se pode perceber pela especificação de requisitos para o sistema em questão, não há grandes restrições de desempenho e disponibilidade, ainda que algumas restrições tenham sido explicitamente apontadas. Assim, levando-se em consideração os requisitos para o sistema proposto, foram considerados como os principais atributos de qualidade a serem incorporados ao sistema os seguintes, apresentados juntamente com as táticas a serem aplicadas: Usabilidade: o Separar a interface do restante da aplicação. O prover ao usuário a capacidade de entrar com comandos que permitam operar o sistema de modo mais eficiente. Para tal, as interfaces do sistema devem permitir, sempre que possível, a entrada por meio de seleção ao invés da digitação de campos como: 
Manutenibilidade o Coerência semântica: a organização do sistema deve se dar de modo que as responsabilidades em um módulo trabalhem em conjunto sem depender excessivamente de outros módulos;
Uso de interfaces com ocultação de informações específicas sobre a implementação dos módulos;
Uso de um intermediário para isolar o mecanismo de persistência de dados;
Uso de um intermediário para tratar as requisições da interface.
Segurança: o Autenticar usuários usando login e senha;
Autorizar usuários, criando os seguintes grupos: (I) Gerente de Acervo – acesso às funcionalidades do controle de acervo; (II) Atendente – acesso às funcionalidades de atendimento a clientes; (III) Administrador – acesso geral a todas as funcionalidades do sistema, incluindo o cadastro de usuários. Limitar a exposição, disponibilizando pela Internet somente funcionalidades de consulta ao acervo.
Manter uma trilha de auditoria para as operações de atendimento ao cliente, sempre registrando o atendente que efetuou uma locação ou devolução (e, por conseguinte, um pagamento).
Ainda que os demais atributos de qualidade não tenham sido considerados como sendo condutores da arquitetura, algumas táticas foram aplicadas visando garantir o nível de atendimento requerido. A seguir, as táticas consideradas são listadas:
Desempenho: o Reduzir overhead computacional em situações que não comprometam a manutenibilidade. Estabelecer uma configuração de hardware mínima para comportar o sistema.
Disponibilidade: uso de exceções e transações para detecção, tratamento e prevenção de falhas. 
Portabilidade: uso da linguagem Java web e de bibliotecas e mecanismos de persistência capazes de rodar em qualquer navegador e sistemas operacionais Windows e Linux.
Os Procedimentos de gerenciamento de mudança dizem respeito a analise de custo e beneficio das mudanças propostas, a provação das mudanças viáveis rastreabilidade de quais componentes do sistema foram alterados. O processo de gerenciamento de mudanças deve surtir efeito quando o software ou a documentação associada são colocados em baseline pela equipe de gerenciamento de configurações. 
Sommerville, Ian. Engenharia de Software, 6ª edição.
	Os processos envolvidos no gerenciamento de versões preocupam-se com a identificação e a manutenção da rastreabilidade das versões de um sistema. Uma versão de sistema é uma instancia de sistema que diferem, de alguma maneira, de outra instancias. Versões de sistema podem ter funcionalidades distintas, desempenho aprimorado ou defeito de software reparado. Algumas versões podem ser funcionalmente equivalentes, mais projetadas para diferentes configurações de hardware e software. Versões com somente pequenas diferenças são as vezes chamadas de variantes. 
DESAFIO 2 - BASEADO NO PMBOK
A Estrutura Analítica de Projetos é uma ferramenta imprescindível no gerenciamento de projetos. A EAP reúne, em um único documento, aspectos de Escopo, Tempo e Custo. Não apenas reúne, mas promove um melhor planejamento desses aspectos.
Organograma do Projeto
O desenvolvimento da EAP é a decomposição do trabalho necessário para a realização de um projeto. O raciocínio é simples, é necessário
dividir o projeto em pacote de trabalhos organizados de cima para baixo hierarquicamente. 
Vejamos o exemplo simplificado da construção de uma casa:
Os pacotes são decompostos até um nível que permita um planejamento mais preciso do trabalho:
	Função
	Atribuição
	Gerente de Projetos
	Desenvolver o escopo e plano do gerenciamento do projeto. Elaborar o prospecto de serviços de procedimento de TI. Gerenciar toda a execução do projeto.
	Analista de Sistemas
	Analisar as rotinas de trabalho fazer as customizações. Desenvolver as novas rotinas para o sistema. Gerenciar a equipe de programação e implantação.
	Analista de Banco de Dados
	Instalar e configurar banco de dados. Realizar testes e auxiliar o Gerente de TI no planejamento do projeto.
	Analista de Suporte
	Gerenciar a equipe de implantação. Instalar o sistema, parametrizar o sistema, realizar testes e treinamento de usuários chaves. Auxiliar o Gerente de Projetos no planejamento do projeto
	Programador / Analista de sistema
	Desenvolvimento das rotinas, manutenção e customização. 
	Técnico de implantação
	Auxiliar a instalação, parametrização e realização de teste no sistema.
Deve - se estimar apenas os pacotes do último nível. O esforço necessário para desenvolver o trabalho no nível acima será dado pela soma dos esforços dos pacotes que o compõem:
E assim sucessivamente até o primeiro nível da EAP, para que possamos ter o esforço total necessário para empreendimento do projeto:
Tarefa Custo Estimado
	Sistema de Gerenciamento de Call Center – SGC
	1
	Gerenciamento do Projeto
	R$ 15.000,00
	2
	Desenvolver o termo de abertura do projeto
	R$ 2.000,00
	3
	Reunião de partida da equipe 
	R$ 1.000,00
	4
	 Identificar as partes interessadas
	R$ 1.000,00
	5
	 Coletar e documentar requisitos 
	R$ 1.000,00
	6
	 Desenvolver a declaração do escopo do projeto 
	R$ 1.000,00
	7
	 Desenvolver o plano de gerenciamento do projeto 
	R$ 1.000,00
	8
	 Gestão de Recursos 
	R$ 1.000,00
	9
	 Gestão de Tempo 
	R$ 1.000,00
	10
	Gestão da Qualidade 
	R$ 1.000,00
	11
	Gestão de Riscos
	R$ 1.000,00
	12
	Gestão de Aplicações
	R$ 1.000,00
	13
	Gestão de Custo%
	R$ 1.000,00
	14
	Aquisição de Equipamentos
	R$ 1.000,00
	15
	Plano cie gerenciamento do projeto 
	R$ 1.000,00
	16
	Analise e Desenvolvimento 
	R$ 1.000,00
	17
	Analise de Sistemas 
	R$ 1.000,00
	18
	Analise das Rotinas atuais 
	R$ 1.000,00
	19
	Analise dos Documentos utilizados
	R$ 1.000,00
	20
	Criar Relatórios de mudanças 
	R$ 1.000,00
	21
	Reunião para apresentação e aprovação das mudanças 
	R$ 1.000,00
	22
	Desenvolvimento 
	R$ 1.000,00
	23
	Reunião apresentação das mudanças pra equipe de desenvolvimento
	R$ 1.000,00
	24
	 1ª Fase Desenvolvimento da customização 
	R$ 1.000,00
	25
	 Reunião de Apresentação 1ª Fase
	R$ 1.000,00
	26
	2ª Fase Desenvolvimento da customização
	R$ 1.000,00
	27
	Fase de integração do sistema 
	R$ 1.000,00
	28
	Testes do Sistema 
	R$ 1.000,00
	29
	Auditoria e finalização do sistema
	R$ 1.000,00
	30
	Instalação e adequação
	R$ 6.000,00
	31
	Valor Total
	R$ 50.000,00
É comum a divisão de um projeto em fases e essa análise pode ser transportada para a EAP. Um modelo bastante comum de EAP é uma decomposição de três níveis. O nível mais abrangente é o projeto. 
As fases do projeto compreendem o segundo nível e os pacotes de trabalho o terceiro nível:
Não existe limitação quanto aos níveis da EAP. Você precisa decompor o trabalho até um nível que possa fazer uma boa avaliação dos esforços necessários para realizá-lo; todavia, uma EAP com muitos níveis pode acarretar numa EAP de difícil leitura.
DESAFIO 3 - PROGRAMAÇÃO JAVA WEB
As tecnologias voltadas para o desenvolvimento de aplicações WEB têm mudado constantemente, como sabemos, inicialmente os sites possuíam apenas conteúdo estático, ou seja, o conteúdo de uma página não podia ser modificado em tempo de execução. Depois, os sites passaram a oferecer páginas com conteúdo dinâmico e personalizado. 
 JSF (Java Serer Faces) é a tecnologia Java para construção de páginas dinâmicas. Primefaces é uma biblioteca de componentes para RIA – Rich Internet Application, o que torna os sistemas com uma interface mais amigável para os usuários. Hibernate é um framework para o mapeamento objeto-relacional. Facilita o mapeamento dos atributos entre um Banco de dados Relacional e o modelo de objetos de uma aplicação.
 A arquitetura Model-view-controller (MVC), em português modelo-visão-controlador, é um padrão de arquitetura de software que separa a representação da informação da interação do usuário com ele. O modelo (model) consiste nos dados da aplicação, regras de negócios, lógica e funções, define o comportamento do sistema, implementando os Beans. Uma visão (view) pode ser qualquer saída de representação dos dados, como uma tabela ou um diagrama, define a camada de visualização. É possível ter várias visões do mesmo dado, como um gráfico de barras para gerenciamento e uma visão tabular para contadores. O controlador (controller) faz a mediação da entrada, convertendo-a em comandos para o modelo ou visão, define as regras de negócio da aplicação.
Projeto - Vamos criar um CRUD, para quem ainda não acostumou com o termo “Create (Criar), Read (Ler), Update (Alterar), Delete (Excluir) ”, iremos implementar um cadastro de clientes. No desenvolvimento desse projeto vamos utilizar o NetBeans 7 com suporte a JSF 2.0, Hibernate 3.6.4 Final, Primefaces 2.2.1 Final, para o banco de dados será o MySql 5. 
 Vamos desenvolver um cadastro de clientes, para isso vamos utilizar o padrão MVC, esse modelo visa separa as classes de acordo com suas responsabilidades, iremos criar pacotes chamados de: Model, View e Controller para visualizarmos com mais facilidade o padrão na prática.  A princípio nosso cliente terá as seguintes informações: nome, cpf ou cnpj, endereço, número, telefone, estado, cidade.
A tela final do trabalho ficara assim: ftp://sistema_sgc/
 
Janela Cliente:
Estrutura do sistema:
Aquivos de programação:
DESAFIO 4 - DIAGRAMAS DA UML
O tipo de arquitetura de sistema definido para o projeto é o Cliente x Servidor, onde:
Cliente interno: responsável pela lógica básica do aplicativo.
Cliente externo: responsável pela interface com o usuário via Internet (browser).
Servidor: será um servidor Apache o responsável pelo gerenciamento do acesso, por todas as funções relativas ao banco de dados e pelas “regras” ou “lógica” do negócio. Nesse servidor ficarão executando a aplicação do SGC e SGBD – Sistema de Gerenciamento Call Center de Banco de Dados (MySQL), que é um banco de dados relacional gratuito, eficiente e otimizado para aplicações Web, multiplataforma, sendo compatível com os sistemas operacionais da família Windows e Linux e, também, com a linguagem de programação Java utilizada na construção do sistema. A conexão entre a aplicação e o banco dados será feita através de uma interface ODBC (Open Database Connectivity) utilizada para acesso de dados através de consultas SQL.
Dessa forma o projeto será constituído de duas camadas onde:
O papel da camada “Cliente” que será composta de
Gerenciamento de apresentação:
Interação com o usuário
Entrada e consulta de dados
Lógica do aplicativo:
Funcionamento do aplicativo 
Partes simples da lógica do negócio
Aplicativos de produtividade pessoal:
Processador de textos, planilha etc.
Navegador Web e Cliente de e-mail.
O papel da camada “Servidor” que será composta de:
Atendimento a Usuários:
Comunicação e autenticação de usuários
Atendimento a solicitações de clientes
Gerenciador de Banco de Dados:
Acesso e organização de registros/dados
 Seleção de registros/dados
Atualização de registros/dados
Execução de Regras do Negócio
Procedimentos armazenados no Banco de Dados
Processamento
de Transações
Conjuntos de operações relacionadas aos processos de negócio.
Diagrama de classe
Diagrama de classe de Domínio
Geração de Modelo físico – SQL
CREATE TABLE Gerência (
cod_func Numero(6),
codclient Numero(10),
FOREIGN KEY(cod_func) REFERENCES Funcionário (cod_func),
FOREIGN KEY(codclient) REFERENCES Cliente (codclient)
)
CREATE TABLE Cliente (
codclient Numero(10) PRIMARY KEY,
nclient Texto(60),
ruaclient Texto(60),
numero Texto(16),
telclient Numero(12),
cpfclient Numero(11),
cnh Texto(23),
rgclient Texto(11)
)
CREATE TABLE Atendimento (
protocolo Numero(11),
codclient Numero(10),
Agendaclient Texto(60),
atendclient Texto(40),
serviço Texto(50),
datainicio Numero(9),
datafinal Numero(7),
FOREIGN KEY(codclient) REFERENCES Cliente (codclient)
)
CREATE TABLE Funcionário (
cod_func Numero(6) PRIMARY KEY,
nomefunc Texto(60),
cargo Texto(50),
setorfunc Texto(50)
)
ALTER TABLE Gerência ADD FOREIGN KEY(codclient) REFERENCES Cliente (codclient)
ALTER TABLE Atendimento ADD FOREIGN KEY(protocol) REFERENCES Agenda Cliente (cod_bug)
Classes persistentes (ORM).
Diagrama de componentes
Diagrama de pacotes
5 Conclusão
Após a conclusão deste trabalho pude ter uma compreensão no que tange o processo de desenvolvimento de software diante do desenvolvimento do projeto de software e a sua importância na gestão das informações, também para assimilar processo de aprendizagem em todas as etapas do desenvolvimento de Sistemas de Informação, evidente que se faz necessário à organização e administração no processo de desenvolvimento de sistema para que os resultado tenham qualidade e eficiência para o efeito desejado. Também sabemos que nos dias atuais é impensável desenvolver uma aplicação sendo ela para qualquer plataforma sem pensar nos item essencial para segurança e requisitos, tambem nas estrutura de documentação e regulamentações. O PMBOK e a UML e requisitos para a java Web é para uma aplicação funcionar de forma adequada. Abordar a viabilização do desenvolvimento de sistema de informação analisado, incrementar o conhecimento em engenharia de software, gestão de projetos e programação para Web.
 
6 REFERÊNCIAS
ALENCAR, A. J., SCHMITZ, E. A., Análise de Risco em Gerência de Projetos. Rio de Janeiro, Editora Brasport, 2006.
TIOBE. TIOBE Programming Community Index. Disponível em: <http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html>. Acesso em 05 de Abril de 2015.
GONÇALVES, Edson. Desenvolvendo aplicações web com JSP, Servlet, Java Server Faces, Hibernate, EJB3 persistence, Ájax. Rio de Janeiro: Ciência Moderna, 2007.
SOMMERVILE, Ian. ENGENHARIA DE SOFTWARE. 6 Edição. São Paulo: Pearson Addison Wesley, 2005.
ENGENHARIA DE SOFTWARE. 8 Edição. São Paulo: Pearson Addison Wesley, 2007.
SHIP, H. M. L. Tapestry In Action. Greenwich: Manning, 2004.
ZIMBRÃO, Geraldo. Mapeamento Objeto-Relacional – Transforme um Modelo de 
Classes em um Modelo Relacional. Revista SQL Magazine, Rio de Janeiro: Neofício 
Editora v.5, ano 1, p.28-33, Edição 5, 2003. 
GAMMA, Erich et al. Padrões de Projeto: Soluções reutilizáveis de software Orientado a Objetos. Porto Alegre: Bookman, 2000.
TIOBE. TIOBE Programming Community Index. Disponível em: <http://www.tiobe .com/index.php/content/paperinfo/tpci/index.html>. Acesso em 05 de Abril de 2015.
�