Unique characteristics of software

Introduction

Over the years, we have evolved many ways of producing better-quality goods in the manufacturing sector. This knowledge can be extended to build better-quality software products if the software professionals understand the characteristics of software and how these compare with those of hardware.
In this section, you will learn about the characteristics of software

Software versus hardware

Software is essentially a set of instructions (programs) that provide the required functionality, the related data, and documents. Therefore, software is a logical system element and differs from hardware, a physical system element, in its characteristics.
An important aspect of software is that it is engineered using team effort, unlike hardware, which is manufactured. The process used for building software, therefore, cannot be expedited the way hardware manufacture can be.
Another aspect of software is that, because the software industry is new, software differs from hardware in the aspect of component usage.
Being a logical system element rather than physical, software also differs in the way it deteriorates over time. It does not wear out the way hardware does.
Let us now discuss each aspect.

Engineering a software product

Software is developed or engineered, not manufactured the way hardware is. Each software product is different because it is built to meet the unique requirements of a customer. Each software therefore needs to be built using an engineering approach.
Building a software product involves understanding what is needed, designing the product to meet the requirements, implementing the design using a programming language, and checking the product against the requirements. All these activities are performed by executing a software project and require a team working in a coordinated way.
The process used for building software is different from manufacturing hardware, where machines are used to produce parts and each worker just needs to perform the assigned task or operate a machine.
Let us see how this software characteristic impacts the ability to speed up the process for building software.

Software project: A team effort

While manufacturing hardware, it is possible to speed up the production by making additional resources available.
In software, the major resource used is people. It is not always possible to speed up building software by adding people because building software requires a team effort. The team has to work in a coordinated way and share a common project goal. Effective communication is required within the team.
A new team member is not immediately productive and needs proper induction into the team and training for work to be done. This requires an investment of time and effort from the existing team members and distracts them from performing their own work. In case a project is already running late adding people to it further slows it down, unless, the people have the required experience, the project is highly compartmentalized, or the project has a well-documented design so that training is minimized. Therefore, careful planning and compartmentalization are required for the addition of people to the project.

Use of standard components in hardware

Hardware uses standard components with well-defined functions and interfaces. The use of these off-the-shelf components helps avoid re-inventing the wheel. The design phase in the life-cycle of a hardware product involves selecting the most suitable components available and deciding on the approach to assemble them. The standard hardware components are useful because they lead to:

• Reduced cost and time-to-market
• Good quality
• Rapid engineering
• Easy maintenance
• Easy enhancement

Over years, component development and interchangeability, component standards, and related engineering practices have evolved for hardware and are now commonplace.

Let us now see the use of standardized components in the context of the software industry, which is a relatively new industry.

Software reuse

Software is typically created from scratch. It is often built according to the specific requirements of a customer and is not created by assembling existing components.
Like the hardware industry, the software industry is also trying to adopt the mechanism of reuse to make it easier and quicker to build. The advantages of software reuse are now being understood and appreciated. Some reuse exists through function libraries and reusable objects that combine function and data.
While reuse and component-based assembly are increasing, most software continues to be custom built, and the current reuse levels are a far cry from what they could be. This is because the software industry is relatively very nascent. Besides, the task of identifying potentially reusable components is difficult because each software product is unique and distinct.

Over time, the software industry hopes to create reusable components that are specific to particular application domains, such as, banking applications, networking, computer graphics, operating systems, medical instrumentation, and human interfaces

Emphasis on component-based development

There is an increasing emphasis on 'component-based' development for computer software—an approach that encourages the creation of reusable software units.
The software industry has well-defined processes for the reuse of components. This includes processes for building components, storing them in libraries from where they can be extracted for reuse, and then, incorporating them as such or with some modifications. However, the use of components does not eliminate the need to engineer the product.
As we move into the first decade of the 21^st century, more and more software will be built using reusable off-the-shelf components to meet customer requirements.

Failure rate of hardware and software

All products (hardware and software) exhibit failure as time passes. The shape of the failure rate curve is reasonably predictable for both hardware and software. However, there is a difference in the failure behavior of hardware and software. This is because hardware is a physical system element while software is a logical system element.
Understanding the failure behavior of software over time tells you what can be expected from software products. It also helps to understand what needs to be addressed to improve the reliability of products and the process that is used to build them. You can see what you need to do to produce software products that behave, as far as possible, in an ideal way.
Let us first understand the failure rate of hardware products

The bathtub curve

Consider the following stages for a hardware widget that has been manufactured.

1.     When first made, hardware is in infant mortality because it may have some initial design or production problems that lead to failure and require rectification. The design and production problems are corrected, and the initially high failure rate decreases rapidly.

2.     After this, an occasional failure may occur, but the overall failure rate remains very low for some time, resulting in the steady state.

3.     Over time, the hardware wears out because of factors such as dust, physical wearing down, misalignments, breakdowns, and malfunctioning of parts. Due to this physical wear and tear, the failure rate starts increasing again. The failure rate ultimately reaches a point where the product becomes unusable.

The failure rate for hardware is so predictable that the failure curve has been given a name—the bathtub curve.

Software failure rates over time

In your opinion:

1.     What is the initial software failure rate when the software is released to customers—high, moderate, or low?

2.     During normal operation after initial errors have been corrected, what sort of failure rate is expected—high, moderate, or low?

3.     How does the failure curve move when the software ages—stay same, goes down, or moves upward?

Software deterioration over time

Consider the following scenarios as software moves from creation into implementation.

1.     The system has been released and is being used by the customers.

2.     The initial problems have been resolved; the system is now working fine.

3.     The software maintenance team is asked to enhance the system functionality. The enhancements (new reports) are made and released.

4.     These new reports have problems at first, which are resolved. These problems are fixed over time.

5.     After some time, further enhancements are needed to meet new requirements. These changes are made, and it takes some time to rectify the associated problems.

6.     Over time, the product has been patched so often to meet changing requirements that there are greater chances of introducing error in case any further changes are made. As a result, it becomes difficult to remove all problems. The failure rates go up and the software deteriorates.

Software deterioration curve

The goal of every person who builds computer software is to accomplish the following:

• Create software of high quality.
• Recognize that the changes made to software will introduce errors but try to keep the following low.
• Slope of the deterioration curve
• Amplitude of the error spikes due to change
• Reduce the impact of side effects and improve the long-term quality of software.

In order to achieve the above goals, it is necessary to build software using well-defined design principles, implement the software using well-understood best practices, and test the software using thorough processes. This is accomplished by following a 'software engineering' approach.