OOAD Estimation

Document Version [3.30] and Date [31.07.2009]

By OPG
TABLE OF CONTENTS

1 Object Oriented (OO) Estimation...............................................................3

1.1 Establish Traceability to Pre-Design Estimation....................................................3
1.2 Splitting of Components.......................................................................................4
1.3 Complexity of Components..................................................................................4
1.4 Mapping to Estimation Worksheet........................................................................6
1.5 Examples.............................................................................................................. 6

Division : Software Doc. Name :Guidelines on Version: 3.20

Development OOAD Estimation
Document Classification: Date: 01/10/2008 Page : 2 of 8
Internal
1 OBJECT ORIENTED (OO) ESTIMATION
Estimation for development phase in Object Oriented Design (OOD) projects is different
than in the non-OOD projects on the basis of nature of software components. In non-OOD
projects development units are categorized as screen programs, processing program and
the reports, whereas the overall component structure of the OOD application evolved
from Use cases is as shown below.
The terminology defined in the design document is as follows:

Use Case

Sub-Use Case 1 Sub-Use Case2 Sub-Use Case n

Sequence Diagrams
Interfaces
Screen 1 Screen 2 Screen n

Interface Component 1

Class Diagrams
Business Business
Object 1 Object 2 Interface Component 2
Business
Object n

Database Design
Interface Component n
Data Data Data
Access 1 Access 2 Access n

While arriving at the development estimations for OOD application, estimation for each of the above
components is considered.

1.1 Establish Traceability to Pre-Design

Estimation
Estimations given during proposal stage are based on the functionality as the
component design is not available at that time. Following steps should be
taken to establish a link between Pre and post design estimates.
 Design should be mapped back to requirements/functionality. This can
provide a link between pre-design estimations and post-design
estimations.

Division : Software Doc. Name :Guidelines on Version: 3.20

Development OOAD Estimation
Document Classification: Date: 01/10/2008 Page : 3 of 8
Internal
 Units identified in the pre-design phase may be broken up into sub-units.
However it should be noted that the pre-design estimate should have taken
this into account by splitting functions into multiple programs and such re-
organisation will not make a difference of more than 10% to the overall
estimate.

1.2 Splitting of Components

1.2.1 Rules for identifying a Work Unit
Each functional unit must be separated into
 The user interface
 Business logic part
 Database interactions required
However, for estimation purposes, there are some exceptions:
 If a module/program can be developed as a single unit it should
not be broken into units of varying complexity
 Even if separate components need to be developed to address
the functionality – for estimation purposes, they need to be split
only if the complexity justifies it. For example, if it involves only
1 a small validation, it must not be treated as a separate object

1.2.2 Additional Considerations

Testing of business objects and data access components
For testing these components, when there is no screen available, a
dummy screen needs to be developed for testing purposes. This
dummy will accept all the parameters used by the object, call the
object and display the results. Since this screen will not have any
navigation and aesthetic requirements, it is not to be treated as a
separate screen but is included in the business component
estimate.

1.3 Complexity of Components

The following section explains the methodology and rules to be applied in
identifying the complexity of work units in the post-design phase for
scheduling purposes. This does not override the Complexity Identification
document that is used for defining complexity in the pre-design phase. The
definitions and sizing rules make the following assumptions:
 There is a development tool available for screen and report programs
 The design for the work units being sized is complete
 The person doing the sizing is familiar with the design

Division : Software Doc. Name :Guidelines on Version: 3.20

Development OOAD Estimation
Document Classification: Date: 01/10/2008 Page : 4 of 8
Internal
  There is a library for standard controls
1.3.1 Object Types
 Web Forms/Reports
 Business Objects
 Data Access
 Interface Components
Any program that does not have user I/O (except acceptance of
parameters) is treated as a process program. All business objects,
data access objects and interface components should be treated as
process programs.

1.3.2 Complexity Rules for a new work unit

The following table gives the criteria for defining the complexity of
a new work unit:

Division : Software Doc. Name :Guidelines on Version: 3.20

Development OOAD Estimation
Document Classification: Date: 01/10/2008 Page : 5 of 8
Internal
 Complexity

Very Simple Simple Medium Complex

Presentatio 3 to 8 fields More than 8 -- ---

n Layer fields
Business Less than five 6 to 9 10 to 15 Attributes More than 15
Objects1 – attributes and Attributes 10 to 15 field level attributes and
Validation validation 6 to 9 field level Validation Validation
methods methods. Validation methods. methods
Type of Work Units

methods
Business Interface classes Up to 2 Between 2 and 4 5 to 8
Objects2 – business rules business rules business rules
Non
Validation
methods
Persistent Single table One header and 2 header detail-
Classes for query. Example less than three detail relationship.
Database lookup values. details. (all 3
Interaction Or details at the (1 header and 2
One header – same level – levels of details – 2
detail table key in header) such combinations)
interaction
routines with no
secondary
updates
Reports 3 to 8 columns More than 8
columns

Any cases, which fall beyond this, are to be estimated separately as

Very Complex or Very Simple and the FP equivalent has to be
determined by the person estimating/authorising the work.
Very Complex units should be broken down as a combination of
simple, medium and complex units, not just for estimation, but also
for ease of specifications, development and testing.

1.4 Mapping to Estimation Worksheet

Component Estimation Unit
Presentation Layer Entry
Business Objects Process
Persistent Classes for Process
Database Interaction

1
If a business object has validation as well as non validation methods, they must be treated as
different classes
2
If a business object has validation as well as non validation methods, they must be treated as
different classes
Division : Software Doc. Name :Guidelines on Version: 3.20
Development OOAD Estimation
Document Classification: Date: 01/10/2008 Page : 6 of 8
Internal
 Reports Reports

Note: Refer to GD/SDP/50 for Estimation Sheet

1.5 Examples
1.5.1 Example 1
Entry screen with 10 fields, 10 validations, 2 base table updates and one
secondary update.
 Presentation Layer
This will just paint screen and interact with business object layer
More than 8 fields – Simple
 Business Object Layer
10 attributes, 10 methods for validation, around one non-validation
method.
Complexity as per table is medium.
 Database Objects
2 tables and one secondary update. This will be simple.
Put 1 Simple entry and two simple processes in Estimation worksheet to
get the number of hours.

1.5.2 Example 2
Process for calculation of depreciation
 Presentation Layer
None
 Business Object Layer
Object with three attributes (Asset life, rate, and number of years), one
method.
Complexity Simple (Due to non-validation method for depreciation, this
became simple).
 Database Objects
One table update and two cross updates. Complexity = Simple.
Put 0 Simple entry and two simple processes in Estimation worksheet to
get the number of hours.

Division : Software Doc. Name :Guidelines on Version: 3.20

Development OOAD Estimation
Document Classification: Date: 01/10/2008 Page : 7 of 8
Internal
AMENDMENT HISTORY
Version Date Amendment History Remarks
No.
1.00 10/01/03 New Release reviewed in Core
Group Date 13th Dec ’02.
2.00 23/02/04 Modified the header and footer
and formatted the document.
3.00 09/11/2006 Changes made to bring the
guideline in line with CMMI ver
1.2 requirements.
3.10 10/12/2007 Modified the header and footer
and formatted the document.
3.20 01/10/2008 Modified the header and footer
and formatted the document.
3.30 31/07/2009 Replaced ESU with FP

QMS Document Control Information

Division: OPG Doc No: FM/OPG/10 Version: 2.00

Division : Software Doc. Name :Guidelines on Version: 3.30

Development OOAD Estimation
Document Classification: Date: 31/07/2009 Page : 8 of 8
Internal