Time Management System
Time Management System child topics: Use Cases?

Time Management System
o Introduction
o Terminology
o Use Cases
 Actors
 UC1: Configuring
 UC2: Processing
 UC3: Reporting
o User scenarios
o Architecture
 Design Discussions
 Design Assumptions
 Context Diagram
 Configuring Change Management Applications
 Configuring
 Approver Role
 Approval Policies
 Processing Timesheets
 Timesheet work flow
 Reporting
 Timesheet summary report
 Timesheet details report
 Missing Timesheets report
 Rejected Timesheets report
o Data Model
 Note: The resource here are work in progress.
 Service
 ${Resource}List
 Connection
 Project
 Team
 ApproverRole
 ApproverPolicy
 Timesheet
 TimesheetHistory
 ProjectTimeSheet
 TimeRecord
o Reviews
 20101020
 20101108
 20101116


20101118
20101119
Introduction
Time Management System (TMS) tracks and manages the time spent by resources on
various projects activities categorized by time codes. Timesheet application collects the
time records from time tracking change management systems and mange them as time
sheets.
Time management broadly includes,
1. Time Sheet life cycle management (new, submitting, revoking, approval and
rejection)
2. Generating appropriate reports on time spent details
Terminology








Rational Project Conductor (RPC) - Project management solution from IBM
Rational , in this context RPC 3.1
Change Management Application (CM) - An application that manages software
changes.
Managed Application (MA) - Any change management application which
supports time tracking capabilities. Eg. RTC
Time Management System (TMS) - The application that manages time spent in
project activity by getting the time entry records from various change
management applications.
Time Record (TR) - A record contains details on daily time spent per person, on
a work item by time code. CM are the source of Time Records
Timesheet (TS) - A combination of of all the 'time records' entered by a Team
Member over period of time
Project Timesheet - Project wise grouping of time records in a given Timesheet.
Enables project wise approval of a Timesheet.
Time code - Time record attribute for categorizing time records based on
different activities, like coding, testing, training etc
Symbol
Description
Not scoped in for RPC 3.1 2010Q2 release
Review comments addressed
Warning
Request for comments
Note
Information or Help
Use Cases
Actors




Administrator: Team Member with administrative privilege to TMS
Approver: Team Member with Timesheet approval rights. Typically project
manager, team lead, resource manager etc.
Team Member: User with author and submit permission for Timesheets
Viewer: A Team Member or a System with access to all time data across projects,
business units or organization either for reporting or for accounting. (Eg. Reports,
Billing)
UC1: Configuring




Administrator configures change management systems as time-record sources
(Eg. RTC, CCM, RQM, Bugzilla, JIRA)
Administrator configures the approval roles and policies
Administrator configures the Timesheet period (default one week)
Approver delegates Timesheet approval rights
UC2: Processing










Team Member shall create or update time-records on CM for new Timesheets
Team Member shall submit a Timesheet
Team Member shall recall a submitted Timesheet
Approver shall (partially) approve submitted Timesheets with optional note
(Project Timesheet).
Approver shall reject submitted or (partially) approved Timesheets with optional
note (reason for the rejection)
Team Member shall create or update time-records of rejected Timesheets
Team Member shall not update time-records of submitted or approved
Timesheets
Timesheets that are ready to be consumed for billing shall be given 'Final' state.
Fine Timesheet content are frozen for good.
Should there be any modification to Final Timesheets can be handled thru new
additional 'Corrective Time records/sheets'
UC3: Reporting
The following time management reports shall be generated by the system




Timesheet summary report
Timesheet details report
Missing Timesheets report
Rejected Timesheets report
User scenarios











For the week of Jan 3,2010 Team Member Ashok has worked on WI 101 of
'Online Action' project and WI 201, 202 of 'Smarter Planet' project.
o scenario 1: Ashok has entered time records for all the three Work Items (
101, 201 & 202)
o scenario 2: Ashok has entered time records for only WI 101 and WI 201
and did not enter time record for WI 202
o scenario 3: Ashok has not entered any time records for any of the three
work items.
Ashok creates a Time sheet in RPC for the week of Jan 3, 2010
Ashok sees the already entered time records ( 3 for scenario 1, 2 for scenario 2,
and none for scenario 3) as part of newly created Time sheet.
Ashok also sees the suggestive list of Work items ( none for scenario 1, WI 202
for scenario 2, and WI 101,201 & 202 for scenario 3) that he would've worked
during this period on but didn't not enter Time records.
Ashok creates the missing Time records.
Ashok now sees all the Time records (WI 101, 201, 202) displayed under the
newly created Timesheet.
Ashok finalizes the Time sheet and submits for approval.
Mahesh, one of the approvers of Online Auction approves Project Timesheet,
with that Time sheet is considered as partially approved
Sudipto, one of the approvers of Smarter Planet approves other Project
Timesheet and now Time sheet is considered 'Approved'
Rejection from either one of Mahesh or Sudipto means the Timesheet as a whole
is rejected, even the other one has approved it
Viewer Bala consumes 'Final' Time sheet details for Billing or Accounting
purposes
Architecture
Design Discussions
1. Time Tracking@CM is mandatory or not?
There are two ways in which TMS can be designed based on where the Time tracking
operation is being done. Time tracking can be done either at TMS side only or at CM
only or at both the places. Current design assumption is that Time tracking to be done at
CM and also enable Time tracking to be done from TMS side as well. This topic
discusses and weighs both the approaches.
Time tracking @ CM is
Time tracking @ CM is NOT mandatory to enable
mandatory to enable TMS
TMS
Developers entering time records Very first time TMS extracts all the CM's Time records
get persisted into CM's
of configured projects and disable CM's time tracking
repository.
capability (RM Model)
Later TMS sync up wiht CM's
Herein after all the time tracking records are stored at
repository
TMS repository only
Team Members@CM enters time Team Members@CM enter time records using TMS
records using CM's native UI
time entry UI thru CALM links (embedded UI)
Team Members@TMS enters
Team Members@TMS enters time record using TMS
time record using TMS native UI native UI
Sync-up required between CM & One time effort later TMS will be the only repository
TM repositories
for Time records
CM system have to have Time
CM system having Time Tracking is optional
tracking
Conclusion: TMS shall be implemented in a phased approach.
Consuming Time tracking from RTC is mandatory for first cut. In long run the time
tracking records can be in TMS
Phase 1: TMS shall not aware of any CM application
Phase 2: TMS shall be aware of WorkItem? of a CM application
Phase 3: TMS shall be aware of WorkItem? and Timetracking and jointly work with CM
Application thru REST API
Phase 4: %ICONURL/{stop}% TMS shall be aware of Work Item and Time tracking
and Time tracking @ CM is done thru delegatable User Interface
2. Linked vs Stored data?
Time records are @ CM repository. There are two ways in which TMS could function.
i.
Time records are only at CM repository and TMS access Time records@CM thru
links
ii.
TMS makes copy of time records@CM repository and sync up at appropriate
times
Conclusion: Approach is to have both Linked and Stored data
Design Assumptions
This section lists all design assumptions we've made while designing TMS.
1. CM Systems have to have Time tracking capability


Each change management systems have to have time tracking capability
implemented.
Each change management system should implement the REST APIs described by
TMS for the integration.
2. One interface for all Time management operations



Team Member should be able to perform all time management operations for
change management systems that are with time-tracking capability.
The operation are time records creation @ change management system, timesheet
submission, approval and reporting.
For time-records creation, the system shall provide suggestive list of work items
on which Team Member would have spent time on, based on code checkin,
assigned active workitems, workitem state transitions or workitem update by a
Team Member.
3. Time record to Timesheet mapping




A Time record is created to store time spent by a single Team Member for a given
period of time on a work item for a type of activity(time code),
All time records by a single Team Member for given period of time (generally a
week) across all the projects, is grouped together as one Time sheet.
A Timesheet may have time-records by a Team Member from two or more
different projects. Eg, Team Member Ashok worked on both Online Auction and
Smarter Planet projects for the week starting 7-Nov-2010.
Project Timesheet is project wise grouping of time-records of a Timesheet's time
records for approval convenience.
4. TMS working when CM offline



TA shall have private repository and store time records pulled from various CM
systems * TA shall have appropriate refresh mechanisms to update local data as
the source data change.
Having private repository enables reporting and querying the approved time
sheets even the CM are disconnected.
However for approval/submission operations the CM applications needs to be
connected and running.
Context Diagram
The following context diagram illustrates the system environment in which TMS
functions also show the high level system interactions in a TMS environment.




TMS is a jazz fronting application and is a part of Rational Project
Conductor(RPC) product solution
TMS shall be configured to work with CM systems with Time tracking
capabilities
For RPC 2011, the scope is to support RTC 3.0 WorkItem? application as Time
record store.
TMS can work with other Change Management applications like Clear Quest,
JIRA, Bugzilla as well, provided REST APIs described by TMS are implemented
at CM side.
Configuring Change Management Applications
As a very first step, list of change management Applications ought to be configured with
TMS. The following diagram show the high level sequences of operation to be done by
administrator as part of Configuring Timesheet Application.
Configuring
At a high level, for each Time management application setup, a Connection List which
contains list of the Change management applications configured to receive time records
from. Each entry of Connection Directory, Connection expected to have the connection
details about each of change management application including how and from where the
time records can be received from.
Connection may have the following properties,




Repository connection details (http://rtcserver/ccm)
Connection methodology (OAuth keys)
List of projects definitions (For RPC, Sub-projects {project area, release plan})
Timesheet retrieval details (time sheet collection URL for each project)
Do we've have to pull all the time-records, or the time-records of RPC configured
projects alone?
PRC's Sub-projects configuration can be leveraged to construct Connection
Directory?
Approver Role
The section describes how the approval role is defined in Timesheet Application.






Approver role is specific to TMS, not in CM's scope.
Different CM applications may have different roles defined within ( Agile [scrum
master], Traditional[project manager, team lead] project areas)
Administrator configures selected (role and process specific) CM roles with timerecord edit permission as ApproverList for project and sub-projects levels
Alternatively RPC's user mapping can be leveraged for Approver role mapping.
Every logged in Team Member assumed to be timesheet user, however operations
like, updating time-records, submitting time-sheets are subjected to permissions
back in CM applications
*Approver*'s scope can be at Project/subproject/team levels or at a Resource
group level
o Projects/subprojects/Teams level approvers can approve time-sheets
filed against the project/sub-projects by any resource
o
Resource level approvers can approve time-sheets filed by member of
resource pool against any project.
Approval Policies
Approval policies are collocation of rules established for performing time sheet approval
task. Approval rules defines the approval process for a given project.
Approval rules include



Levels of approvals (one tire or multi-tire?)
Number of approvals (how many approvers required at each level?)
Order of approvals (who get to approve first?)
Approval policy may differ from project to project based of the process being followed.
Here's an example of an apporval policy: For approving Online Auction project timesheets, there ought to be 'one' team level approver and 'one' project level approvar
required in the same order.
Though this resource provide support to specify such elaborated policies, For RPC 3.1
release, the scope is to implement *One approver" policy.
Processing Timesheets
Time sheets are collection of all time records entered by one resource(person) over period
of time (week) across all the projects. Time records of a Timesheet are grouped by
project called Project Timesheet for project level approval. Following class diagram
shows the relationships between Time sheets, Project Timesheet and Time Records.
Change management systems are the sources for time-records and the time records are
expected to be exposed thru REST Api. Time code attribute of time-record denotes the
type of the activities on which the time is entered, which helps in categorizing the time
for accounting purposes.
The life cycle of time sheet can be more understanding if we see the life cycle of Project
Timesheet and the Time sheet itself.
Timesheet work flow
Following describes Timesheet life cycle work flow with following fixed states.
Current system does not support modification or including of new states.
Timesheet's life cycle



All created
Time
Sheets are
first
assigned
with New
state
New timesheets are
open for
users to
update it's
time record
and submit
after
validation
Approver
can either
accept or
reject the
Project
Timesheet




*Project Timesheet's* life cycle
When all
the Project
Timesheet
s are
approved
the
'Timesheet'
considered
approved
Approved
time-sheets
are ready
to be taken
for billing
or
accounting
Time
sheets
consumed
for billing
or
accounting
are set to
'Final'
state.
Rejected
Timesheets
are open
again for
Team
Members
to update
and
resubmit





All
created
Project
Timeshee
t are first
assigned
with New
state
New
Project
Timeshee
t are open
for users
to update
it's time
record and
submit
after
validation
Project
level
approvers
can either
accept or
reject the
Project
Timeshee
t
Rejected
Project
Timeshee
t are open
again for
Team
Members
to update
and
resubmit
Project
Timeshee
ts of a
Final
Timesheet
is also
Final, and
is locked
for good.
Lock and Unlock symbols denote whether the time-records are editable or not, in a
given state.
Reporting




TA shall expose all the resources for reporting as per RDF based OSLC
reportable Rest spec.
ODS ETL (Java & DM) needs to be written to pull data from TA to Data
Warehouse.
Data collection: RTC 3.0 Planning ETL needs to be re factored, so that disabling
RTC 3.0 time sheet jobs and enabling TA time sheet jobs are possible.
The following time management reports shall be generated by the system
Timesheet summary report



Timesheet Summary by Employee: Aggregate timesheet data per employee.
Timesheet Summary by Pool/Employee: Displays aggregate timesheet data per
employee sorted by resource pools. The Report Parameters window is displayed
before opening the report that lets you filter the report by state, these include: All,
Submitted, Approved, Rejected, or Missing.
Monthly Timesheet: Monthly time spent summary
Timesheet details report



Timesheet Detail by Employee: Timesheet data by individual resource.
Timesheet Detail by Pool/Employee: Displays timesheet data for resources
Grouped by resource pools.
Timesheet Detail by Project: Timesheet data grouping resources by project.
Missing Timesheets report
Missing time sheet report should give count of 'time sheets that weren't created' or
'time sheets that weren't submitted' for a resource when he's assigned to a task.
Rejected Timesheets report
Rejected time sheet report should give count of 'time sheets that were rejected'.
Data Model
The data model consists of a set of resource types in Timesheet Application. Each
resource type is described by listing and describing its properties.
Note: The resource here are work in progress.
Service
Description
TMS has unique tms:Service resource that acts as the root resource for all the resources
managed by this system.
Properties
Property
Range
Type
Occurren Edit
ce
s
tms:connectionList
resourc
tms:ConnectionList
e
exactlyone
tms:projectList
resourc
tms:ProjectList
e
exactlyone
tms:teamList
resourc
tms:TeamList
e
exactlyone
tms:approverList
resourc
tms:ApproverList
e
exactlyone
tms:approvalPolicyLis resourc tms:ApprovalPolicyLi exactlyt
e
st
one
tms:timeSheetList
resourc
tms:TimeSheetList
e
exactlyone
tms:projectTimeSheet resourc tms:projectTimeSheet exactlyList
e
List
one
Description
The resource for
read creating and
querying
only tms:Connection
resources.
The resource for
read creating and
querying
only tms:Project
resources.
The resource for
read
creating and
querying tms:List
only
resources.
The resource for
read creating and
querying
only tms:Approver
resources.
The resource for
read creating and
querying
only tms:ApprovalPolic
y resources.
The resource for
read creating and
querying
only tms:TimeSheet
resources.
read The resource for
creating and
only querying
tms:timeRecordList
resourc
exactlytms:TimeRecordList
e
one
tms:ProjectTimeSh
eet resources.
The resource for
read creating and
querying
only tms:TimeRecord
resources.
${Resource}List
Description
TMS service contains exactly one ${Resource}List resource. New connection resources
are created by POSTing to this list. The list may be queried to search for ${Resource}.
Properties
Property
Range
Type
Occurrence Edits Description
The service
read- root that
tms:service
resource tms:Service
exactly-one
only manages this
list.
A
zero-orread${Resource}
tms:member*${Resource}* resource tms:*${Resource}*?
more
write that belongs
to this list.
${Resource} can be Connection, Project, ApporverRole?, ApproverPolicy?, TimeSheet?,
TimeRecord?
Connection
Description
An tms:Connection is an information resource that facilitates connecting to change
management systems. Every time a new change management system configured to TMS
a new connection resource created and added.
Properties
Property
Range
Type
Occurrence Edits
readdc:identifier
datatype xsd:string exactly-one
only
readdc:connectionURL datatype xsd:string exactly-one
write
Description
The short identifier for this
Connection within its list.
The url for connecting to
change management system
REST API for timeRecords
readdc:timerecordURL datatype xsd:string exactly-one
retrieval/update/lock
write
operations
Project
Description
Properties
Property
Range
Type
Occurrence Edits
readdc:identifier datatype xsd:string
exactly-one
only
readtms:connection resource tms:Connection exactly-one
write
Description
The short identifier for this
project within its list.
Connection in which this
project is available
Team
Description
Properties
Property
Range
Type
Occurrence Edits
readdc:identifier datatype xsd:string
exactly-one
only
readtms:project resource tms:Connection exactly-one
write
Description
The short identifier for this
Team within its list.
Project in which this team is
available
ApproverRole?
Description
Properties
Property
Range
Type
Occurrence Edits
readdc:identifier datatype xsd:string exactly-one
only
zero-orreadtms:project resource tms:Project
more
write
readdc:name
datatype xsd:string exactly-one
only
readdc:sourceRole datatype xsd:string exactly-one
only
Description
The short identifier for this
ApproverRole within its list.
For which project
The string identifier for approve
role.
The string identifier for source
system role.
ApproverPolicy?
Description
Properties
Property
dc:identifier
Range
Type
Occurrence Edits
datatype xsd:string exactly-one
readonly
readonly
readtms:approverRole
resource resource exactly-one
write
readtms:approvalsRequired datatype xsd:number exactly-one
write
readtms:apporvalOrder
datatype xsd:number exactly-one
write
tms:project
resource resource
exactly-one
Description
The short identifier for
this ApproverPolicy
within its list.
project for which the the
approval policy record.
Approver role
How many 'Approver'
roles have to apporve
number stating orders or
approval
Timesheet
Description
The timesheet resource.
Properties
Property
Range
Type
Occurrence Edits
Description
read- The short identifier for this
dc:identifier datatype xsd:string exactly-one
only
Timesheet within its list.
user
startDate
endDate
state
TimesheetHistory?
Description
Properties
dc:identifier
date
datatype xsd:string
exactly- read- The short identifier for this
one
only TimesheetHistory within its list.
stateTransition
user
notes
ProjectTimeSheet?
Description
Properties
Property
dc:identifier
Range
Type
Occurrence Edits
datatype xsd:string exactly-one
readonly
Description
The short identifier for this
Project Timesheet within its
list.
parentTimesheet
project
state
TimeRecord?
Description
Properties
Property
dc:identifier
Range
Type
Occurrence Edits
Description
The short identifier for
readdatatype xsd:string exactly-one
this TimeRecord within
only
its list.
parentProjectTimesheet
date
timeSpent
team*
workitemId
timeCode
Reviews
Lists all the review meetings held and review comments provided by participants.
Review comments with ' ' marks are already addressed and incorporated into document.
20101020
Arthur, Per, Sudipto, Mahesh, Prem, Vikas, Karthi
1.
2.
Separate use cases for each reports should be combined to a single Use Case.
In general, the document should have Use Cases defined at high level, and
main flow and alternate flows should be documented under User Stories
3.
Use Case 2 (Timesheet viewing) & 3 (Timesheet submitting ) should be
combined, in case the user wishes to edit the time records, a separate widget
should be launched to allow him to add/modify the data. editing time record
should be done within the timesheet view
4.
Use Case 4(viewing) & 5 (approving) should be combined, in case the project
manager wishes to edit or view, a separate widget is launched.
5.
There is no requirement to show Timesheet widget in User profile view.
6.
Timesheet view itself is a work in progress view that is based on query
mechanism.
7.
Browser refresh should suffice in case of new time records being added for the
date range instead of separate refresh button action.
8.
User and date range are the only differentiating characteristics of a Timesheet.
Other attributes like approver and WI/Project area can be used for
filtering/classification.
9.
A Timesheet can have multiple approvers in case his work spans across
different project areas/team areas. The status of timesheet is "Approved" only
when all the approvals are in "Approved" state.
10. We need to map approvers from team area to resources for timesheets.
11.
Resource manager has authority to approve all time records for the resource
managed by him.
12. But Project manager has authority to approve time records in his project/ team
area boundaries. resource manager approval is lower priority for the first
release
13. For scoping purpose only Project Manager kind of approver will supported in
first version.
14. Time tracking records are copied in timesheets and should be made available as
read-only data, while we still need to provide links to the WIs
15. Questions posted after the call:
i.
Timesheet state transition validation
ii.
Can user cancel the timesheet submission?
20101108
Bala, Mahesh, Sudipto, Karthi
1.
What about partial approval ?
i.
Can user update partially approved time sheets?
ii. What is the workflow for rejecting already Approved TS as you mention
above ?
iii. Approver approves time entries for a few WI's & rejects some. What
happens to Timesheet as a whole?
2.
Cover three possible usage scenario of time entry from CM side. ie User enters
all the time records, partial and none. How TMS would work?
3.
Can TMS work when the CM applications are down / offline ? TMS would'nt
be maintaining its own store with duplicate data. Data will be retreived from other
systems & workflow executed based on actions. Correct ?. * With CM offline,
TMS expected to work with already approved time sheets, however for the
approval operation the CM apps had to be online*
4.
Configuration information for TMS has to be maintained separately.. eg :
We would need to maintain approver list for each project, delegate list etc ?. How
are we planning to maintain this ?. Separate project area for TMS ?
5.
What's a project in TMS scope? The project in TMS is same as the project
RPC.
6.
Attach RDF XML sample for each RDF resource elements
20101116
Arthur, Gail, Neil, Per, Bala, Sudipto, Mahesh, Sharoon, Aradhya, Prem, Vikas, Karthi
1.
2.
3.
4.
5.
6.
7.
'User' actor is too generic should be renamed as team-member/contributor
'Consumer' actor should be 'Viewer'
In case the approved timesheet is found to be incorrect/needs modification we
should not change its content but create a correction transaction or compensating
time record. This is not in scope but worth putting note on.
Partial approved states will have unlocked time records.
There should be two state flows, one for time record and another for time sheet
Approver can approve time sheet and not individual time records, but the
design is planned to have approval at group of time records for project (Project
Timesheets)
'Final' state should be included in the state transition, right now its OK to have
transition from 'Approved' state to 'Returned' state (earlier known as Rejected).
20101118
Arthur,Gail, Per, Sudipto, Mahesh, Sharoon, Aradhya, Prem, Karthi
1.
2.
3.
4.
5.
6.
Working scenario for TMS and Time tracking feature of @ CM application.
*Time tracking in CM is mandatory for first cut. But in long run the time tracking
records should be in TMS. Priority 1: have TMS work with the Existing data in
RTC.
Offline capability of TMS - Not to worry at this moment, will take an
iterative approach towards this. Tirst let the TMS take time records from
RTC.
Linked vs Stored data? it's both linked and stored. The time records needs
to be stored in TM Application.
Time sheet part can be called as the Project Timesheet.
Prepare list of ToDo?'s from RTC. Timerecord locking, Time spent
updating.
Have a link to the Time sheet in the Work Item system.
20101119