portifolio em grupo
DESCRIPTION
Excelente trabalho em grupoTRANSCRIPT
Tailândia - PA2015
ELISSANDRO SOARES DA COSTAGUSTAVO DOS REIS NUNES
KEITON STEFANY PEREIRA DOS SANTOSTIELE MODESTO SILVA
SISTEMA DE ENSINO PRESENCIAL CONECTADOANÁLISE E DESENVOLVIMENTOS DE SISTEMAS DE INFORMAÇÃO.
PORTIFOLIOPRODUÇÃO TEXTUAL INTERDISCIPLINAR - GRUPO
Tailândia2015
PORTIFOLIOPRODUÇÃO TEXTUAL INTERDICIPLINAR - GRUPO
Trabalho interdisciplinar individual de Análise em Desenvolvimento de Sistemas, apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média no quarto semestre nas disciplinas de Engenharia e Projeto de Software, Projeto Orientado a Objetos e Programação Para Web II.
Professores: Luis Claúdio Perini Marco Ikuro Hisatomi Márcio Roberto Chiaveli Veronice de Freitas
ELISSANDRO SOARES DA COSTAGUSTAVO DOS REIS NUNES
KEITON STEFANY PEREIRA DOS SANTOSTIELE MODESTO SILVA
Sumário1 OBJETIVO............................................................................................................3
2 INTRODUÇÃO......................................................................................................4
3 ENGENHARIA E PROJETO DE SOFTWARE (DESAFIO 1)...............................5
3.1 Projeto da Arquitetura....................................................................................5 Identificar requisitos relevantes à arquitetura;...............................................5 Classificar e priorizar requisitos relevantes à arquitetura;.............................5 Identificar riscos e restrições;........................................................................5 Atacar maiores riscos técnicos;.....................................................................5 Desenvolver Visão geral da arquitetura;........................................................5 Definir organização de alto nível;..................................................................5 Identificar mecanismos de análise;...............................................................5 Promover o reuso;.........................................................................................5 Avaliar a arquitetura......................................................................................53.1.1 Identificar requisitos relevantes à arquitetura.........................................63.1.2 Classificar e priorizar requisitos relevantes à Arquitetura......................73.1.3 Identificar riscos e restrições..................................................................83.1.4 Atacar maiores riscos técnicos...............................................................83.1.5 Desenvolver a visão geral da arquitetura...............................................83.1.6 Definir organização lógica de alto nível..................................................93.1.7 Identificar mecanismos de análise.......................................................103.1.8 Promover o reuso.................................................................................103.1.9 Avaliar a arquitetura.............................................................................11
4 GERENCIAMENTO DO PROJETO (BASEADO NO PMBOK- DESAFIO 2)......12
4.1 EAP (Estrutura analítica do Projeto)............................................................124.2 CRONOGRAMA DO PROJETO..................................................................134.3 Relação dos envolvidos, papéis dentro do projeto......................................14
4.3.1 Patrocinador do Projeto........................................................................144.3.2 Equipe de Projeto.................................................................................154.3.3 Partes Interessadas.............................................................................164.3.4 Gerente de Projeto...............................................................................174.3.5 Gerente de Programas.........................................................................18
5 FORMULÁRIO PARA LANÇAMENTO DE EMPRÉSTIMO (DESAFIO 3)..........20
6 DIAGRAMAS PARA REPRESENTAR A ARQUITETURA DO SISTEMA (UML-
DESAFIO 4)...............................................................................................................21
6.1 Diagrama de Classe:...................................................................................216.2 Diagrama de Componentes.........................................................................226.3 Diagrama de Pacotes..................................................................................22
7 CONCLUSÃO.....................................................................................................24
8 REFERÊNCIAS BIBLIOGRÁFICAS...................................................................25
3
1 OBJETIVO
O presente trabalho tem por objetivo, ampliar nossos conhecimentos nas
áreas de Engenharia e Projeto de Software, Programação para Web II e Projeto
Orientado a Objetos mostrando os desafios dos mesmos, assim como o passo a
passo do desenvolvimento. Familiarizando o leitor como os métodos utilizados.
2 INTRODUÇÃO
Levantamos uma pesquisa junto a empresa Extra Informática, CNPJ
Nº 15.334.029/0001-87, Localizado à Avenida Para, 269, Bairro Piçarreira, CEP
68695-000, Tailândia Pará, a qual trabalha com prestação de serviços e
desenvolvimento de software, sobre informações para a elaboração de um plano de
desenvolvimento de software para o modelo de uma biblioteca Escolar, visando à
automatização através do controle de Usuários, Livros, Alunos, Empréstimos,
Devoluções, Reservas dentre outros.
O software terá a finalidade de efetuar o cadastramento de usuários
do software, a Escola, cadastramento dos livros, Editoras, Autores, Leitores
(Alunos), reserva de livros pelos leitores, sistema de impressão de etiquetas para os
Livros, sistema de lembrete, caso o leitor atrase a entrega do livro, baixa no sistema
para liberar leitor para próxima locação, todos esses requisitos funcionando em
comunicação com o banco de dados, armazenando todos os processos.
3 ENGENHARIA E PROJETO DE SOFTWARE (DESAFIO 1)
3.1 PROJETO DA ARQUITETURA
Sistema para Biblioteca Escolar – “BE System”
Utilizaremos para representação da Arquitetura do software o Modelo 4+1 de
Philippe Kruchten
Identificar requisitos relevantes à arquitetura;
Classificar e priorizar requisitos relevantes à arquitetura;
Identificar riscos e restrições;
Atacar maiores riscos técnicos;
Desenvolver Visão geral da arquitetura;
Definir organização de alto nível;
Identificar mecanismos de análise;
Promover o reuso;
Avaliar a arquitetura.
3.1.1 Identificar requisitos relevantes à arquitetura
Requisitos Funcionais – Casos de Uso:
a) Cadastro do Acervo (Livros e Revistas).
b) Cadastro de Alunos (Leitores).
c) Empréstimo.
d) Reserva.
e) Cancelamento.
f) Devolução.
Visão de Casos de Uso
Principais requisitos de qualidade (não-funcionais)a) Leitor pode fazer sua reserva remotamente (WWW) de forma segura.
b) Pico de 1000 acessos simultâneos.
c) Tempo de resposta para reserva: 6 seg.
d) A interface para o Usuário (funcionário) deve ser rica (Gráfica, etc) e
acessível pela internet.
e) Disponibilidade do sistema de 99,9%.
f) Estimativa de crescimento de 25% ao ano.
Identificação dos casos de uso críticosa) Reserva.
b) Empréstimo.
C) Devolução.
d) Login.
e) Cadastro de Aluno (Leitor).
f) Cadastro de Acervo (Livros e Revistas).
3.1.2 Classificar e priorizar requisitos relevantes à Arquitetura
Requisito de Qualidade Classificação
Reserva Online para Alunos (Leitores) Cadastrados Segurança
Pico de 1000 acessos simultâneos Segurança
Tempo de resposta de reserva 6 seg. Performance
A interface para o Usuário (funcionário) deve ser rica Usabilidade
Disponibilidade do sistema de 99,9% Disponibilidade
Estimativa de crescimento de 25% ao ano Escalabilidade
Aviso de Atraso na Devolução do empréstimo Interoperabilidade
a) Priorização dos casos de uso arquiteturalmente significativos
b) Rastreabilidade entre Requisitos funcionais e não-funcionais.
Ordem Caso de Uso Requisitos Suplementares
1 Reserva Online Segurança, Performance, Interoperabilidade,
disponibilidade
2 Empréstimo Usabilidade
3 Devolução Usabilidade, Performance
3.1.3 Identificar riscos e restrições
Principais restrições identificadas:
a) O Sistema de identificação do Aluno (Leitor) dever ser realizado
através de webservices no momento da reserva online.
b) O servidor de aplicações deve ser o Sun GlassFish.
c) O SGBD deve ser o MySQL 10GB.
d) A aplicação web deve ser compatível com IE 7 e Firefox 3 ou
versões superiores.
Principais riscos identificados.
a) Apesar de ser compatível com J2EE, o servidor de aplicações não é
conhecido pelos desenvolvedores.
3.1.4 Atacar maiores riscos técnicos
Ações de mitigação a riscos e aos requisitos de qualidade mais
severos.
Riscos ou requisitos Severo Mitigação
Performance Teste de stress sobre a Reserva Online
Disponibilidade Teste de maturidade
Escalabilidade POC Cluster
Avaliação servidor de aplicação POC avaliação, Capacitação da Equipe
3.1.5 Desenvolver a visão geral da arquitetura
a) Explorar e avaliar opções arquiteturais de alto nível.
b) Prover um entendimento da estrutura para os patrocinadores e demais
stakeholders.
c) Levar em consideração:
Designer da rede pré-existente
Banco de dados pré-existentes
Ambiente web
Configuração dos servidores
Uso de padrões.
d) Produto típico: modelo de implantação preliminar
Visão de Implantação
3.1.6 Definir organização lógica de alto nível
a) Criar uma estrutura inicial para o modelo design.
b) Mostrar pacotes de desenho arquiteturalmente significativos.
Visão lógica utilizando um padrão MVC
3.1.7
Identificar mecanismos de análise
a) O que é necessário para “dar vida” aos componentes.
b) Alguns mecanismos de análise:
Persistência
Gerência de Transações
Redundância
Troca de Informações
3.1.8 Promover o reuso
a) Identificar ativos pré-existentes que possam colaborar para a solução.
b) Realizar uma avaliação preliminar.
Redução de custos e riscos.
Não reinventar a roda!
3.1.9 Avaliar a arquitetura
a) O objetivo é rever o resultado e analisar alternativas.
Avaliação do grau de atendimento dos requisitos de qualidade.
Utilização de checklists para validação
Métodos clássicos: ATAM, CBAM, SAAM, e ARID (SEI 0 Carnegie
Mellon)
b) Ferramentas de análise estrutural e arquitetural podem auxiliar na
avaliação arquitetura e conformidade do código
Rational software Architect
SA4J
Metrics (plugin do Eclipse)
SourceMonitor
JDepend
4 GERENCIAMENTO DO PROJETO (BASEADO NO PMBOK- DESAFIO 2)
4.1 EAP (ESTRUTURA ANALÍTICA DO PROJETO)
4.2 CRONOGRAMA DO PROJETO
ID
EAPNome da Tarefa Duração Início Término
Nomes dos
Recursos
1 TELAS 30 DIAS 01/06/2015 01/07/2015 Eq
uip
e d
e Pro
gram
ação
1.1 Login - - -
1.2 Cadastros - - -
1.3 Reserva / Empréstimos/
Devolução /
Cancelamento
- - -
1.4 Consulta / Status
Empréstimos- - -
2 SEGURANÇA 45 DIAS 01/06/2015 15/07/2015Gerente de
Projetos2.1 Perfil do Usuário
(Funcionário)- - -
2.2 Acesso (Permissão)- - -
Gerente de
Projetos
2.3 Interface Web- - -
Desenvolvimento
de Software
3 EQUIPE/SOFT 20 DIAS 10/06/2015 30/06/2015Gerente de
Projetos3.1 Cotação de Servidores - - -
3.2 Uso de Serviços - - -Gerente de
Projetos
3.3 Instalação / Conf. SGBD - - -Desenvolvimento
de Software
3.4Envio de dados,
Armazenamento, Backup- - -
Desenvolvimento
de Software
4 TREINAMENTO 45 DIAS 01/07/2015 15/08/2015
Geren
te de
Pro
jeto e
Eq
uip
e d
e
Pro
gra
ma
ção
4.1Plano,
Treinamento- - -
4.2 Cronograma - - -
4.3 Documentação - - -
5 IMPLEMENTAÇÃO 20 DIAS 15/08/2015 05/09/2015Equipe de
Desenvolvimento
de Software5.1
Operações:
Adicionar, Excluir,
Atualizar, Gravar
- - -
5.2Manutenção Perfectiva,
Corretiva- - -
Equipe de
Programação
4.3 RELAÇÃO DOS ENVOLVIDOS, PAPÉIS DENTRO DO PROJETO
4.3.1 Patrocinador do Projeto
A empresa pesquisada (Extra Informática) também está engajada no
projeto, participando como Patrocinador. A seguir algumas de suas atribuições:
4.3.1.1 Durante a iniciação do projeto
O patrocinador é responsável financeiro e moral do projeto;
É uma parte interessada;
Atua como o porta-voz do projeto para a alta administração;
Obtém o apoio apropriado para o projeto;
Fornece o financiamento;
Fornece a declaração do trabalho do projeto (SOW);
Fornece informações que ajudam a desenvolver o termo de abertura
do projeto;
Define prioridades entre os projetos.
4.3.1.2 Durante o planejamento do projeto
Pode revisar a EAP;
Disponibiliza tempo para a equipe planejar o projeto;
Fornece a lista dos riscos;
Fornece opinião de especialista;
Aprova o plano final de gerenciamento do projeto.
4.3.1.3 Durante a execução, monitoramento e controle
Protege o projeto de influências externas e mudanças;
Aplica políticas de qualidade;
Fornece opinião de especialista;
Soluciona conflitos que vão alem do controle do gerente de projetos;
Aprova ou rejeita mudanças;
Esclarece questões de escopo;
Trabalha com o gerente de projetos para monitorar o progresso.
4.3.1.4 Durante o encerramento do projeto
Fornece a aceitação formal das entregas do projeto;
Apoia a coleta de registros históricos de projetos anteriores.
4.3.2 Equipe de Projeto
Suas funções:
Identificar e envolver as partes interessadas;
Identificar os Requisitos;
Identificar restrições e premissas;
Criar a EAP;
Decompor os pacotes de trabalho em atividades;
Identificar dependências entre as atividades;
Fornecer estimativas de tempo e custo;
Participar da identificação dos riscos;
Cumprir os planos de qualidade e comunicações;
Realizar o trabalho definido na declaração de escopo do projeto;
Participar das reuniões;
Conduzir melhorias nos processos;
Recomendar mudanças no projeto (inclusive corretivas).
4.3.3 Partes Interessadas
Podem estar envolvidas:
No desenvolvimento do plano de gerenciamento do projeto;
Na aprovação de mudanças no projeto;
Fazendo parte do comitê de controle de mudanças;
Verificando o Escopo;
Na Identificação das Restrições;
Na Identificação dos Requisitos;
No Gerenciamento dos Riscos.
Criação do project charter e na declaração de escopo do projeto
4.3.3.1 Gerentes funcionais
Melhorar a utilização do pessoal;
Ajudar em problemas relacionados ao desempenho dos membros da
equipe;
Gerenciar as atividades que ocorrem em sua área funcional;
Recomendar mudanças no projeto, inclusive ações corretivas;
Aprovar o plano final de gerenciamento do projeto, durante o seu
desenvolvimento;
Aprovar o cronograma final, durante o seu desenvolvimento;
Fornecer sua experiência no assunto;
Participar o planejamento do projeto até que os pacotes de trabalho
estejam designados;
Informar o gerente do projeto sobre outros projetos que podem ter
impacto em seu projeto;
Podem designar pessoas específicas e negociar recursos com o
gerente do projeto.
4.3.4 Gerente de Projeto
Responsável por gerenciar o projeto a fim de cumprir os seus objetivos
propostos
É designado para o projeto na fase inicial ou antes.
Pode ajudar na elaboração do termo de abertura
É o responsável pelo projeto,
MAS NÃO NECESSARIAMENTE PELOS RECURSOS
Não precisa ser um especialista técnico
Influencia a equipe do projeto e o ambiente no qual a equipe trabalha:
Promovendo boa comunicação;
Evitando que a equipe tenha que lidar com questões políticas;
Realçando aspectos positivos de diferenças culturais;
Solucionando problemas.
Promove interações profissionais entre a equipe e outras partes interessadas
Seleciona os processos adequados para o projeto
Identifica e analisa restrições e premissas
Lidera e orienta os esforços de planejamento do projeto
Identifica dependências entre as atividades
Deve entender que um cronograma irrealista é uma falha do Gerente de
Projetos
Sabe como lidar com essas situações
Compreende e faz cumprir a responsabilidade social e profissional
Determina e entrega os níveis de qualidade necessários
Auxilia a equipe e outras partes interessadas na execução do projeto
Define o plano de gerenciamento de mudanças do projeto
Determina a necessidade de solicitações de mudanças, incluindo ações
corretivas e preventivas recomendadas e o reparo de defeitos, além de
aceitar ou rejeitar mudanças dentro de sua autoridade, ou enviar solicitações
de mudanças ao comitê de controle de mudanças
Mantém o controle sobre o projeto medindo o desempenho e determinando
se são necessárias mudanças
Usa métricas para verificar se há variações e tendências no trabalho do
projeto
Trabalha com a equipe para solucionar variações em relação ao plano de
gerenciamento do projeto
Desenvolve reservas de tempo e custo para o projeto
Deve ter a responsabilidade e autoridade necessárias para realizar o trabalho
de gerenciamento do projeto
DEVE DIZER "NÃO" QUANDO NECESSÁRIO
É a única pessoa que pode integrar os componentes do projeto em uma
unidade coesa que atenda às necessidades do cliente
Dedica mais tempo à ser proativo do que à solucionar problemas
É responsável pelo sucesso ou fracasso do projeto
Realiza o encerramento do projeto no final de cada fase e o encerramento do
projeto como um todo
Realiza ou delega a maioria das atividades de Gerenciamento do Projeto
Aplica seus conhecimentos sobre Gerenciamento de projetos e usa sua
habilidade pessoal e de liderança para que o Projeto seja bem sucedido
4.3.5 Gerente de Programas
Responsável por Gerenciar um grupo de projetos relacionados
Gerenciar projetos relacionados para alcançar resultados que não seriam
obtidos gerenciando cada projeto separadamente
Assegurar que os projetos selecionados ofereçam apoio aos objetivos
estratégicos da organização
Supervisionar para ajustar os projetos para benefício do programa
Orientar e oferecer apoio aos esforços individuais do GP
Relação entre as Partes Interessadas
Cadastro e relatório Utilizando Java Web
Projeto BE System – Eclipse
Banco MYSQL
5 FORMULÁRIO PARA LANÇAMENTO DE EMPRÉSTIMO (DESAFIO 3)
Relatório de Empréstimos
6 DIAGRAMAS PARA REPRESENTAR A ARQUITETURA DO SISTEMA (UML-
DESAFIO 4)
6.1 DIAGRAMA DE CLASSE:
a) Classes de Domínios
b) Classes persistentes (ORM)
6.2 DIAGRAMA DE COMPONENTES
6.3 DIAGRAMA DE PACOTES
7 CONCLUSÃO
Concluindo podemos afirmar que com a evolução das tecnologias há
uma desenvoltura em todas as áreas. Como este portifólio que foi explanado sobre o
sistema bibliotecário, adquirimos um pouco sobre de como fazer propostas de
projetos, como gerencia-lo e revendo sobre alguns diagramas.
Em suma, obtive crescimento do conhecimento na área das
respectivas matérias abrangidas por este portfólio.
8 REFERÊNCIAS BIBLIOGRÁFICAS
1. BADKE, Todêsca. Biblioteca popular: uma experiência no bairro das Laranjeiras. Palavra-Chave, São Paulo, n. 4, p. 18-9, maio, 1984.
2. DAMASIO, Edilson; RIBEIRO, Carlos Eduardo N. Software livre para bibliotecas, sua importância e utilização: o caso Gnuteca. Disponível em: http://eprints.rclis.org/7915/ 1/RDBCI-2006-79[1].pdf>. Acesso em: 25 nov. 2010.
3. FRAGOSO, Graça Maria. Biblioteca na escola. Disponível em: <http://dici.ibict.br/archive/00000883/01/Rev[1].AC-2005-78.pdf>. Acesso em: 25 nov. 2010.
4. SOMMERVILLE, Ian. Engenharia de Software. São Paulo: Pearson Education do Brasil, 2009.
5. Resenha sobre China Telecom pesquisada no site.
6. Ellis, C.A., Barthelmess, P., Quan, B. e Wainer, J. NEEM: An Agent Based Meeting Augmentation System. Technical Report CU-CS-937-02, University of Colorado at Boulder, Computer Science Department, 2002.
7. Ellis, C.A. e Wainer, J. Groupware and Computer Supported Cooperative Work. In Weiss, G. (Ed.) Multiagent, Systems, MIT Press, 1999.
8. Enembreck, F. and Barthès, J. P. Personal Assistant to Improve CSCW. Proceedings of the 7th International CSCWD, Rio de Janeiro, 2002, pp 329 – 335.
9. Esborjörnsson, M. and Östergren, M. Issues of Spontaneous Collaboration and Mobility. Workshop on Supporting Spontaneous Interaction in Ubiquitous Computing Settings, UBICOMP'02, Göteberg, Sweden, 2002.
10. Fish, R. S., Kraut R. E. and Chalfonte, B. L. The VideoWindow System in Informal Communications. Proceedings CSCW, 1990.