[sin-na7] gestão de projetos e empreendedorismo - atividade: status report
DESCRIPTION
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.TRANSCRIPT
Alessandro Almeida | www.alessandroalmeida.com 15/10/2013
2° Semestre de 2013
SIN-NA7
Consolidando o aprendizado de Gestão de Projetos
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
# 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
PRONTUÁRIO NOME
16020075 THIAGO BANDEIRA DE MELLO
11201631 JÚLIO CESAR RODRIGUES
10201485 ROGÉRIO DE LIMA
08100791 VIVIAN CAMPELO
Índice
SISTEMAS DE INFORMAÇÃO
Status Report
PRONTUÁRIO NOME
16020075 THIAGO BANDEIRA DE MELLO
11201631 JÚLIO CESAR RODRIGUES
10201485 ROGÉRIO DE LIMA
08100791 VIVIAN CAMPELO
CVV – Carteirinha Virtual de Vacinação
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.
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.
Cadastro facilitado
Sistema automatizado
Relatórios
Consulta facilitada
Disponível on-line
Maior qualidade na apresentação das informações
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.
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
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
Levantamento de
Dados
Estudo dos
dados
Relatórios de
Pesquisas
Sistema
Cadastros
Administradores
Enfermeiros
Usuário final
Relatórios
Análise final
Possíveis melhorias
e correções
Controle de
Acesso
Administrador
Enfermeiros
Usuário final
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)
Rogério
Gerente de Projeto
Rogério Analista de Requisitos
Thiago B.
Desenvolvedor
Vivian
Analista de Testes
Júlio Cesar
DBA
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)
CVV – Carteirinha Virtual de Vacinação
SETEMBRO OUTUBRO NOVEMBRO DEZEMBRO
1 2 3 4 1 2 3 4 5 1 2 3 4 1 2 3 4
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 Vivian
Encaminhar módulo para o testador
Vivian
Treinamento usuário final Júlio
Teste sistema final (Usuário) Vivian
Realizar testes unitários (20/10)
Encaminhar módulo para o testador (25/10)
# 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.
DATA DESCRIÇÃO DA MUDANÇA
Ago/2013 Substituição de Recursos do Time do Projeto
Set/2013 Alteração da periodicidade de report. do projeto para semanal
# 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
CVV – Carteirinha Virtual de Vacinação
PRONTUÁRIO NOME
10100822 Rodrigo Pestana
07112584 Diogo Carasco
Índice
SISTEMAS DE INFORMAÇÃO
Status Report
PRONTUÁRIO NOME
10100822 Rodrigo Pestana
07112584 Diogo Carasco
Sistema de Vendas
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.
Desenvolver um sistema que faça o cadastro do cliente, o controle das vendas, controle do estoque.
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
O sistema será desenvolvido em Java, e banco de dados em Sql, podendo futuramente ser disponibilizado em ambiente web.
Descrição de Caso de Uso.
Diagrama de Classe
Manual para os usuários
Projeto TCC
Documentação
Descrição de
Caso de Uso
Regras de
Negócio
Requisitos
Funcionais
Diagrama de
Classes Treinamento
Manual de
uso
Testes
Plano de Testes
Script e Testes
Levantamento
de Dados
Reunião com os
clientes.
Sistema
Cadastros
Gerente
Funcionários
Clientes
Relatórios
Vendas
Estoque
Controle de
Acesso
Gerente
Funcionários
Estrutura Analítica do Projeto
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
Lucas
Gerente de Projeto
Cesar
DBA
Diogo
Desenvolvedor
Rodrigo
Documentação
Lucas Akeda
Analista de Negócios
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.
Graph for Sales
# 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 prazo de entrega
N 20 Eliminar Evitar Atrasos no andamento do projeto.
DATA DESCRIÇÃO DA MUDANÇA
01/2014 Mudança com os integrantes do grupo
01/2014 Reuniões semanalmente
# DESCRIÇÃO
1 Convivência de uma rotina de projetos
2 Organização de Trabalho
3 Lidar com grandes responsabilidade
4
5
Graph for Sales
PRONTUÁRIO NOME
11103655 Carolina Kewerrhause
10200796 André A. Gattini
10201118 Aline Siqueira
10200521 Kauê Clerici Leite
Índice
SISTEMAS DE INFORMAÇÃO
Status Report
PRONTUÁRIO NOME
11103655 Carolina Kewerrhause
10200796 André A. Gattini
10201118 Aline Siqueira
10200521 Kauê Clerici Leite
<Maternity System>
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.
Desenvolver um sistema para controle de cadastro e relatórios de uma maternidade.
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;
Maternity System
Documentação Desenvolvimento
B.D. Eng
Diagramas: ◦ Caso de uso;
◦ Classe;
◦ Sequência;
◦ Domínio;
Descrição de caso de uso;
Modelos: ◦ Relacional;
◦ Entidade e Relacionamento;
◦ Normalização;
Regras de Negócio;
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
Carolina Gerente de Projeto
Carolina Documentadora
Aline DBA
Kauê Documentador
André Desenvolvedor
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.
<Maternity System>
# DESCRIÇÃO TIPO CRITIC. SITUAÇÃO AÇÕES
1 Adotar Live Stream como diferencial para o sistema.
Positivo 15 Explorar Implementar do sistema
2 Adotar RFID como diferencial para o sistema
Positivo 5 Aceitar Implementar do sistema e comprar o material necessário
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
Negativo 5 Eliminar
Desenvolver uma nova ideia de projeto que atenda as especificações e qualificações, respeitando as datas de entrega e escopo solicitados
DATA DESCRIÇÃO DA MUDANÇA
Ago/13 Acréscimo de relatórios e cadastros
Set/13 Impedimentos para adotar RFID
# 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
<Maternity System>
PRONTUÁRIO NOME
09106933 Anderson Porfírio Trindade
10200365 Diego Marques dos Santos
09106538 Itamar Rocha
10200275 Leandro Gonçalves
Índice
SISTEMAS DE INFORMAÇÃO
Status Report
PRONTUÁRIO NOME
09106933 Anderson Porfírio Trindade
10200365 Diego Marques dos Santos
09106538 Itamar Rocha
10200275 Leandro Gonçalves
MyUniversity
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.
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.
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
My University
Documentação Sistema Testes Validação
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
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
Descrição de
Caso de Uso
Diagrama de
Caso de Uso
Modelo de
Dados
Modelo
Conceitual
Modelo
Lógico
Modelo Físico
Diagrama de
Classes
Mapear
Classes
Sistema
Cadastros
Validação e
Testes unitários
Relatórios
Validação e
Testes
unitários
Controle de
Acesso
Cadastros de
Perfis
Testes
Testes de
integração
Perfis de
Acesso
Validação
Validar junto
ao Cliente
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
Diego Líder
Diego
Analista/Desenvolvedor
Anderson
Analista/DBA
Itamar Analista de Requisitos
Leandro Analista de Requisitos
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.
MyUniversity
1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5
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 Anderson
SISTEMA
CADASTROS
Desenvolvimento Diego
Validação e Testes unitários Leandro
RELATÓRIOS
Desenvolvimento Anderson
Validação e Testes unitários Itamar
CONTROLE DE ACESSO
Cadastros de Perfis Anderson
Validação e Testes unitários Itamar
TESTES
Teste de integração Itamar
Perfis de Acesso Leandro
VALIDAÇÃO
Validar junto ao Cliente Diego
SETEMBRO OUTUBRO NOVEMBRO DEZEMBRO
Modelo de Dados ◦ Modelo Conceitual
◦ Modelo Lógico
◦ Modelo Físico
Diagrama de Classes ◦ Mapear Classes
Sistemas ◦ Cadastros
◦ Relatórios
◦ Controle de Acesso
# 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
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 .
# 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.
MyUniversity
PRONTUÁRIO NOME
10200013 Amanda Cristina Santos Ferreira
10200086 Evandro E. Hernandes
10200371 Henrique Pereira dos Santos
10200652 Pedro Ruan
10102205 Thales Dourado Damião
Índice
SISTEMAS DE INFORMAÇÃO
Status Report
PRONTUÁRIO NOME
10200013 Amanda Cristina Santos Ferreira
10200086 Evandro E. Hernandes
10200371 Henrique Pereira dos Santos
10200652 Pedro Ruan
10102205 Thales Dourado Damião
SICE – Sistema de Comandas Eletrônicas
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.
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.
Automatização dos processos comerciais.
Controle de estoque.
Auxilio nos processos contábeis.
Agilizar a venda.
Histórico de venda.
Interface simplificada.
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
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.
Projeto TCC
- SICE
Documentaç
ão
Descrição
de Caso de
Uso
Regras de
Negócio
Requisitos
Funcionais
Requisitos
Não
Funcionais
Diagramas
Caso de Uso
Classes
Fluxo de
Dados
Apresentaçã
o Testes
Plano de
Testes
Script de
Testes
Evidências
de Testes
Levantamen
to de Dados
Entrevistas
com os
Clientes
Pesquisa de
Campo
Sistema
Cadastros
Usuário
Produto
Cliente
Relatórios
Venda por
Período
Perfil de
Acesso
Gerente
Caixa
Bar
Venda
Produto
Estoque
Histórico
Cartão
Recarga
Saldo
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)
Henrique\Evandro\Thales
Gerente de Projeto
Henrique, Amanda e
Evandro
Analista de Requisitos
Thales e Pedro
Desenvolvedor
Todos os Integrantes
Analista de Testes
Henrique, Amanda e
Pedro
DBA
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.
SICE – Sistema de Comandas Eletrônicas
OUTUBRO NOVEMBRO DEZEMBRO JANEIRO
1 - - 31 1 - - 30 1 - - 31 1 - - 31
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
Normalização do Projeto.
Atualização dos Diagramas.
Otimização.
# DESCRIÇÃO TIPO CRITIC.
SITUAÇÃO AÇÕES
1 Não atendimento ao prazo
Negativo 20 Indisponibilidade por parte do grupo
Fazer reunião para organização e divisão das tarefas.
2 Não atendimento ao escopo
Negativo 20 Documentação inadequada com as normas do TCC
Limitar o tempo de entrega e focar nas tarefas
3 Indisponibilidade do Servidor
Negativo 20 Servidor fora do ar
Manutenções preventivas
DATA DESCRIÇÃO DA MUDANÇA
Dez/2012 Saída de Integrante – Ana Paula
Fev/2013 Entrada de Integrantes – Evandro e Pedro
# 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.
SICE – Sistema de Comandas Eletrônicas
PRONTUÁRIO NOME
10200358 Francisco Sousa
10100908 Felipe Quirino
08101271 Juan Hernandes
10100065 Vinicius Passos
Índice
SISTEMAS DE INFORMAÇÃO
Status Report
PRONTUÁRIO NOME
10200358 Francisco Sousa
10100908 Felipe Quirino
08101271 Juan Hernandes
10100065 Vinicius Passos
Sistema de Processo Seletivo
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.
Desenvolver um sistema para gerenciar a administração de processos seletivos dos ingressantes de uma universidade.
Automação de processos;
Maior consistência de dados;
Redução no prazo dos resultados;
Relatórios precisos e objetivos.
Sistema de plataforma WEB, desenvolvido na linguagem PHP com banco de dados MySQL, e com auxílio de outras linguagens JavaScript, CSS e XML.
Gerenciar Concursos;
Realizar Inscrições;
Impressão do Material de Provas;
Correção de Provas;
Classificação (Aprovados/Espera/Eliminados);
Relatórios administrativos e pedagógicos;
Controle de acesso ao Sistema;
Documentação e manuais.
Sistema de Processo Seletivo
Documentação
Engenharia
Diagramas de
casos de usos
Diagramas de
classes
Diagrama de
sequência
Diagrama de
domínio
Banco de
Dados
Mapeamento
Normalização
Modelo
Relacionamento
Modelo Físico
(Script)
Testes
Validações
Segurança
Sobrecarga
Levantamento
de Dados
Visita ao
Cliente
Analise de
requisitos
Sistema
Gerenciar
Concursos
Mantém
Campus
Mantém
Cursos
Mantém Salas
Mantém Agenda
de Provas
Realizar
Inscrições
Mantém
Candidatos
Inscreve
Candidato
Impressão do
Material de
Provas
Lista de Mural
Lista de
Presença
Cartões Prova
Objetiva
Cartões de
Redação
Manual do
Fiscal de Prova
Correção de
Provas
Mantém
Gabaritos
Correçao da
Prova Objetiva
Importar Notas
de Redação
Processar
Classificação
Relatórios
Aprovados/Espe
ra/Eliminados
Desempenho na
Prova Objetiva
Estatisticas de
Participantes
Demanda por
Curso
Demanda por
Localidade
DESCRIÇÃO (P)REMISSA (R)ESTRIÇÃO
Projeto deve ser concluído antes de 06/2014. R
Todo o sistema deve ser documentado. P
O sistema deve ser executado em qualquer S.O. P
Vinícius /
Francisco Gerentes de Projeto
Vinícius
Passos Analista de requisitos
Francisco
Sousa Software Engineer
Juan
Hernandes Documentador
Felipe
Quirino DBA
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 (Database Administrator) Mapeamento, normalização, modelagem e controle de acessos ao banco de dados.
Sistema de Processo Seletivo
Diagramas UML (Validado);
Modelagem do Banco de Dados (Validado);
Documentação (Validado);
Relatório de Testes (Unitários e Integrados).
# 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.
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).
# 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.
Sistema de Processo Seletivo
PRONTUÁRIO NOME
10200370 RAFAEL PIRES MACHADO KLENK SERRA
10200362 REGIANE PEREIRA DE MOURA
Índice
SUTRAN STATUS REPORT
DADOS DO GRUPO
PRONTUÁRIO NOME
10200370 RAFAEL PIRES MACHADO KLENK SERRA
10200362 REGIANE PEREIRA DE MOURA
RESUMO DO PROJETO
SUTRAN
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.
OBJETIVO DO PROJETO
• Desenvolver um sistema que gerencie as infrações de
trânsito com base na implantação do RFID nos veículos.
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.
• 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.
DESCRIÇÃO MACRO DA SOLUÇÃO
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.
ESTRUTURA ANALÍTICA DO PROJETO
Projeto TCC
Documentação
Diagrama de Caso de Uso
Regras de Negócio
Requisitos Funcionais
Requisitos Não Funcionais
Descrição de Caso de Uso
Diagrama de Classes
Homologação
Plano de Testes
Evidências de Testes
Modelo Logico
Sistema
Cadastros
Usuário interno
Usuário externo
Proprietário
Fabricante
Concessionaria
Veiculo
Multas
Relatórios Controle de
Acesso
Usuário interno
Usuário externo
Modelo Físico Apresentação
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
ORGANOGRAMA DO PROJETO
Regiane Gerente de Projeto
Regiane Documentador
Regiane Desenvolvedor
Regiane Testador
Rafael Documentador
Rafael DBA
Rafael Testador
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;
SITUAÇÃO DO PROJETO
SUTRAN
CRONOGRAMA DAS PRÓXIMAS ATIVIDADES
1 2 3 4 1 2 3 4 5 1 2 3 4 1 2 3 4
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
SETEMBRO OUTUBRO NOVEMBRO DEZEMBRO
CRONOGRAMA DAS PRÓXIMAS ATIVIDADES
MODELAGEM
Criar modelo conceitual Regiane
Criar modelo normalizado Rafael
Criar modelo de entidade-relacionamento Regiane
Criar dicionário de dados Regiane
SISTEMA
CADASTROS
Usuário Interno
Codificar módulo de uso ao usuário interno Regiane
Realizar testes unitários Regiane
Encaminhar módulo para o testador Regiane
Usuário Externo
Codificar módulo de uso ao usuário externo Rafael
Realizar testes unitários Rafael
Encaminhar módulo para o testador Rafael
Proprietário
Codificar módulo Rafael
Realizar testes unitários Regiane
Encaminhar módulo para o testador Regiane
1 2 3 4 1 2 3 4 5 1 2 3 4 1 2 3 4
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
SETEMBRO OUTUBRO NOVEMBRO DEZEMBRO
Fabricante
Codificar módulo Rafael
Realizar testes unitários Regiane
Encaminhar módulo para o testador Rafael
Concessionária
Codificar módulo Rafael
Realizar testes unitários Regiane
Encaminhar módulo para o testador Regiane
Veiculo
Codificar módulo Rafael
Realizar testes unitários Regiane
Encaminhar módulo para o testador Rafael
Multas
Codificar módulo Rafael
Realizar testes unitários Regiane
Encaminhar módulo para o testador Rafael
RELATÓRIOS
Identificar relatórios Regiane
Desenhar o modelo dos relatórios
Desenvolver os relatórios Regiane
CRONOGRAMA DAS PRÓXIMAS ATIVIDADES
1 2 3 4 1 2 3 4 5 1 2 3 4 1 2 3 4
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
SETEMBRO OUTUBRO NOVEMBRO DEZEMBRO
CONTROLE DE ACESSO
Identificar os perfis Regiane
Identificar os acessos de cada perfil Regiane
Identificar os usuários para cada perfil Rafael
Criar um documento de perfis e acesso
Codificar módulo Rafael
Realizar testes unitários Regiane
Encaminhar módulo para o testador Regiane
APRESENTAÇÃO
Criar documento com as funcionalidade do sistema Regiane
Criar manual funcional Regiane
CRONOGRAMA DAS PRÓXIMAS ATIVIDADES
1 2 3 4 1 2 3 4 5 1 2 3 4 1 2 3 4
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
SETEMBRO OUTUBRO NOVEMBRO DEZEMBRO
PRÓXIMAS ENTREGAS
• Sistema:
• Controle de Acesso
• Cadastro de Penalidades
• Cadastro de Infrações
• Cadastro de RFID por veiculo.
• Controle de infrações com uso do RFID.
RISCOS
# DESCRIÇÃO TIPO CRITIC. SITUAÇÃO AÇÕES
1 Não implementação da
tecnologia RFID nos veículos. 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. Negativo 10 Melhorar Revisar toda a
documentação.
4
Alteração na legislação que
determina o uso do RFID nos
veículos.
Negativo 4 Eliminar
Analisar as alterações que
impactaram no projeto,
caso elas existam.
5 Prazo de entrega estourado. Negativo 8 Melhorar
Dividir o projeto em
partes e fazer entregas
parciais.
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
MUITO OBRIGADO!
SUTRAN
[email protected] www.alessandroalmeida.com/unifieo.htm www.slideshare.net/alessandroalmeida