Chapter 6

Chapter 6

System Engineering

CHAPTER OVERVIEW AND COMMENTS

This intent of this chapter is to provide a brief  introduction to the system engineering process. The overall structure of computer-based systems is discussed and a brief overview of the system engineering hierarchy is presented. Business process engineering (BPR) and product engineering are discussed in overview fashion.

Note: Some reviewers of this edition argued that a discussion of system engineering is beyond the scope of a software engineering text. I disagree. In many cases, the software element of a system does not integrate properly or fails altogether because software engineers treat their system element (software) as if it existed in a vacuum. It does not!

The treatment of system engineering in SEPA is necessarily brief, but it does emphasize the importance of a “system view.” I think this concept should be communicated to your students.

6.1    Computer-Based Systems      

This section introduces the systems view of engineering (all complex systems can be viewed as being composed of cooperating subsystems). The elements of computer-based systems are defined as software, hardware, people, database, documentation, and procedures. Software engineering students find it difficult to think about system elements other than software when they begin to develop their first projects. It is important to get students in the habit of taking time to understand the all the elements of the systems in which their software products will reside.

Discuss each of the system elements presented here and indicate how they are organized in various well know systems (e.g., a mobile-phone network).

This chapter begins with Machiavelli's quote on the dangers associated with the introduction of a "new order". It might be worthwhile to project how computer-based systems will introduce a "new order" in the first few decades of the 21st century. You might use Toeffler, Naisbitt, or Negroponte as guidelines for these discussions. Topics could include: the Internet (personal privacy and e-commerce), intelligent agents, artificial reality, artificial intelligence, office automation, education, warfare, medicine, voice recognition, robots, vision systems, personal digital assistants, appliance computers, DVD/mp3, networks, and data warehousing issues.

6.2    The System Engineering Hierarchy

The key to system engineering is a clear understanding of context. For software development this means creating a "world view" and progressively narrowing its focus until all technical detail is known. It is important to get students in the habit of recognizing the importance of developing alternative solutions to problems. In software engineering there is rarely one right way of doing something. Instead designers must consider the tradeoffs present in the feasible solutions and select one that seems advantageous for the current problem. This section lists several factors that need to be examined by software engineers when evaluating alternative solutions (assumptions, simplifications, limitations, constraints, and preferences). This section also cautions students that developing reactive systems without some simulation capability is a risky practice.

Spent a few moments walking though Figure 6.1, discussing  the difference between a world view, a domain view, an element view and detailed views. Ideally provide an example using the system you discussed earlier.

6.3    Business Process Engineering: An Overview

In general, this section will be of interest to students who have an IT focus, although all software engineers should understand it ramifications.

Software engineers usually do not participate in the upper levels of business process engineering (information strategy planning and business area analysis). Student projects usually begin with the assumption that this work has been done and is understood by the customer.

Convince your students that it is important for software engineers to understand the results of the business considerations that have taken place prior to beginning the definition of the requirements for a specific information system to support a particular business application. Discuss the problems that can occur when this does not happen.

6.4    Product Engineering: An Overview

Emphasize that software engineers participate in all levels of the product engineering process that begins with requirements engineering. The analysis step maps requirements into representations of data, function, and behavior. The design step maps the analysis model into data, architectural, interface, and software component designs. Detailed discussion of analysis and design techniques appears in the next several chapters of SEPA.

Use the SafeHome sidebar in this chapter as a point of departure for a discussion of the issues that need to be addressed as part of product engineering.

6.5    System Modeling

Rather than discussing the Hatley-Pirbhai technique (Section 6.5.1). most instructors will opt to present the use of UML in system modeling. Selected UML diagrams are presented in Section 6.5.2. You might want to discuss the syntax and semantics for all of the UML diagrams presented here.

Note: SEPA does not go into great detail on the mechanics for constructing UML diagrams. If you are going to stress UML in your course, plan to spend some additional time on diagrammatic syntax and semantics for UML diagrams.