University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
This document is a record of the approach that was used to develop the PS 8 upgrade estimates.
Estimating Approach for PS Upgrades
Estimates were made for the following phases/functions within the Application areas (CPU’s):
1. Development (Code and Unit Test)
2. Analysis
3. System Test (& SIR processing)
4. Performance Tuning
5. Applying PeopleSoft Fixes
6. Performance Support
7. Batch Architecture and Query Processing
8. Infrastructure
9. Security
10. Data Warehouse
11. Third Party Products and Interfaces
Data Conversion was not calculated separately but assumed to be incorporated into the other
upgrade phases. This is one area to verify for future upgrades.
1.) Development (Code and Unit Test) Estimating
(back to top)
Step 1: Determine modified objects. Modifications were identified down at the object level in
order to determine the effort to recode (development estimates) in the new version.
Modifications fell into three categories: a) those objects that required no action. They would be
carried forward but required little or no effort to do so. b) Hand applies. These objects would
need to be reapplied by hand once the data conversion was complete. c) objects requiring a
significant redesign effort.
Step 2: Determine level of difficulty for each object. Appendix A indicates the criteria used for
determining the level of difficulty.
Step 3: Determine Development values based on the category and difficulty of mod. See
Appendix A for table of development hours based on object type and level of difficulty. Hand
Applied objects were estimated using the upgrade hours while new development were estimated
using the development hours indicated in Appendix A.
Objects and development hours were tracked in Upgrade Dev-UT & Analysis Estimates
EXAMPLE. Several iterations were made at determining category and difficulty.
Document1
Page 1 of 16
Last Updated: 2/9/2016
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
2.) Analysis Estimating
(back to top)
Step 1: Business Processes were identified in each of the product areas and categorized based
on 5 Criteria
The Criteria include
A.
B.
C.
D.
E.
Business Process Level of Difficulty for Systems Test Efforts
Business Process Level of Impact to the University Community
Level of Change in Functionality
Interfaces to and from the Business Process
Test Conditions were previously defined.
A
B
D
C
E
The following definitions were used to help determine how difficult the Business Process would
be to System Test.
Difficult: If four (4) or more of the following are true:
 More than 3 hand-offs as part of the Business process
 More than 3 panels are referenced as part of the Business process
 More than 20 fields with multiple choices and much error checking logic
Document1
Page 2 of 16
Last Updated: 2/9/2016
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT



User starts up a remote call or batch job as part of the process
User is required to schedule the process for less busy times
Business Process is a prerequisite to other Business Processes
Medium: If three (3) or more of the following are true:
 One or two hand-offs as part of the Business Process
 Process requires user to simultaneously access 2 panels for reference
 More than 5 but less than 20 fields with multiple choices and moderate
error checking
 Three or more panels are referenced as part of the Business Process
Low:
If at least 3 of the following are true:
 No hand-offs as part of the Business Process
 3 or less panels are referenced as part of the Business process
 Business Process is a terminating process (is not a prerequisite to other
business processes).
 No remote calls are initiated in the process
 There are no scheduling requirements for performing the processes
 Little or no error checking logic in the panels
Step 2: Calculate Analysis hours based on the % of Dev hours determined by the values for the
criteria A, B, and C. Analysis hours for Hand Applied Objects are percentages of the time
needed to code and unit test. New measures are assigned for the 3 of the 5 criteria mentioned
previously and identified below.
Upgrade Phase
Criteria
Usage
Measures
Analysis/Design
A. Business Process Level of
Difficulty
Analysis/Design
B. Business Process Level of
Impact to the University Community
1.
2.
3.
1.
35%
25%
10%
for
20%the
Analysis/Design
C. Business Process Level of
Change in Functionality Between
Versions
Difficult
Medium
Easy
High impact, high visibility
University
2. Medium impact, medium
visibility
3. Low impact, low visibility
1. High
2. Medium
3. Low
15%
10%
20%
15%
5%
Percentages are accumulative so that analysis for development of objects for a specific Business
Process could require up to 75% of Development hours. Therefore, percentages for Analysis
would be calculated as
(Measure for Business Process Level of Difficulty + Measure for Business Process Level of
Impact + Measure for Business Process Level of Change)
Document1
Page 3 of 16
Last Updated: 2/9/2016
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
As a example, if
Criteria A=Difficult
Criteria B=Medium Impact, visibility
Criteria C=Medium
Then the corresponding measures would be
Criteria A=35%
Criteria B=15%
Criteria C=15%
The resulting equation would be
(.35+ .15 + .15)=.65 or 65% of the development hours of the object. These rates are recorded in
BP System Test Estimates HR_SA.xls
Analysis (Design Time) for new modifications required by the upgrade is calculated based on the
table in Appendix A.
Step 3: Multiply Dev hours in the New Dev Estimates.xls by the rates recorded in the Business
Process Spreadsheets. The result is recorded in Upgrade Dev-UT & Analysis Estimates
EXAMPLE.
3.) System Test (& SIR Processing) Estimating
(back to top)
Step 1: Values were assigned for each of the 5 criteria as described in the following table
Upgrade Phase
Criteria
Usage
System Test
A. Business Process Level of Difficulty
for Systems Test Efforts
System Test
B. Business Process Level of Impact to
the University Community
1.
2.
3.
1.
2.
System Test
C. Business Process Level of Change in
Functionality Between Versions
System Test
D. Business Process Interfaces
System Test
E. Test Conditions Defined
Document1
Page 4 of 16
Last Updated: 2/9/2016
3.
4.
5.
6.
1.
2.
3.
1.
2.
Measures
Difficult
1. = 120 hours
Medium
2. = 60 hours
Easy
3. = 20 hours
High impact, high visibility
1. = for
100% of A
the University
2. = 60% of A
Medium
impact,
medium
3. = 30% of A
visibility
Low impact, low visibility
High
1. = 2.0 x A
Medium
2. = 1.6 x A
Low
3. = 1.3 x A
Yes, external to MAIS
1. = 80 hours
Yes, internal to MAIS
2. = 40 hours
No
3. = 0 hours
Yes
Y = 1.0 x A
No
N = 1.25 x A
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
Step 2: Calculate the number of hours for System Test at the Business Process level based on
the following formula
(((Measure for Level of Difficulty*Measure for Level of Impact)*Measure for Level of Change
in Functionality Between Version)+Measure for Business Process Interface)+((Measure of Test
Conditions – 1 )*Measure for Level of Difficult)
To further our example, if
Criteria A=Difficult
Criteria B=Medium Impact, visibility
Criteria C=Medium
Criteria D=Yes, Internal to MAIS
Criteria E=No
Then the corresponding measures would be
Criteria A=120 hours
Criteria B=60%
Criteria C=1.6
Criteria D=40
Criteria E=1.25
The resulting equation would be
(((120*.60)*1.6)+40+((1.25-1)*120))= 185.2 hours to System Test the Business Process
Hours are recorded at the business process level in Upgrade System Test Estimates
EXAMPLE.xls.
4.) Performance Tuning Estimating
(back to top)
Performance Tuning, in this case, refers to the work effort required within the CPU’s to apply
and test tuning recommendations. This was calculated as a straight 6% of the development effort
(i.e. Tuning Hrs = .06*Dev Hours) for the HR and SA CPU’s. A factor of 3% was used for the
Financial Upgrade estimates.
5.) Applying PeopleSoft Fixes Estimating
(back to top)
Even though the upgrade will occur with the most recent Service Pack in place for the HE
product, a large number of fixes, including tax updates and Financial Aid Regulatory Releases,
will need to be applied. The same is assumed to be true for the Financial upgrade as. This work
effort was estimated based on the System Test Hours for the SA CPU’s and on Development for
the HR and FIN CPU. SA Fixes are calculated at a straight 27% of System Test hours. HR
Document1
Page 5 of 16
Last Updated: 2/9/2016
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
Fixes are calculated at a straight 27% of Development hours. The FIN Fixes are calculated at a
straight 15% of Development hours.
6.) Performance Support Estimating
(back to top)
This is the Performance Support effort required within the CPU’s and does not reflect the
corresponding User Services tasks. Effort was based on the number of training guides required,
etc. Appendix B includes spreadsheets for the three CPU’s.
7.) Batch architecture and Query Processing Estimating
(back to top)
For the HE Upgrade, separate estimates were made for work effort in the CPU as a result of
changes in the Batch architecture. An estimate of 30 minutes per batch job to reestablish the
paperwork and then an additional 15 minutes per job for verification was made. 45 minutes for
each of the 2428 batch jobs translates to 1782.25 hours total for both HR and SA CPU combined.
A worse case scenario of 2445 queries was used as a basis for the queries estimates. 1 hour of
effort was assigned to each query generating a total of 2445 hours for both HR and SA CPU
combined.
These estimates are maintained in Upgrade Batch & Query Estimates EXAMPLE.xls
8.) Infrastructure Estimating
(back to top)
FTE Requirements for Production Support and each Discretionary project were identified at the
Unit level on a biweekly basis. The requirements were summed and then compared against staff
available during the course of the proposed upgrade timeline. Incremental staff needs were
identified for the upgrade and then smoothed over the timeline.
Infrastructure Hardware, Software and staffing example see - Upgrade TIO-Infrastructure
Estimates EXAMPLE.xls
9.) Security Estimating
(back to top)
These estimates are the effort identified within EAS for establishing roles and system (tier II)
access within the new PeopleSoft environments. Creation of roles is divided into three
categories: easy, medium, complex. An easy role is estimated to take 5 minutes to complete; a
medium role will take 8 minutes; a complex role, 10 minutes. An estimate of the number of
roles within category was made for each of the CPU’s
Document1
Page 6 of 16
Last Updated: 2/9/2016
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
Tier II or system access support was also estimated by support needed for each of the PeopleSoft
Databases.
For example see - Upgrade Security Estimates EXAMPLE.xls
10.) Data Warehouse Estimating
(back to top)
Data Warehouse estimates are based upon the number of SQRs and the level of table
modification in the new version of the product and the effort required based on historical actuals.
Anticipated effort is 40 hours per SQR. Additional effort is required for changes to the Business
Object Universe, FTP file loads and for Appending to existing data sets. For example see Upgrade DW Estimates EXAMPLE.xls. See also Appendix C for copies of the spreadsheets.
11.) Third Party Products and Interfaces Estimating
(back to top)
Upgrades required to third party products and their corresponding interfaces are estimated on a
per product basis. To date, the only product impacted is IVR.
Document1
Page 7 of 16
Last Updated: 2/9/2016
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
Appendix A: Detail Design and Code/Unit Test Estimating Factors
(back to Development (Code and Unit Test) Estimating)
Object
Type
Work Unit
Complex
-ity
Dev
Detail
Design
Batch
(Cobol,
SQR,
C etc)
New
Easy
Enhance
People
Soft
Objects
Panel new
or
enhanced
Record
(New)
Document1
Upgrade
Detail
Design
Upgrade
Code &
Unit Test
Description of Complexity
8
Dev
Code
& Unit
Test
24
2
4
Standalone (is not called or has
calls),1 input/ 1 output,
read/process/write flow, no
internal arrays, simple business
logic
Medium
Difficult
24
60
40
120
4
8
8
16
Easy
4
8
2
4
Medium
16
32
4
8
Difficult
40
100
8
16
Easy
4
8
0
2
Medium
Difficult
6
8
12
16
1
2
4
8
Easy
3
5
0
0.5
Medium
8
12
1
0.5
Difficult
12
18
2
0.5
Page 8 of 16
Last Updated: 2/9/2016
Meets 2-4 of the following
criteria: called or call module,
multiple input, multiple outputs,
multiple logic paths, multiple
internal arrays, array insert/delete
logic, complex business logic,
non-standard error processing
No changes to inputs or outputs,
simple business logic change to
existing logic flow, localized
change.
Change to input or output format,
medium complexity localized
change or simple non-localized
change.
Meets 1-2 of the following
criteria: change to program flow,
non-simple, non-localized change
or complex localized logic
change, additional input,
additional output
Simple interface, 1 scroll bar, 1
panel group
Complex interface, 2-3 scroll
bars, more than 1 panel group.
New record supports simple
complexity functionality (breadth
of use, frequency of use,
complexity of panels used in).
New record supports moderately
complex functionality (breadth of
use, frequency of use, complexity
of panels used in).
New record supports moderately
complex functionality (breadth of
use, frequency of use, complexity
of panels used in).
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
Record
(modified)
Peoplecod
e
Reporti
ng
PS/Query
to
PS/nVisio
n (New or
Enhanced)
PS/Query
to Crystal
Document1
Medium
6
8
1
0.5
Difficult
8
12
2
0.5
Easy
4
8
0
2
Medium
12
20
1
4
Difficult
24
80
2
8
Very
Difficult
48
160
4
12
Easy
12
30
0
2
Medium
18
45
2
4
Difficult
27
72
4
8
Easy
8
16
0
2
Page 9 of 16
Last Updated: 2/9/2016
Modified record supports complex
functionality (breadth of use,
frequency of use, complexity of
panels used in).
Modified record supports complex
functionality (breadth of use,
frequency of used, complexity of
panels used in).
Requires none of the following:
New or modified translate values
for delivered field, modifies
delivered PeopleCode, relational
field edits, relational edits of
calculations between scroll bar
levels.
Requires 1-2 of: New or modified
translate values for delivered
field, modifies delivered
PeopleCode, relational field edits
among 2-3 fields, relational edits
or caluations between 2 scroll bar
levels, uses derived fields to
control panel processing.
Requires 3-4: New or modified
translate values for delivered
field, modifies delivered
PeopleCode, relational field edits
among 3+ fields, relational edits
or calculations among 3+ scroll
bar levels, uses derived fields to
control panel processing
Requires 5 or contains other
criteria: New or modified
translated values for delivered
field, modifies delivered
PeopleCode, relational field edits
among 3+ fields, relational edits
or calculations among several
scroll bar levels, uses derived
fields
Simple SQL (1-2 tables), simple
(default) spreadsheet output.
Moderate SQL (2-4 tables),
moderate customized spreadsheet
output.
Complex SQL (>4
tables),complex customized
spreadsheet output.
Simple SQL (1-2 tables), simple
(default) report output.
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
Report
New or
Enhanced
PS/Query
(New or
Enhanced)
Wordfl
ow
New
Workflow
Modified
Workflow
Transla
te
Values
App
Engine
Translate
Values
App
Engine
Document1
Medium
16
32
2
4
Difficult
48
96
4
8
Easy
8
6
0
0.5
Medium
12
12
0.5
2
Difficult
48
96
1
4
Easy
12
30
12
30
Medium
Difficult
Easy
16
20
4
38
45
8
16
20
4
38
45
8
Medium
Difficult
Easy
8
16
14
24
8
16
0
14
24
0.25
Medium
Difficult
Easy
0
0
2
0.25
0.25
4
Medium
Difficult
4
8
8
16
Page 10 of 16
Last Updated: 2/9/2016
Moderate SQL (2-4 tables),
moderate customized report
output
Complex SQL (>4 tables),
complex customized report
output.
Simple SQL (1-2 tables), simple
(default) list output.
Moderate SQL (2-4 tables),
moderate customized list output.
Complex SQL (>4 tables),
complex customized report
output.
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
Appendix B:
Performance Support Estimates
(back to Performance Support Estimating)
HRMS CPU Estimates
SA CPU Estimates
Document1
Page 11 of 16
Last Updated: 2/9/2016
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
FIN Estimates
Document1
Page 12 of 16
Last Updated: 2/9/2016
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
Document1
Page 13 of 16
Last Updated: 2/9/2016
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
Appendix C: Data Warehouse Estimates
(back to Data Warehouse Estimating)
HR Data Warehouse
PS 8 Upgrade High Level Estimates
CRAS
x5
days/
SQR
# SQRS
2
x 3 CRAS Universe
complex Changes
factor
(days)
10
30
Total
C Program Append
Estimate
Changes Data Set - (Person
(days)
extra days Days)
Load/ FTP
Changes
(days)
10
5
20
15
80
HR
x5
days/
SQR
# SQRS
19
Universe
Changes
(days)
95
10
Total
Load/ FTP Append Data Estimate
Changes Set - extra
(Person
(days)
days
Days)
5
110
HR Snapshot
x5
days/
SQR
# SQRS
9
Universe
Changes
(days)
45
10
Total
Load/ FTP Append Data Estimate
Changes Set - extra
(Person
(days)
days
Days)
5
15
75
Payroll
x5
days/
SQR
# SQRS
8
Universe
Changes
(days)
40
10
Total
Load/ FTP Append Data Estimate
Changes Set - extra
(Person
(days)
days
Days)
5
15
70
Grand Total:
(person days)
335
Assumtions:
2680 hours
- no purging will be taking place where the data is expected to be archived in the DW
- no major changes in SQR will happen
- no new functionality
Document1
Page 14 of 16
Last Updated: 2/9/2016
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
SA Data Warehouse
PS 8 Upgrade High Level Estimates
Admissions Roster
Load/
x 5 Universe FTP
Append Data
days/ Changes Changes Set - extra
SQR (days) (days) days
# SQRS
12
60
10
5
Total
Estimate
(Person
Days)
0
87
Recruiting and Adm
Load/
x 5 Universe FTP
Append Data
days/ Changes Changes Set - extra
SQR (days) (days) days
# SQRS
45 225
10
5
Total
Estimate
(Person
Days)
0
285
Adm Snapshot
Load/
x 5 Universe FTP
Append Data
days/ Changes Changes Set - extra
SQR (days) (days) days
# SQRS
7
35
10
5
Total
Estimate
(Person
Days)
15
72
Student Records
Load/
x 5 Universe FTP
Append Data
days/ Changes Changes Set - extra
SQR (days) (days) days
# SQRS
63 315
10
5
Total
Estimate
(Person
Days)
3
396
Adm Snapshot
Load/
x 5 Universe FTP
Append Data
days/ Changes Changes Set - extra
SQR (days) (days) days
# SQRS
7
35
10
5
Total
Estimate
(Person
Days)
15
72
Adm Snapshot
Load/
x 5 Universe FTP
Append Data
days/ Changes Changes Set - extra
SQR (days) (days) days
# SQRS
7
35
10
5
Total
Estimate
(Person
Days)
15
Adm Snapshot
Document1
Page 15 of 16
Last Updated: 2/9/2016
72
University of Michigan Administrative Information Services
PS Upgrade Methodology
M 8000A Estimating Approach for PS Upgrades DRAFT
Load/
x 5 Universe FTP
Append Data
days/ Changes Changes Set - extra
SQR (days) (days) days
# SQRS
7
35
10
5
Total
Estimate
(Person
Days)
15
72
Grand Total:
(person days)
335
Assumtions:
2680 hours
- no purging will be taking place where the data is expected to be archived in the DW
- no major changes in SQR will happen
- no new functionality
PS 8 SA DD
Upgrade
High Level
Estimates
Provided
5/16/02
# of Sqrs
x 5 days per
SQR
Admissions Roster
Recruiting and Adm
Adm Snapshot
Student Records
Third Week
FA/SF
Ext Org/Acad Struc
12
45
7
63
20
29
12
60
225
35
315
100
145
60
5
5
5
5
5
5
5
10
10
10
10
10
10
0
0
0
15
3
15
3
0
87
285
72
396
150
192
77
Total
188
940
35
60
36
1259
Dataset
+ 5 days + 10 days
Load/FTP
Unv
Append
Extra
days: 3
per table
Total
or 15 per
estimate
DS
(person days)
10072
Total for all SA datasets updated for version 8 = 1259 person days
Document1
Page 16 of 16
Last Updated: 2/9/2016
hours