PDDR

From ProgSoc Wiki

Jump to: navigation, search

PDDR P-Diddy, Yarr!, n. [PDDR: PDDR Duh! Duh! Recurses.]

  1. ProgSoc Dance, Dance Revolution!
  2. Means of trial; as, absence is a PDDR of love.

Note: it'd be nice if someone who had a clue about the in's and out's of wiki-text would fix up the formatting of this. I couldn't be bothered. :P

Contents

Stakeholders

Dance School Franchise 
Envisions managing the operation of multiple venues that service a dance school. Needs software to manage venues, memberships, customer relations and attendance. Receives commissions from the dance school and employs front-of-house door staff.
Dance School 
The dance school has a number of franchised outlets. Each franchise has an privately negotiated arrangement with the school. The school requires franchisees to pay fees and submit to other forms of branding compliance.
ProgSoc 
developing a software system to manage a dance school franchise.

Functional specification

A dance venue seeing 20 or 30 customers a night wishes to raise attendance to 100 by March 2008. Keeping administrative burden below 4 hours per week, and supporting multiple users is important.

Goals:

  • to provide excellent front-of-house service by knowing every customer, what level of dancing progression they've reached, which of venues they dance at and how often, and what they need next to have fun and improve their dancing (a workshop? a DVD? to learn a routine at their next level?)
  • optimise POS so that 100+ customers a night can be easily served by two door staff, who are free to focus on customer welcoming, advice, and education, because administration and money-taking is straightforward, very efficient, and really hard to screw up
  • link physical venues with online purchasing and a weekly email newsletter customised to each customer's location and dancing progression, containing highly relevant advice and information

What do we have now? A "method in the madness" system of selling casual entry, 5-class passes, monthly passes, student discounts, merchandise, etc., using a baroque and time-consuming paper-based reconciliation sheet, and using raffle ticket books as a means of counting the number of sales. The rec sheet, money, and ticket books then get sent to the school's head office for administration, calculation of venue commission, etc. A random collection of door staff with no particular skills in customer service. Customer retention issues.

The setup needs to be mobile. Internet access is not currently available. First venue is at Bondi Junction.

High-level architecture

The overall solution will be split into two packages. A head office package, and a POS package (could be POS-client and POS-master?).

Head-office system:

  • Client: debian, gnome, firefox
  • Application: web application on RoR
  • RDBMS: MySQL
  • Server: web server w/ redundant disk + backup device (USB?)

Head-office system features:

  • online 'reconcile'/'update' process (Ruby? Python?)
  • dedicated public web service (HTTP) interface to 'head office' DB
  • scripts for doing mailouts from head office.

POS system:

  • Client: debian, gnome, firefox
  • Application: web application on RoR
  • RDBMS: MySQL
  • Workstation: cheap dedicated POS notebook (ex-lease w/ spares, $100-$200 ea.)

POS system features:

  • POS systems can operate w/o internet
  • single-master w/ networked slaves (i.e. one notebook is the server)
  • flat file export/import of database state (w/ schema version number) (for backups, migrations, testing)
  • member numbers (customer shouldn't have to know it)
  • images would be smart (visual id) /img/member_no.jpg
  • salient member info visible to staff on main screen turn on

Notes:

Need to think about the database schema (relatively complex membership/payment/subscription options). Need to think about synchronising data... I think Internet will be required, but not necessarily at POS. Two notebooks can operate w/ cross-over cable, but two staff giving personal service likely only need one notebook between them... except if they're looking up customer details regularly mid-conversation.

Development approach

The Linux approach would be to look at the problem, work out how to solve it for multiple customers, and release bite-sized packages which work together to solve your problems in a modular, customisable way.

Our approach: Scope the problem and solve it, deploy and learn. Then extract the nuggetty bits which may potentially be useful elsewhere.

Development environment

To-do List

  • John is working through "RailsSpace" -- a book on Ruby On Rails development
  • ProgSoc is deploying new infrastructure -- once complete SVN, RoR, and MySQL services will be available

Subversion

MySQL

Ruby on Rails

Domain attributes

Here is a list of every attribute in the entire domain, without respect to schema or entity:

member_number
member_name
member_full_name
member_email
member_level
membership_type
franchise_number
franchise_name
venue_number
venue_name
employee_number
employee_name
employee_full_name
attendance_date
offer_number
offer_name
offer_description
publication_name
sale_price

Notes:

  • front-of-house door staff name... is there a need for 'classes' of employees?
  • improvement offer {workshop, DVD, routine}... still not sure what to call 'improvements'? Offers?
  • amount of money taken for membership at venue on date... what 'sale' information we record needs to be clarified.
  • member email address... what other contact information should we keep?
  • member weekly email opt-in... model this as a subscription..?
  • member location... 'location' refers to which venue they typically frequent? Are memberships venue affinitive?
  • membership discount { none, student }... should be recorded with sale..?
  • merchandise..?
  • venue commission... should we capture this?

List the facts that the system must capture. These will be catered for by the ER model. Some things in the ER model will be incidental... this section exists to document the facts that are important to the business.

  • member's status, having active membership or not
  • active member's attendance at venue on date
  • member's subscription to publications
  • record of sale for membership

Database schema

Notes:

  • the issue of sync'ing multiple POS databases with a head-office DB is interesting. There are a number of ways to handle this... I'm not going to concern myself with it immediately. I'm thinking that we'll just log 'transactions' to files, apply those transactions to the local database, and send those transaction files to head-office during sync. Head office will then send a POS system all transactions that happened at other locations or something like that.
  • I think we'll want to use surrogate keys (GUIDs, prolly... it's a distributed and disconnected system), and I think those will be called <entity>_id. This is all a bit of a mess in the notes below. Work in progress and all that. :)
  • The issue of resolving conflicts will exist. I.e. what happens if two new members get allocated the same member number at two different venues and this isn't discovered until synchronisation..? Maybe include a 'venue_code' in member numbers, etc. The best idea is probably to maintained a fully versioned system at head-office and a last-in-wins system. The ability to inspect previous values exists in the unlikely chance it is necessary to do so.
  • Maybe have an 'entity' table (or view) and also a 'transaction' table.

PDDR Head office database schema: pddroff

PDDR Point of Sale database schema: pddrpos

member
( member_id, member_number, member_name, member_full_name, member_email, member_level )
membership
( membership_id, member_id, membership_type, discount_option )
franchise
( franchise_id, franchise_name )
franchise_venue
( franchise_id, venue_id )
venue
( venue_id, venue_number, venue_name )
user
( user_id, username, password )
employee
( employee_id, employee_number, employee_name, employee_full_name )
employee_user
( user_id, employee_id )
attendance
( attendance_id, membership_id, venue_id, attendance_date )
offer
( offer_id, offer_number, offer_name, offer_description )
publication
( publication_id, publication_name )
subscription
( subscription_id, member_id, publication_id )
sale
( sale_id, membership_id, sale_price, ?? )
offer_notification
( member_id, offer_id )

Enumerations/Lookup data:

member_level
{ beginner, intermediate, intermediate_advanced, advanced }
membership_type
{ casual, five_class_pass, monthly }
discount_option
{ none, student }

Note:

  • members have multiple memberships.
  • membership expiry is based on date or number of attendances.
 * casual: 1 attendance
 * five_class_pass: 5 attendance
 * monthly: expires at midnight on last night of calendar month
  • no credit extended

Business process

Overview

The business process for the point of sale systems and the head office systems will be documented here. System interactions will be described in terms of services provided by the system, forms that can be input into the system (either without effects as 'queries', or with potential affect as 'inputs'), and documents that can be returned from the system categorised as files, publications, or notifications. Business process will be elucidated in this way.

This is where role based security will be described if necessary. Files are documents that can and often do change, publications are immutable documents for broad (often public) access, notifications are immutable documents that are addressed for dispatch, and views are documents composed of files, publications and forms. Business services support up to two operations: Query and Submit; each operation accepts a completed form as its parameter. Parameters to the query operation of a service are called queries, and parameters to the submit operation of a service are called inputs.

The schema of queries and inputs are expressed by their form. After processing an input a service responds by constructing a query that refers the user agent to its next state. After accepting a query a service responds with a composite document known as a view.

Services that accept queries are called views. Services that accept inputs are called managers. Thus queries are for views, and inputs are for managers.

Documents

Documents are exposed in views which are in turn accessed via screens. Screens accept queries from users, determine the parameters for document requests, request those documents, and then compose those documents into views. Thus documents are not directly requested by users, they are constructed based on the parameters determined by a screen. Documents are created by querying the back-end stores. There are three types of documents: Files, Publications, and Notifications.

Files

Files are mutable documents, they are liable to contain changes upon each request.

Active Member Registry
[ { member_number, member_name, member_full_name, member_level } ]
Member History
{ member_number, member_name, member_full_name, member_level,
attendance_list: [ { venue_name, attendance_date } ] }

Publications

Publications are immutable documents, they return the same content upon each request. Publications are 'public' and have unrestricted access.

Weekly Newsletter

Notifications

Notifications are immutable documents, they are typically dispatched to an address list. Notifications are 'private' documents and are intended only for people on the address list. Typically they are dispatched via email.

Weekly Newsletter Alert
{ member_name, member_email, publication_id? }

Views

Views are composite documents created from an aggregation of forms, files, publications and notifications. Views are created by parameterising requests for documents. Views don't need to know about the back-end stores as they arbitrate requests to form, file, publication and notification providers.

Login View
Login Form
POS Main View
Active Member Registry, New Member Form, New Membership Form
Head Office Main View
New Venue Form, New Employee Form

Forms

This section specifies the attributes of formal requests. Requests are either queries, which return a view, or inputs which perform some action and construct a query for redirection.

Queries

Queries are requests which return views -- they are handled by screens.

Login View Request
POS Main View Request
Head Office Main View Request

Inputs

Requests are requests for changes -- they are handled by managers and return queries.

Login Form
{ username, password }
New Member Form
{ member_name, member_full_name, member_email, member_level }
New Membership Form
{ member_number, membership_type, sale_price, ..? }
Attendance Form
{ member_number, venue_number, attendance_date }
New Venue Form
{ ... }
New Employee Form
{ ... }

Services

Things a user can interact with.

Screens

Screens accept queries and return views.

Login Screen
Login View
POS Main Screen
POS Main View
Head Office Main Screen
Head Office Main View

Managers

Managers accept inputs and return queries (or error notifications). Managers directly manipulate the back-end stores and apply business logic appropriate to their service.

Session Manager 
Login Form -> POS Main View | Head Office Main View
Member Manager 
New Member Form -> todo
Membership Manager 
New Membership Form -> todo
Attendance Manager 
Attendance Form -> todo
Venue Manager 
New Venue Form -> todo
Employee Manager 
New Employee Form -> todo

HTTP interface design

Here we talk about how the business process is exposed via HTTP.

POS system

Screens

/login 
Login Screen
/home 
POS Main Screen

Managers

/session_manager 
Session Manager
/member_manager 
Member Manager
/membership_manager 
Membership Manager
/attendance_manager 
Attendance Manager

Head Office system

Screens

/login 
Login Screen
/home 
Head Office Main Screen

Managers

/session_manager 
Session Manager
/venue_manager 
Venue Manager
/employee_manager 
Employee Manager

Web-based user interface design

Here we talk about user-interface considerations. I envisage the POS 'main view' as having a full list of members with their photo.

Use case analysis

Here we'll walk through particular user interactions with the system via its user interface.

Questions

  1. Should staff record notes about conversations regarding customer service? Should the nature of those conversations be recorded in a 'machine readable' way? (e.g. verbally advised member number 123 of offer number 321 on 2007-12-13)
  2. What are the contingency plans? I.e. laptop hardware failure, inability to connect to network, data corruption, stolen money or equipment, etc. How will the system cater for such eventualities?

Use cases

  1. Employee arrives at work and turns on notebook
  2. Employee records attendance of existing member with active membership
  3. Employee records attendance of existing member with no current membership
  4. Employee records attendance of person not yet a member

Technical specification

Transactions

Here we'll list all the types of transactions supported in the system and nominate a file format for logging them. They'll need to be replayed at head office during sync.

Personal tools