BC0045-Structured
System Analysis and Design
1.How
do you and your organization define system? Mention the systems that require
engineering.
The term “system” originates
from the Greek term systema, which means to “place together.” Multiple business
and engineering domains have definitions of a system. This text defines a
system as:
• System: An integrated set
of inter operable elements, each with explicitly specified and bounded
capabilities, working synergistically to perform value-added processing to enable
a User to satisfy mission oriented operational needs in a prescribed operating
environment with a specified outcome and probability of success. To help us
understand the rationale for this definition, let’s examine each part in
detail.
Some systems require
the analysis, design, and development of specialized structures,
complex interactions,
and performance monitoring that may have an impact on the safety, health, and
well-being of the public as well as the environment, engineering of systems may
be required. As we investigate WHAT is required to analyze, design, and develop
both types of systems, we will find that they both share a common set concepts,
principles, and practices. Business systems, for example, may
require application of
various analytically and mathematical principles to develop business models and
performance models to
determine profitability and return on investment (ROI) and statistical theory
for optimal waiting line or weather conditions, for example. In the case of
highly complex systems, analytical, mathematical, and scientific
principles may have to be applied. We refer to this as the engineering
of systems, which may require a mixture of engineering disciplines such as
system engineering, electrical engineering, mechanical
engineering, and
software engineering.
2.
Explain the guiding principles that govern system acceptability.
Principle System
acceptability is determined user satisfaction; user satisfaction is determined
by five User criteria:
1. Provide value –
meaning operational utility.
2. Fit within the
user’s system and mission applications – meaning
operational
suitability.
3. Be available to
conduct missions – meaning operational availability.
4. Accomplish
performance objectives – meaning operational
effectiveness.
5. Be affordable –
meaning cost effectiveness.
Principle Despite the
most technically innovative and elegant SE design
solutions, Users’
perceptions of a system, product, or service constitute
reality.
3.
Explain the types of behavior patterns emerge when systems interact with their
.
When systems interact
with their OPERATING ENVIRONMENT, two types
of behavior patterns
emerge:
1. Systems interact
with or respond to the dynamics in their OPERATING ENVIRONMENT. These
interactions reflect peer-to-peer role-based behavioral patterns such as
aggressor, predator, benign, and defender or combinations of these.
2. System Responses –
behavior, products, by-products, or services – and
internal failures
sometime result in adverse or catastrophic effects to the
system – creating
instability, damage, degraded performance, for example – that may place the
system’s mission or survival at risk.
When we analyze
interactions of a SYSTEM OF INTEREST (SOI) with its OPERATING ENVIRONMENT, two
fundamental types of behavior emerge :
1. Hierarchical
interactions (i.e., vertical interactions under the command and control of
higher order systems).
2. Peer level
interactions.]
We characterize SOI
interactions with its OPERATING ENVIRONMENT to include two types of entities:
1) HIGHER ORDER
SYSTEMS and
2) a PHYSICAL
ENVIRONMENT.
The identification of
OPERATING ENVIRONMENT domains enables us to expand the System Architecture
construct. Most engineering environments establish standards and conventions
for interpretive reading. For example, graphics read from left to right and
from top to bottom. The convention is that data processing and work flow
progress from left to right. If we had placed the SOI on the left side and the
OPERATING ENVIRONMENT on the right side, this would have created a false perception
that the SOI drives its OPERATING ENVIRONMENT.
4.
What do you understand from Organizational Aspects of system Life Cycles?
Each system product
or service is an asset of a higher level organization that also has a system
life cycle. Those same systems and products may include lower level systems or products that also
have system life cycles. Therefore we have multiple levels of system life
cycles within higher level system life cycles.If we examine the system life
cycle of Organizational Entity 2, we might find that the organization evolves
through several lines of business (LOBs) LOB 1, LOB 2, and so on. Within each
LOB, the organization has a core product line that consists of Product Model 1,
which evolves into Product Model 2, and so forth. Observe the overlapping of
Product 1 and Product 2 life cycles.
Application of System Life Cycles
We can apply the
concept of system life cycles within system life cycles to an example such as
small engine developer. The organization, which has a life cycle, may evolve
through a number of organizational life cycles as small business, corporation,
and so on. During Organizational Life Cycle 2
the organization may develop several LOBs two-cycle engines, four-cycle
engines, and so on – to support marketplace opportunities such as lawn mowers,
edger’s, and small tractors The organization's four cycle LOB may evolve
through Product Model 1, Product Model 2, and so forth. Each product model
builds on its predecessor
The preceding
discussion focused on a system or product suppliers system life cycles. The
same analogy applies to users of system, product, and services. Their
organizations evolve through similar life cycles.
5. Create your own definitions
of a system. Based on the “system” definitions.
a.
Identify your viewpoint of shortcomings in the definitions.
b.
Provide rationale as to why you believe that your definition overcomes those
shortcomings.
c. From an historical
perspective, identify three precedented systems that were replaced by
unprecedented systems.
A system is a set of
interacting or interdependent components forming an integrated whole[1] or a
set of elements (often called 'components' ) and relationships which are
different from relationships of the set or its elements to other elements or
sets.[citation needed] Fields that study the general properties of systems
include systems science, systems theory, systems engineering, cybernetics,
dynamical systems, thermodynamics, and complex systems. They investigate the
abstract properties of systems' matter and organization, looking for concepts
and principles that are independent of domain, substance, type, or temporal
scale.[citation needed] Some systems share common characteristics,
including:[citation needed] A system has structure, it contains parts (or
components) that are directly or indirectly related to each other; A system has
behavior, it contains processes that transform inputs into outputs (material,
energy or data); A system has inter connectivity the parts and processes are
connected by structural and/or behavioral relationships. A system's structure
and behavior may be decomposed via subsystems and sub-processes to elementary
parts and process steps. The term system may also refer to a set of rules that
governs structure and/or behavior. Alternatively, and usually in the context of
complex social systems, the term institution is used to describe the set of
rules that govern structure and/or behavior.
6.
State all the system decomposition and integration design guidelines.
System structures are
viewed from two SE perspectives:
1. Analytically, as a
top-down, hierarchical decomposition or expansion.
2. Physically, as
bottom-up, vertically integrated sets of entities.
3. System composition
entity relationships (ERs) enable us to analytically
decompose
hierarchical systems into manageable design levels of
complexity. Figure
9.4 provides a framework for the rules stated in
Table
|
Level or
Tier
|
Nomenclature
(Optional)
|
Scoping
Definition
|
|
0
|
User’s
SYSTEM Level
|
A level of abstraction that represents the User’s
business environment with your SYTEM OF INTEREST (SOI) as an embedded
element. We refer to this as the Level 0 or Tier 0 system.
|
|
1
|
SYSTEM Level
|
A level of abstraction that describes on the top-level
representation of your SOI from the organization’s
(observer’s) frame of reference. Architectural representations (i.e., an
architectural block diagram,
ABD) of the SYSTEM level include the SOI boundaries,
interfaces to external systems in the operating environment, and embedded
SEGMENT level entities (if applicable) or PRODUCT level entities and their
interfaces. This level of abstraction is referred to as a
Level 1 or Tier 1 system.
|
|
2
|
SEGMENT
Level
(optional)
|
Refers to system entities at the first level of
decomposition below
the SYSTEM level. Each instance of a SEGMENT level
entity is
referred to as a Level 2 or Tier 2 system.
An architectural representation of a SEGMENT level
entity
includes:
1. Level 3 or Tier 3 PRODUCTS and lower level entities.
2. Their internal PRODUCT level relationships.
3. The SEGMENT’s relationships with external entities
within the
SYSTEM
(i.e., with other SEGMENTS) and external systems beyond
the
SYSTEM’s boundaries, as applicable. Consider the
following
example:
EXAMPLE: A communications SYSTEM might consist of
landbased,
sea-based, air-based, and space-based SEGMENTS.
|
|
3
|
PRODUCT
Level
(optional)
|
Refers to system entities at the first level of decomposition
below
the SEGMENT level. Each instance of a PRODUCT Level
entity is
referred to as a Level 3 or Tier 3 system.
An architectural representation of a PRODUCT level
entity
includes:
1. Level 4 or Tier 4 SUBSYSTEMS and lower level
entities.
2. Their internal SUBSYSTEM level entity relationships.
3. The PRODUCT’s relationships with external entities
within the
SYSTEM
(i.e., with other PRODUCTS) and external systems beyond
the
SYSTEM’s boundaries, as applicable.
|
|
4
|
SUBSYSTEM
Level
|
Refers to system entities at the first level of
decomposition below
the PRODUCT Level. Each instance of a SUBSYSTEM level
entity is referred to as a Level 4 or Tier 4 system.
An architectural representation of a SUBSYSTEM level
entity
includes:
1. Level 5 or Tier 5 ASSEMBLIES and lower level
entities.
2. Their internal ASSEMBLY level entity relationships.
3. The SUBSYSTEM’s relationships with external entities
within
the SYSTEM (i.e., with other SUBSYSTEMS) or external
systems beyond the SYSTEM’s boundaries, as applicable.
|
|
5
|
ASSEMBLY
Level
|
Refers to system entities at the first level of
decomposition below
the SUBSYSTEM level. Each instance of an ASSEMBLY level
entity is referred to as a Level 5 or Tier 5 system.
An architectural representation of an ASSEMBLY level
entity
includes:
Scoping Definition
1. Level 6 or Tier 6 COMPONENTS and lower level
entities.
2. Their internal SUBASSEMBLY level entity
relationships.
3. The ASSEMBLY’s relationships with external entities
within the
SYSTEM (i.e., with other ASSEMBLIES) or external
systems
beyond the SYSTEM’s boundaries, as applicable.
|
|
6
|
SUBASSEMBLY
Level
|
Refers to system entities at the first level of
decomposition below
the ASSEMBLY level. Each instance of a SUBASSEMBLY
level
entity is referred to as a Level 6 or Tier 6 system.
Architectural representation of a SUBASSEMBLY Level
entity
includes:
1. Level 7 or Tier 7 PARTS.
2. Their internal PART level entity relationships.
3. The SUBASSEMBLY’s relationships with external
entities within
the SYSTEM (i.e., with other SUBASSEMBLIES) or external
systems beyond the SYSTEM’s boundaries, as applicable.
|
|
7
|
PART Level
|
Refers to the lowest level decompositional element of a
system.
An architectural representation of a PART includes form
factor
envelope
drawings, schematics, and models.
Engineering drawings, which are produced at all
system levels of abstraction, consist of two basic
types:
1. Dimensional drawings or schematics for internally
developed or
externally procured and modified internally items.
2. Source control drawings that bound part parameters
and
characteristics for externally procured parts.
For software systems, the PART level equates to a
source line of
code (SLOC).
|
7.
Identify three types of systems or system upgrades that may be ideal candidates
for a Waterfall Development Model strategy.
1.rainfall
2.ground waterfall
3.drought
The Waterfall
Development Model represents one of the initial attempts to
characterize software
development in terms of a model. Today, the Waterfall Model exemplifies how
many organizations develop systems and products. The term “waterfall” has
always been a misnomer and tends to confuse many people. The term reflects the
graphical top-down, diagonal representation rather than the actual
implementation. As we will see in a later Unit, the earlier stages do represent
expansion of levels of design detail over time. Unlike the Waterfall Model, the
V-Model is implemented with highly iterative and recursive feedback loops
within and between levels of abstraction. In the Waterfall approach,
“development activities are performed in sequential order, with possibly minor
overlap, and minimal or no iteration between activities. User needs are determined,
requirements are defined, and the full system is designed, built, and tested
for ultimate delivery at one point in time. Some people refer to this as a
stage-wise model.”
8.
List all the steps involved in mission analysis.
Organizational and
system missions range from simple tasks such as writing
a letter to
performing highly complex International Space Station (ISS)
operations, managing
a government. Regardless of application, mission
analysis requires
consideration of the steps specified below:
Step 1: Define the
Primary Mission Objective(s)
Step 2: Develop a
Mission Strategy
Step 3: Define
Phase-Based Operations and Tasks
Step 4: Create a
Mission Event Timeline (MET)
Step 5: Bound and
Specify the Mission OPERATING ENVIRONMENT Interactions
Step 6: Identify
Outcome-Based System Responses
Step 7: Identify
Mission Resources and Sustainment Methods
Step 8: Perform a
Mission Task Analysis
Step 9: Assess and
Mitigate Mission and System Risk
9.
Identify three types of systems or system upgrades that may be an ideal
candidates for a Spiral Development Model strategy.
Some systems require
the analysis, design, and development of specialized structures, complex
interactions, and performance monitoring that may have an impact on the safety,
health, and well-being of the public as well as the environment, engineering of
systems may be required. As you investigate WHAT is required to analyze,
design, and develop both types of systems, you will find that they both share a
common set concepts, principles, and practices. Business systems, for example,
may require application of various analytical and mathematical principles to
develop business models and performance models to determine profitability and
return on investment (ROI) and statistical theory for optimal waiting line or
weather conditions, for example. In the case of highly complex systems,
analytical, mathematical, and scientific principles may have to be applied. We
refer to this as the engineering of systems, which may require a mixture of
engineering disciplines such as system engineering, electrical engineering,
mechanical
engineering, and
software engineering. These disciplines may only be required at various stages
during the analysis, design, and development of a system, product, or service. This
text provides the concepts, principles, and practices that apply to the
analysis, design, and
development of both types of systems. On the surface
these two categories
imply a clear distinction between those that require
engineering and those
that do not.
10.
Explain in brief the four primary system development models.
1. The
Waterfall Development Model
The term “waterfall”
has always been a misnomer and tends to
confuse many people.
The term reflects the graphical top-down, diagonal
representation rather
than the actual implementation. As we will see in a
later Unit, the
earlier stages do represent expansion of levels of design
detail over time.
Unlike the Waterfall Model, the V-Model is implemented
with highly iterative
and recursive feedback loops within and between levels
of abstraction.
2.
The Evolutionary
Development Model
In general, the
Evolutionary Development Model is based on the premise
that “stages consist
of expanding increments of an operational software
product, with the
directions of evolution being determined by operational
experience.” (Source:
Boehm, p. 63) This conception is based on an
evolutionary strategy
of a system or product development through a series
of pre-planned
product improvement (P3I) releases.
3.
The Spiral
Development Model
Spiral development
employs a series of highly iterative development
activities whereby
the deliverable end product of each activity may not be
the deliverable
system. Instead, the evolving set of knowledge and
subsequent system
requirements that lead to development of a deliverable
system contribute to
the maturing design solution.
4.
The Incremental
Development Model
The incremental
approach determines user needs and defines the
overall architecture,
but then delivers the system in a series of increments –
i.e., software
builds. The first build incorporates a part of the total planned
capabilities, the
next build adds more capabilities, and so on, until the entire
system is complete.”
(Source: Glossary: Defense Acquisition Acronyms and
Terms)
and B = 
= 
y-
z = 
........(1)
........(1)
for the data 
are
=na + b
+ c
Xy = a
+c
8.9
3 = 100
354
21.1