Racheiros

Escopo

Aplicação web gratuita voltada para organização de eventos de qualquer natureza, como reuniões, festas, rachas, treinos, etc.

• Um usuário cadastrado poderá criar o evento e enviar convites para pessoas cadastradas ou não, que deverão responder ao convite, e assim o criador do evento poderá controlar e administrar o mesmo;
• Fornecedores de produtos ou serviços, como por exemplo distribuidoras de bebidas e alimentos, locadores de espaços próprios para a prática em questão, etc., poderão se cadastrar com um perfil de prestador de serviços, que poderá ser pesquisado e contatado pelos administradores de eventos a fim de estabelecer um canal de comunicação efetivo e simplificado entre eles e registro de suas tarefas;
• Promoções poderão ser ofertadas para usuários de acordo com suas práticas registradas.

Cronograma

• Modelagem do Sistema - 09/03 - 03/04
  • Definição do escopo
  • Especificação dos requisitos
  • Diagrama de Classes
  • Diagrama de Casos de Uso
  • Detalhamento dos Casos de Uso
• Implemenação do Banco de Dados - 06/04 - 17/04
  • Desenho do Banco de Dados
  • Escolha do SGBD
  • Implementação do Banco de Dados
• Implantação da Infraestrutura - 20/04 - 01/05
  • Definição do ambiente
  • Aquisição do endereço
  • Deploying da aplicação
• Desenvolvimento da aplicação - 04/05 - 20/07
  • Criação de interface básica
  • Implemenação do Controle de Versões
  • Desenvolvimento dos casos de uso

5W2H

• What?
  • Qual o nome da solução?
    • http://www.racheiros.com.br/ (Sujeito a alteração)
  • Qual o objetivo, a finalidade?
    • Desenvolver um site que ajude o usuário a organizar eventos, simplificando tarefas como como marcar horários, cotar preços, escolher locais, estimar a quantidade de presentes, convidar pessoas, controlar pagamentos e qualquer outra tarefa que se deve preocupar a realizar um determinado evento. Além de auxiliar usuários fornecedores de serviços e ou produtos a divulgar e controlar suas atividades, como por exemplo, proprietários de locais à reservar horários e gerenciar o uso de seu estabelecimento. Desta forma, sendo um atrativo meio de comunicação para fabricantes e lojas que poderão lançar seus produtos e promoções para usuários que possam se interessar, de acordo com suas práticas.
  • O que é a aplicação?
    • Um portal web com interface gráfica intuitiva para facilitar a comunicação entre os usários e com buscas de informações, tais como dados dos usuários, grupos, locais e horários livres, serviços interessantes para o tipo de evento e consulta de preços.
  • Qual o diferencial deste serviço?
    • Simplificar as atividades na organização de eventos, colocando tudo que é essencial a fácil acesso do usuário.

• Why?

• Where?

• When?

• Who?

• How Much?

• How?

Requisitos

Funcionais

• Cadastro de usuários com opção de importar dados de redes sociais (Facebook, Twitter, Google+...);
• Cadastro de prestadores de serviço que deverão classificar sua natureza com tags;
• Recuperação de senha;
• Usuário poderá criar e gerenciar grupos;
• Destacar aniversários dos membros de cada grupo;
• Usuário poderá criar e administrar eventos únicos ou períodicos, e que necessitam ou não pagamento;
• Possibilitar o controle de quem quitou ou não o débito para eventos que requerem pagamento;
• Fornecer informações para transferência bancária e anexo de comprovantes de pagamento do evento por parte dos participantes;
• Cadastro de local para o evento (Possibilitar que o cadastro do local seja completado pelo fornecedor de serviço de locação);
• Envio de convites com confirmação de presença pelos administradores dos eventos para os convidados que poderão ou não ser cadastrados à aplicação;
• Manter histórico de eventos;
• Usuário poderá repetir um evento criado pelo mesmo;
• Usuário poderá agendar eventos;
• Atualização e cálculo da presença individual de cada convidado;
• Administrador criador do evento poderá adicionar usuários cadastrados e confirmados como administradores do evento;
• Administradores poderão pesquisar e contatar prestadores de serviços cadastrados;
• Visualização do evento para qualquer convidado;
• Relatórios estatísticos sobre frequência e reputação de usuários cadastrados;
• Permitir qualificação do evento por parte dos convidados presentes;
• Publicidade para usuários de acordo com suas práticas recentes.

A aplicação poderá, posteriormente:

• Permitir controle financeiro e pagamentos online aos fornecedores e organizadores de eventos com pagamento;
• Permitir a inclusão de vídeos, fotos e textos nos eventos;
• Permitir relatorios de personalizados (campos a escolha do usuário);
• Envio de SMS ou URA para confirmação de presença;
• Permitir qualificação do site pelos usuários.

Não-funcionais

• Autenticação do usuário por email/nome de usuário e senha (ou contas de redes sociais);
• Interagir com usuários por e-mail;
• Seguir uma arquitetura orientada a serviços, facilitando integrações com outros sistemas;
• Ser disponibilizado na web;
• Possuir interface adequada para acesso em diferentes dispositivos e plataformas;
• Estabelecer vínculo com o calendário do Google;
• Utilizar https para login e páginas de gerenciamento, e http para o restante.

Versão anterior

Escopo 1a. versão

• Desenvolver uma solução web para acesso gratuito onde:
  • Administradores de grupo possam organizar seus eventos (rachas, ensaios, treinos, encontros, ...)
  • Atletas, artistas, músicos, etc, possam utilizar de um portal para atualização de informações e integração com seus pares
  • Empresas de aluguel de quadras, associações ou clubes possam manter um registro dos responsáveis por cada evento e ainda manter um canal de comunicação efetivo com eles
  • Empresas de compra em lote possam oferecer promoções de produtos alinhados com o uso dos membros dos grupos

Cronograma

• Modelagem do Sistema - 09/03 - 03/04
  • Definição do escopo
  • Especificação dos requisitos
  • Diagrama de Classes
  • Diagrama de Casos de Uso
  • Detalhamento dos Casos de Uso
• Implemenação do Banco de Dados - 06/04 - 17/04
  • Desenho do Banco de Dados
  • Escolha do SGBD
  • Implementação do Banco de Dados
• Implantação da Infraestrutura - 20/04 - 01/05
  • Definição do ambiente
  • Aquisição do endereço
  • Deploying da aplicação
• Desenvolvimento da aplicação - 04/05 - 20/07
  • Criação de interface básica
  • Implemenação do Controle de Versões
  • Desenvolvimento dos casos de uso

5W2H

• What?
  • Qual o nome da solução?
    • http://www.racheiros.com.br/
  • Qual o objetivo, a finalidade?
    • Construir um site que ajude os praticantes de esportes ou eventos em geral e organizadores destes a reunir com seus parceiros para marcarem horários em quadras, estúdios ou locais específicos e ajude empresários proprietários destes locais à reservar horários e gerenciar o uso de seu estabelecimento. Desta forma, sendo um atrativo meio de comunicação para fabricantes e lojas de equipamentos que por sua vez poderão lançar seus produtos e promoções.
  • O que é a aplicação?
    • Um portal web com interface gráfica intuitiva para facilitar a comunicação entre os usários e com buscas de informações, tais como dados dos usuários, grupos, locais e horários livres.
  • Qual o diferencial deste serviço?
    • A utilização de uma comunicação por SMS com os usuários para a confirmação de presença e confirmação de eventos, a possibilidade de agendar horários nos locais pela internet, o gerenciamento da utilização destes locais, divulgação de promoções, lojas e lançamento de produtos.
  • Resumo:
    • Um sistema Web que permite a criação de grupos de usuários referentes a determinada necessidade com funções interessantes como agendar compromissos, convidar por e-mail, controlar frequencia, permitir interação pelo site e uma série de serviços adicionais.

• Why?
  • O porquê de se desenvolver essa solução?
    • O caso mais comum é o inúmeros organizadores de “rachas” que gastam muito dinheiro e tempo toda semana entrando em contato com outros “racheiros” e quadras para que possam agendar e confirmar os “rachas”. Por outro lado os donos de quadras podem gerenciar melhor seu negócio facilitando novas locações, automatizando e documentando os dados de seu estabelecimento.
  • Qual o motivo?
    • Porque o mercado de aluguéis de campos, quadras, locais de eventos têm crescido nos últimos anos e o número de locais também.
  • Porquê alguém investiria neste negócio?
    • Porque as pessoas estão constantemente se encontrando, seja para uma finalidade esportiva, seja um grupo musical ou ainda uma comunidade qualquer. Efetivamente, todos querem comunicar aos demais sobre compromissos e muitas vezes controlar estas reuniões seja pelo simples cálculo da assiduidade ou ainda vinculando a pontuações, como no caso de premiação pela fidelidade
    • Com base nessa prática tão comum, ter um sistema que facilite a vida do administrador e também de todos os membros do grupo passa a ser interessante para todos. Se puder adicionar a participação de outras entidades que possam fazer uso do banco de dados de pessoas e gerar benefícios mais viável fica ainda o desenvolvimento de uma aplicação. Se for gratuita então, aí poderá ser bastante utilizada.

• Where?
  • Onde encontro solução similar? (Sistema igual ou próximo do que pretendo fazer)
    • www.peladeiro.com.br,
  • Onde poderá ser instalada?
    • A proposta inicial é que esta aplicação seja instalada num servidor Web comercial e que os administradores e membros possam acessá-la facilmente, simplesmente recebendo um usuário e senha.
  • Onde pode ser desenvolvida?
    • O desenvolvimento será feito na incubadora do UFU - Universidade Federal de Uberlândia
  • Onde poderá ser usada?
    • Em qualquer dispositivo que suporte HTML e tenha conexão com a internet. Disponível para usuários em qualquer lugar do mundo. Isto inclui dispositivos móveis como tablets e celulares
  • Onde poderá ser testada?
    • Em clubes, quadras, ginásios, estúdios, locais de eventos que aderirem ao projeto experimentalmente para que seja divulgado aos usuários, principalmente, esportistas os horários disponíveis dos locais agendados.

• When?
  • Quando começar a desenvolver?
    • O projeto está previsto para ser desenvolvido a partir do 3o. bimestre
  • Qual a previsão de lançamento da 1a. fase?
    • No 5o. bimestre, correspondendo a 10 meses de desenvolvimento, testes e disponibilização para o público.
  • Este projeto tem o seguinte cronograma:
    • 1o. bimestre: Projeto
    • 2o. bimestre: Modelagem
    • 3o. bimestre: Protótipo
    • 4o. bimestre: Desenvolvimento Fase I
    • 5o. bimestre: Teste e entrega Fase I
    • 6o. bimestre: Desenvolvimento Fase II e Manutenção Fase I

• Who?
  • Quem pode usar?
    • Organizadores de “rachas”, “racheiros”, (não se limitará apenas à futebol), donos de campos ou quadras esportivas, lojas e fabricante de equipamentos esportivos.
  • Quem pode desenvolver?
    • Qualquer programador com a infra estrutura necessária e tempo disponivel.
  • Quem poderá colocar o conteúdo?
    • As lojas e fabricantes de equipamento poderão fazer campanhas publicitárias de mercadorias e donos de quadras poderão também convidar grupos de esportistas à conhecerem suas quadras.
  • Detalhamento:
    • X Patrocinadores
    • 1 Integrador por 3 meses
    • 1 Projetista por 2 meses
    • 1 Arquiteto do ambiente por 4 meses
    • 1 Arquiteto do software por 5 meses
    • 1 DBA x 5 meses
    • 2 Desenvolvedor Junior por 4 meses
    • 1 Desenvolvedora Senior por 4 meses
    • 2 Web Designer por 3 meses
    • 1 Advogado por 1 contrato
    • 1 Analista de Mkt por 3 meses
    • 1 Analista de suporte por 6 meses

• How Much?
  • Quando custará o produto para o usuário final?
    • O preço para os racheiros é ZERO
  • Quanto custo todo o desenvolvimento?
    • O investimento total para desenvolvimento da solução envolvendo pessoal, equipamentos e demais custos estará em torno de R$ 200.000,00
  • Quanto é o custo para o provedor de conteúdo?
    • Para os estabecimentos esportivos o custo será de R$100,00 mensais. Para os patrocinadores o custo dependerá do tipo de campanha ele desejará fazer (SMS, e-mail ou banner).
  • Detalhamento de custos:
    • Hospedagem: 90 Euros/ano
    • Servidores: 2 x R$ 15.000,00
    • Notebooks: 4 x R$ 3.000,00
    • Dispositivos móveis:
      • Celulares: 5 x R$ 500,00
      • Tablets: 3 x R$ 1.200,00
    • Ads do Google: R$ 5.000,00 a cada trimestre
    • Registro da marca: R$ 10.000,00
    • Brindes para 1o.s cadastros: 50 x R$ 50,00

• How?
  • Como desenvolver?
  • Utilizar a linguaguem Java com banco de dados SQL para armazenamento das informações do site
  • Como testar?
    • Distribuir versões gratuitas para quadras e clubes para gerenciar seus horários de funcionamento e agendamento de locações.
  • Como adquirir?
    • Os estabelecimentos que desejam adquirir a ferramenta devem pagar uma mensalidade de manutenção e hospedagem das informações de suas quadras no site. Os patrocinanores devem fechar contratos para utilizarem os diversos meios de comunicação com os “racheiros”, tais como SMS, e-mail e banners no site.
  • Detalhamento:
    • Projeto: DotProject para acompanhamento de projeto
    • Modelagem: UML usando software Entreprise Architect
    • Desenvolvimento: Linguagem Java
    • Versões: SVN
    • Documentação: MediaWiki
    • Framework: Eclipse
    • Testes: JUnit
    • Ambientes:
      • Servidor:
      • Cliente: Firefox, Chrome e IE
      • Móvel: Android, Iphone e Nokia

Requisitos

Funcionais

• A aplicação deve (1a. Fase):

1. permitir a criação de grupos gerenciados por um administrador
2. criar uma forma simples de agendar os eventos
3. disponibilizar uma forma de configuração (parametrização) de funcionalidades
4. convidar os membros para os eventos programados
5. possibilitar a atualização e o cálculo da presença individual de cada membro
6. emitir relatórios estatísticos sobre frequência e pontuação
7. manter um histórico dos eventos passados
8. destacar os aniversários dos membros de cada grupo
9. Permitir a votação do Bola Cheia e do Bola Murcha
10. Permitir a pesquisa de grupos, e seus membros, inclusive sem login
11. Permitir recuperação de senha por email.
12. Cadastrar local.
13. permitir edição de grupo pelo administrador de grupo
14. permitir montagem de times randômicos dentro de eventos agendados

• A aplicação deve (2a. Fase):

1. facilitar a inclusão de vídeos, fotos e textos
2. Permitir controle financeiro e pagamento de racha por paypal ou pagseguro
3. Permitir importação de do outolook ou gmail para usuários (o administrador do racha pode criar varios usuários, e o sistema mandar os dados de acesso para cada um)
4. Permitir relatorios de personalizados (varios campos a escolha do usuário)
5. Mandar SMS de confirmação de presença
6. Mandar URA de confirmação de presença
7. Permitir a qualificação do site por parte dos usuários
8. Disponibilizar um mapa da onde a pessa esta, até a quadra (com o GPS, (Ex. IGO))
9. Montar um mapa geografico da casa dos integrantes do grupo, e sugerir a melhor quadra.
10. Possibilitar aos usuários opinar e dando idéias para implementação de novos recursos e funcionalidades.

Não-funcionais

O sistema deve:

1. ser disponibilizado na web
2. ter interface adequada para acesso por PCs, tablets, Ipads e celulares
3. interagir com os usuários por email
4. garantir autenticação do usuário pelo email e senha (com contas gmail, orkut, twitter, facebook, etc)
5. integrar-se com redes sociais como Facebook, Twitter e outras
6. vincular ao Google Calendar
7. Ser https apenas no login, e http para todo o site. (obs. sem logar o usuário poderá ver todos os dados (para aparecer no google))
8. Seguir uma arquitetura orientada a serviços, para facilitar a criação de integrações com outros sistemas

Objetos

• Usuario
  • apelido
  • sexo
  • idade
  • email
  • nome
  • sobrenome
  • cep (#)
  • numero
  • dataDeNascimento
  • codTime
  • foneCelular
  • foneFixo
  • groupsList (lista de grupos aos quais pertence)
  • peso (o quão hábil é o jogador para determinada modalidade)

• GrupoDoJogador
  • modalidade
  • time (#)
  • nome
  • numeroDeIntegrantes
  • listadeIntegrantes (nomes)
  • dataCriação
  • melhorJogador (de todas as partidas participadas e a partida do dia)
  • piorJogador (de todas as partidas participadas e a partida do dia)
  • pontuacao
  • presencaUltimosJogos

• Time
  • codTime
  • nomeTime
  • estado

• Quadra
  • cep (#)
  • numero
  • nomeQuadra
  • nomeProprietario
  • modalidade
  • preco
  • referencia
  • telefones
  • nomeFantasia

• Cep
  • codCep
  • cidade
  • bairro
  • estado

• Equipe
  • nomeEquipe
  • quadra
  • horario

• Horario
  • codHorario
  • horario

• Racha (Evento)
  • horario (#)
  • quadra (#)
  • listaGrupos (GrupoDoJogador (#)) (times participantes do evento marcado)

• Empreendedor
  • nome
  • sobrenome
  • email
  • listaDeQuadras (quadra(#))

Casos de Uso

• 01 - Manipular dados de usuário

Subcaso de uso 1.1: cadastrar usuário.
Descrição: cadastra um usuário.
Evento iniciador: usuário clica em “cadastrar”.
Atores: usuário.
Pré-condição: nenhuma.
Seqüência de eventos:
1. Usuário clica no botão cadastrar.
2. Sistema exibe formulário com dados (nome, sobrenome, data de nascimento, estado, cidade, idade, sexo, email, telefone, endereço, apelido) a serem preenchidos.
3. Usuário clica em salvar.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de cadastro efetuado com sucesso.
Pós-condição: usuário devidamente cadastrado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 4).

Subcaso de uso 1.2: atualizar/editar usuário.
Descrição: altera dados de um usuário.
Evento iniciador: usuário clica em “atualizar dados cadastrais”.
Atores: usuário.
Pré-condição: usuário autenticado.
Seqüência de eventos:
1. Usuário clica no botão “atualizar dados cadastrais”.
2. Sistema exibe formulário contendo todos os dados cadastrais.
3. Usuário altera os dados de interesse e clica em salvar.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de alteração de cadastro efetuada com sucesso.
Pós-condição: alterações de cadastro devidamente registradas.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 4).
3. Usuário desiste da atualização e aperta em cancelar.

Subcaso de uso 1.3: excluir conta.
Descrição: remover usuário do sistema.
Evento iniciador: usuário clica em “excluir conta”.
Atores: usuário.
Pré-condição: usuário autenticado.
Seqüência de eventos:
1. Usuário clica no botão “excluir conta”.
2. Sistema pede confirmação de senha.
3. Confirmada a senha, sistema exibe uma tela contendo um campo “motivo” para preenchimento.
4. Usuário preenche o campo e clica em excluir.
5. Sistema remove os dados cadastrais.
6. Sistema exibe mensagem “conta excluída com sucesso”.

Pós-condição: dados cadastrais removidos do banco de dados.
Extensões:
1. Usuário desiste da exclusão de conta e aperta em cancelar.
2. Usuário erra a senha na confirmação e sistema informa a mensagem “senha incorreta” e exibe opções de tentar novamente ou cancelar.

• 02 - Fazer login
  

Descrição: usuário entra com nome de usuário e senha para logar no sistema.
Evento iniciador: usuário clica no botão “login”.
Atores: usuário.
Pré-condição: nenhuma.
Seqüência de eventos:
1. Usuário preenche seus dados (nome de usuário e senha).
2. Usuário clica no botão “login”.
3. Sistema exibe mensagem “usuário autenticado”.

Pós-condição: usuário autenticado no sistema.
Extensões:
1. Usuário entra com alguma informação inválida (nome de usuário ou senha) e o sistema exibe mensagem “nome de usuário ou senha inválido”.

• 03 - Se inscrever em grupo

Subcaso de uso 3.1: Solicitar inclusão.
Descrição: Solicitar inscrição a grupo de jogadores de determinada modalidade.
Evento iniciador: usuário clica em “inscrever em grupo”.
Atores: usuário.
Pré-condição: usuário autenticado.
Seqüência de eventos:
1. Usuário clica no botão “inscrever em grupo”.
2. Sistema envia solicitação de inscrição ao administrador do grupo em questão.
3. Solicitação fica pendente até que o administrador do grupo avalie e aprove a solicitação.
4. Solicitação é aprovada e usuário se torna membro daquele grupo.
5. Lista de grupos a que o usuário pertence é atualizada (novo grupo inserido).

Subcaso de uso 3.2: Enviar solicitação.
Descrição: Sistema envia solicitação de inclusão do usuário ao administrador de grupo.
Atores: sistema.
Pré-condição: nenhuma.
Seqüência de eventos:
1. Sistema envia solicitação de inclusão de usuário ao administrador de grupo.
Pós-condição: nenhuma.

Subcaso de uso 3.3: Aprovar solicitação.
Descrição: Administrador aprova solicitação de inclusão.
Evento iniciador: usuário clica em “inscrever em grupo”.
Atores: administrador de grupo.
Pré-condição: administrador de grupo autenticado.
Seqüência de eventos:
1. Usuário clica no botão “aprovar solicitação”.
2. Sistema inclui usuário à lista de integrantes do grupo.
Pós-condição: usuário é membro do grupo.
Extensões:
1. Administrador reprova solicitação.

04 – Criar grupo gerenciado

Descrição: criar um grupo de usuários.
Evento iniciador: usuário clica em “criar grupo”.
Atores: administrador de grupo, Sistema.
Pré-condição: estar autenticado.
Seqüência de eventos:
1. Usuário clica no botão “criar grupo”.
2. Sistema exibe formulário com dados (modalidade, nome do grupo, data de Criação (automático)) a serem preenchidos.
3. Usuário clica em concluído.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de criação efetuada com sucesso.
Pós-condição: grupo devidamente criado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 4).

Subcaso de uso 4.1: importar grupo.

Descrição: criar um grupo de usuários.
Evento iniciador: usuário clica em “criar grupo”.
Atores: administrador de grupo, Sistema.
Pré-condição: estar autenticado.
Seqüência de eventos:
1. Usuário clica no botão “criar grupo”.
2. Usuário clica no botão “importar grupo”.
3. Usuário seleciona o grupo de uma lista aonde o sistema apresenta todos os grupos existentes com filtro por localização geográfica (estado, cidade, bairro).
4. Sistema exibe formulário com dados previamente preenchidos (modalidade, data de Criação (automático)), passíveis de alteração caso usuário julgue necessário.
5. Usuário clica em concluído.
6. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
7. Se as informações estão corretas, aperta no botão confirmar.
8. Sistema exibe mensagem de criação efetuada com sucesso.
9. Sistema envia uma solicitação de confirmação a todos os usuários do grupo importado, exibindo a estes as informações do novo grupo criado.
Pós-condição: grupo devidamente criado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 4 (passo 5).
3. Sistema valida nome do grupo aonde este não deve ser o mesmo do grupo importado (passo 5).

05 - criar uma forma simples de agendar os eventos

Subcaso de uso 5.1: Criar um evento.
Descrição: cadastra um evento
Evento iniciador: usuário clica em “Cadastrar Evento”.
Atores: usuário.
Pré-condição: Estar autenticado.
Seqüência de eventos:
1. Usuário clica no botão “Cadastrar Evento”
2. Sistema exibe formulário com dados (nomeDoEvento, gruposParticipantes, contatoResponsavel (telefone / email), apelidoResponsavel, eventoStatus (ativo,desativo), eventoTipo (privado, publico), quantidadeMaximaPessoas ) a serem preenchidos.
3. Usuário clica em salvar.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de cadastro efetuado com sucesso.
7. Sistema envia convite para todos os usuários dos grupos convidados.
Pós-condição: Evento devidamente cadastrado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 4).

Subcaso de uso 5.2: Cadastrar datas/local evento.
Descrição: cadastra datas do evento e o local.
Evento iniciador: usuário clica em “Cadastrar data/local”.
Atores: usuário.
Pré-condição: evento cadastrado.
Seqüência de eventos:
1. Usuário clica no botão “Cadastrar data/local”.
2. Usuário seleciona um item da lista de datas disponíveis para usuário selecionar (calendário com hora e minuto).
3. Usuário seleciona um item da lista de repetições disponíveis para o usuário selecionar (semanal, mensal, quinzenal, anual, diária ) (este campo não é obrigatório).
4. Usuário informa o local que o evento será realizado (campo text) 5. Usuário clica em salvar.
6. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
7. Sistema informa ao usuário quais usuários tem evento conflitante.
8. Se as informações estão corretas, aperta no botão confirmar.
9. Sistema exibe mensagem de cadastro efetuado com sucesso.
Pós-condição: Data do evento %nomeEvento% devidamente cadastrado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 6).

Subcaso de uso 5.3: Cadastrar Alerta Evento
Descrição: cadastra um alerta do evento
Evento iniciador: usuário clica em “Cadastrar Alerta” dentro da tela do evento.
Atores: usuário.
Pré-condição: Evento cadastrado.
Seqüência de eventos:
1. Usuário clica no botão “Cadastrar alerta”.
2. Sistema exibe lista de alertas disponíveis para usuário selecionar (e-mail, Sms, Ligação TextToSpeack).
3. Sistema exibe lista de períodos disponíveis para alerta (x meses, x semanas, x dias, x horas), o usuário poderá selecionar apenas 1. (ex. 1 hora, ou 2 semana, ou 3 dias).
4. Usuário coloca texto para alertar o evento (sistema traz texto pré formado).
5. Usuário clica em salvar.
6. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
7. Se as informações estão corretas, aperta no botão confirmar.
8. Sistema exibe mensagem de cadastro efetuado com sucesso.
Pós-condição: Alerta do evento %nomeEvento% devidamente cadastrado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 6).

Subcaso de uso 5.4: Cadastrar pontuação / punição.
Descrição: Cadastrar pontuação / punição.
Evento iniciador: Usuário clica em “Cadastrar pontuação / punição” dentro da tela do evento.
Atores: usuário.
Pré-condição: Evento cadastrado.
Seqüência de eventos:
1. Usuário clica no botão “Cadastrar pontuação / punição”.
2. Sistema exibe para o usuário um conjunto de campos contendo:

• Nome
  
• Ponto (-100 a +100)
  
• Quantidade de dias/eventos para expiração
  
• Flag de punição ou pontuação
  

3. Usuário informa todos os campos acima e clica no botão +.
4. Sistema acrescenta este cadastro na lista imediatamente abaixo dos campos.
5. Sistema limpa os campos de maneira que o usuário possa voltar ao passo 2.
5. Após a criação das punições/pontuações, o usuário clica em salvar.
6. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
7. Se as informações estão corretas, aperta no botão confirmar.
8. Sistema exibe mensagem de cadastro efetuado com sucesso.
Pós-condição: Alerta do evento %nomeEvento% devidamente cadastrado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 6).

06 – Parametrizar funcionalidades.

Descrição: disponibilizar uma forma de configuração (parametrização) de funcionalidades.
Evento iniciador: usuário clica em “configurações”.
Atores: usuário, sistema.
Pré-condição: estar autenticado.
Seqüência de eventos:
1. Usuário clica no botão “configurações”.
2. Sistema exibe uma tela de configurações (estado: inativo/ativo (ser notificado de eventos), bloco de tela pertinente às informações do usuário (nome, apelido, etc...)).
3. Usuário faz as alterações desejadas de seu perfil.
4. Usuário clica em “salvar definições”.
5. Sistema exibe tela de confirmação.
6. Usuário clica em “confirmar alterações”.
6. Sistema exibe mensagem de alterações efetuadas com sucesso.
Pós-condição: alterações devidamente salvas.
Extensões:

Subcaso de uso 6.1: (a definir: subcasos de configuração de parâmetros do perfil do usuário).

07 – Acompanhar jogo em andamento.

Descrição: possibilitar a atualização e o cálculo da presença individual de cada membro.
Evento iniciador: usuário clica em “atualizar dados do jogo”.
Atores: administrador de grupo, Sistema.
Pré-condição: estar autenticado.
Seqüência de eventos:
1. Usuário clica no botão “atualizar dados do jogo”.
2. Sistema exibe tela com lista de todos os jogadores convocados (e confirmados) para o jogo aonde o administrador do evento seleciona no sistema todos os que compareceram. Pontua cada jogador de acordo com seu desempenho no jogo selecionando os campos (criados na criação do evento), (exemplo: quantidade de gols marcados, de faltas cometidas, dribles feitos, tomadas de bola, etc).
3. Usuário clica em concluído.
4. Sistema exibe tela de confirmação para encerrar evento.
5. Usuário confirma.
4. Sistema salva pontuação do evento.
Pós-condição: presença dos jogadores confirmada.
Extensões: nenhuma.

Casos de Uso A validar

Subcaso de uso 4.2: editar grupo.

Descrição: edita um grupo de usuários.
Evento iniciador: usuário clica em “editar grupo”.
Atores: administrador de grupo, Sistema.
Pré-condição: estar autenticado.
Seqüência de eventos:
1. Usuário clica no botão “editar grupo”.
2. Sistema exibe formulário com dados previamente preenchidos (modalidade, data de Criação (automático)), passíveis de alteração.
3. Usuário clica em concluído.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de alteração efetuada com sucesso.
Pós-condição: grupo devidamente alterado.
Extensões:
1. Campo(s) obrigatório(s) não podem ser alterados para vazio(s) e retorna o valor anterior.
2. Usuário verifica que alguma informação está incorreta e volta ao passo 4 (passo 5).

Subcaso de uso 5.5: Convidar membros.
Descrição: Convidar membros para o evento.
Evento iniciador: Usuário clica em “Convidar membros” dentro da tela do evento.
Atores: usuário.
Pré-condição: Evento cadastrado.
Seqüência de eventos:
1. Usuário clica no botão “Cadastrar membro”.
2. Sistema exibe para o usuário uma lista de usuarios.
3. Usuário seleciona os membros que deseja convidar.
4. Usuario clica em convidar.
5. Sistema envia um convite para participar a cada membro convidado.
6. Sistema exibe mensagem de todos membros convidados.
Pós-condição: Membros escolhidos devidamente convidados.
Extensões:
1. Membros convidados devem informar se comparecerão ou nao ao evento, sendo passivel de alteração.
2. Um membro nao pode ser convidado mais de uma vez.

Subcaso de uso 6.1:Cadastrar empreendedor .

Descrição:cadastra um empreendendor .
Evento iniciador:usuario clica em cadastrar novo empreendendor .
Atores:usuario .
Pré-condição:nenhuma.
Seqüência de eventos:
1. Usuario clica em cadastrar novo empreendendor.
2. Sistema exibe formulário com dados (nome, sobrenome, data de nascimento, email, telefone, #listas de quadras) a serem preenchidos..
3. Usuário clica em salvar.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de cadastro efetuado com sucesso.
Pós-condição:empreendedor devidamente cadastrado.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 4).

Subcaso de uso 6.2:Cadastrar quadra .

Descrição:cadastra uma quadra .
Evento iniciador: usuario clica em nova quadra.
Atores:usuario .
Pré-condição: estar logado como empreendedor.
Seqüência de eventos:
1. Usuario clica em nova quadra.
2. Sistema exibe formulário com dados (estado, cidade, telefone, endereço, valor do aluguel ) a serem preenchidos.
3. Usuário clica em salvar.
4. Sistema captura todas as informações e monta uma tela para o usuário confirmar se todos os dados informados por ele estão corretos.
5. Se as informações estão corretas, aperta no botão confirmar.
6. Sistema exibe mensagem de cadastro efetuado com sucesso.
Pós-condição:quadra devidamente cadastrada.
Extensões:
1. Sistema detecta campo(s) obrigatório(s) vazio(s) e alerta para seu(s) preenchimento(s).
2. Usuário verifica que alguma informação está incorreta e volta ao passo 2 (passo 4).
3. Verificar a veracidade dos dados

Infra-estrutura

Será usada a infra do Google para hospedagem inicial, pois é sem custo e permite o uso de java.
Para isto, todos os desenvolvedores devem saber como programar ja sobre as APIS do google.

Um passo inicial.

Ler todo o site abaixo (iniciando pela pagina que será aberta, e passando por todos os menus do lado esquerdo)

• https://developers.google.com/appengine/docs/whatisgoogleappengine?hl=pt-BR

Outras leituras:

• http://blog.globalcode.com.br/2010/10/google-app-engine-em-10-minutos-sem.html

• http://www.thiagovespa.com.br/blog/2010/10/03/comecando-com-google-app-engine/

Layout

Considerações gerais

• O layout deve:

1. Ser o mais "clean" possível, evitando o excesso de imagens e cores
2. Ser estruturado de forma que a largura mínima suportada seja de 1024 pixels, por ser a mais comum atualmente
3. Seguir a estrutura geral adotada pelas redes sociais mais populares

Estrutura

Haverão dois tipos de layouts: para quem estiver autenticado no sistema e para quem não estiver. Dentro de cada layout haverão variações, de acordo com a seção em que o usuário estiver

Para usuários não autenticados:

• Será constituído de 3 blocos: cabeçalho, conteúdo e rodapé.

1. Cabeçalho:
   1. Busca aberta ao público no topo;
   2. Campo de login/senha e link para recuperar senha;
2. Conteúdo: bloco de conteúdo, será diferente para cada página do site;

1. Rodapé:
   1. Links para as páginas com textos institucionais e informações de copyright;

Para usuários autenticados:

• Será constituído de 4 blocos: cabeçalho, menu lateral, conteúdo e rodapé.

1. Cabeçalho:
   1. Logotipo
   2. Informação de login do usuário
   3. Botão para logout
2. Menu lateral:
   1. Menu com atalho para as principais/mais usadas funções do sistema

Os layouts específicos de cada página serão descritos mais a frente.

Home

• O conteúdo se dividirá em duas colunas:

1. Primeira coluna: Informação sobre o serviço (sucintamente e chamativa, talvez uma imagem). Talvez uma observação pode ser colocada para usuários que desejem utilizar outros recursos (para donos de quadra, etc);
2. Segunda coluna: Formulário de cadastro (praticamente um pré-cadastro, ou seja, será requerido do usuário somente as informações essenciais para a utilização das funções básicas do sistema);

Exercícios

• 1o. Calculadora
  • Arquivo:Primeiro Exercicio.pdf

Estágio

• Engenharia de Software
  • Luthuli Akanni Paixão (luthuliakanni@hotmail.com)
• Atividades:
  • I - Estudar projeto
  • I -Definir Objetos do sistema
  • I -Desenhar Classes
  • I -Modelar usando software UML
  • II - Validar Diagrama de Casos de Uso
  • II - Concluir documentação dos Diagramas de Classes e Casos de Uso
  • III - Monitoria
  • III -Estudar Diagramas de Sequencia, Estado, Colaboração, etc (
  • III -Desenhar novos diagramas (para o projeto atual ou outro qualquer)
  • IV - Estudar SOA
  • IV - Aplicar SOA em algum projeto
  • V - Estudar novas tendências em ESOF

MVC

Model view controller (MVC), é um padrão de projeto (design pattern) o qual tem por finalidade separar as responsabilidades como visualização (view), modelo (model) e controle (controller) em uma arquitetura em camadas. Esta por sua vez é a chave para a independência entre os componentes e esta independência é que vai atingir os objetivos de eficiência , escalabilidade , reutilização e facilidade de manutenção.

Como dito antes, cada camada é responsável por uma parte na aplicação:

A camada de visão ou visualização:

é responsável unicamente por implementar as classes de interface com o usuário, ou seja, esta não possui nenhum código de processamento ou de persistência dos dados. Sua única responsabilidade é a apresentação da interface ao usuário onde se dá a interação dele com o aplicativo, não importando se esta camada é implementada usando JSF (para aplicações web), swing para aplicações desktop ou console (linha de comando) como ilustrado na figura acima. Isso mostra que se tivermos nossa aplicação cuja camada de visualização está implementada usando console, podemos simplesmente trocar para uma camada implementada em swing onde esta troca é totalmente transparente para o resto da aplicação, ou seja, as outras classes não "saberão" que a troca foi efetuada justamente pelo fato do aplicativo possuir uma arquitetura em camadas, demonstrando claramente a separação de responsabilidades.

A camada de controle:

como o próprio nome sugere, é a camada responsável pelo controle da aplicação. Esta é uma camada intermediária entre a lógica de negócio (camada de modelo)e a visualização. Este controle se dá no fluxo da apresentação de acordo com as ações do usuário. Assim, se o usuário toma determinada atitude, como por exemplo de salvar informações de cadastro num banco de dados, esta camada invocará métodos de outra camada (a camada de modelo), passando os parâmetros necessários para tal. Ou se o usuário deseja consultar informações que estão no banco, novamente esta camada invocará métodos da camada de modelo para tal. Resumindo, esta camada governa o fluxo da apresentação dos dados ao usuário.

A camada de modelo:

é a camada mais importante da aplicação, pois nela está o coração do sistema. É aqui que são processadas as informações, bem como o mapeamento ou modelagem dos dados. É responsável também pela persistência do mesmo num dado banco de dados. Esta camada concentra toda a lógica de negócio do sistema definindo assim, o comportamento do mesmo.

Concluindo, o uso do design pattern MVC é muito importante para favorecer a manutenibilidade, extensibilidade e a eficiência do código, promovendo a segregação de responsabilidades em camadas.

Membros

1. Luiz Cláudio Theodoro (Idealizador)
2. Joáo Paulo Cruz Araújo (Integrador)
3. Tiago Barros de Souza (Projetista)
4. Pedro Macedo Leite (Arquiteto do ambiente)
5. Thiago Vasconcelos Mundim (Arquiteto do software)
6. Lucas Pires de Oliveira (DBA)
7. Caio Augusto Araújo de Oliveira (Web Designer)
8. Ana Lúcia Soares (Desenvolvedora)
9. Elisabete Carvalho Oliveira (Desenvolvedora)
10. Vanessa Shiguemi Caetano de Oliveira (Desenvolvedora)
11. Hiago Araujo Silva (Desenvolvedor)
12. Luiz Felipe Guardieiro Rodrigues (Desenvolvedor)
13. Luthuli Akanni Paixao (Estagiario em ESOF)
14. Fábio Donisete Silva (Desenvolvedor)
15. Saulo Garcez Santos (Desenvolvedor)

• Rafaella Picolo Garcia (Desenvolvedora) (Solicitou dispensa)