APPLICATION OF 80/20 RULE IN SOFTWARE ENGINEERING WATERFALL
MODEL
Muzaffar Iqbal and Muhammad Rizwan
Abstract— Software process is the most important part of
software project management, and software process models are
important means of implementing the software process in any
software organization. When there is need to improve the software
process, then the need to improve the work-task part (software
process models) of the software process must arise. As, there is
need of increasing the commitment of software project managers
through out the software development life cycle (SDLC), so we
need to give them the list of activities in Waterfall Model, which
should be made efficient by the software development team, to get
the 80% productivity (output) easily, by reducing the effort of
software development and ultimately increasing the performance of
the software process. So, the idea of 80/20 rule (Pareto Principle,
1935) can be applied in the software engineering process model, in
this regard.
The Pareto Principle (1935) directed us to focus on what is really
important in any field and field’s work. Software process is most
important part of software project management (SPM). This is also
then ultimately needed for software project management (SPM)
improvement. Our main research work is to improve the work-task
part of the software process (i.e. software process models by
applying the Pareto Principle – 80/20 Rule (1935) (or law of vital
few) (1935), in the software engineering process models (or work-
task part of the software process). This will be to facilitate the
software project manager, using the software process models
practically more efficient than without application of 80/20 Rule in
software engineering Waterfall model. This has resulted in the
reduction of the software development effort and increase in the
performance of the software process. The results (efficient and
improved software process models) will be implemented in the
software industry, by software project managers, by focusing on the
list of activities giving 80 percent of the overall productivity of the
software process. The results will be the list of activities having the
capability to give 20 percent of the overall productivity of the
software Waterfall process, to be ignored, eliminated or designated
to reduce the effort.
I. INTRODUCTION
Pareto’s 80/20-law (Pareto, 1935) is the rule given by
Vilfredo Pareto who observed that 20 percent of the
population owned 80 percent of the usable land (Pareto,
Muhammad Rizwan (Author 1) is with the University Institute of
Information Technology, Arid Agriculture University Rawalpindi, Punjab,
Pakistan. Email: rizwan.uaar@gmail.com
Muzaffar Iqbal (Author 2) is with the Federal Urdu University of Arts,
Science & Technology Islamabad, Pakistan (corresponding author: 301-
524-4147; e-mail: muzaffar.iqbal123@ yahoo.com).
978-1-4244-4609-4/09/$25.00 ©2009 IEEE
1935). Pareto found the same use of 80/20 rule in other
economical and natural processes.
Nowadays, many projects show the same 80/20
distribution of yield vs. costs. This is often attributed to
Pareto’s observation and is called Pareto’s 80/20-law or the
law of the trivial many and the critical few (Pareto Principle,
1935).
The problem for research was that software process
Waterfall model is not efficient at the moment, as the
software development professionals don’t know that which
part(s) of the model need more attention than others. So, the
work-task part of the software Waterfall process should be
improved, to make the software process model efficient and
more useful. This is done by identifying the activities which
can give 80 percent of the overall productivity, if these
activities are properly focused by a software project manager
at each stage/ phase of Software Development Life Cycle
(SDLC). We have applied 80/20 rule (Pareto Principle,
1935) in software Waterfall process model, to reduce the
effort and increase the performance. We gave a list of
activities which must be followed, which give the 80 percent
productivity of overall performance. Also, a list of activities
which can be eliminated, ignored or delegated, as giving
only 20 percent overall productivity. So, software Waterfall
process model can be improved and made efficient by
focusing only the activities mentioned in our results.
Our research proposes some quality improvements in
the existing software engineering process models through
the application of 80/20 rule (Pareto Principle, 1935) in the
context of software project management in terms of
considerable improvement of nine quality parameters while
software development using different programming
languages following improved Waterfall Model. We are
applying 80/20 rule (Pareto Principle, 1935) in software
engineering process model (Waterfall Model) to improve the
work-task part of the process of the Software Project
Management (SPM), to produce maximum outputs in less
time/resources by effort optimizing (reduction) and high
performance. The results will be implemented in the
software industry, by software project managers.
Historical descriptive (survey based) research method
(Kuh et al. (2005), Patton (1990)), of research was adopted
to conduct this study through the Waterfall Model
Evaluation Questionnaire. The software Waterfall process
model was evaluated and after applying 80/20 rule in the
software Waterfall process model improved and efficient
form of Waterfall Process Model has emerged..
We being researchers personally visited different
software houses of Pakistan to collect data for evaluation of
Waterfall process model. Development effort of software
industry was studied and analyzed. A structured interview
was conducted from the current software industry of
Pakistan (mainly Islamabad and Rawalpindi), to find out
software process model being used for different nature of
software projects and in different software companies. The
software experts were also asked to give response to apply
the 80/20 rule in Waterfall model, by identifying the
activities which are giving them 80 percent of overall
productivity at work. This valuable feedback was analyzed
to give improvement in the software process model. The
function points analysis environmental factors rating
questionnaire was conducted from the software industry
from the software experts.
We have used analysis techniques in our research work
to get results in the standard form as proof, for improved
software Waterfall process model by implementing the
Function Point Analysis (FPA) [16] and COCOMO (Cost
Constructive Model) [17] as needed to show the
“Application of 80/20 Rule in Software Process Model
(Waterfall Model)”. This was just to give improved/ efficient
form of the software process model (work-task part) of
software process, which has resulted in the form of
improvement in the values of the evaluation (estimation)
parameters as have been used in our research to validate the
improved performance of Waterfall process model.
II. RESULTS AND DISCUSSIONS
It was observed and concluded that 144 activities of
Waterfall Model in the form of Waterfall Model Evaluation
Questionnaire was analyzed through the application of 80/20
Rule. This led us to focus on the 85 activities to get the 70%
to 80 % of the whole productivity through the reduction of
the effort and increasing the performance of the model.
There were 45 activities which may be ignored, eliminated
or delegated, as these were giving the 20 % productivity.
a. Activities which can be ignored:
The following is the list of activities which can be
ignored, eliminated or designated) as giving 20 percent of
overall productivity.
1. Concept Definition Phase [13]:
i. In the activity ‘Feasibility Analysis/ Problem Concept
Exploration’ [13]:
• Collection of product/ system’s relevant
information like required processing for these data
items or input [13]
• Formulating alternatives [13]
ii. In the activity ‘Requirements’ Definition’ [13]:
• For all system elements (at abstract level), gather
and establish Non-functional Requirements [13]
• Doing analysis of Non-functional Requirements
[13]
• Justifying the system’s economic (cost) feasibility
using COCOMO Model and Wide-Band Delphi
Process [13]
• Justifying the system’s technical feasibility using
COCOMO Model and Function Points [13]
2. Requirements Elicitation & Specification Phase:
[11][13]
i. In the activity ‘Requirements Analysis’ [13]:
• Collecting (in detail) Non-functional Requirements
[13]
ii. In the activity ‘Requirements’ Specification’ [13]:
• Reviewing the SRS from user/ client for customer
Acceptance and agreement [13]
3. User Design Phase: [13]
i. In the activity ‘Requirements’ Definition’ [13]:
• For all system elements (at abstract level) [13]
o Gather and establish Non-functional
Requirements [13]
o Doing analysis of Non-functional
Requirements [13]
o Justifying the system’s economic (cost)
feasibility using COCOMO Model and
Wide-Band Delphi Process [13]
o Justifying the system’s technical feasibility
using COCOMO Model and Function
Points [13]
ii. In the activity ‘Structural Analysis of SRS (Software
Requirements Specification)’ [13]:
• Detailed analysis of different functions to be
supported [13]
• Creating Data Flow Diagram (DFD)- Level 0 to
determine what to do (at abstract level) [13]
• Documenting all this? [13]
iii. In the activity ‘Structured Design/ Software
Architecture Design’ [13]:
• Documenting all this? [13]
iv. In the activity ‘Detailed Design (System Design)’ [13]:
• Designing and documenting the algorithms of the
modules [13]
• Design the Project Definition Procedure [13]
• Design the Project Management Procedure [13]
• Design the System Analysis Procedure [13]
• Design the Software Programming Procedure [13]
• Documenting all these tasks [13]
4. Implementation (Coding & Unit Testing) Phase [13]:
i. In the activity ‘Implementation Process’ [13]:
• Test the code using Reviews [13]
• Reviewing the code tests [13]
• Approving the change by the user/ client [13]
ii. In the activity ‘Unit Testing Process [13]:
• Create test data like Live Data and Sampling[13]
• Develop test requirements (standards) [13]
5. System Testing phase [13]:
i. In the activity ‘System Integration and System Testing’
[13]:
• Create ‘Draft Integration Plan’ to identify standards
for integration [13]
• Testing the System Integration to provide
appropriate training for personnel to carry out the
integration [13]
• Provide appropriate documentation on each
subsystem for integration [13]
• Provide audit or review reports [13]
• Identify standards for integration [13]
• Develop system test requirements (Standards) [13]
• Create system test data like Sampling [13]
• Doing SQA (Validation) by (Doing the White-box
Testing, Doing the Beta Testing), Doing SQA
(Verification) by (Doing User manual Inspection)
[13]
• Reviewing the Integration Plan (if any change) [13]
• Ensuring the working again (if any change) [13]
6. Operations & Maintenance Phase [13]:
i. In the activity ‘Deploying the system’ [13]:
• Developing test conditions [13]
• Create test data/ cases (for user to check the
system) [13]
ii. In the activity ‘Maintaining the deployed system’ [13]:
• Maintain support request log [13]
7. Retirement/ Replacement Phase [13]:
i. In the activity ‘Retirement process’ [13]:
• Conduct parallel operations (if applicable) [13]
• Retire system [13]
b. Activities which must be focused to get 80%:
The following is the list of activities which must be
focused as giving 80 percent of overall productivity.
1. Concept Definition Phase [13]:
i. In the activity ‘Feasibility Analysis/ Problem Concept
Exploration’ [13]:
• Analyzing the problem domain [13]
• Collection of product/ system’s relevant
information (like Data elements/ system inputs and
System’s required outputs) [13]
ii. In the activity ‘Requirements’ Definition’ [13]:
• For all system elements (at abstract level) [13]
o Gather and establish Functional
Requirements [13]
o Allocating some requirements to software
[13]
o Doing analysis of Functional
Requirements [13]
o Investigating the problem properly from
the user [13]
o Taking decisions for new requirements
(prioritizing user requirements) [13]
o Justifying the system’s technical feasibility
(by Estimating complexity of system) [13]
o Justifying the system’s Behavioral
feasibility using Bench-Marks and
Perspectives [13]
2. Requirements Elicitation & Specification Phase [13]:
i. In the activity ‘Requirements Analysis’ [13]:
• Collecting (in detail) Functional Requirements [13]
• Documenting the requirements & data related to the
system being built [13]
• Review and finalize the requirements (to have
agreement from the user about freezing of
requirements), for design phase [13]
ii. In the activity ‘Requirements Specification’ [13]:
• Organizing user requirements into Software
Requirements Specification (SRS) [13]
• Focusing on what needs to be done, not how to do
[13]
• Documenting all this? [13]
3. User Design Phase [13]:
i. In the activity ‘Structural Analysis of SRS (Software
Requirements Specification)’ [13]:
• Creating the use cases and Use Case Diagram [13]
• Identification of the data flow among the different
functions [13]
• Documenting all this? [13]
ii. In the activity ‘Structured Design/ Software
Architecture Design’ [13]:
• Decomposing the system into modules [13]
• Representing relationship among the modules [13]
iii. In the activity ‘Detailed Design (System Design)’ [13]:
• Designing and documenting the data structures
(objects) of the modules (programs) [13]
• Create the Entity Relationship Diagram (ERD) [13]
• Creating the Activity Diagram of each use case
(scenario) of the system [13]
• Design the Software Design Procedure [13]
• Design the Deployment/ Implementation
(hardware) procedure [13]
iv. In the activity ‘Creating Object-Oriented Design’
[13]:
 • Identifying various objects related to the problem
domain and the solution domain [13]
• Refining the objects structure and their
relationships to obtain the detailed design [13]
• Creating Sequence Diagram [13]
• Create the Class Diagram [13]
• Documenting all these? [13]
4. Implementation (Coding & Unit Testing) Phase [13]:
i. In the activity ‘Implementation Process’ [13]:
• Creating the source code [13]
• Creating object code [13]
• Test the code using (Inspections and Reviews) [13]
• Reviewing the code tests [13]
• Reviewing the requirements (if change occurs) as
well as design for verification and validation (SQA-
Software Quality Assurance) [13]
• Approving the change by the user/ client and
Document the change [13]
• Doing the Alpha Testing) [13]
• Creating the validation document/ report [13]
• Doing SQA (Verification) (by Checking the
conformity of Software Requirements Specification
(SRS)) [13]
• Doing the Tool-based Inspection [13]
• Creating the verification document/ report [13]
• Managing the system design [13]
• Documenting the (test results and reports) [13]
6. Operations & Maintenance Phase [13]:
i. In the activity ‘Deploying the system’ [13]:
• Plan installation [13]
• Distribute software [13]
• Install software [13]
• Plan software testing [13]
• Execute the test (by user) [13]
• Accept software in operational environment [13]

ii. In the activity ‘Unit Testing Process’ [13]: ii. In the activity ‘Maintaining the deployed system’ [13]:
• Create test data (like Assumed Data, Live Data and • Operate the system [13]
Sampling) Plan the unit testing [13]Establishing the • Providing technical assistance and consultancy (for
test cases [13] (corrective maintenance), in case of errors) [13]
• Develop test requirements (standards) [13] • Providing the user’s requirements to extend it
• Execute the unit test cases (checking each module (further (another project) to do (perfective
or interface) Managing the unit design [13] maintenance)) [13]
• Documenting the test results and reports [13]
7. Retirement/ Replacement Phase [13]:
5. System Testing phase [13]: i. In the activity ‘Retirement process’ [13]:
i. In the activity ‘System Integration and System Testing’ • Notify user(s) [13]
[13]:
• Create Draft Integration Plan (to identify the
components/ units/ modules to be integrated [13]
• Identify personnel for integration) [13]
• Perform integration (to integrate sub-systems) [13]
• Testing the System Integration (to provide the
overall planning and coordination Integrator
activities) [13]
• Plan the final Integration Plan [13]
• Document subsystem software unit and database
[13]
• Plan system testing, create system test data (like
Assumed Data, Live Data) [13]
• Execute the system tests [13]
• Ensuring the working of (internal logics and
Functions And Verification) [13]
• Doing SQA (Validation) (by checking the
conformity of user requirements) [13]
• Doing the Black-box Testing [13]
 Application of 80/20 rule in waterfall Model:
1. FPA (Total Function Points of the phases of the software Waterfall process model)
2. N (Total Environmental Non-functional Influence Factors)
3. CAF (Complexity Adjustment Factors)
4. AFP (Adjusted Functional Points)
5. KLOC (Kilo Lines of Code)
6. E (Effort) - Unit of measurement is Persons- Month
7. TDEV (Project Time Duration) - Unit of measurement is Persons-Month (PM)
8. SS (Average Staff) - Unit of measurement is Persons
9. P (Productivity)

The measured values of quality parameters [17] of
software development (i.e. MFP (total function points of the
phases of the software process model), N (total
environmental influence factors), CAF (complexity
adjustment factors), AFP (adjusted function points), KLOC
(kilo lines of code), E (effort) unit of measurement is
persons- month, TDEV (project time duration) unit of
measurement is persons- month, SS (average staff) unit of
measurement is persons) after the application of 80/20 rule
in Waterfall Model is reduced as compared to the estimated
measured values of these parameters before application of
80/20 rule in Waterfall Model.
The improvement in terms of the reductions in measured
values is in turn improving the measured values of quality
parameter of software development (i.e. P (Productivity)) is
increased i.e. performance has increased after the application
of 80/20 Rule in Waterfall Model.
This improvement is achieved on the basis of the
importance of the activities of the phases of the Waterfall
Model which are giving the 80 percent output at the work if
our proposed improved Waterfall Model is strictly followed.
All this was the illustration about improving of the activities
having the capability to give the 80 percent output
(productivity) as followed by software development team
during SDLC (Software Development Life Cycle) using
programming languages [17] (such as C, C++, C#, HTML,
JAVA, ORACLE, PL/SQL, SQL, VB and ASP) for software Development Life Cycle) duties being the software project
development being done in an organic mode of COCOMO manager as we recommended in above results.
(Constructive Cost Model). All this improvement in
Waterfall Model is just because of application of 80/20 rule
in Waterfall Model which resulted in high process [1]
performance by reducing the process effort just after
application of 80/20 rule in software process model [2]
(Waterfall Model).
[3]
III. CONCLUSION
The results as impact of our research work before and [4]
after application of 80/20 Rule in Waterfall Model has been
compared through the comparison graphs developed for each
[5]
language being used for software development. This was on
the basis of nine evaluation (estimation and measured)
parameters (raw modified Function Points (FP)[15], total [6]
non-functional environmental factor (N)[15], Complexity
adjustment factor (CAF)[15], Adjusted Function Points [7]
(AFP)[15], KLOC( Kilo lines of Code)[15], Effort (E)[15],
(Total project duration) TDEV[15], Average staff (SS)[15],
and Productivity (P)[15]. After analysis of results, the [8]
improvement has been observed as software development
source, in each of parameter, which showed that after
application of 80/20 rule in software model (Waterfall [9]
model), the considerable improvement was seen which made
[10]
the software process model (Waterfall model) more useful
and efficient (as is done through the application of 80/20
rule in software process model (Waterfall model), as the
effort is reduced and overall performance of the software [11]
process has been increased to much extent and efficiently.
Thus, as a result, we achieved Software Process Model
Improvement, Effort Reduction, Software Process [12]
Performance Enhancement (Optimization). [13]
[14]
The results of our research work is offering the software [15]
professionals to adopt our approach by focusing on the list
of critical activities of the Waterfall Model (after the
[16]
application of 80/20 rule in this Waterfall Model), which are
giving the 80 percent output (productivity) and performance
of the software process, as the effort is reduced and
performance has been increased. So, finally software process [17]
has been improved.
Also, the way of focusing on the critical activities, this
can give high output in each phase of the software process
Waterfall Model to focus on, by applying 80/20 rule on the
activities of any phase of the software process model
(Waterfall Model). So, the phases have been improved as
well as whole software process model has been improved i.e.
Waterfall Model just after the application of 80/20 rule in
the software process model (Waterfall Model).
All the results of research work achieved can be
achieved and implemented practically, if our approach will
be used for practical development, to get the 80 percent of
the overall productivity of the software process, to make the
software Waterfall process model more efficient. This all
facilitates software project managers to ensure efficient use
of Waterfall Model and to perform all SDLC (Software
REFERENCES
Koch, R., 2004, The 80/20 Principle. In: ‘Living the 80/20 Way’. pp.
1-6. Nicholas Brealey Publication, Melbourne Australia.
Ultsch, A., 2002, Proof of Pareto’s 80/20 Law and Precise Limits for
ABC-Analysis, Data Bionics Research Group University of
Marburg/Lahn, Germany. pp. 1-11.
Pressman, R., S., 1998, Software Project Management. In: Software
Engineering – A Practitioner’s Approach, Fourth Edition, pp. 28-38.
McGraw- Hill Companies Publication, Inc. USA.
Mendez, Y., B., 2004, Project Management for Software Process
Improvement. In: Proceedings of PMI Global Congress’, Prague,
Czech Republic.
Stellman, A., Greene, J., (2005), Process Improvement. In: ‘Applied
Software Project Management’. pp. 277-293. Amazon.com, O'Reilly,
Publication.
Scacchi, W., 2001, Process Model in Software Engineering, J. J.
Marciniak ed., Encyclopedia of Software Engineering, 2nd Edition,
John Wiley and Sons, Inc, New York, December 2001.
Dennis, A., Wixom, B., H., 2000, Project Management – Coordinating
Activities. In: ‘System Analysis and Design’. pp. 72-80. John Wiley &
Sons Publication, Inc. New York, USA.
Pressman, R., S., 1998, Software Process Improvement. In: Software
Engineering – A Practitioner’s Approach, Fourth Edition, Software
Project Management. p.78. McGraw- Hill Companies Publication, Inc.
USA.
Kuhl, 2002, Project Lifecycle Model: How they differ and when to
use them.
Futrell, R., T., Shafer, D., F., Shafer L. I., 2004, “Waterfall Model
Activities”. In: ‘QUALITY SOFTWARE PROJECT
MANAGEMENT, 3rd Edition’. pp. 269-271. (Pearson Education
Publication, India).
Pressman, R., S., 1998, “The Linear Sequential Model”. In:
‘SOFTWARE ENGINEERING – A PRACTITIONER’S
APPROACH, FOURTH EDITION’. pp. 29- (McGraw- Hill
Companies Publication, Inc. USA).
Parida, P., 2006, “Essence of Waterfall Model”.
Mall, R., 2004 Classical Waterfall Model”. In: “Fundamentals of
Software Engineering”, p.p. 19-26.
Wright, S., 1999, “SOFTWARE INSTALLATION PLAN (SIP).
David Consulting Group, 2005, QSM Function Point Programming
Languages Table. (A Publication of Quantitative Software
Management, Inc.)
Futrell, R., T., Shafer, D., F., Shafer L. I., 2004, “Function Points
Analysis”. In: ‘QUALITY SOFTWARE PROJECT
MANAGEMENT, 3rd Edition’. pp. 325-337. (Pearson Education
Publication, India).
Futrell, R., T., Shafer, D., F., Shafer L. I., 2004, “Basic COCOMO”.
In: ‘QUALITY SOFTWARE PROJECT MANAGEMENT, 3rd
Edition’. pp. 376 -379. (Pearson Education Publication, India).