In my previous entry I outlined a system through which I will track my progress (both in work output and quality improvement). While I potentially could track all required information using pre-existing tools, skills development, adaption of platforms and other complexities might make it more difficult to adapt say, Microsoft Office 2007 to the system than developing a (partial) solution myself. I’ve named this system “StudentQuest” the idea is actually inspired by MMO’s and other large-scale RPGs - all of them have a solution for managing what a player is supposed to be doing at any given moment - quest management. Since there is a clear personal progression and understanding that this system is focused on only a single aspect of the total experience, StudentQuest seemed like an appropriate name.
Scheduling, note data and work unit products can all be developed using Microsoft Office 2007. Project planning, estimation, quality analysis and other “process tasks” will have to be developed external to the system.
Which means the software, if it were to be built, would not:
- Author or manage documents, physical or virtual other than by reference.
- At first build, allow for work-unit-level process and planning (this would be done ad hoc).
- Create or display calendars at first build.
- At first build, track extraneous data integral to productivity such as resources, school supplies, study partners, etc
Which means the system, on first build, will:
- Track productivity and estimation accuracy for work units and courses.
- Track study-time requirements as a function of lecture quantity and difficulty.
- Track a partial work-unit lifecycle from estimation, skipping planning, development and post-mortem (QA is teacher marking).
- Allow various reports to be generated on productivity, work quality and overall progress.
- Report on schedule adherence, estimation accuracy and allow recursive adjustment to project scheduling.
- Indicate work-hour parameter warnings (over-load or under-load)
Now we’ve defined the basic scope for an initial build let’s define some basic use-cases.
Create a course
User elects to create a course. The user is prompted to enter information regarding the course including: course name, course code, start date, end date, professor, number of lectures, number of seminars, number of labs, projected difficulty of course (score from 1 - 100). System will validate fields and update database.
Create a work unit.
User elects to create a work-unit. User selects a course association. User is prompted to input the following: Work unit name, work unit description (usually the assignment description, test outline or other information regarding specification), due date, start date (if pre-planning course outline, default is “today”), estimated total work-time (in minutes), percentage complete (default = 0%).
Update work unit progress.
User is presented with a work-unit table. The user can update progress increase and work-time additions (in minutes).
View work-unit progress.
User is presented with a report table for all work-units including cumulative hours, total progress, schedule adherence, estimation accuracy, projected completion date, work adjustment, scheduled hours remaining, projected hours remaining.
Post-Mortem
Once a work-unit’s progress is 100% it is added to the post-mortem list. A user selects the post-mortem list and selects a work unit. The user is then shown a final progress report and is asked to input QA information. The user inputs a grade (either letter or percentage or both) and can input and add one or many “fault points”. For each fault point a user is asked to input a name, brief description, cost, scope, probability of recidivism and corrective prognosis.
View fault-point list.
As fault-points are added a list is available. A user can view this list which displays a report of all fault-points with the ability to sort by cost, scope, probability of recidvism, risk or work-unit of origin. This is presented as a table/check-list for easy printing as a user-side QA.
I think that is a sufficient set of use-cases for an initial build. Even if the feature count doesn’t expand beyond this, it should be a useful application for preliminary calculations and recursive analysis.