Racheiros

Escopo

• 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

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.

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 de 2012
  • Qual a previsão de lançamento da 1a. fase?
    • No 5o. bimestre de 2012, correspondendo a 10 meses de desenvolvimento, testes e disponibilização para o público.
  • Este projeto tem o seguinte cronograma:
    • 1o. bimestre de 2012: Projeto
    • 2o. bimestre de 2012: Modelagem
    • 3o. bimestre de 2012: Protótipo
    • 4o. bimestre de 2012: Desenvolvimento Fase I
    • 5o. bimestre de 2012: Teste e entrega Fase I
    • 6o. bimestre de 2012: 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.

• 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, faceboo, 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

• 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”.

Para 5a. feira - 14/06

• 03
• 04
• 05
• 06
• 07
• 08
• 09
• 10

• n

Infra-estrutura

• http://www.hetzner.de/en

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

Cronograma de Trabalho

1. Entrega 1 - 02/03/2012 - Todos
   1. Colaborar no escopo, requisitos funcionais e não-funcionais
2. Entrega 2 - 09/03/2012 - Todos
   1. Sugerir separação das funcionalidades entre Fase I e Fase II
   2. Caio: Benchmark de front-ends
   3. Thiago: Desenho dos casos
   4. Lucas: Desenho dos classes
   5. Pedro: Proposta de alocação do ambiente
3. Entrega 3 - 16/03/2012
   1. Caio: Atualizar Wiki
4. Entrega n - Data - Responsável

Estágio

• Engenharia de Software
  • Luthuli Akanni Paixão (luthuliakanni@hotmail.com)
  • 172 horas
    • I - Mai e Jun/2012: 3 hs/sem
    • II - Jul/2012: 10 hs/sem
    • III -Ago a Nov/2012: 3 hs/sem
    • IV - Dez/2012: 10 hs/sem
    • V - Jan: 10 hs/sem
• 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

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)