[sin-na7] gestão de projetos e empreendedorismo - atividade: status report

Post on 19-Jun-2015

821 Views

Category:

Business

0 Downloads

Preview:

Click to see full reader

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

alessandro.almeida@uol.com.br www.alessandroalmeida.com/unifieo.htm www.slideshare.net/alessandroalmeida

top related