Casual Staff Management System CaSMaS

1
Casual Staff Management System (CaSMaS)

• By Jason Thomas

2
This Presentation

• Explain what I am doing
• Present current understanding of requirements
• Examine work flow
• Receive comments and confirm direction of
  requirements

3
RUP requirements Process

• Analyse the problem
• Understand the stakeholders needs
• Define the system
• Manage the scope
• Refine the system

4
Output of Process

• Vision Document (superseded)
• This presentation (preliminary analysis)
• Software Requirements Specification (SRS)
• Report (recommendations, size estimate of system,
  survey of alternatives)

5
List of People Interviewed

• Leon Sterling Chair of Facilities Committee
• Saeed Araban Manage current Casual Staff
  Recruitment process
• Michael Ciavarella Lecturer and Past Head Tutor
• Adam Hendrix Academic Support Programmer
• Julien Reid Financial Officer
• Lee Naish Privacy Officer
• 255 Tutors Casual Tutors, Casual Head Tutor
• Louise Walker Timetabling interface
• Vanessa Smith Data Entry for Casual Pays
• Jon Calendar Department Manager
• Rao Kotagiri Head of Department
• Antonette Mendoza Lecturer and Past Head Tutor
• Linda Stern Lecturer, developed specifications
  for a previous CaSMaS
• Aaron Burnham System Administrator

6
Purpose of System

• Integrated system to manage the recruitment,
  allocation, coordination, and payment of all
  casual staff within the Department of Computer
  Science and Software Engineering (Dept. of CSSE)

7
Motivation

• Current suite of tools are not integrated
• Current tools are not intuitive and often
  difficult to use
• Current process has not been streamlined
• Want to add support for the departments quality
  management initiatives (e.g. TADS)

8
Problems with TCSBS

• Allocations are difficult and staff burn-out
• Difficult to delegate allocation duty to Head
  Tutor
• Cannot select what is information worth
  displaying
• No interface with either Central Timetabling or
  Alloc8
• No easy access to dept. policies
• No ability to authorise access to facilities
• Doesnt cover FYC or SYC

9
More Problems with TCSBS

• Decentralised nature makes meeting global dept.
  hiring policies difficult (hire post-grads first)
• No data consistency or guidance w.r.t. open tute
  in Alloc8
• System is buggy and sometimes doesnt act as
  expected (making and accepting offers)
• Has back-door with access to ALL information
• No feedback on tutor performance from lecturer
• Doesnt explain all responsibilities (FYC, etc.)

10
Current Timetable input
11
Proposed Timetable input
12
Problems with Current Pay System

• Only text file interface
• Not adapted to current process (casual head
  tutors)
• No provision for managing or tracking swaps,
  marking, Head Tutor duties
• GENESIS requires manual entry of pay-claims, and
  manual approval to pay
• TADS pay slips through the cracks
• No feedback to casual about status of pay

13
Privacy Considerations

• Should not link Casual Staff with Student number
• If we maintain information on anyone, we must
  make it available to them and give them the
  opportunity to request errors be fixed
• There should be a well defined purpose for
  collecting each piece of data
• All data should have an expiry date

14
Privacy Considerations (Contd)

• Access to information should be limited to a
  specific purpose
• We must be open about information stored,
  including access logs
• Users should not be able to access unnecessary
  information
• All sensitive information should be communicated
  via secure link (e.g. https, ssh)

15
Who will use the System?

• Casual tutors, lab demonstrators, after hours
  supervisors, help desk supervisors
• Casual Head Tutors
• Lecturer (Subject Coordinators)
• Casual Staff Coordinator (if created)
• Administration and Support Staff
• Department and Teaching Coordinators

16
Actor (Role) List

• Department Coordinator (HoD or Dept. Manager)
• Teaching Coordinator (Academic)
• Administration Staff
• Casual Staff Coordinator (Academic)
• Subject Coordinator (Academic)
• Subject Head Tutor (Academic or casual staff)
• Casual Staff (applicant, candidate, employed)

17
User Environment

• Dept. LAN, consisting of Solaris 5 x86 servers,
  Windows 98, 2000, and XP desktops, Mac OS X
  desktops, Linux desktops
• Home computers connected via 56kbps modem running
  Windows 98, 2000, or XP, Mac OS X, or Linux

18
Product Perspective

• Replace or supplement current suite of tools
• Improve workflow or directly interface with
  external university systems (Central Timetabling,
  Alloc8, Genesis (Payroll))
• Provide short term and long term solutions
• Maintain data security and integrity
• Provide transparency of decisions and work flow
  for Auditing Purposes

19
High Level Features

• Advertise available casual position
• Facilitate allocation of casual staff to duties,
  focused on scheduling
• Facilitate Casual staff position offers and
  acceptance of offers
• Track work performed for payment
• Payment of work performed

20
High Level Features (Contd)

• Track the training, experience, and past
  performance of casual staff
• Facilitate coordination of casual staff
  performing duties
• Facilitate authorisation of access to facilities
  for casual staff
• Generate reports to facilitate each stage
• Log all data access for auditing purposes

21
New Features

• Ability for Staff to create new applicant
• Control over what data can be updated at each
  stage
• Facilitate access to student marks (requires
  student consent)
• Manage casual staff swapping classes, both
  temporarily and perminently

22
New Features (Contd)

• Auto-allocation, modify, approve for each subject
  timetable
• Each user should be able to view all information
  on themself
• Log all data access (must inform all users of
  this)

23
New Features (Contd)

• after login, list all activities user can perform
  (e.g. apply, update, submit pay-claim)
• Pay-claims include a reminder, defaults, modify,
  and submit
• Allow (and encourage) applicants to update
  availability information
• Clear explanations for user interface
• Force all staff to use the system (consistent
  data)

24
New Features (Contd)

• Clear upfront contractual obligations stated
• Automate data entry into GENESIS
• Include appraisal of casual staff by coordinating
  staff (4 grades)
• Produce subject summaries (budget)
• Facilitate First and Second Year Centre
  scheduling, semi-automated

25
User Interface

• Web and shell interfaces
• Minimize effort for user
• Able to display necessary information
• Differentiate between applicants and candidates
• Whiteboard approach to timetabling
• Task oriented interface
• Propose and approve approach to scheduling
• Allow negotiation between subject coordinators

26
Report Generation

• Ability to select a subset of data to display
• Ability to reduce set of applicants to candidates
• Ability to sort and search via multiple criteria
  (e.g. applied for 253, is PG, available at 10am)
• Ability to change configuration parameters
  (including number of people required for each
  class)
• Ability to store and share report templates

27
Central Information

• Noticeboard for each class of user
• Important dates
• Relevant policies

28
Training and Help

• Available for beta testing before release
• Demonstrate system on delivery
• Provide online help
• User Manual
• Sufficient documentation for maintenance (SRS,
  SDD, code, test cases)
• Make Dept. and University Policies easily
  available

29
Context Level DFD
30
Sub systems

• Recruitment
• Allocation
• Coordination
• Payment

31
Recruitment Process
32
Allocation
33
Coordination
34
Payment
35
Quality Focus

• Correctness
• Maintainability
• Modularity
• Reliability
• Useability

36
Staged Delivery

• Recruitment and Allocation available in January
  for testing, in use by semester 1, 2005
• Payment
• Coordination and Tracking

37
Questions and Comments?