Software-Embedded Systems.

Software-embedded systems (also referred to as software-shaped systems, real-time systems, or sociotechnical systems) are hybrid combinations of hardware, software, and people. This category of systems is one in which the principal actions are performed by hardware but with software playing a major supporting role. Examples are vehicles, radar systems, computer-controlled manufacturing machinery, and so on. The function of software is usually that of performing critical control functions in support of the human operators and the active hardware components.

Software-embedded systems usually run continuously, typically on embedded microprocessors (hence the designation), and the software must therefore operate in real time. In these systems, software is usually embodied in components designed in accordance with requirements flowed down from system and subsystem levels. The requirements may be specified for individual software components or for a group of components operating as a subsystem. In these systems, the role of software can range from control functions in household appliances to highly complex automation functions in military weapons systems.

Software-Intensive Systems.

Software-intensive systems, which include all information systems, are composed largely of networks of computers and users, in which the software and computers perform virtually all of the system functionality, usually in support of human operators. Examples include automated information processing systems such as airline reservations systems, distributed merchandising systems, financial management systems, and so on. These software-intensive systems usually run intermittently in response to user inputs and do not have as stringent requirements on latency as real-time systems. On the other hand, the software is subject to system-level requirements directly linked to user needs. These systems can be very large and distributed over extended networks. The World Wide Web is an extreme example of a software-intensive system.

In software-intensive systems, software is key at all levels, including the system control itself. Hence, these must be systems engineered from the beginning. Most of them can be thought of as “transactional” systems (financial, airline reservation, command, and control). They are generally built around databases that contain domain information entities that must be accessed to produce the desired transaction.

Data-Intensive Computing Systems.

A type of software system that is significantly different from the above software system categories includes large-scale computing resources dedicated to executing complex computational tasks. Examples are weather analysis and prediction centers, nuclear effects prediction systems, advanced information decryption systems, and other computationally intensive operations.

These data-intensive computing systems usually operate as facilities in which the computing is typically performed either on supercomputers or on assemblies of high-speed processors. In some cases, the processing is done by a group of parallel processors, with computer programs designed for parallel operation.

The development of data-intensive computing systems requires a systems approach like other systems. However, most of these are one of a kind and involve very specialized technical approaches. Accordingly, this chapter will be focused on the systems engineering problems associated with the much more common software-embedded and software-intensive systems.

Structural Units.

Most hardware components are made up of standard physical parts, such as gears, transistors, motors, and so on. The great majority are implementations of commonly occurring functional elements, such as “generate torque” or “process data” (see Chapter 3). In contrast, software structural units can be combined in countless different ways to form the instructions that define the functions to be performed by the software. There is not a finite set of commonly occurring functional building blocks, such as makeup hardware subsystems and components. The main exceptions are generic library functions (e.g., trigonometric) contained in some software programming environments and certain commercial software “components” mostly related to graphic user interface functions.

Interfaces.

Because of its lack of well-defined physical components, software systems tend to have many more interfaces, with deeper and less visible interconnections than hardware systems. These features make it more difficult to achieve good system modularity and to control the effects of local changes.

Functionality.

There are no inherent limits on the functionality of software as there are on hardware due to physical constraints. For this reason, the most critical, complex, and nonstandard operations in systems are usually allocated to software.

Size.

While the size of hardware components is limited by volume, weight, and other constraints, there is no inherent limit to the size of a computer program, especially with modern memory technology. The large size of many software-based systems constitutes a major systems engineering challenge because they can embody an enormous amount of custom-built system complexity.

Changeability.

Compared to the effort required to make a change in a hardware element, it is often falsely perceived to be easy to make changes in software, that is, “merely” by altering a few lines of code. The impacts of software changes are more difficult to predict or determine due to the complexity and interface problems cited above. A “simple” software change may require retesting of the entire system.

Failure Modes.

Hardware is continuous in both structure and operation, while software is digital and discontinuous. Hardware usually yields before it fails and tends to fail in a limited area. Software tends to fail abruptly, frequently resulting in a system breakdown.

Abstraction.

Hardware components are described by mechanical drawings, circuit diagrams, block diagrams, and other representations that are models of physical elements readily understood by engineers. Software is inherently abstract. Besides the actual code, architectural and modeling diagrams are highly abstract and each diagram restricted in its information context. Abstractions may be the single most fundamental difference between software and hardware.

The above differences, summarized in Table 11.3, profoundly affect the systems engineering of complex software-dominated systems. Not appreciating these differences and effectively accounting for them have contributed to a number of spectacular failures in major programs, such as an attempted modernization of the air traffic control system, the initial data acquisition system for the Hubble telescope, the Mars Lander spacecraft, and an airport baggage handling system.

For the majority of systems engineers who do not have experience in software engineering, it is essential that they acquire a grounding in the fundamentals of this discipline. The following sections are intended to provide a brief overview of software and the software development process.

Linear Development Models

The waterfall model is the classic software development life cycle, also called the “sequential” model (see Fig. 11.4). It consists of a sequence of steps, systematically proceeding from analysis to design, coding and unit test, and integration and system test. The waterfall model with feedback (see dashed arrows) depicts the adjustment of inputs from a preceding step to resolve unexpected problems before proceeding to the subsequent step. The waterfall model corresponds most closely to the conventional system life cycle. Table 11.4 lists the system life cycle phases, their objectives, and the corresponding activity in the waterfall life cycle phase.

Over the years, the basic waterfall model has morphed into many variations, including some that quite honestly could no longer be described as linear. Waterfall has been combined with the other types to form hybrids that could be classified as a combination of two or more categories. And while the basic waterfall model is rarely used in today’s modern software engineering community, its basic principles can be recognized throughout, as will be evidenced in the next two sections.

Feasibility Analysis.

The decision to proceed with system design has been seen to require the demonstration of technical feasibility. Within the realm of software, almost anything appears feasible. Modern microprocessors and memory chips can accommodate large software systems. There are no clear size, endurance, or accuracy limits such as there are on hardware components. Thus, technical feasibility tends to be taken for granted. This is a great advantage of software but also invites complexity and the assumption of challenging requirements. However, the resulting complexity may in itself prove too difficult and costly.

Software-Embedded System Components.

As noted previously, the software elements in software-embedded systems are usually at the component level, referred to as computer system configuration items (CSCIs). Their requirements are generated at the system and subsystem levels and are allocated to CSCIs, usually in a formal requirement specification document. The software team is expected to design and build a product to these specifications.

Too often, such specifications are generated by systems engineers with an inadequate knowledge of software capabilities and limitations. For example, a large dynamic range in combination with high precision may be prescribed, which may unduly stress the system computational speed. Other requirement mismatches may result from the communication gap that frequently exists between systems and software engineers and organizations. For such reasons, it is incumbent on the software development team to make a thorough analysis of requirements allocated to software and to question any that fail to have the characteristics described in Chapter 7. These reasons also constitute a good argument for including software engineers in the top-level requirements analysis process.

Software-Intensive System Requirements.

As noted earlier, in a software-intensive system, software dominates every aspect and must be an issue at the highest level of system requirements analysis. Thus, the very formulation of the overall system requirements must be subject to analysis and participation by software systems engineers.

The basic problems in developing system requirements for software-intensive systems are fundamentally the same as for all complex systems. However, there are several aspects that are peculiar to requirements for systems that depend on the extensive software automation of critical control functions. One special aspect has been noted previously, namely, unreasonable performance expectations based on the extensibility of software. Another is the generally diverse customer base, with little understanding of what software automation is capable of doing, and hence is often not a good source of requirements.

The consequences of these and other factors that inhibit the derivation of a reliable set of requirements typically result in a considerable degree of uncertainty and fluidity in software-based system requirements. This is a major reason for the use of prototyping, RAD, or evolutionary development, all of which produce an early version of the system that can be subjected to experimentation by users to modify and firm up initial assumptions of desired system characteristics.

Several variations of developing software requirements exist today. Of course, many depend on the type of software development model being used; however, some generic features exist regardless of the model chosen. Figure 11.8 depicts a hierarchy of software requirements, starting with the user needs at the apex. These needs are decomposed into desired features, functional and performance requirements, and finally specifications. If the system in question is software embedded, the upper levels of the hierarchy are typically performed at the system level and requirements or specifications are allocated to software subsystems or components.

If the system in question is software intensive, the upper levels of the hierarchy are needed. In those cases, a separate process for developing and refining requirements may be needed. Several processes have been offered in the literature. A generic process is presented in Figure 11.9. Four steps, which can be further divided into separate steps, are critical to this effort:

• Requirements Elicitation. This step seems straightforward but, in reality, can be challenging. Bridging the language barrier between users and developers is not simple. Although tools have been developed to facilitate this process (e.g., use cases, described below), users and developers simply do not speak the same language. Many elicitation methods exist—from direct interaction with stakeholders and users, involving interviews and surveys, to indirect methods, involving observation and data collection. Of course, prototyping can be of valuable use.
• Requirements Analysis and Negotiation. Chapter 7 described a series of methods to analyze and refine a set of requirements. These are applicable to software as much as they are to hardware. In general, these techniques involve checking four attributes of a requirements set: necessity, consistency, completeness, and feasibility. Once requirements have been refined, they need to be accepted—this is where negotiation begins. Requirements are discussed with stakeholders and are refined until agreement is reached. When possible, requirements are prioritized and problematic requirements are resolved. A more advanced analysis is then performed, examining the following attributes: business goal conformity, ambiguity, testability, technology requirements, and design implications.
• Requirements Documentation. Documentation is always the obvious step and can be omitted since everyone is expecting the requirements to be documented. We include it because of the criticality in articulating and distributing requirements to the entire development team.
• Requirements Validation. This step can be confusing because many engineers include “analysis” in this step, that is, the concept that each requirement is evaluated to be consistent, coherent, and unambiguous. However, we have already performed this type of analysis in our second step above. Validation in this context means a final examination of the requirements set in whole to determine whether the set will ultimately meet the needs of the users/customers/parent system. Several methods exist to enable requirement validation—prototyping, modeling, formal reviews, manual development, and inspection—even test case development can assist in the validation process.

Use Cases.

As mentioned in Chapter 8, a popular tool available to requirements engineers is the use case. A use case has been best described as a story, describing how a set of actors interact with a system under a specific set of circumstances. Because the set of circumstances can be large, even infinite, the number of possible use cases for any system can also be large. It is the job of the requirements engineer, developers, users, and systems engineer to limit the number and variety of use cases to those that will influence the development of the system.

Use cases represent a powerful tool in bridging the language gap between users, or any stakeholder, and developers. All can understand sequences of events and activities that need to be performed. Although use cases were developed for describing software system behavior and features, they are regularly used in the systems world to describe any type of system, regardless of the functionality implemented by software.

Interface Requirements.

Whichever the type of an essential tool of requirements analysis is the identification of all external interfaces of the system, and the association of each input and output with requirements on its handling within the system. This process not only provides a checklist of all relevant requirements but also a connection between internal functions required to produce external outcomes. In all software-dominated systems, this approach is especially valuable because of the numerous subtle interactions between the system and its environment, which may otherwise be missed in the analysis process.

Software Building Blocks.

The objective of the partitioning process is to achieve a high degree of “modularity.” The principles that guide the definition and design of software components are intrinsically similar to those that govern hardware component design, but the essentially different nature of the implementation results in significant differences in the design process. One fundamental difference is in regard to commonly occurring building blocks such as those described in Chapter 3. There is a profusion of standard commercial software packages, especially for business and scientific applications (e.g., word processors, spread sheets, and math packages), but rarely for system components. Exceptions to this general situation are the commercial-off-the-shelf (COTS) software components heavily used in low-complexity information systems.

Another source of software building blocks is that of common objects (COs). These are somewhat the equivalents in software to standard hardware parts such as gears or transformers, or at higher levels to motors or memory chips. They are most often used in the graphical user interface (GUI) environment. The CO concept is represented by the Microsoft-developed distributed common object model (DCOM). A more vendor-independent implementation is the common object resource broker architecture (CORBA), which is a standard defined by the Object Management Group (OMG), an organization committed to vendor neutral software standards. However, these CO components comprise only a small fraction of system design. The result is that despite such efforts at “reuse,” the great majority of new software products are very largely unique.

Modular Partitioning.

Despite the lack of standard parts, software modules nevertheless can be well structured, with an ordered hierarchy of modular subdivisions and well-defined interfaces. The same principles of modularity to minimize the interdependence of functional elements that apply to hardware components are applicable also to computer programs.

The principles of modular partitioning are illustrated in Figure 11.10. The upper patterns show the elements of “binding,” also referred to as “cohesion,” which measures the mutual relation of items within software modules (represented by boxes with the names of colors). It is desirable for binding to be “tight”—all closely related items should be grouped together in a single functional area. Conversely, unrelated and/or potentially incompatible items should be located in separate areas.

The lower two diagrams illustrate the elements of “coupling,” which measures the interactions between the contents of different modules (boxes). With tight coupling as illustrated at the left, any change within a module will likely dictate changes in each of the other two modules. Conversely, with “loose” coupling, interactions between the modules are minimized. The ideal arrangement, usually only partially achievable, is illustrated in the right-hand diagram, where interactions between modules are kept simple and data flows are unidirectional. This subject is discussed further below as it relates to different design methodologies.

Architecture Modeling.

As noted in Chapter 10, models are an indispensable tool of systems engineering for making complex structures and relationships understandable to analysts and designers. This is especially true in software-dominated systems where the abstract nature of the medium can make its form and function virtually incomprehensible.

The two main methodologies used to model software systems are called “structured analysis and design” and “object-oriented analysis and design (OOAD).” The former is organized around functional units called procedures and functions. It is based on a hierarchical organization and uses decomposition to handle complexity. Generally, structured analysis is considered a top-down methodology.

OOAD is organized around units called “objects,” which represent entities and encapsulate data with its associated functions. Its roots are in software engineering and it focuses on information modeling, using classes to handle complexity. Generally, OOAD can be considered a bottom-up methodology.

FFBD.

The FFBD comes in a variety of forms. We introduced one of those varieties, the functional block diagram, in Chapter 8 (see Fig. 8.4). The FFBD is similar, except that rather than depicting functional interfaces like the block diagram, connections (represented by arrows) represent flow of control. Since the FFBD incorporates sequencing (something that neither the functional block diagram (FBD) nor the integrated definition 0 (IEDF0) formats do), logical breaking points are depicted by summing gates. These constructs enable the depiction of process-oriented concepts. Almost any process can be modeled using the FFBD. Figure 11.11 is an example of an FFBD.

As with all functional diagrams, each function within the hierarchy can be decomposed into subfunctions, and a corresponding diagram can be developed at each level. Functional diagrams are the standard method within structured analysis to depict a system’s behavior and functionality.

DFD.

This diagram consists primarily of a set of “bubbles” (circles or ellipses) representing functional units, connected by lines annotated with the names of data flowing between the units. Data stores are represented by a pair of parallel lines and external entities are shown as rectangles. Figure 11.12 shows a DFD for the checkout function of a small public library system.

A system is normally represented by DFDs at several levels, starting with a context diagram in which there is only one bubble, the system, surrounded by external entity rectangles (see Fig. 3.2). Successive levels break down each of the bubbles at the upper levels into subsidiary data flows. To systems engineers, a software DFD is similar to the functional flow diagram except for the absence of control flow.

ERD.

The ERD model defines the relationships among data objects. In its basic form, the entities are shown as rectangles and are connected by lines representing the relationship between them (shown inside a diamond). In addition to this basic ERD notation, the model can be used to represent hierarchical relationships and types of associations among objects. These models are extensively used in database design.

STD.

An STD models how the system behaves in response to external events. An STD shows the different states that the system passes through, the events that cause it to transition from one state to another, and the actions taken to effect the state transition.

Data Dictionary.

In addition to the above diagrams, an important modeling tool is an organized collection of the names and characteristics of all data, function, and control elements used in the system models. This is called the “data dictionary” and is a necessary ingredient in understanding the meaning of the diagrammatic representations. It is analogous to a hardware part and interface listing of sets of data and procedure declarations, followed by the definition of a number of procedures that operate on the data. It is not difficult to trace the functional relationships, evidenced by function/procedure calls, and thereby to construct a “function call tree” tracing the flow of functions throughout the program.

Modeling and Functional Decomposition.

Object-oriented design (OOD) also has the advantage of using a precisely defined and comprehensive modeling language—the Unified Modeling Language (UML). This provides a powerful tool for all stages of program development. The characteristics of UML are described in Chapter 8.

A shortcoming of the OO methodology as commonly practiced is that it does not follow a basic systems engineering principle—that of managing complexity by partitioning the system into a hierarchy of loosely coupled subsystems and components. This is accomplished by the systems engineering step of functional decomposition and allocation. By focusing on objects (things) rather than functions, OOD tends to build programs from the bottom-up rather than the top-down approach inherent in the systems engineering method.

OOD does have a structural element, the use case, which is basically a functional entity. As described above, use cases connect the system’s external interfaces (actors) with internal objects. The application of use cases to design the upper levels of the system architecture and introducing objects at lower levels may facilitate the application of systems engineering principles to software system design. This approach is described in Rosenberg’s book, Use Case Driven Object Modeling with UML.

Strengths of UML.

The UML language combines the best ideas of the principal methodologists in the field of OOAD. It is the only standardized, well-supported, and widely used software modeling methodology. It therefore serves as a high-level form of communicating software architectural information within and among organizations and individuals engaged in a development program.

Moreover, UML has been applied successfully in software-intensive systems projects. Portions of UML are also used regularly in systems engineering to assist in communicating concepts and in bridging the language gaps between engineers and users (e.g., use case diagrams) and between software and hardware engineers (e.g., communications diagrams).

A major strength of UML is the existence of commercial tools that support the construction and use of its repertoire of diagrams. In the process, these tools store all the information contained in the diagrams, including names, messages, relationships, attributes, methods (functions), and so on, as well as additional descriptive information. The result is an organized database, which is automatically checked for completeness, consistency, and redundancy. In addition, many of the tools have the property of converting a set of diagrams into C++ or Java source code down to procedure headers. Many also provide a limited degree of reverse engineering—converting source code into one or several top-level UML diagrams. These capabilities can save a great deal of time in the design process.

Robustness Analysis.

This is an extension of OO methodology that serves as a link between OO analysis (what) and design (how). It classifies objects into three types:

1. 1. boundary objects, which link external objects (actors) with the system;
2. 2. entity objects, which embody the principal objects that contain data and perform services (functions); and
3. 3. control objects, which direct the interaction among boundary and entity objects.

Robustness analysis creates a robustness diagram for each UML use case, in which the objects involved in the processing of the use case are classified as boundary and entity objects and are linked by control objects defined for the purpose. An example of a robustness diagram for the checkout use case for an automated library is shown in Figure 11.13. It is seen to resemble a functional flow diagram and to be easily understandable.

In the process of preliminary design, the robustness diagram is transformed into class, sequence, and other standard UML diagrams. Control objects may remain as controller types, or their functionality may be absorbed into methods of the other objects. To a systems engineer, robustness analysis serves as an excellent introduction to OOAD.

Function-Class Decomposition (FCD).

This methodology, referred to as FCD, is a hybrid method that combines structured analysis with OO methodology. It is aimed at the top-down decomposition of complex systems into a hierarchy of functional subsystems and components, while at the same time identifying objects associated with each unit.

As previously noted, conventional OO methodology tends to design a system from the bottom-up and has little guidance on how to group objects into packages. It is said to lead to a “flat” modular organization. The FCD method seeks to provide a top-down approach to system partitioning by using functional decomposition to define a hierarchical architecture into which objects are integrated. In so doing, it introduces the important systems engineering principle of functional decomposition and allocation into OO software system design.

FCD uses an iterative approach to partition successively lower levels of the system while at the same time also adding such objects as turn out to be needed for the lower-level functions. UML class diagrams are introduced after the first several levels are decomposed. The developers of the FCD method have demonstrated its successful use on a number of large system developments.

Program Building Blocks.

A computer program may be considered to consist of several types of subdivisions or building blocks. In descending order of size, the subdivisions of a computer program and their common names are as follows:

1. 1. A “module” or “package” constitutes a major subdivision of the overall program, performing one or more program activities. A medium to large program will typically consist of from several to tens or hundreds of modules.
2. 2. In OO programs, a class is a unit composed of a set of “attributes” (data elements) combined with a set of associated “methods” or “services” (functions). An object is an instance of a class.
3. 3. A function is a set of instructions that performs operations on data and controls the processing flow among related functions. A “utility” or “library function” is a commonly used transform (e.g., trigonometric function) that is supplied with an operating system.
4. 4. A “control structure” is a set of instructions that controls the order in which they are executed. The four types of control structures are the following:
   1. (a) Sequence: a series of instructions;
   2. (b) Conditional Branch: if (condition) then (operation 1), else (operation 2);
   3. (c) Loop: do while (condition) or do until (condition); and
   4. (d) Multiple Branch: case (key 1): (operation 1) … (key n) (operation n).
5. 5. An “instruction” is a “declarative” or “executable” order to the computer, composed of language key words, symbols, and names of data and functions.
6. 6. A language key word, symbol, or name of a data element or function.

Finally, a “data structure” is a definition of a composite combination of related data elements, such as a “record,” “array,” or “linked list.”

As noted previously, software has no commonly occurring building blocks comparable to standard hardware parts and subcomponents such as pumps, motors, digital memory chips, cabinets, and a host of others that simplify designing and building production hardware. With few exceptions, software components are custom designed and built.

Program Design Language (PDL).

A useful method for representing software designs produced by the conventional structured analysis and design methodology is PDL, sometimes called “structured English.” This consists of high-level instructions formatted with control structures like an actual computer program, but consists of textual statements rather than programming language key words and phrases. PDL produces a program listing that can be readily understood by any software engineer and can be translated more or less directly into executable source codes.

OOD Representation.

It was seen that OOD produces a set of diagrams and descriptive material, including defined objects that constitute intermediate program building blocks. Through the use of a UML support tool, the design information can be automatically converted into the architecture of the computer program.

Fourth-Generation Language (4GL) and Special-Purpose Language.

4GLs are typically proprietary languages that provide higher-level methods to accomplish a problem solution in a specific domain. These 4GLs are usually coupled with a database system and are related to use of the structured query language (SQL). A key feature of 4GL tools is to bring the programming language environment as close to the natural language of the problem domain as possible and to provide interactive tools to create solutions. For example, the creation of a user input form on a workstation is carried out interactively with the programmer. The programmer enters the labels and identifies allowable entry values and any restrictions, and then the “screen” becomes part of the application. 4GLs can speed up the development time for specific applications but are generally not portable across products from different vendors.

There are many specialty areas where very efficient high-level languages have been developed. Such languages usually take on the jargon and constructs of the area they are intended to serve. The intent of these special-purpose languages is to mimic the problem domain where possible, and to decrease development time while increasing reliability. In many cases, the special-purpose nature of such languages may limit performance for the sake of ease of use and development. When undertaking custom software development, the systems engineer should explore the availability and utility of languages in a required specialty area. Table 11.6 lists a number of special-purpose languages that have been developed for specific application domains, such as expert systems and Internet formatting.

Editors.

Editors provide programmers with the means to enter and change source code and documentation. Editors enhance the entry of programming data for specific languages. Some editors can be tailored to help enforce programming style guides.

Debuggers.

Debuggers are programs that allow an application to be run in a controlled manner for testing and debugging purposes. There are two major types of debuggers: symbolic and numeric. The symbolic debugger allows the user to reference variable names and parameters in the language of the source code. A numeric debugger works at the assembly or machine code level. The computer instructions written in a programming language is called “source code.” To convert the source code produced by the programmers into executable code, several additional tools are required.

Compilers.

A compiler converts the source language into an intermediate format (often called object code) that is compatible for use by the hardware. In this process, the compiler detects syntax errors, omissions of data declarations, and many other programming errors, and identifies the offending statements.

A compiler is specific to the source language and usually to the data processor. Compilers for a given language may not be compatible with each other. It is important to know what standards govern the compiler that will be used and to be aware of any issues associated with code portability. Some compilers come with their own programming development environment that can increase programmer productivity and simplify the program documentation process.

Linkers and Loaders.

A linker links several object code modules and libraries together to form a cohesive executable program. If there is a mixed language application (C and Java are common), the combination of a compiler and linker that works on multiple languages is required. Tools that help manage the linking of complex applications are essential in the management and control of software development. A loader converts linked object code into an executable module that will run in the designated environment. It is often combined with the linker.

Computer User Interfaces.

As noted previously, a critical part of engineering operational software systems is the design of the user interface. A computer interface should display information in a form giving the user a clear and well-organized picture of the system status so as to assist the decision process effectively and to provide simple and rapid modes of control. The selection of the appropriate interface mode, display format, interactive logic, and related factors most often requires prototype design and testing with representative users.

The most common control modes offered by computer interfaces are menu interactions, command languages, and object manipulation. A summary of some comparative characteristics of these is given in Table 11.8.

The most rapidly growing computer interface mode is that of object manipulation, the objects being usually referred to as “icons.” In addition to the characteristics listed in Table 11.8, graphical presentations of information can often present relationships and can convey meaning better than text. They enable the user to visualize complex information and form inferences that can lead to faster and more error-free decisions than can be achieved by other methods. GUIs are most commonly seen in PC operating systems such as Macintosh OS and Microsoft Windows. The power of the World Wide Web owes a great deal to its GUI formats.

To the systems engineer, GUIs offer both opportunities and challenges. The opportunities are in the virtually infinite possibilities of presenting information to the user in a highly enlightening and intuitive form. The challenges come from the same source, namely, the sheer number of choices that tempt the designer to continue to optimize, unrestrained by an inherent limit. Since GUIs involve a complex software design, there is a risk of cost and schedule impact if the systems engineer is not alert to this hazard.

Advanced Modes.

In designing user interfaces for computer-controlled systems, the rapidly advancing technology in this area makes it necessary to consider less conventional modes that offer special advantages. Three examples are briefly described below:

1. 1. Voice Control. Spoken commands processed by speech recognition software provide a form of rapid and easy input that leaves the hands free for other actions. Currently, reliable operation is somewhat limited to carefully enunciated words selected from a fixed vocabulary. Capabilities to understand sentences are gradually being evolved.
2. 2. Visual Interaction. Computer graphics are being used to aid decision makers by generating displays modeling the results of possible actions, enabling “what-if” simulations in real time. Visual interactive simulation (VIS) is an advanced form of visual interactive modeling (VIM).
3. 3. Virtual Reality. A form of 3-D interface in which the user wears stereo goggles and a headset. Head movements generate a simulated motion of the image corresponding to what the eyes would see in the virtual scene. Such displays are used for a growing variety of tasks, such as design of complex structures and pilot training. They are used in battlefield situations and games.

Test Paths.

The unconstrained use of control structures (branches, loops, and switches) may create a multitude of possible logical paths through even a relatively small program. This makes it impractical to test all possible paths and forces the choice of a finite number of cases.

Interfaces.

The typically large number of interfaces between software modules, and their depth and limited visibility, makes it difficult to locate strategic test points and to identify the exact sources of discrepancies encountered during testing.

Abstraction.

The design descriptions of software are more abstract and are less intuitively understandable than hardware design documentation. This complicates test planning.

Changes.

The apparent ease of making changes in software requires correspond­ingly more frequent retesting. Local changes often require repetition of system-level tests.

Failure Modes.

The catastrophic nature of many software errors has two critical consequences. One is the severity of the impact on system operation. The other is that prompt diagnosing of the source of the failure is often frustrated by the inoperability of the system.

Black Box Testing.

The section on unit testing described white box testing as addressing the known design features of the component. Validation and other system-level tests consider the system under test as an input-to-output transfer function, without any assumption of its internal workings. As such, black box testing is complementary to white box testing and is likely to uncover interface errors, incorrect functions, initialization errors, as well as critical performance errors.

Alpha and Beta Testing.

For software products built for many users, as in the case of much commercial software, most producers have a number of potential customers operate the software before releasing the product for distribution. Alpha testing is typically conducted in a controlled environment at the developer’s site, often by employees of a customer. The developer records errors and other problems. Beta testing is conducted at a customer’s site without the developer’s presence. The customer records the perceived errors and operating problems and reports these to the developer. In both cases, the advantage to the customer is the opportunity to become acquainted with an advanced new product. The developer gains by avoiding the risk of fielding a product containing user deficiencies that would significantly curtail the product’s marketability.

CASE.

CASE is a collection of tools that are designed to standardize as much of the software development process as possible. Modern CASE tools revolve around graphics-oriented diagramming tools that let the designer define the structure, program and data flow, modules or units, and other aspects of an intended software application. By the use of well-defined symbology, these tools provide the basis for the requirements analysis and design phases of the development cycle.

Requirements Management Tools.

The derivation, analysis, quantification, revision, tracing, verification, validation, and documentation of operational, functional, performance, and compatibility system requirements have been seen to extend throughout the system life cycle. For a complex system development, it is a critical and exacting task that involves operational, contractual, as well as technical issues. Several computer-based tools are commercially available that assist in creating an organized database and provide automatic consistency checks, traceability, report preparation, and other valuable services.

Software Metrics Tools.

Several commercial tools and tool sets are available to produce automatically measures of various technical characteristics of computer programs, relating to their semantic structure and complexity. (See later section on metrics.)

Integrated Development Support Tools.

Several tools have become available that provide a set of compatible integrated support functions, and, in some cases, the capability of importing and exporting data from and to complementary tools from other manufacturers. For example, some tools integrate project management, UML diagramming, requirements analysis, and metrics acquisition capabilities. Such tools simplify the problem of maintaining information consistency among the related domains of software development.

Software Configuration Management (CM).

CM in system development was discussed at some length in Chapter 10. Its importance increases with system complexity and criticality. In software systems, strict CM is the most critical activity during and after the engineering development stage. Some of the reasons for this may be inferred from the section on the differences between hardware and software:

1. 1. Software’s abstractness and lack of well-defined components makes it difficult to understand.
2. 2. Software has more interfaces; their penetration is deeper and hence is difficult to trace.
3. 3. Any change may propagate deep into the system.
4. 4. Any change may require retesting of the total system.
5. 5. When a software system fails, it often breaks down abruptly.
6. 6. The flexibility of software renders making a software change deceptively easy.

Capability Maturity Levels.

The CMM defines six capability and five maturity levels as summarized in Tables 11.9 and 11.10. The CMMI process is fully institutionalized. Key performance areas (KPAs) are defined for each level and are used in determining an organization’s maturity level. Each KPA is further defined by a set of goals and key practices that address these goals. SEI also defines key indicators that are designed to determine whether or not the KPA goals have been achieved. These are used in CMM assessments of an organization’s capability maturity level.

CMMI is widely used by industry, especially by large system and software development organizations. The U.S. DoD prescribes a demonstration of CMMI Level 3 capability for major system acquisitions. However, the investment necessary to achieve CMMI certification is considerable, and it is generally estimated that going from level 1 to level 2 or from level 2 to level 3 requires from 1 to 2 years.

Systems Engineering Implications.

Examination of the KPAs reveals that they address a combination of project management, systems engineering, and process improvement issues. At level 2, the KPAs addressing requirements management and CM are clearly systems engineering responsibilities, while project planning, project tracking and oversight, and subcontract management are mainly project management functions. At level 3, software product engineering, intergroup coordination, and peer reviews are of direct concern to systems engineers. At higher levels, the focus is largely on process improvement based on quantitative measurements of process results.

Project Metrics.

Software project metrics are concerned with measures of the success of project management—stability of requirements, quality of project planning, adherence to project schedules, extent of task descriptions, quality of project reviews, and so on. These are basically the same as would be used on any comparable project to track management practices. A reason for greater attention to project metrics on a software development is the traditionally more difficult task of reliable planning and estimating new software tasks. Project metrics should be tailored to the formality, size, and other special characteristics of the project.

Process Metrics.

Software process metrics are fundamental to the practice of establishing process standards as described in the previous section on software capability maturity assessment. Such standards identify a set of process areas that need to be addressed. They do not generally prescribe how they should be handled but require that appropriate practices be defined, documented, and tracked.

Technical Metrics.

Technical software metrics are focused largely on assessing the quality of the software product rather than on management or process. In that sense, they are an aid to design by identifying sections of software that are exceptionally convoluted, insufficiently modularized, difficult to test, inadequately commented, or otherwise less than of high quality. Such measures are useful for directly improving the product, and for refining design and programming practices that contributed to the deficiencies. There are numerous commercial tools that are designed to track technical software metrics.

Management of Metrics.

Software metrics can be useful in developing good practices and in improving productivity and software quality. However, they can also be misused with negative results for the projects and the software staff. It is important to observe a number of principles in the management of metrics:

1. 1. The purpose of each metric must be clearly understood by all concerned to be beneficial and worth the effort to collect and analyze.
2. 2. The metrics collected on a given project should be appropriate to its character and criticality.
3. 3. The results of metrics collection should be used primarily by the project to increase its probability of success.
4. 4. The results should never be used to threaten or appraise individuals or teams.
5. 5. There should be a transition period for the introduction of new metrics before the data collected are used.

Process Improvement.

The establishment and widespread adoption of software process standards, such as CMMI, have significantly strengthened the discipline used in software design. They have introduced engineering practices and management oversight into a culture derived from science and art. For large, well-defined projects, these approaches, which have been found to reduce failure rates, vary significantly. For smaller projects having loosely defined requirements, agile methods have attracted many adherents.

Programming Environment.

Computer-aided programming environments, such as that for Visual Basic, are likely to continue to improve, providing better automatic error checking, program visualization, database support, and other features designed to make programming faster and less prone to error. Integration of syntax checking, debugging, and other programming support functions into the environment, along with more powerful user interfaces, is likely to continue to improve productivity and accuracy.

Integrated CASE Tools.

Requirements and CM tools are being integrated with modeling and other functions to facilitate the development, upgrading, and maintenance of large software programs. The integration of these tools enables the traceability of program modules to requirements and the management of the massive number of data elements present in complex systems capabilities. While the development of such tools is expensive, their growth and consequent increases in productivity are likely to continue, especially if more emphasis is placed on reducing the time and cost of becoming proficient in their use.

Software Components.

Reuse of software components has long been a major goal, but its effective realization has been the exception rather than the rule. One such exception has been the availability of commercial GUI components, supporting features such as windowing and pull-down menus. With the proliferation of automated transactional systems (financial, travel, inventory, etc.), it is likely that numerous other standard components will be identified and made commercially available. The gains in development cost and reliability in automated transactional systems are potentially very large.

Design Patterns.

A different approach to reusable components has been the development of design patterns. A seminal work on this subject by Gamma et al. defines 23 basic patterns of OO functions and describes an example of each. The patterns are subdivided into three classes: creational patterns that build various types of objects, structural patterns that operate on objects, and behavioral patterns that perform specified functions. While this approach appears to hold great promise of creating versatile software building blocks, it has thus far not been adopted by a significant fraction of developers.

Software Systems Engineering.

Perhaps the most significant advance in the development of software-dominated systems would come from the effective application of systems engineering principles and methods to software system design and engineering. Despite the many differences between the nature of software and hardware technologies, some avenues to narrowing this gap are being actively explored. The development of the CMMI by SEI, which addresses both systems engineering and software engineering in a common framework, may contribute to a more common outlook. However, real progress in this direction must involve education and extensions of current software methodologies to facilitate modular partitioning, clean interfaces, architectural visibility, and other basic features of well-designed systems. The continuing demand for complex software-dominated systems may accelerate efforts to introduce systems engineering methods into software development.