Development and Operation Principles

Development and Operation Principles

Seven principles commonly describe the phases for evaluating a system during design, under development, or in operation. These principles are Functionality, Utility, Usability, Efficiency, Maintainability, Scalability, and Testability. These, too, are in no particular order, may vary in relevance, and are heavily interdependent.

To illustrate this interdependence, we use a common Project Management trigon that shows the software development trade-off (see Figure 2.1). The attributes of a project may be represented by a point within the trigon. The customer can choose to optimize any two, but the third is dictated at its worst possible value. (The closer you move toward a property, the greater that property's value. At the points for Functionality, Cost, and Time, you have Maximum Functionality, Minimal Cost, and Minimal Time, respectively.) Of course, anyone who has ever done project management knows that you are always tasked to optimize all three.

Figure 2.1. The Project Management trigon

Functionality

Functionality is the principle that a system or component perform different tasks of relevance toward a goal.

As illustrated in Figure 2.1, functionality is a primary factor in making development trade-offs and the main factor governing many other principles in a system. It is no wonder, therefore, that developers want to develop the functionality first (by starting coding or by prototyping circuit boards of a system). To do this, they make many trade-offs, including sacrificing security. As the illustration indicates, however, functionality can be instituted in the early stages, but developers will pay later in time or cost, or both.

Utility

Utility is the principle describing the extent to which a system or component meets the goals established.

There is some debate about whether utility is any different from functionality in a development environment. We believe that it is, and the best way to explain the difference is with the following example. An engineer has to diagnose the logic within a microchip; the tool she has available is a Swiss Army knife. Although the knife has a lot of functionality, it does not offer much utility for the problem at hand.

Usability

Usability is the principle that a system or component be intuitive and simple to use.

For example, the first home DOS computers would boot to a prompt C:\> with a blinking cursor when turned on. To write a letter using a word processor, the user would have to change directories to the location of the word processor:

C:\> cd c:\progfiles\wp 

Then, to start the program, the user would have to type another command:

C:\progfiles\wp> wp 

The alternative was for users to learn how to change the path statement in the autoexec.bat file or create a batch file to perform the steps for them. In addition to this new step, they would have to learn the 8.3 character-naming scheme, thus making file management for today's average user nearly impossible. The learning curve to make these first machines useful was steep indeed.

Unfortunately, these usability issues are not just bad memories of the past. Today, you can find similar cases with palmtop devices that force the user to learn a new alphabet or cellular devices that require users to enter text from a numeric keypad.

Efficiency

Efficiency is the principle that a system or component use both internal and external resources effectively.

The priority of efficiency has changed greatly in the past few years. With PC memory and hard drive prices dropping, the recent past saw little need for efficient code. However, with the available real estate in mobile devices being offered at a premium, efficiency is increasingly higher on developers' priority list.

Maintainability

Maintainability is the principle that a system be easy and cost-effective for a user, or others on her behalf, to access and modify for upgrades, troubleshooting, and preventative maintenance.

For example, a particular model of a popular sports car manufacturer, which shall remain nameless, required that the engine be removed to change the rear spark plugs. This resulted in very poor maintainability. Owners had to pay for the labor and for parts such as gaskets and oil to have this procedure done at 15,000 20,000 mile intervals to maintain performance. Interestingly, rather than change the design, this manufacturer encouraged the development of new spark plugs that did not need to be changed for 100,000 miles, thereby increasing maintainability. Even though this solution would not have immediately come to mind for most people, it did increase maintainability. This also illustrates that there are many ways to obtain a satisfactory result when you keep an open mind about trade-offs.

Scalability

Scalability is the principle that a system be extendable or usable for an expanded customer base.

A good example would be that of a local telecommunications provider who advertised the ability to bring high-speed Internet service to area businesses without the need to run fiber-optic cable. Instead, it claimed to use wireless microwave from its network to the customers'. The architecture, although great in theory, was not as scalable as advertised. When the telecommunications provider tried to expand its service beyond a relatively small customer base, its wireless network was choked by the demand, and service was, shall we say, less than acceptable.

Testability

Testability is the principle that the requirements of the system be well-defined and specific so that tests can be created to prove directly that the requirements have been met.

A classic example would be a requirement that the system be easy to use. The phrase easy to use is meaningless without concrete, specific definition. How would you test this? How can testers know for whom it is supposed to be easy to use? (The requirements would be starkly different for a computer engineer than for a retired government clerk.) When it comes to security issues, we have seen requirements such as "the system shall be secure." Part of the process of ensuring that you have good and valid requirements is to determine how these requirements will be tested. Again, if the effort is placed up-front, there will be real benefit later in the development process and in the final product.