wiki

Santa Monica

Revisão de 13h55min de 12 de junho de 2014 por Lclaudio (discussão | contribs) (Criou página com '= Escopo = <br> * Desenvolver um portal que promova o resgate histórico e atualizações futuras da saga da Associação Atlética Santa Mônica, equipe de futebol de Uberl...')
(dif) ← Edição anterior | Revisão atual (dif) | Versão posterior → (dif)

Escopo


  • Desenvolver um portal que promova o resgate histórico e atualizações futuras da saga da Associação Atlética Santa Mônica, equipe de futebol de Uberlândia, apoiada pela Universidade Federal de Uberlândia que participa das seguintes competições:
    • Campeonato Amador de Futebol
    • Campeonato de Futebol Juniores
    • Campeonato Master de Futebol
    • Campeonato Brasileiro de Universidades (O grupo da AASM que participa do campeonato amador é base para a equipe que disputa o nacional).


5W2H

  • What?
    • Qual o nome da solução?
      • Santa Monica UFU
    • Qual o objetivo, a finalidade?
      • Construir um site que permita a divulgação da história da Associação Atlética Santa Mônica UFU e também a divulgação dos torneios atuais onde a equipe estiver envolvida.
    • O que é a aplicação?
      • Um portal web com interface gráfica amigável para permitir a inclusão de dados como fotos, vídeos, depoimentos e reportagens, a apresentação na linha do tempo de todos os personagens que fizeram parte da história da equipe e a conexão dos membros numa rede social exclusiva.
    • Qual o diferencial deste serviço?
      • A montagem de uma ampla base de dados que poderá representar toda a história da associação com aspectos interessantes como redes sociais, comunicação via SMS, email e áudio para criar uma relação forte entre os elementos que fizeram parte da saga da equipe.
    • Resumo:
      • Um sistema Web que permite apresentar na linha do tempo, a saga histórica de uma equipe de futebol com forte interação entre todos os que contribuíram para a evolução do grupo. Conterá depoimentos, imagens, vídeos e detalhes completos sobre as atividades, participações, títulos e situações diversas vividas pelo grupo. O software poderá ser compartilhado para que outras agremiações o utilizem para seus registros históricos.


  • Why?
    • O porquê de se desenvolver essa solução?
      • Para que a evolução histórica de equipes, grupos, bandas e qualquer reunião de pessoas em eventos determinados possa ser registrada, atualizada e divulgada na Internet.
    • Qual o motivo?
      • Porque a história poderá ser ampliada para funcionalidades amplas sem as limitações de redes sociais como temos hoje no timeline do Facebook, por exemplo.
    • Porquê alguém investiria neste negócio?
      • Porque para as pessoas interessa muito que suas contribuições para alguma finalidade sejam registradas, divulgadas e reconhecidas. Este site facilita o trabalho de cadastrar os fatos, incluir images e vídeos e ainda apresentar de uma forma interessante para o público afim.


  • Where?
    • Onde encontro solução similar? (Sistema igual ou próximo do que pretendo fazer)
      • Facebook
    • Onde poderá ser instalada?
      • Na nuvem
    • 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.
  12. Cadastrar quadra.
  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.


Para 5a. feira - 14/06
  • 04
  • 05
  • 06
  • 07
  • 08
  • 09
  • 10
  • n


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)




Outras leituras:





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);

Esquema de cores


Exercícios



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


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)


Disponível em “http://3.143.69.156/wiki/index.php?title=Santa_Monica&oldid=27456”