The load with the load

Or as it is still possible to design projects in terms of performance in such a way that they can be put into operation with a clear conscience.

This article shows you what challenges in connection with the load and performance can occur during a software project and which technical, organizational, personnel and external effects have. You will also learn more about the most common causes and how you can deal with these risks in order to keep the project from financial damage.

Table of contents

What challenges can occur in the course of the project?

Our experts deal intensively with the topic of non-functional requirements and analyze the causes that can affect performance. From many processed inquiries and projects carried out, we can determine the following, frequently occurring causes:

• Weaknesses in or completely missing Performance requirements often lead to unexpected costs late in the course of the project. Hardly any project deals with the non-functional requirements such as performance at an early stage. Significant key figures such as quantity scaffolds or expected user numbers are often missing. This regularly means that the developed systems have excessive response times, slow processing, frequent server errors or susceptibility to attacks.
• There will be new and Untiped technologies used in which it is not clear at the beginning of the development whether and how the expected load can be mastered. In this way, incorrect assumptions are taken out of inexperience or there is too little reliable information on how the software used (framework, service, etc.) behaves with higher user numbers or more frequent and large data processing.
• Architecture or the necessary architectural votes are missing in the course of the project. This is particularly the case in the agile environment in which there are often no dedicated architecture specialists in the DEV teams.

• Operating requirementsin particular for system monitoring, lack, so that no performance ratings and therefore no performance optimization can be carried out in the development phase. Over the entire development process, analysis data is missing that provide information on whether the target system meets the implicit or explicitly mentioned performance requirements.
• External softwarewhich forms part of the overall system as a supply of another service provider or as a standard software, cannot meet the expected performance claims.
• An inadequate Communication During the course of the project, further errors often lead to further errors. Software that is developed without clear coordination, with unclear requirements or on the basis of numerous assumptions can also lead to performance restrictions.

What complications can occur later in the company?

Some restrictions rose from the development phase to the company and are rarely addressed with suitable measures.

• Missing scaling, which optimizes the use of the existing resources, so that only as much power is used as is currently required. The systems should be in Ideal case dynamically growing with And then only book the resources when the performance limits reached.
• Even if an environment is defined, it should be determined which Performance reserves this has. Especially with increasing data volume.
• Missing or inadequate System monitoring in the operation of the software Or the system prevents early intervention and proactive measures.

What does the ideal world look like?

As already mentioned from many other people from product development and management, the early integration of the QS, but also the operation in the project is immensely important. This gives you another look with all points of view of those who are involved in the development and operation of the application. The early employment of all roles, with requirements analysis, design, architecture and specifications, can be used make a financially attractive contribution. In particular, considerations and stipulations on non-functional requirements such as performance, efficiency, reliability, maintainability, etc. can therefore be taken into account during development.

This automatically creates agile processes and DevOps procedures that offer an enormous advantage.

What if the project becomes too expensive?

The principle of early integration of all roles does not make a project more expensive, but that Earnings shift more to the beginning of the project. In other ways, employees are involved in the overall course. In an agile approach, this hardly notices this due to the iterative way of working. Because in the short time units, the expenses are only transferred to other activities. In this way, user stories can be more complex, but this avoids developmental efforts, subsequent coordination efforts and bug fixings or change-request effort.

Perhaps the statement about higher costs is also due to the fact that the expense record is not made in any project so small and can therefore be kept. And it is also known that increased expected operating costs are hardly determined as a risk due to savings in the development and this comprehensive view is often missing. Even if there are no examples from IT, large projects such as the Elbphilharmonie and Stuttgart 21 illustrate how much costs can be underestimated and what consequences inadequate risk analyzes have.

What to do with performance problems while the project is already running?

Sometimes earlier mistakes can no longer be changed and you have to tackle other activities through the advanced time. It won't always be the best solution, but you can still be a achieve satisfactory result.

In this situation, let's take a look at the framework conditions that have probably occurred. A large part of the budget has already been used up, we can no longer go back for financial reasons. We have already progressed so far that it is hardly possible to complete on time. A large part of the requirements are implemented functionally, only performance shows weaknesses. This is a barely solvable situation to satisfy everyone involved.

Basically one should Clear prioritization of the requirements and findings with sufficient gradations exist. Because not everything can be Prio one. In addition, the performance requirements should be recorded and they are also prioritized. In addition, the main business cases must be defined, which are later implemented as scenarios in the performance test tool. This should be chosen more with carelessness than to choose too much and too difficult to choose scenarios to be implemented, there is a lack of time. It is important to set up sufficient system monitoring that gives an insight into the system state at any time and allows fast reactions.

For us there are three good opportunities to continue:

• One Series of repeated performance tests With increasing load, it is carried out and the metrics are collected to show whether the expectations and the actual performance of the system match. This is how the performance limit is determined and you can turn the right screws in the development and the improvement can steadily test with new repetition runs.
• As an alternative to the repeated performance tests Performance test runs determined the performance limit of the system. On the basis of these values, an operating concept is created in which the number of users that go into operation are set. Additional system monitoring monitors this and enables quick intervention. Later, other user groups can be switched on if the system has been further developed and the performance features ensure stable operation.
• Our third proposal says that the Further development is hard stopped And now all resources must be put into optimization of the existing system. Thus there was an opportunity that the desired number of users will be achieved. Here, too, the main use cases must be carried out by performance tests and the performance limits must be confirmed. Certainly some iterations are necessary to achieve the target size. This can lead to a solution that works within the schedule and budget. Functionalities that have not been realized must be implemented at a later date.

Conclusion

A perfect requirement management, risk management, project planning, architecture and design would take into account non-functional requirements from the start. Due to the complexity, however, we rarely achieve this ideal state.

If you are already in the middle of the project implementation for various reasons, then try to follow one of our suggestions. Return and get advice on what you can deliver as a minimum of functionality and how you tackle the performance problems with the right means and check your system for performance requirements. From experience we know that lack of features and budget after -demands are uncomfortable on all sides. You won't be able to avoid these discussions.

Was this article helpful for you? Or do you have any further questions about performance tests? Write us a comment or please call us.

Moritz Salein works as a test manager in the area of ​​software consulting services. There, his focus is on advice on test processes, test automation and performance testing. He takes on conceptual tasks, technical implementations and test development services. In addition, topics such as submissive, agile development, training and coaching are other fields of activity.