Ariquemes
2015
XXXXXXXXXXXXXX
XXXXXXXXXXXXXX
XXXXXXXXXXXXX
Ariquemes
2015
SUMRIO
1
INTRODUO.......................................................................................................5
CONSIDERAES FINAIS........................................................................................23
REFERNCIAS...........................................................................................................23
1 INTRODUO
Foco no Cliente
Liderana
Tomada de Deciso
Fornecedor
Essa arquitetura de aplicao pode ser bastante genrica como
a arquitetura de sistemas de gerenciamento de informaes, ou muito mais
especficas.
Finalidade
6
A finalidade do Plano de Desenvolvimento de Software reunir
todas as informaes necessrias para controlar e gerenciar o prottipo de projeto
de Gerenciamento de Navegao e Controle GNC. Ele descreve a abordagem
dada ao desenvolvimento do software e o plano de nvel mais alto gerado e usado
pelos gerentes para coordenar o esforo 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
relao ao cronograma.
Membros da equipe do projeto utilizam-no para entender o que
precisam fazer, quando precisam faz-lo e quais so as outras atividades das quais
eles dependem.
Escopo
7
Controle de Cronograma e Oramento
As despesas so monitoradas pelo gerente de projeto, e reportadas
e avaliadas mensalmente. (Consulte Relatrios e Mtricas abaixo).
O gerente de projeto mantm uma programao mostrando a data
esperada de cada marco. Os itens de linha na programao incluem pacotes de
trabalho atribudos a pessoas. Cada pessoa a quem atribudo um pacote de
trabalho fornece ao gerente do projeto informaes sobre o percentual de concluso
das tarefas semanalmente. As mudanas na programao ficaro a cargo dos
patrocinadores do projeto, que decidiro se o escopo ser alterado a fim de
preservar as datas-alvo de concluso.
Controle de Qualidade
Os defeitos sero registrados e monitorados como Solicitaes de
Mudana, e as mtricas de defeito sero coletadas (consulte Relatrios e Mtricas
abaixo).
Ser necessrio que todos os produtos liberados sejam submetidos
ao processo de reviso adequado, conforme est descrito no Caso de
Desenvolvimento. A reviso necessria para assegurar que cada produto liberado
seja de qualidade aceitvel, usando as orientaes descritas nos pontos de
verificao e nas diretrizes de reviso do RUP para Projetos Pequenos.
Todos os defeitos encontrados durante a reviso que no forem
corrigidos antes da liberao para integrao devero ser capturados como
Solicitaes de Mudana para que no sejam esquecidos.
Um exemplo disso so as linhas de produtos de aplicaes que so
criadas com base em um ncleo de arquitetura com variaes que satisfazem os
requisitos especficos do cliente.
Ao se projetar uma arquitetura de sistema, necessita-se decidir o
que seu sistema e classes mais amplas de aplicao tm em comum, e decidir
quanto conhecimento dessas arquiteturas de aplicao pode-se reusar.
A arquitetura de um sistema de software pode ser baseada em um modelo ou
estilo de arquitetura especfico. Um estilo de arquitetura um padro de organizao
de sistema (Garlan e Shaw, 1993). Como uma organizao cliente-servidor ou uma
arquitetura em camadas.
8
estrutura do subsistema. freqente que o modelo de subsistema
inclua mais detalhes que o modelo de organizao, nem sempre h
um mapeamento simples dos subsistemas para a estrutura
organizacional.
Arquitetura de sistemas distribudos -
Sabe-se
que
quase
modelo
cliente-gordo
faz
uso
dessa
capacidade
de
9
Arquitetura de Aplicaes - Sistemas de aplicaes so criados
para atender algumas necessidades de negocio ou organizacionais. Todos os
negcios tm muito em comum, eles necessitam contratar pessoas, emitir faturas,
administrar as contas e outros. Um dos vrios modelos de aplicaes a aplicaes
de processamento de dados: que voltada a dados:
esse
tipo
de
sistema
especifico
pelo
fato
de
10
Manutenibilidade o Coerncia semntica: a organizao do sistema deve se
dar de modo que as responsabilidades em um mdulo trabalhem em conjunto sem depender
excessivamente de outros mdulos;
Uso de interfaces com ocultao de informaes especficas sobre a
implementao dos mdulos;
Uso de um intermedirio para isolar o mecanismo de persistncia de dados;
Uso de um intermedirio para tratar as requisies da interface.
Segurana: o Autenticar usurios usando login e senha;
Autorizar usurios, 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 usurios. Limitar a exposio, disponibilizando pela Internet somente
funcionalidades de consulta ao acervo.
Manter uma trilha de auditoria para as operaes de atendimento ao cliente,
sempre registrando o atendente que efetuou uma locao ou devoluo (e, por conseguinte, um
pagamento).
Ainda que os demais atributos de qualidade no tenham sido considerados
como sendo condutores da arquitetura, algumas tticas foram aplicadas visando garantir o nvel de
atendimento requerido. A seguir, as tticas consideradas so listadas:
Desempenho: o Reduzir overhead computacional em situaes que no
comprometam a manutenibilidade. Estabelecer uma configurao de hardware mnima para
comportar o sistema.
Disponibilidade: uso de excees e transaes para deteco, tratamento e
preveno de falhas.
Portabilidade: uso da linguagem Java web e de bibliotecas e mecanismos de
persistncia capazes de rodar em qualquer navegador e sistemas operacionais Windows e Linux.
11
Os
processos envolvidos
no
gerenciamento
de
verses
12
Organograma do Projeto
13
Os pacotes so decompostos at um nvel que permita um planejamento
mais preciso do trabalho:
Funo
Atribuio
Gerente de Projetos
Analista de Sistemas
Analista de Suporte
Programador / Analista de
sistema
Tcnico de implantao
R$ 15.000,00
R$ 2.000,00
14
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Valor Total
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 1.000,00
R$ 6.000,00
R$ 50.000,00
15
No existe limitao quanto aos nveis da EAP. Voc precisa
decompor o trabalho at um nvel que possa fazer uma boa avaliao dos esforos
necessrios para realiz-lo; todavia, uma EAP com muitos nveis pode acarretar
numa EAP de difcil leitura.
para
gerenciamento
uma
viso
tabular
para
contadores.
16
Final, para o banco de dados ser o MySql 5.
Vamos desenvolver um cadastro de clientes, para isso vamos utilizar o padro
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 padro na prtica. A princpio nosso cliente ter as seguintes
informaes: nome, cpf ou cnpj, endereo, nmero, telefone, estado, cidade.
A tela final do trabalho ficara assim: ftp://sistema_sgc/
Janela Cliente:
17
Estrutura do sistema:
Aquivos de programao:
18
ser
um
servidor
Apache
responsvel
pelo
Gerenciamento de apresentao:
19
Lgica do aplicativo:
Funcionamento do aplicativo
Atendimento a Usurios:
Seleo de registros/dados
Atualizao de registros/dados
Processamento de Transaes
Diagrama de classe
20
21
telclient Numero(13),
cpfclient Numero(11),
cnh Texto(20),
rgclient Texto(15)
)
CREATE TABLE Atendimento (
protocolo Numero(12),
codclient Numero(10),
Agendaclient Texto(60),
atendclient Texto(40),
servio Texto(60),
datainicio Numero(8),
datafinal Numero(8),
FOREIGN KEY(codclient) REFERENCES Cliente (codclient)
)
CREATE TABLE Funcionrio (
cod_func Numero(6) PRIMARY KEY,
nomefunc Texto(60),
cargo Texto(50),
setorfunc Texto(50)
)
ALTER TABLE Gerncia 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
22
Diagrama de pacotes
23
CONSIDERAES FINAIS
Este
trabalho
proporcionou
uma
reflexo
no
processo
de
REFERNCIAS
24
SHIP, H. M. L. Tapestry In Action. Greenwich: Manning, 2004.
TIOBE.
TIOBE
Programming
Community
Index.
Disponvel
em:
<http://www.tiobe .com/index.php/content/paperinfo/tpci/index.html>. Acesso em 05
de Abril de 2015.
ZIMBRO, Geraldo. Mapeamento Objeto-Relacional Transforme um Modelo de
Classes em um Modelo Relacional. Revista SQL Magazine, Rio de Janeiro: Neofcio
Editora v.5, ano 1, p.28-33, Edio 5, 2003.
TIOBE.
TIOBE
Programming
Community
Index.
Disponvel
em:
<http://www.tiobe .com/index.php/content/paperinfo/tpci/index.html>. Acesso em 05
de Abril de 2015.
25