Software Engineering

4
SECTION 1
  Software Engineering Fundamentals
distribution, training, operations, support, and disposal. The principles of systems 
engineering include:
1. 
A system represents a complex, human-made product that involves hardware, 
software, and human operators to work effectively. The system or product must 
be understood in terms of its complete set of life-cycle processes, which impact 
the feasibility of potential design solutions.
2. 
A product is a combination of interrelated parts organized into a complex 
whole.
3. 
A product is human-made (designed, manufactured, tested, operated, and sus-
tained) for a specific, sometimes generalized, purpose. This eliminates “natural” 
or “biological” systems from consideration as a system of interest.
4. 
The effectiveness of the product in operation is a result of the application of sys-
tem thinking, which attempts at understanding how parts influence, cooperate, 
and collaborate with one another within a collective whole. This necessitates 
understanding the effects of the operational environment on the performance of 
the product and its constituent parts.
5. 
A product involves a hierarchical arrangement of smaller, less complex com-
ponents and parts. The design of a complex product cannot be derived without 
decomposing the problem space into manageable problems for which one or 
more technical solutions can be discriminated.
6. 
The system architecture represents the complete set of product life-cycle 
requirements and the product functional and physical configurations that pro-
vide its technical description.
7. 
The product is realized when the individual parts or components are fabricated 
(or procured), assembled, integrated, and tested.
These systems engineering principles can be easily adapted to a software prod-
uct. The computing environment provides the hardware component and represents 
the major element of the operational environment. The software product is the 
focus of the software engineering effort, and it must be designed to be operated 
by end users. The set of software life-cycle processes differs slightly since soft-
ware is not manufactured or fabricated, and its methods of replication, distribu-
tion, and training may vary significantly from a system-based product that involves 
hardware.
The practices associated with systems engineering were established in the early 
1940s and have been proven to resolve large, complex system or product design 
challenges. These practices involve:
●
  Requirements analysis
●
  Functional analysis and allocation
●
  Design synthesis
●
  Systems analysis
●
  Verification and validation
●
 Control

---

5
Summary
These six practices, and their adaptation to apply to the engineering of software 
products, is the main focus of this book. Section 2 provides the detailed definition 
of these practices as they apply to software engineering. The titles of these practices 
have been modified slightly to distinguish them from the systems engineering prac-
tices. This enables the same practices to be applied while acknowledging the differ-
ence in their application to solve a different design problem.
Summary
The chapters in this section provide a framework within which the software engi-
neering principles and practices are founded. The vocabulary used to present these 
software engineering principles and practices has been carefully chosen to avoid con-
fusion. However, the language quagmire that exists in the software industry coupled 
with potential conflicts in other engineering disciplines may impair the applicability  
of the precise terms used to express these software engineering concepts. For the sake 
of comprehending this manuscript, accept the terms used within the book as a means of 
expressing underlying philosophies. Once they have served their usefulness, the terms 
themselves may be discarded and replaced with more pleasing words and expressions.
Software development should be conducted in a project context. This estab-
lishes a relationship between the technical endeavor to design, implement, and test 
a software product, and management and control mechanisms intended to ensure 
that project expenditures, resources, and schedule milestones are satisfied. This 
highlights the fact that all products must be designed to be manufactured and sup-
ported throughout their life cycle to achieve established cost and schedule objec-
tives. Terms like 
design-to-cost
, 
design-to-support
, and 
life-cycle costs
 denote that 
a product has a perceived value, and the engineering of the product must ensure 
that its value, as expressed in purchase price, operational costs, etc., is in line with 
the benefits it offers its customers and stakeholders. Therefore, architectural design 
decisions must account for the impact a design solution bears on project resources, 
as well as the customer or consumer.
Architectural decisions will ultimately have the most substantial impact on soft-
ware development costs, as well as the effectiveness of the product throughout its 
life cycle. Software is easy to modify, thereby stakeholders believe that there are 
low costs to adding new features, functionality, or improved user interface mecha-
nisms. Architectural decisions affect the structure of the software product that facil-
itates its ability to be modified, extended, and enhanced. Therefore, it is essential to 
understand what a software architecture looks like, how it is developed, and how it 
is analyzed to facilitate shrewder design decisions. Architectural decisions establish 
a structural framework for the software product that makes it resilient to elementary 
changes. This resilience enables the software product to evolve during the software 
development effort, as well as throughout its operational life cycle.
Furthermore, software engineering must embrace an integrated product and pro-
cess (IPPD) philosophy. IPPD development addresses the consideration of software 

---