Software Performance Engineering Techniques

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Abstract— improving performance of software, sites and services is a holy grail of software industry. A new approach for implementation of Poka-Yoke method in software performance engineering is proposed. Poka-Yoke is a mistake proofing technique used in product design. The effectiveness of Poka-Yoke in software development was evaluated using two case studies: product redesign mini-project given to six groups of students and a survey of online services in the software industry. Both quantitative and qualitative evaluation was done. Our proposed five-step mistake proofing technique for software development using Poka-Yoka evaluation demonstrated the effectiveness. The results showed that an implementing Poka-Yoke technique improves the software development process. Regression analysis showed that Poka-Yoke has a greater impact on software quality that uses the current state of the art software development models. Improved UGAM scores also showed linearity and justified Poka-Yoke implementation. Our findings recommend usage of techniques for mistake proofing for overall software performance. The aim is to reduce errors in software development process. We are also proposing HQLS: a new approach for high quality in the large scale software development in this paper.

Keywords- Poka-Yoke Principles, Performance, UGAM, Security, Quality, Mistake-proofing, Detection.


In view of Mukesh Jain, across the globe, end-user performance of the majority of our online services, websites and software applications is a matter of concern. Global and local competitors in the regions have led to fierce competition for comparatively better performance than competitor services. Slow services impacts on user experience, operational cost, mind-share, market share and revenue. Turning the tide on performance can have real impacts on any company’s bottom line. One of the key messages sent from the markets is that we need to do a better job of improving performance of our sites and services globally. The performance of most of the sites and services in many cases lag.

For example, in the US, on broadband connection, MSN/Live Search takes 3 seconds to display the results compared to Google’s 1.5 seconds and the Yahoo’s 2.5 seconds. For Search, we have seen that the longer it takes to load the results page, the more people abandon the page (i.e. People typically begin leaving a page after waiting 4 seconds, and more than 50% of users abandon the page after waiting for 6 seconds).

Site performance in countries like India makes many products almost impossible to use. Recent testing showed that it takes around 40 seconds for somebody in India to login into Hotmail and see their mailbox, while it takes just 5 seconds when using competitor email products like, rediffmail and Indiatimes. This may lead to significant loss in email market share in India. The heat chart in the Table 2 reflects the comparative performance of the online services market. The table shows the PLT [Page-Load-Time] in seconds for the user in each of the major countries. We show the 75th percentile, meaning that 75% of transactions in the country are better than this number, and 25% are worse. The numbers on the left are MSN. On the right is the "top" competitor for that service in that market.

Jain proposed a scheme and procedure to prevent and/or detect performance issues in time for the product engineering team to take action and fix them and prevent them from happening. Users don’t like to wait for a page to load. With zero (or very low) switching cost, it is challenging for any service to retain the users with slow performance (compared to the major competitor in that market). If the service is slow once in a while – users may not notice and/or will not mind. But if it is consistently slow, it will impact their productivity and they will look for faster options.

The field of Poka-Yoke has a large amount of literature in product design methods, software testing techniques, and management (M.Dudek Burlikowska et al, 2009; Lawrence P Chao et al, 2003; Harry Robinson, 1997, etc). These proposals are excellent demonstrations of how Poka-Yoke design methodology can result in improved user-experience design and service performance with fewer defects in their respective domains. Unfortunately, major gaps between Poka-Yoke and SE continue to exist in academics, literature, and industrial practice.

The next section gives an overview of related work in Poka-Yoke. Sections 3 and 4 describe the proposals for software performance, engineering and HQLS: a new approach for high quality in large scale software development. The Section 3 also has qualitative evaluations of software performance engineering proposal. Sections 5 describe case studies that evaluated the architecture for HQLS and their findings. Section 6 draws conclusions from the study.


In recent years, research on applying Poka Yoke in software has received much attention [7, 8, 9, and 10]. Harry Robinson introduced Poka-Yoke (mistake-proofing) into the Hewlett Packard’s software process and he claims they have been able to prevent literally hundreds of software localization defects from reaching their customers. As per Gojko Adzic, author of Impact Mapping “software classes should not allow us to proceed and blow up when something goes wrong. Exceptions can be an effective way of giving more documentation, but the signal should be clean and unambiguous, in order not to mislead users or client-developers. Software must be designed to prevent a complete crash, even in the face of system failure. Auto-save features are a good example. It’s not often that the power gets cut, but when it does, our users will surely appreciate that we saved most of their work” [11]. Much of the research focus is for ZOC, quality control, identifying defects. However, the limitation that associated research brings is not applying Poka- Yoke in entirety.


Here are the Poka-Yoke based 5 steps (model) we can adapt (in parts or full) to Prevent and/or Detect performance problems at the right time and fix it as depicted in the Table 1 [18].


The first step for this would be to include performance as part of the strategy and focus. Considering performance as

Key part of the deliverable is important. “Like security& accessibility, we should consider performance as integral part of any feature. Performance cannot be an afterthought-

If we do not focus performance from the beginning – it might be too late to fix it and in some cases we might miss the opportunity”.


The approach to design and development makes a significant difference towards the vulnerability of the process for performance issues. This is the one of a prevention type of mistake-proofing solution. The design methodology and the development process can prevent many kinds of performance problems.

This is the one of a prevention type of mistake-proofing solution replacing manual work with an automated tool can save resources and enhances the quality of the product.


Testing for performance will be important here. Performance should not be considered as a separate feature - it should be part of each and every feature and scenario, use case. "TEST PASS IS INCOMPLETE without PERFORMANCE Testing". Testing needs to be performed based on the "End-user" settings. The Majority of the people have slower machines than what Jain team uses in Microsoft.

D.Monitoring/Measurement (Detection)

For all the sites that are live in production, we need to have monitoring/measurements in place to be able to monitor performance trends and detect/report issues.

This detection method does nothing to prevent the performance impact from happening. Instead, it aims to find the performance problem at the earliest opportunity in order to minimize the damage. With this mistake-proofing solution, the right problem is detected and reported at the right time to the right people.

The monitoring system (webHancer, SQM, WebWatson, etc.) can measure performance at the end-user and report it back to Microsoft. An alerting system can be built on top of it that can have business rules/criteria for detecting performance patterns (for key user scenarios) and report to the appropriate people.

Example: Business Scenario for measurement of Quality of Service can be explained in different types like absolute measurement, relative measurement and competitive measurement.

This mistake-proofing solution does nothing to prevent the performance problem from happening. However, means are provided to minimize the impact of any performance issue.

By this time the majority of the people would understand the importance of Performance and how they can contribute to improve the same.