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 department’s 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 • Doesn’t 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 doesn’t act as expected (making and accepting offers) • Has “back-door” with access to ALL information • No feedback on tutor performance from lecturer • Doesn’t 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 (Cont’d) • 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 (Cont’d) • 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 (Cont’d) • 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 (Cont’d) • 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 (Cont’d) • 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?