Software Characteristics

To know an understanding of software (and ultimately an understanding of software engineering) it is very important to examine the characteristic of the software that make it different from the other things which human beings build.  When hardware is built the human creative procedure (analysis, design, construction) it is ultimately translated into a physical form. If we create a new computer our initial sketches formal design drawings and bread boarded prototypes evolve into a physical product (VLSI chips, circuit boards, power supplies and etc). Software is a logical element rather than a physical system element. Thus software has their own characteristic that differs considerably from those of hardware.

Software is evaluated or engineered it is not manufactured in the classical sense. Although some similarities exist among software development and hardware manufacture the two activities of the software are fundamentally different. In the both activities high quality is achieved by good design but the manufacturing phase for hardware have to phase quality problems that are nonexistent (or easily corrected) for software. Both activities are depend  on  people  but  the  relationship among people  applied  and  work  accomplished is  entirely different.

Software is does not wear out. The above figure depicts failure rate as a function of time for hardware.   The relationship is often called the "bathtub curve" that is indicates that hardware exhibits relatively high failure rates early in its life (these type of failures are often attributable to design or manufacturing defects) the failure rate drops to a steady state level and defects are corrected (hopeful, quite low) for some period of time. As the time passes, however the failure rate of software increase again as hardware components suffer from the cumulative effects of vibration, dust, abuse, temperature extremes, and many more environmental maladies.  Stated simply the hardware starts to wear out.

Figure 1.1 Failure curve for hardware

Software is not susceptible to the environmental maladies that cause hardware to wear out.  In theory thus the failure rate of curve for software should take the form shown in the figure 1.1. The undiscovered defects will cause high failure rates early in the life program. However, the curve flattens that is shown in another figure 1.2 is a gross over simplification of actual failure models for software. However the implication of clear software is does not wear it out. But it does deteriorate!

This seeming contradiction can best be explained by evaluating the Figure 1.3 in the During its life, software will undergo change (maintenance) As changes are made it is likely that some new defects will be introduced with it that causing the failure rate curve to spike as shown in Figure 1.3 previously the curve can return to the real steady state    failure rate the another change is requested causing the curve to spike again Slowly the minimum failure of the software  rate level start to rise the software is deteriorating due to change.

Figure 1.2 Failure curve for software (ideallized)

Figure 1.3 Actual failure curve for software

Most of the software is custom-built rather than being assembled from the existing components. As consider the manner in which the control hardware for a microprocessor is based product for designed and built.  The design engineer draws a simple schematic of the digital circuitry which can do some fundamental analysis to ensure that the proper function will be achieved and after that it refers to a catalog of digital components. Each and every integrated circuit (often called an "IC" or a "Chip") has a component number a standard set of integration a well -defined interface and defined validated function guidelines. After each part is selected it can be ordered off the shelf.

Sadly the software designers are not afforded the luxuries which are described above. There are no catalogs of software components with the few exceptions. I t is possible to order off- the -shelf software but only as a complete unit not as components that can be reassembled into new programs. Although it has been written about "software reusability we are only beginning to see the successful implementations of the concept.