1.3 Complexity increases

---

We are aware that many products meet our expectations, but also that some are afflicted with problems, such as malfunction or inadequate performance. One reason for such negative experiences is that products are becoming increasingly sophisticated and complex (e.g., the incorporation of software in different types of products improves the functionality of the products significantly, but at the cost of increased complexity and decrease in robustness). This is because software does not follow physical laws, and consequently its behavior is less predictable. Complexity makes it harder, and more expensive, to maintain high quality and is consequently most important to master. The first step toward mastering complexity, however, is to understand what actually makes a product complex.

A product can be complex for many reasons, some of them more obvious than others. A hardware product may be mechanically complex (e.g., a mechanical watch). No one doubts there must be extreme precision during the production and that maintenance (repair) is expensive. But what makes building a bridge or developing a software application complex?

Some examples of the parameters that influence complexity are:

• Complex functionality. Many products being developed today have complex functionality. Cars, airplanes, industrial control systems, mobile phones, television sets, and computers are some of examples of products with complex functionality. In addition to complex main functions, very often the products must fulfill a number of requirements to make the product more usable, adaptable, configurable, or more attractive. There are products in which properties such as reliability, robustness, availability, and performance are of crucial importance. These types of requirements specify not particular functions, but a behavior of the product. For this reason, these types of requirements are designated as nonfunctional or extra-functional requirements, sometimes quality of services. There is also another type of nonfunctional requirements, which refer to the development process. Examples of these requirements are modifiability, testability, reusability, and traceability. A large number of requirements and a large number of different types of requirements, often incompatible, lead to many difficulties in the development process. One of the problems is traceability of requirements: Which requirements are fulfilled and to which extent in a product? Transition of information from one phase to another is one of the largest problems in a development process.

• Complex structure. To avoid the difficulties in solving complex problems, a well-known principle, divide and conquer, is usually applied. By this, a large problem is divided into many small problems that are easier to solve. Different principles and methods can be used in such a process. Examples of these methods are top-down structural refinement, object-oriented approach, data flow analysis, unified modeling, and component-based approach. There are many references in the literature, old and new, addressing this problem [4–7]. However, transforming a large problem to many small problems usually implies that relationships between the parts become complex. The relationships between components can be so complex that it is almost impossible to grasp them. Changes in one component or its replacement can have a significant impact on other components.

• Complex operational behavior. In some cases the interaction between a product and its consumers can be complex, which makes it difficult to predict the behavior of the product in its operation. It is known that systems can excel at things that they were never designed for. The customers may want to use the products in a particular way or for a particular purpose that may require redesign of the product. This will further require extensive service, maintenance, or new development of the product.

• Product and component versions and variants. A product may consist of many components, and each component may exist in many versions. If, for example, a product consists of three components and each component exists in two versions, by combining all versions of the components, we have eight different versions of the product (as illustrated in Figure 1.4). If the product consists of four components and every component is produced in three versions, then we can build 81 versions of the product. Mathematically, the number of combinations grows n-powered with the number of components and versions. For n components in k versions, we get kn possible versions of the product. Many of these versions are valid, but it may also happen that particular combinations of component versions are impermissible (because the versions are not compatible). Some may be managed as variants (i.e., they exist in parallel both during development and during maintenance). Keeping track of the versions and configurations of their products is a big challenge for many companies today.

  
  Figure 1.4: Component versions and product versions.

• Complex development process. When the products are complex, then the development process tends to be complex as well. When many people with different roles are involved in the development process, it is important for them to have access to accurate information. In smaller groups, information can be spread in an informal and direct way. However, when the group grows, direct exchange of information is impossible to achieve. As Brooks observed [8], communication between people in a group becomes rapidly more complex when the group grows. When two people communicate directly with each other, there is one communication link between them; when they are three, there are three links, and for four people, the number of links grows to six. For a group of n people, there are n( n- 1)/2 direct communications links. It is obvious that for larger groups, and for processes active under longer periods, there must exist well-defined and efficient ways to access information (see Figure 1.5).

  
  Figure 1.5: Direct relationships between group members.

• Distributed development and production. Both development and production may be geographically distributed. For software, the developers are often dispersed to several sites, often in different countries, while developing the same system. The production of hardware is often outsourced (i.e., produced by another company). In some cases, many different producers are involved, producing different parts of the final product.

• Need for maintenance. Demand for maintenance and further development of a product means we must keep track of the status of all products released—sometimes even when the customer makes modifications.

• Products containing both hardware and software components. When a product consists of both hardware and software, it is important to understand the problems of both hardware and software development, production, and maintenance processes. Although these processes might be quite different, they must work together in the end. We will give some further, more concrete examples to explain some types of complexity.

• Maintenance. After 6 months of extensive selling of a new car model, a major mechanical failure in the brake system is proven after several accidents. Investigations have found that brake pads are not strong enough. The company must now replace this part in all cars already produced and delivered and on the production line. They are lucky—three independent suppliers produce this part for them. They now “only” need find out who the responsible supplier is and exchange all parts from this supplier with a part from any of the other two suppliers. Fortunately, they treat each produced car as an individual and can trace and determine which cars have the part that must be replaced from their serial numbers. Within a few days, they send a letter to the known owners of the cars sold during the current time period and even prepare a Web page in which the owners can enter their car serial numbers and learn for themselves if they should visit the garage. Unfortunately, it may be that the responsible supplier also produced this part for previous models. The company must now investigate if this part must be replaced in these cars as well. If they are fortunate, it is only the new environment (the new car model) that stresses the part to failure.

• Development—Scenario 1. During the development phase, it was noticed that some of the requirements required modification. The requirements documents therefore had to be updated and approved by authorized people. In addition, the test cases affected by these requirements had to be modified accordingly. The result was the generation of many updated documents, followed by a document flow through the organization in order to assure that all steps in the predefined process were followed. It is a complex task to assure that all documents are updated and that all people concerned are aware of the changes concerned.

• Development—Scenario 2. Kevin in Austin, Texas, and Martin in Lund, Sweden, live in different places but work in the same company and develop the same software product. Kevin reorganizes some code in order to improve the product performance. Martin suddenly experiences a problem with his part of the code; the program crashes unaccountably. After several days of testing and frustration, he learns that another person has changed the code he is using, thus causing the crash. After further investigation, it becomes known that Kevin’s optimization of his code caused the problem on Martin’s part. Why could Martin not see, at once, that he was using code that had been changed and that this change might cause unpredictable behavior of his code? He should be able to see and easily find out what kind of change had been made and by whom.

---