Before software can be engineered, the system it is part of must be understood. The overall objective of the system must be determined, the role of the system elements (hardware, software, people, data, etc.) must be identified, and the operational requirements must be created. A representation (i.e., prototype, specification, symbolic model) of the system is produced as the result of the system engineering process. It is important that system engineering work products be managed using the quality assurance techniques discussed elsewhere in this text.
Systems
Don't take a "software-centric" view of the system; consider all system elements before focusing on software.
Good system engineering begins with a clear understanding of the "world view" and progressively narrows until technical detail is understood.
Complex systems are actually a hierarchy of macro-elements that are themselves systems.
Computer-Based System Elements
Software
Hardware
People
Database
Documentation
Procedures
System Engineering Hierarchy
World view
Domain view
Element view
Detailed view
System Modeling
Define the processes that serve the needs of the view under consideration
Represent the process behavior and the assumptions on which the behavior is modeled
Explicitly define the exogenous (links between constituents) and endogenous (links between constituent components) input to the model
Represent all linkages (including outputs) required to understand the view
System Model Restraining Factors
Assumptions
Simplifications
Limitations
Constraints
Preferences
System Simulation
If simulation capability is not available for a reactive system, project risk increases.
Consider using an incremental, iterative process model that will allow the delivery and testing of incrementally more complete products.
Business Process Engineering Hierarchy
Information Strategy Planning (world view)
Business Area Analysis (domain view)
Business System Design (element view - software engineers)
Construction and Integration (detailed view - software engineers)
Business Process Engineering Architectures
Data architecture - provides framework for information needs of a business or business function
Applications architecture - those system elements that transform objects within the data architecture for some business purpose
Technology infrastructure - provides foundation for the data and application architectures
Product Engineering Hierarchy
Requirements engineering (world view)
Component engineering (domain view)
Analysis and Design modeling (element view - software engineers)
Construction and Integration (detailed view - software engineers)
System Model Template
User interface
Input
Process and control functions
Output
Maintenance and self test
Systems Modeling Process
System Context Diagram (SCD) - top level node in system hierarchy used to establish the boundary between the system being implemented (system model template serves as its basis)
System Flow Diagram (SFD) - refinement of the process and control functions from SCD, derived by identifying the major subsystems and lines of information flow (precursor to Data Flow Diagram discussed in Chapter 12)
Initial SFD is becomes the top level node of a hierarchy of more successively more detailed SFD's
System Specification - developed by writing narrative description for each subsystem and definitions for all data that flow between subsystems
System Modeling with UML
Deployment diagram - depicts hardware elements that are part of the physical architecture of the system
Activity diagram - used to represent the procedural aspects of the system software elements, similar to a flowchart in that system functions are shown as nodes, decision points are shown as diamonds, and arrows are used to show flow through the system
Class diagram - shows the class attributes and operations that may be applied to the class within the context of the system
Use-case diagram - illustrates the manner in which an actor interacts with the system, each labeled oval within a system boundary represents one text scenario or use-case
