Sistema de Controle
de Motel
http://code.google.com/scmotel
Professor Júlio Guido Militão
Equipe
Francisco Wellyngton Do Rego Coelho
 Luiz Alberto Barbosa Mesquita
 Marcio Odair Fernandes Da Cunha
 Rafael Mello Falcao Marinho

Objetivo

Criar um sistema para gerenciar o Motel
Delirius informatizando todo o processo
que hoje é feito manualmente. O sistema
proporciona ao seu usuário ter total
controle sobre os passos do cliente desde
sua entrada até a sua saída do motel.
Entrevista










Repórter: Francisco Wellyngton R. Coelho
Entrevistado: Rogério Fontelene
FW: Você quer um programa para controle de Motel?
RF: Exatamente, preciso de um sistema para responder a
todas as minhas necessidades.
FW: Qual o motel e sua função lá?
RF: O motel é o Delirius em Maracanau, sou consultor do
Motel
FW: O que vocês tem lá hoje em funcionamento, algum
sistema?
RF: Nos estamos fazendo a implementação do sistema,
pegando como base a rotina que eles atualmente utilizam
lá, que é através de livros, tudo manual.
FW: Hoje não tem nenhum sistema controlando?
RF: O sistema lá a gente ainda está começando a fazer a
implementação e por enquanto ainda está sendo tudo por
escrito, logo ocorre aquelas falhas, porque é tudo
manualmente.
Material coletado com o cliente
Requisitos Funcionais
Manter cadastro de apartamentos
disponíveis e ocupados
 Controlar tempo de estadia
 Controlar o consumo de produtos
 Fornecer valor total da estadia
 Fornecer demonstrativo financeiro
diário/periódico

Requisitos Funcionais
CONTROLAR O CONSUMO DE PRODUTOS

Deve haver no sistema um módulo para
cadastro de consumo dos apartamentos,
de forma a controlar o estoque e o valor
final da conta do cliente.
Requisitos Funcionais
FORNECER DEMONSTRATIVO FINANCEIRO DIÁRIO/PERIÓDICO

O sistema deverá gerar um relatório
diário/periódico de contas, informando
todos os movimentos financeiros.
Requisitos Não Funcionais
Representação interativa de cômodos
 Privacidade
 Sistema operacional
 Banco de dados
 Linguagem utilizada

Requisitos Não Funcionais
REPRESENTAÇÃO INTERATIVA DE CÔMODOS

A tela principal do sistema deverá conter uma
imagem de um conjunto de quadros
representativos dos apartamentos, que no caso
de ocupado deverá estar representado na cor
vermelha e no caso de desocupado deverá
aparecer na cor verde, para que seja possível
identificar rapidamente quais os cômodos
disponíveis.
Requisitos Não Funcionais
PRIVACIDADE

O sistema deve manter a privacidade, de
modo que não seja necessário ao cliente
informar nome ou outras informações
pessoais.
Diagrama de Caso de Uso
Casos de Uso Essenciais
Solicitar Fechamento da Conta
 Escolher acomodação
 Realizar conferência
 Confirmar consumo
 Pagar
 Lançar consumo
 Fazer reserva

Casos de Uso Essenciais
SOLICITAR FECHAMENTO DA CONTA
Informar apartamento
 Informar hora de saída
 Informar extras
 Solicitar conferência

Casos de Uso Essenciais
REALIZAR CONFERÊNCIA
Informar apartamento
 Emitir lista de extras disponíveis antes da
consumação
 Informar a lista de extras consumidos
 Confirmar consumo

Cenário

O cliente estaciona seu veículo na entrada do motel e
informa qual o tipo de apartamento que ele deseja. O
atendente verifica se há algum apartamento disponível e
caso positivo, informa o número do apartamento e lhe
entrega as chaves. O cliente dirige-se ao apartamento e
estaciona seu carro na garagem. Quando o cliente
desejar sair, ele solicita o fechamento da conta e dirigese à postaria de saída. A atendente solicita à camareira
para realizar a conferência dos extras consumidos e
então confirma o consumo com o cliente. Após a
confirmação, a atendente informa o valor a ser pago
para o cliente efetuar o pagamento. O caso de uso se
encerra.
Storyboard
ESCOLHER ACOMODAÇÃO
Passo 1
Clicar sobre o botão correspondente ao número
do quarto desejado.
Passo 2
Os dados referentes ao apartamento são
importados pelo sistema sem a necessidade de
interação com o usuário. Se necessário, inserir
informações o veículo e quantidade de
pessoas. Clicar no botão Salvar.
Storyboard
ESCOLHER ACOMODAÇÃO
Passo 3
O sistema exibe uma mensagem informando
que o registro foi lançado com sucesso.
Passo 4
O sistema exibe a tela com todos os quartos,
disponíveis (cor verde) e ocupados (cor
vermelha). O caso de uso se encerra.
Storyboard
SOLICITAR FECHAMENTO DA CONTA
Passo 1
O sistema exibe a tela com todos os quartos,
disponíveis (cor verde) e ocupados (cor
vermelha). Clicar sobre o botão correspondente
ao quarto que deseja fechar a conta.
Passo 2
O sistema exibe a tela de saída com os dados
do apartamento referente ao valor, data de
entrada/saída, etc., automaticamente. Se
houver consumo clicar na aba “Lançamento de
Produtos”.
Storyboard
SOLICITAR FECHAMENTO DA CONTA
Passo 3
O usuário digita as informações sobre os
produtos consumidos e clica no botão com o
ícone de adicionar. O sistema exibe a
mensagem informando que as alterações foram
salvas com sucesso.
Passo 4
Para fazer o fechamento da conta é necessário
informar o código da conferente e clica no
botão Finalizar Saída em seguida irá aparecer
a janela solicitando a forma de pagamento.
Escolha a forma de pagamento, e o sistema
salva e finaliza o fechamento do quarto.
Avaliação
LISTA DE PROBLEMAS ENCONTRADOS







Só primeira tela tem ajuda
Storyboard sem mostrar como navegar pela tela
Não tem telas de prevenção de erro do usuário
Não informar quais campos são obrigatórios
Janela “Forma de Pagamento” e “Movimento de
Conta” tem um botão sem informar o que faz
O campo número da placa não informa o
formato
Sistema não apresenta boa navegabilidade
Avaliação
Problema encontrado: Não tem telas de prevenção de erro do usuário
Heurística:
Auxilia os usuários a reconhecerem, diagnosticarem e
se recuperarem de erros
Severidade:
É imperativo consertar antes de se lançar o produto
Solução adotada:
Adicionamos as telas de prevenção de erros, mostrando
algumas janelas de diálogo como feedback para o
usuário.
Avaliação
Problema encontrado: Não informar quais campos são obrigatórios
Heurística:
Prevenção de erros
Severidade:
O conserto deve receber baixa prioridade
Solução adotada:
Adicionamos um * (asterisco) nos campos obrigatórios e
adicionamos nas telas uma mensagem informando que
os campos que tem o asterisco são obrigatórios.
Conclusão

Nesta Disciplina aprendemos muitas técnicas para desenvolver uma
Interface agradável e útil para o usuário.

Mas o melhor foi quando iniciamos o trabalho prático para
desenvolver um projeto real, começamos a compreender melhor o
que foi visto na teoria, o contato com um usuário real, a entrevista e
foram uma experiência boa e muito válida para que em breve quando
tivermos a oportunidade de desenvolver um projeto, já teremos uma
certa experiência e evitaremos os erros durante a nossa
aprendizagem.
Obrigado.