Os slides fazem parte de uma atividade realizada pelos alunos da turma SIN-NA7 (7º semestre de Sistemas de Informação – 2º semestre de 2013).
Tema da atividade: Status Report do Projeto TCC.
3.
Os próximos slides fazem parte de uma
atividade realizada pelos alunos da turma
SIN-NA7 (7º semestre de Sistemas de
Informação – 2º semestre de 2013)
Tema da atividade: Status Report do Projeto TCC
4. #
Nome do Projeto
1
CVV – Carteirinha Virtual de Vacinação
2
Graph for Sales
3
Maternity System
4
MyUniversity
5
SICE – Sistema de Comandas Eletrônicas
6
SPS – Sistema de Processo Seletivo
7
SUTRAN
9.
Nosso projeto foi elaborado pensando numa maior
comodidade das pessoas em terem acesso a um
documento de suma importância para todos, mas
que em grandíssima parte dos casos, encontra-se
danificado, desatualizado, desorganizado ou
perdido.
10.
O principal objetivo deste trabalho é o
desenvolvimento de um software que terá a
longo prazo a função de substituir por completo
a Carteira de Vacinação, documento este que
grande parte das pessoas o tem danificado,
desatualizado ou perdido. Todas as pessoas que
utilizarem o serviço de vacinas a partir da data de
sua implantação, já contarão com o cadastro
automático e pessoas que queiram virtualizar os
dados, poderão se dirigir aos postos de
cadastramento e efetua-lo.
12.
Software que terá a longo prazo a função de
substituir por completo a Carteira de
Vacinação, documento este que grande parte
das pessoas o tem danificado, desatualizado
ou perdido.
13.
IDENTIFICAÇÃO DO CLIENTE
IDENTIFICAÇÃO DA EQUIPE DE DESENVOLVIMENTO.
RECURSOS HUMANOS E MATERIAL
AMBIENTE DE INFORMÁTICA
REQUISITOS MINIMOS DO AMBIENTE DE INFORMATICA
MAPEAMENTO DE PROCESSOS
TESTE DO SOFTWARE
14. CVV
Documentação
Técnico
Regras de
Negócio
Requisitos
Funcionais e Não
Funcionais
Orçamento
Tecnologia
necessária
Riscos
Testes
Início dos testes
Resultados
testes
Sistema
Levantamento de
Dados
Cadastros
Relatórios
Estudo dos
dados
Administradores
Análise final
Relatórios de
Pesquisas
Enfermeiros
Possíveis melhorias
e correções
Usuário final
Controle de
Acesso
Administrador
Enfermeiros
Usuário final
15. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
O orçamento é limitado a R$90.000,00.
(R)
O prazo limite para implementação de 4 meses
(R)
A área de TI dará apoio ao projeto até a conclusão do
mesmo.
(P)
É necessário o apoio irrestrito de todos os envolvidos
dentro da divisão.
(P)
Os membros da equipe terão dedicação exclusiva ao
projeto.
(P)
17. PAPEL
RESPONSABILIDADES
Responsável pelo Projeto
Nome: Rogério
SUP/TEC – Analista de Sistemas
Equipe de TI
Thiago B - Desenvolvedor WEB
Conhecimentos em PHP, MySql e Microsoft Office
Júlio Cesar - DBA
Conhecimentos MySql, Microsoft Office e Inglês
Fluente(muito desejável)
Vivian - Analista de Testes
boa habilidade analítica
uma mente desafiadora e curiosa
atenção aos detalhes e tenacidade
entendimento de falhas de software comuns
conhecimento do sistema ou aplicativo em teste
(muito desejável)
19. SETEMBRO
1
DOCUMENTAÇÃO
RESPONSÁVEL
DESCRIÇÃO DE CASO DE USO
Mapear requisitos funcionais
Rogério
Mapear requisitos não funcionais Rogério
Mapear regras de negócio
Vivian
Criar documento
Thiago
Inserir diagramas
Júlio
Validar com o cliente
Rogério
DIAGRAMA DE CASO DE USO
Identificar atores
Rogério
Definir casos de uso
Júlio
Criar diagramas
Júlio
SISTEMA
CADASTROS
Usuário
Codificar módulo
Thiago
Realizar testes unitários
Encaminhar módulo para o
testador
Treinamento usuário final
Vivian
Teste sistema final (Usuário)
Vivian
Vivian
Júlio
2
3
OUTUBRO
4
1
2
3
4
NOVEMBRO
5
1
2
3
DEZEMBRO
4
1
2
3
4
21. #
DESCRIÇÃO
TIPO CRITIC. SITUAÇÃO
AÇÕES
1
Recursos mais
talentosos
(P)
8
Em mitigação
Analisar a viabilidade
Avaliar o impacto no
prazo
2
Resistência dos
usuários finais
(N)
13
Eliminado
Ações de divulgação
e orientação
- Benefícios
- Praticidade
3
Requisitos além
da capacidade
computacional
(N)
15
Eliminado
Mapeado o parque
tecnológico do
cliente.
Verificado os
requisitos de
software e hardware.
23. #
DESCRIÇÃO
1
Os recursos planejados estiveram disponíveis
2
Reuniões Semanais
3
Envolvimento do Cliente para mapeamento de requisitos
4
Validação do sistema in loco
29.
O sistema irá solucionar o problemas dos
comércios como: perda de comanda, erros
no fechamento do caixa e diminuir o tempo
de atendimento ao publico deixando mais
rápido e fácil para seus clientes.
30.
Desenvolver um sistema que faça o cadastro
do cliente, o controle das vendas, controle do
estoque.
31.
Maior facilidade para o fechamento do caixa.
Maior facilidade para o controle do estoque.
Acabar com o risco de o cliente perder a
comanda
Diminuir o tempo de atendimento aos
clientes
32.
O sistema será desenvolvido em Java, e banco
de dados em Sql, podendo futuramente ser
disponibilizado em ambiente web.
34. Estrutura Analítica do Projeto
Projeto TCC
Documentação
Descrição de
Caso de Uso
Regras de
Negócio
Diagrama de
Classes
Treinamento
Manual de
uso
Sistema
Testes
Plano de Testes
Levantamento
de Dados
Reunião com os
clientes.
Cadastros
Gerente
Funcionários
Requisitos
Funcionais
Script e Testes
Clientes
Relatórios
Vendas
Estoque
Controle de
Acesso
Gerente
Funcionários
35. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
O TCC será finalizado sem mudanças de membros do grupo.
Premissa
O programador estará disponível pra este projeto
Premissa
O cliente disponibilizará ambiente de hardware e software
conforme acordado em reuniões.
Premissa
O projeto precisa ser concluído antes de 01/07/14
Restrição
O projeto será desenvolvido na linguagem Java
Restrição
O projeto não pode ultrapassar o custo de R$500,00
Restrição
37. PAPEL
RESPONSABILIDADES
Gerente de Projeto
Acompanhar as atividades da equipe e Criar os planos
do projeto
DBA
profissional responsável por gerenciar, instalar,
configurar, atualizar e monitorar um banco de dados ou
sistemas de bancos de dados
Desenvolvedor
Profissional que desenvolve ou faz manutenção de
software em um grande sistema ou alguém que
desenvolve software para uso em computadores
pessoais.
Documentação
Responsável pela documentação do projeto exemplo:
Descrição de Caso de Uso , Diagrama de Classe, Manual
para usuário.
Analista de Negócios
profissional responsável por encontrar as melhores
oportunidades de negócio no mercado, sempre atento
às novas tendências, às inovações na criação de novos
produtos.
40. #
DESCRIÇÃO
TIPO CRITIC. SITUAÇÃO
AÇÕES
1
Entrega antes do
prazo
P
6
Aceitar
Bom andamento do
projeto
2
Não aceitação do
sistema pelos
clientes
N
6
Aceitar
Mostrar o projeto para o
cliente durante o
desenvolvimento do
sistema
3
Não atendimento ao N
prazo de entrega
20
Eliminar
Evitar Atrasos no
andamento do projeto.
48.
Atualmente, a maternidade que foi tomada
como referência, não possui um método
informatizado para controle de atendimentos.
Todo o processo é realizado em papel,
gerando demora no atendimento, além de
perdas consideráveis de informações.
50.
Eliminação de processos manuais;
Gerar um atendimento médico mais rápido;
Gerar um atendimento médico mais eficiente;
Segurança da maternidade;
Otimização para gerar relatórios;
54. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
Não haverá alteração do grupo do TCC
P
A técnica de enfermagem, Madalena, estará presente
durante todo o projeto para dar apoio às regras de
negócio.
P
Projeto deve ser concluído até Maio/14
R
56. PAPEL
RESPONSABILIDADES
Gerente de Projetos
Gerencia as entregas do grupo dentro do
prazo específico.
Documentador
Realiza os diagramas e a documentação
oficial do TCC.
DBA
Realiza a documentação de Banco de
Dados.
Desenvolvedor
Desenvolve o sistema do projeto.
61. #
DESCRIÇÃO
TIPO
1
Adotar Live Stream como
diferencial para o sistema.
Positivo
15
2
Adotar RFID como diferencial
para o sistema
Positivo
5
Aceitar
3
Não cumprimento dos prazos
de entrega
Negativo
10
Eliminar
Respeitar a nova data de entrega,
tendo ciência das consequências
4
Cumprir, com antecedência, os
prazos de entrega
Positivo
3
Aceitar
Aguardar a apresentação do TCC
5
Alteração da banca avaliadora
do TCC
Negativo
8
Aceitar
Alteração da documentação e/ou
sistema de acordo com o padrão do
novo(a) avaliador(a) da banca
6
Não atender as regras de
negócios de acordo com o
estabelecido no escopo
Negativo
8
Eliminar
Reavaliar a documentação e sistema
para identificar as possíveis falhas
7
Ser aprovado pela banca
avaliadora
Positivo
20
Explorar
O grupo se torna Bacharel em
Sistemas de Informação
8
Ser reprovado pela banca
avaliadora
Eliminar
Desenvolver uma nova ideia de projeto
que atenda as especificações e
qualificações, respeitando as datas de
entrega e escopo solicitados
Negativo
CRITIC.
5
SITUAÇÃO
Explorar
AÇÕES
Implementar do sistema
Implementar do sistema e comprar o
material necessário
63. #
DESCRIÇÃO
1
Cumprir os prazos de entrega
2
Respeitar os modelos de escopo da documentação dado pelos
professores presentes na banca avaliadora
3
Avaliar a possibilidade de implementação da tecnologia que será
apresentada como diferencial para a banca avaliadora
4
Conceito de “tecnologia diferencial” para o projeto TCC
69.
O que nos inspirou e nos inspira é a grande
barreira existente entre alunos e professores.
Barreira essa referente à comunicação. Por
isso decidimos criar o MyUniversity.
70.
O principal objetivo do MyUniversity, e
proporcionar um ambiente interativo. Onde
alunos e professores de uma mesma
faculdade podem trocar informações de uma
maneira mais fácil e intuitiva.
71.
Uma melhor comunicação entre alunos e
professores.
Maior controle dos eventos da faculdade.
Facilidade para o aluno em saber o que está
acontecendo na Instituição e no que isso o
influencia,
Maior interatividade entre alunos
73.
Diagrama de Caso de Uso
Diagrama de Classe
Diagrama de sequência
Descrição completa de caso de uso
Modelo Lógico
Modelo Físico
Dicionário de dados
Script do banco de dados
Normalização
74. My University
Documentação
Levantamento
de Requisitos
Mapear
requisitos
funcionais
Mapear
requisitos não
funcionais
Mapear regras
de negócio
Criar
documento
Validar com o
cliente
Casos de Uso
Sistema
Modelo de
Dados
Descrição de
Caso de Uso
Modelo
Conceitual
Diagrama de
Caso de Uso
Modelo
Lógico
Modelo Físico
Diagrama de
Classes
Mapear
Classes
Cadastros
Validação e
Testes unitários
Relatórios
Validação e
Testes
unitários
Testes
Controle de
Acesso
Cadastros de
Perfis
Testes de
integração
Perfis de
Acesso
Validação
Validar junto
ao Cliente
75. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
O TCC será finalizado com a formação atual
P
As responsabilidades não serão redefinidas
P
O Projeto será realizado em Ambiente Web
R
Os dados serão atualizados pelo Cliente
R
Devemos finalizar tudo até a data da apresentação
R
77. PAPEL
RESPONSABILIDADES
Líder do Projeto
Acompanhar andamento do projeto e
cronograma.
Analista de negócios
Levantar requisitos.
Desenvolvedor
Encontrar soluções de desenvolvimento
para os problemas apontados.
DBA
Estruturar BD.
Testador
Realizar testes de telas e regras de negócio
Documentador
Realizar a documentação do projeto.
79. SETEMBRO
1
DOCUMENTAÇÃO
RESPONSÁVEL
LEVANTAMENTO DE REQUISITOS
Mapear requisitos funcionais
Anderson
Mapear requisitos não funcionais
Itamar
Mapear regras de negócio
Diego
Criar documento
Leandro
Inserir diagramas
Itamar
Validar com o cliente
Diego
CASOS DE USO
Identificar atores
Anderson
Descrição de casos de uso
Leandro
Diagrama de casos de uso
Itamar
MODELO DE DADOS
Modelo Conceitual
Itamar
Modelo Lógico
Itamar
Modelo Físico
Diego
DIAGRAMA DE CLASSES
Mapear Classes
SISTEMA
CADASTROS
Desenvolvimento
Validação e Testes unitários
RELATÓRIOS
Desenvolvimento
Validação e Testes unitários
CONTROLE DE ACESSO
Cadastros de Perfis
Validação e Testes unitários
TESTES
Teste de integração
Perfis de Acesso
VALIDAÇÃO
Validar junto ao Cliente
Anderson
Diego
Leandro
Anderson
Itamar
Anderson
Itamar
Itamar
Leandro
Diego
2
3
4
OUTUBRO
5
1
2
3
4
NOVEMBRO
5
1
2
3
4
DEZEMBRO
5
1
2
3
4
5
80.
Modelo de Dados
◦ Modelo Conceitual
◦ Modelo Lógico
◦ Modelo Físico
Diagrama de Classes
◦ Mapear Classes
Sistemas
◦ Cadastros
◦ Relatórios
◦ Controle de Acesso
81. #
DESCRIÇÃO
TIPO CRITIC. SITUAÇÃO
AÇÕES
1
Indisponibilidade
dos usuários
para
levantamento de
informações.
N
Alta
Em negociação
Alocar uma pessoa
da equipe para
levantar os requisitos
2
Tempo de
implantação
N
Alta
Em andamento
Focar nas atividades
pendentes
82. DATA
DESCRIÇÃO DA MUDANÇA
Agosto/2013 Antigamente o My Univesity era um sistema direcionado
a uma Universidade e as informações dos usuários eram
obtidos através de importação do ando de dados da
Universidade em que o My University estava alocado.
Hoje possui cadastro de Universidade, bem como dos
alunos e professores dessa Universidade, sendo agora
uma responsabilidade da própria Universidade incluir os
usuários .
83. #
DESCRIÇÃO
1
Entrar sempre em Contato com os Stakeholders, para que eles
possam visualizar o andamento do projeto.
2
Trabalhar em Equipe
3
Realização de reuniões periódicas para acompanhamento de
status do Projeto.
4
Determinar e cumprir Prazos.
89.
Visa facilitar e agilizar o processo de compra
de produtos de estabelecimentos de
entretenimento, desde restaurantes à casas
noturnas, proporcionando um maior controle
e capacidade gerencial do estabelecimento.
90.
Desenvolver um sistema capaz de gerenciar
comandas eletrônicas de maneira segura e
eficaz, possibilitando ao cliente adicionar
créditos para utiliza-las nas dependências do
estabelecimento, visando a praticidade e
segurança na utilização.
91.
Automatização dos processos comerciais.
Controle de estoque.
Auxilio nos processos contábeis.
Agilizar a venda.
Histórico de venda.
Interface simplificada.
92.
Desenvolvido em Adobe AIR 3;
Escrito em AS3 integrado com o MySQL
através de um Servidor escrito em PHP;
- Isso possibilita a exportação do aplicativo para o
sistema Android.
Frontend realizando requisições POST para o
backend funçoes.php
93.
Diagrama de Classe.
Diagrama de Sequência.
Diagrama de Caso de Uso.
Descrição completa do Caso de Uso.
Normalização.
Script DML.
DER.
MER.
Interface com o Usuário.
Apresentação do sistema.
94. Projeto TCC
- SICE
Documentaç
ão
Descrição
de Caso de
Uso
Regras de
Negócio
Diagramas
Caso de Uso
Apresentaçã
o
Sistema
Testes
Levantamen
to de Dados
Cadastros
Plano de
Testes
Entrevistas
com os
Clientes
Usuário
Pesquisa de
Campo
Requisitos
Funcionais
Classes
Script de
Testes
Requisitos
Não
Funcionais
Fluxo de
Dados
Evidências
de Testes
Relatórios
Venda por
Período
Perfil de
Acesso
Venda
Cartão
Gerente
Produto
Recarga
Produto
Caixa
Estoque
Saldo
Cliente
Bar
Histórico
95. DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
O objeto de estudo disponibilizara a rotina de seu
estabelecimento.
(P)
O objeto de estudo nos informara sobre o fluxo de
operações e dados gerados de tais processos.
(P)
O objeto de estudo disponibilizara os dados para
levantamento de requisitos.
(P)
O Sistema terá integração com Android.
(P)
Os documentos de banco de dados serão validados pelo
professor Anderson e os referentes a levantamentos e
descrições serão validados pelo professor Alessandro.
(P)
O sistema precisa estar concluído até 31/05/2014, para
que seja apresentado à Banca de TCC.
(R)
97. PAPEL
RESPONSABILIDADES
Gerente de Projeto
Responsável pelo cronograma e decisões a
serem tomadas.
Analista de Testes
Realiza os teste integrados e avalia
possíveis falhas.
Desenvolvedor
Desenvolver via código o sistema.
DBA
Trata da base de dados, desenvolve scripts,
modelagem e diagramas específicos.
Documentador
Desenvolve os diagramas e documentos de
apoio ao projeto.
99. OUTUBRO
1
DOCUMENTAÇÃO
RESPONSÁVEL
BANCO DE DADOS
Normalização
Henrique/Amanda
ATUALIZAÇÃO - DIAGRAMAS
Diagrama de Caso de Uso
Amanda
Diagrama de Classes
Henrique
Diagrama de Fluxo de Dados
Evandro
Diagrama Entidade Relacional
Evandro
SISTEMA
OTIMIZAÇÃO
Analise do Sistema - Buscando
GAP's
Thales/Pedro
Correção de GAP's
Thales/Pedro
-
-
31
NOVEMBRO
1
-
-
30
DEZEMBRO
1
-
-
31
JANEIRO
1
-
-
31
101. # DESCRIÇÃO
TIPO
CRITIC
SITUAÇÃO
.
1 Não atendimento
ao prazo
Negativo
20
Indisponibilidade
por parte do
grupo
2 Não atendimento
ao escopo
Negativo
20
Documentação
Limitar o
inadequada com
tempo de
as normas do TCC entrega e
focar nas
tarefas
3 Indisponibilidade
do Servidor
Negativo
20
Servidor fora do
ar
AÇÕES
Fazer reunião
para
organização
e divisão das
tarefas.
Manutenções
preventivas
103. #
DESCRIÇÃO
1
O Grupo precisa estar atento aos prazos determinados para
entrega de Atividades.
2
O Grupo precisa seguir oque foi determinado no cronograma do
projeto, para que não haja acumulo de tarefas.
3
Deve haver reuniões constantes para alinhar todos os integrantes
sobre o andamento das atividades.
4
Lidar com grandes responsabilidades.
5
Captar experiências do dia-a-dia de projetos reais.
109.
O Projeto SPS irá resolver os problemas que
uma Fundação de pesquisas tecnológicas tem
referente a administração de processos
seletivos, que são: Deficiência na execução de
processos, problemas com restrições
tecnológicas, tempo de execução e grandes
margens de falha humana que podem
comprometer diretamente nos resultados.
110.
Desenvolver um sistema para gerenciar a
administração de processos seletivos dos
ingressantes de uma universidade.
114. Sistema de Processo Seletivo
Documentação
Engenharia
Banco de
Dados
Sistema
Testes
Levantamento
de Dados
Gerenciar
Concursos
Realizar
Inscrições
Impressão do
Material de
Provas
Correção de
Provas
Relatórios
Diagramas de
casos de usos
Mapeamento
Validações
Visita ao
Cliente
Mantém
Campus
Mantém
Candidatos
Lista de Mural
Mantém
Gabaritos
Aprovados/Espe
ra/Eliminados
Diagramas de
classes
Normalização
Segurança
Analise de
requisitos
Mantém
Cursos
Inscreve
Candidato
Lista de
Presença
Correçao da
Prova Objetiva
Desempenho na
Prova Objetiva
Diagrama de
sequência
Modelo
Relacionamento
Sobrecarga
Mantém Salas
Cartões Prova
Objetiva
Importar Notas
de Redação
Estatisticas de
Participantes
Diagrama de
domínio
Modelo Físico
(Script)
Mantém Agenda
de Provas
Cartões de
Redação
Processar
Classificação
Demanda por
Curso
Manual do
Fiscal de Prova
Demanda por
Localidade
116. Vinícius /
Francisco
Gerentes de Projeto
Vinícius
Passos
Analista de requisitos
Francisco
Sousa
Software Engineer
Juan
Hernandes
Documentador
Felipe
Quirino
DBA
117. PAPEL
RESPONSABILIDADES
Gerente de Projeto
Validar documentação e diagramas,
estipular prazos, definir escopo e calcular
custos.
Analista de Requisitos
Análise de requisitos, desenvolvimento dos
diagramas UML e qualidade de software.
Software Egineer
Desenvolvimento de arquitetura,
prototipação, codificação, validações,
testes e design.
Documentador
Criação das atas de reunião, documentar
especificação técnica e funcional, criação
do manual.
DBA
Mapeamento, normalização, modelagem e
controle de acessos ao banco de dados.
(Database Administrator)
121. #
DESCRIÇÃO
TIPO CRITIC. SITUAÇÃO
AÇÕES
1
Entrega fora do
prazo
N
20
Eliminar
Realizar as tarefas no
prazo definido o
quanto antes.
2
Entregar
antecipada
P
12
Melhorar
Se possível, antecipar
as datas previstas no
cronograma
3
Sistema com
divergência entre
a documentação
N
15
Eliminar
Realizar
homologação
unitária com o
acompanhamento da
documentação
4
Alteração no
Escopo
N
8
Minimizar
Definir (fechar)
escopo.
122. DATA
DESCRIÇÃO DA MUDANÇA
Abril/2013
Equipe – Entrada do Vinícius e Juan no projeto SPS
Setembro/2013 Escopo – Finalização das regras de negócio e criação
de todos os diagramas UML (Eng. Software).
123. #
DESCRIÇÃO
1
Interagir com os principais stakeholders para a perfeita validação
dos requisitos.
2
Definir meios de comunicação (E-mail, disco virtual), manter o
grupo sobre andamento das etapas e eventos inesperados.
3
Realizar reuniões semanais (presenciais) com a equipe para o
alinhamento de atividades.
4
Quando houverem dúvidas sobre determinado assunto, consultar
professores, especialistas, amigos e etc. que possuem vivência
com o assunto.
129. JUSTIFICATIVA
• O sistema irá controlar de forma mais segura as
infrações de trânsito, com o uso do RFID que será
implantado nos veículos à partir de 2016.
130. OBJETIVO DO PROJETO
• Desenvolver um sistema que gerencie as infrações de
trânsito com base na implantação do RFID nos veículos.
131. BENEFÍCIOS ESPERADOS
Redução de custos;
Redução nas fraudes no sistema de multas;
Automação do processo de um agente de trânsito;
Segurança no processo de infrações.
132. DESCRIÇÃO MACRO DA SOLUÇÃO
• O sistema será desenvolvido na linguagem Java e banco
de dados Microsoft SQL Server. O sistema irá usar a
tecnologia RFID para controle dos veículos.
133. ESCOPO DO PROJETO
• O escopo do projeto abrange os tópicos abaixo:
• Diagrama de casos de uso, descrição de caso de uso,
diagrama de classes, diagrama de sequencia e
diagrama de atividades, modelo descritivo, modelo
entidade relacionamento, mapeamento, modelo
relacional, dicionário de dados, normalização, scripts
DML, scripts DDL, apresentação do sistema.
134. ESTRUTURA ANALÍTICA DO PROJETO
Projeto TCC
Sistema
Documentação
Diagrama de
Caso de Uso
Diagrama
de Classes
Regras de
Negócio
Requisitos
Funcionais
Requisitos Não
Funcionais
Descrição de
Caso de Uso
Homologação
Modelo
Logico
Cadastros
Relatórios
Controle de
Acesso
Modelo
Físico
Plano de
Testes
Usuário
interno
Usuário interno
Evidências
de Testes
Usuário externo
Usuário externo
Proprietário
Fabricante
Concessionaria
Veiculo
Multas
Apresentação
135. PREMISSAS E RESTRIÇÕES DO PROJETO
DESCRIÇÃO
(P)REMISSA
(R)ESTRIÇÃO
O projeto será desenvolvido com uma base de dados nova sem
qualquer integração com o ambiente atual.
P
A integração com RFID será baseada no artigo 2º da resolução Nº
212 de 13 de Novembro de 2006.
P
O sistema será implantado em todo o território brasileiro.
P
O projeto somente será implantado após a implantação do chip
RFID nos veículos.
R
O projeto deverá ser desenvolvido até junho/2014.
R
136. ORGANOGRAMA DO PROJETO
Regiane
Gerente de Projeto
Regiane
Documentador
Regiane
Desenvolvedor
Regiane
Testador
Rafael
Documentador
Rafael
DBA
Rafael
Testador
137. PAPÉIS E RESPONSABILIDADES
PAPEL
RESPONSABILIDADES
Gerente de Projetos
- Desenvolver e acompanhar cronograma;
- Acompanhar entregas;
- Validar as documentações;
Documentador 1
- Criar os módulos de caso de uso, descrição de caso.
Programador
- Desenvolver módulos do sistema;
Testador 1
- Criar casos de teste;
Documentador 2
- Levantar os requisitos;
- Desenvolver diagramas (Classes, sequencia),
Modelo entidade relacionamento, Modelo
conceitual, Modelo descritivo;
DBA
- Criação do banco de dados;
Testador 2
- Testar os módulos;
- Criar documento com os resultados dos teste;
139. CRONOGRAMA DAS PRÓXIMAS ATIVIDADES
SETEMBRO
1
DOCUMENTAÇÃO
RESPONSÁVEL
DIAGRAMA DE CASO DE USO
Mapear requisitos funcionais
Rafael
Mapear requisitos não funcionais
Regiane
Mapear regras de negócio
Rafael
Identificar atores
Regiane
Definir casos de uso
Rafael
Criar diagrama de caso de uso
Regiane
DIAGRAMA DE CLASSES
Identificar classes e os relacionamentos
Rafael
Criar diagrama de classes
Rafael
Homologação
Identificar casos de testes
Rafael
Criar documento com casos de testes
Regiane
Criar documento de validação de testes
Rafael
2
3
OUTUBRO
4
1
2
3
4
NOVEMBRO
5
1
2
3
DEZEMBRO
4
1
2
3
4
140. CRONOGRAMA DAS PRÓXIMAS ATIVIDADES
SETEMBRO
MODELAGEM
1
Criar modelo conceitual
DOCUMENTAÇÃO
Criar modelo normalizado
DIAGRAMA DE CASO DE USO
Criar modelo de entidade-relacionamento
Mapear requisitos funcionais
Criar dicionário de dados
Regiane
RESPONSÁVEL
Rafael
Mapear requisitos não funcionais
SISTEMA
Mapear regras de negócio
CADASTROS
Regiane
Identificar atores
Usuário Interno
Definir casos de uso uso ao usuário interno
Codificar módulo de
Criar diagrama de caso de uso
Realizar testes unitários
DIAGRAMA DE CLASSES
Encaminhar módulo para o testador
Identificar classes e os relacionamentos
Usuário Externo
Criar diagrama de classesao usuário externo
Codificar módulo de uso
Homologação
Realizar testes unitários
Identificar casos de testes o testador
Encaminhar módulo para
Criar documento com casos de testes
Proprietário
Criar documento de validação de testes
Codificar módulo
Regiane
Rafael
Regiane
Rafael
Regiane
Rafael
Regiane
Regiane
Regiane
Regiane
Rafael
Rafael
Rafael
Rafael
Rafael
Rafael
Regiane
Rafael
Rafael
Realizar testes unitários
Regiane
Encaminhar módulo para o testador
Regiane
2
3
OUTUBRO
4
1
2
3
4
NOVEMBRO
5
1
2
3
DEZEMBRO
4
1
2
3
4
141. CRONOGRAMA DAS PRÓXIMAS ATIVIDADES
SETEMBRO
Fabricante
Codificar módulo
DOCUMENTAÇÃO
Realizar testes unitários
DIAGRAMA DE CASO DE para o testador
Encaminhar módulo USO
Mapear requisitos funcionais
Concessionária
1
Rafael
RESPONSÁVEL
Regiane
Rafael
Rafael
Mapear requisitos não funcionais
Codificar módulo
Mapear regras deunitários
Realizar testes negócio
Regiane
Rafael
Rafael
Regiane
Identificar atores
Encaminhar módulo para o testador
Regiane
Regiane
Definir
Veiculo casos de uso
Rafael
Criar diagrama de caso de uso
Codificar módulo
Regiane
Rafael
DIAGRAMA DE CLASSES
Realizar testes unitários
Regiane
Encaminhar módulo relacionamentos
Identificar classes e ospara o testador
Rafael
Rafael
Multas
Criar diagrama de classes
Rafael
Codificar
Homologaçãomódulo
Realizar casos unitários
Identificar testes de testes
Rafael
Encaminhar módulo para de testes
Criar documento com casoso testador
RELATÓRIOS
Criar documento de validação de testes
Identificar relatórios
Desenhar o modelo dos relatórios
Desenvolver os relatórios
Regiane
Rafael
Rafael
Regiane
Rafael
Regiane
Regiane
2
3
OUTUBRO
4
1
2
3
4
NOVEMBRO
5
1
2
3
DEZEMBRO
4
1
2
3
4
142. CRONOGRAMA DAS PRÓXIMAS ATIVIDADES
SETEMBRO
CONTROLE DE ACESSO
Identificar os perfis
Identificar os
DOCUMENTAÇÃO acessos de cada perfil
Identificar os usuários para cada perfil
DIAGRAMA DE CASO DE USO
Criar um documento de perfis e acesso
Mapear requisitos funcionais
Codificar módulo
Realizar testes unitários
Mapear requisitos não funcionais
Encaminhar módulo para o testador
Mapear regras de negócio
APRESENTAÇÃO
Identificar atores com as funcionalidade do sistema
Criar documento
Criar casos funcional
Definirmanualde uso
Criar diagrama de caso de uso
Regiane
Regiane
RESPONSÁVEL
Rafael
Rafael
Regiane
Regiane
Regiane
Rafael
Regiane
Regiane
Rafael
Regiane
DIAGRAMA DE CLASSES
Identificar classes e os relacionamentos
Rafael
Criar diagrama de classes
Rafael
Homologação
Identificar casos de testes
Rafael
Criar documento com casos de testes
Regiane
Criar documento de validação de testes
Rafael
1
2
3
OUTUBRO
4
1
2
3
4
NOVEMBRO
5
1
2
3
DEZEMBRO
4
1
2
3
4
144. RISCOS
# DESCRIÇÃO
CRITIC. SITUAÇÃO AÇÕES
Negativo
15
Explorar
Buscar tecnologias
alternativas.
2 Saída de membros da equipe. Negativo
3
Aceitar
Buscar novos membros
para a equipe.
3 Documentação em desacordo.
10
Melhorar
Revisar toda a
documentação.
Eliminar
Analisar as alterações que
impactaram no projeto,
caso elas existam.
Melhorar
Dividir o projeto em
partes e fazer entregas
parciais.
1
Não implementação da
tecnologia RFID nos veículos.
TIPO
Alteração na legislação que
4 determina o uso do RFID nos
veículos.
5 Prazo de entrega estourado.
Negativo
Negativo
Negativo
4
8
145. LIÇÕES APRENDIDAS
#
DESCRIÇÃO
1
Desenvolver cronograma para acompanhamento das atividades
2
Realizar reuniões com a equipe do projeto para discutir novas ideias e melhorias
3
Realizar reuniões com os professores para validar as documentações