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 time-
record 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 time-
sheets, 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
time-
sheets
are open
for users
to update
it's time
record
and
submit
after
validatio
n
 Approve
r can
either
accept or
reject the
Project
Timeshe
et
 When all
the
Project
Timeshe
ets are
approved
the
'Timeshe
et'
consider
ed
approved
 Approve
d time-
sheets
are ready
to be
taken for
billing or
accounti
ng
 Time
sheets
consume
d for
billing or
accounti
ng are
set to
'Final'
state.

 Rejected
Timeshe
ets are
open
again for
Team
 Member
s to
update
and
resubmit
*Project Timesheet's* life cycle
 All
created
Project
Timesh
eet are
first
assigne
d with
New
state
 New
Project
Timesh
eet are
open
for
users to
update
it's time
record
and
submit
after
validati
on
 Project
level
approve
rs can
either
accept
or reject
the
Project
Timesh
eet
 Rejecte
d
Project
Timesh
 eet are
open
again
for
Team
Membe
rs to
update
and
resubmi
t

 Project
Timesh
eets of
a Final
Timesh
eet 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

Occurren Edit
Property Range Type Description
ce s
The resource for
read creating and
resourc exactly-
tms:connectionList tms:ConnectionList - querying
e one
only tms:Connection
resources.
The resource for
read creating and
resourc exactly-
tms:projectList tms:ProjectList - querying
e one
only tms:Project
resources.
tms:teamList resourc tms:TeamList exactly- read The resource for
 creating and
-
e one querying tms:List
only
resources.
The resource for
read creating and
resourc exactly-
tms:approverList tms:ApproverList - querying
e one
only tms:Approver
resources.
The resource for
read creating and
tms:approvalPolicyLis resourc tms:ApprovalPolicyLi exactly-
- querying
t e st one
only tms:ApprovalPolic
y resources.
The resource for
read creating and
resourc exactly-
tms:timeSheetList tms:TimeSheetList - querying
e one
only tms:TimeSheet
resources.
The resource for
read creating and
tms:projectTimeSheet resourc tms:projectTimeSheet exactly-
- querying
List e List one
only tms:ProjectTimeSh
eet resources.
The resource for
read creating and
resourc exactly-
tms:timeRecordList tms:TimeRecordList - querying
e one
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.
zero-or- read- A $
tms:member*${Resource}* resource tms:*${Resource}*?
more write {Resource}
 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 Description

read- The short identifier for this
dc:identifier datatype xsd:string exactly-one
only Connection within its list.
read- The url for connecting to
dc:connectionURL datatype xsd:string exactly-one
write change management system
REST API for timeRecords
read-
dc:timerecordURL datatype xsd:string exactly-one retrieval/update/lock
write
operations

Project

Description

Properties

Property Range Type Occurrence Edits Description

read- The short identifier for this
dc:identifier datatype xsd:string exactly-one
only project within its list.
read- Connection in which this
tms:connection resource tms:Connection exactly-one
write project is available

Team

Description

Properties

Property Range Type Occurrence Edits Description

dc:identifier datatype xsd:string exactly-one read- The short identifier for this
 only Team within its list.
read- Project in which this team is
tms:project resource tms:Connection exactly-one
write available

ApproverRole?

Description

Properties

Property Range Type Occurrence Edits Description

read- The short identifier for this
dc:identifier datatype xsd:string exactly-one
only ApproverRole within its list.
zero-or- read-
tms:project resource tms:Project For which project
more write
read- The string identifier for approve
dc:name datatype xsd:string exactly-one
only role.
read- The string identifier for source
dc:sourceRole datatype xsd:string exactly-one
only system role.

ApproverPolicy?

Description

Properties

Property Range Type Occurrence Edits Description

The short identifier for
read-
dc:identifier datatype xsd:string exactly-one this ApproverPolicy
only
within its list.
read- project for which the the
tms:project resource resource exactly-one
only approval policy record.
read-
tms:approverRole resource resource exactly-one Approver role
write
read- How many 'Approver'
tms:approvalsRequired datatype xsd:number exactly-one
write roles have to apporve
read- number stating orders or
tms:apporvalOrder datatype xsd:number exactly-one
write 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

exactly- read- The short identifier for this

dc:identifier datatype xsd:string
one only TimesheetHistory within its list.
date
stateTransition
user
notes

ProjectTimeSheet?

Description

Properties

Property Range Type Occurrence Edits Description

The short identifier for this
read-
dc:identifier datatype xsd:string exactly-one Project Timesheet within its
only
list.
parentTimesheet
project
state

TimeRecord?

Description

Properties

Property Range Type Occurrence Edits Description

 The short identifier for
read-
dc:identifier datatype 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. Separate use cases for each reports should be combined to a single Use Case.
2. 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. 'User' actor is too generic should be renamed as team-member/contributor

2. 'Consumer' actor should be 'Viewer'
3. 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.
4. Partial approved states will have unlocked time records.
5. There should be two state flows, one for time record and another for time sheet
 6. 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)
7. '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. 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.
2. 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.
3. Linked vs Stored data? it's both linked and stored. The time records needs
to be stored in TM Application.
4. Time sheet part can be called as the Project Timesheet.
5. Prepare list of ToDo?'s from RTC. Timerecord locking, Time spent
updating.
6. Have a link to the Time sheet in the Work Item system.

20101119