Lecture 1.

1
System Boundary
Definition
A system boundary defined by those relationships which relate to membership of the system
The setting of a boundary and hence the identification of a system is ultimately the choice of the
observer .…
any particular identification of a system is a human construct used to help make better sense of a
set of things and to share that understanding with others if needed (SEBOK Part 2)

Closed Systems encloses all aspects of the system exist within this boundary
o no interactions with its environment
o useful for work with abstract systems and for some theoretical system descriptions

Open Systems comprises systems elements and relationships which can be considered part of the
system, and those which describe the interactions across the boundary between system
elements and elements in the environment
o system exchanges inputs and outputs with its environment

1
(Ref: 1968, von Bertalanfly (1968) General System theory: Foundations, Development, Applications, New York: George Braziller) © LGChan
 Lecture 1.1
System Environment
Definition
Anything affecting a subject system or affected by a subject system through interactions with it, or
anything sharing an interpretation of interactions with a subject system (IEEE 1175.1-2002
(R2007), 3.6)
The surroundings (natural or man‐made) in which the system‐of-interest is utilized and supported;
or in which the system is being developed, produced or retired (INCOSE 2010)

System Environment is the space, beyond the system boundary, which interacts with the system
of interest
o Immediate Environment: intended effect of the planned system
o Potential Environment: o likely impact of the planned system
Unknown Environment: unintended side effects of the system

9
© LGChan
 Lecture 1.1
System Elements Interactions
Interaction of various elements (materials, energy, data, signals, procedures) will produce new
behavior of a system (emergent behavior)
When certain elements are missing in the system, these elements can be inputted from outside
Example:
o Energy is required to operate a system
o Input data information to software systems

Definition
Process is work performed on, or in response to, incoming information or changing conditions
o Process is a system interaction
o “Work Done”

Function is a process that transforms inputs into outputs

o Function is a system behavior
o A system may have more than one function depending on the input
o “Ability to Do Work”
3
© LGChan
 Lecture 1.1
Interactions of a System
Two Types of Interactions

Internal Interactions within the System of Interest

These are Processes performed among system elements which are governed by properties of
system elements (natural or man-made)

External Interactions with the System Environment

These are inputs or outputs at the system interfaces located at the system boundary

Interactions produce emergent properties and new behavior of a System

System Functions are normally seen as external behavior of a System

System Processes are internal transformation inside a System

4
© LGChan
 Lecture 1.1
System of Systems (SoS)
Definition
A SoS is an integration of a number of constituent systems which are
independent and operatable, and which are networked together for a period
of time to achieve a certain higher goal (SEBoK)

A SoS is a system-of-interest whose elements are managerially and/or

operationally independent systems. These interoperating and/or integrated
collections of systems produce results unachievable by the individual systems
alone (INCOSE Handbook)

A SoS is a set or arrangement of systems that results when independent and

useful systems are integrated into a larger system that delivers unique
capabilities (US Department of Defense)
5
© LGChan
 Lecture 1.1
Systems Interfaces
Interfaces are the points of contact between interacting system elements and other subsystems
(internal interface) or the environment (external interface) at the system boundaries

o Interfaces embed functions of component parts or subcomponents at the systems boundary

o An Interface can be physical object (eg USB connector) or
a functional link (eg software layer function in Application Programming Interface, API)

o Importance of Systems Interfaces

– hide the complexity of the systems of interest, its systems elements, and interactions of elements
– defines system of interest at its boundary
– specification key to assembly/integration/checkout, maintainability, product evolution and
adaptability
– potential area of design uncertainty because it depends on the definition of system of interest,
boundary and environment

6
© LGChan
 Lecture 1.1
Engineering Systems
Definition
An open complex system of technical or socio-technical elements that exhibit emergent
properties not exhibited by the individual system elements (SEBoK)

A class of systems characterized by a high degree of technical complexity, social intricacy, and
elaborate processes, aimed at fulfilling important functions in society (de Weck)

Properties of Engineering Systems:

o complex and large scale systems
o created by and for people (artificial)
o having a purpose with multiple views
o satisfying key stakeholders value propositions (requirements)
o having a life cycle and evolution dynamics
o having a boundary and an external environment
o being a part of a system-of-interest hierarchy

7
Ref: de Weck 2011 Engineering Systems-Meeting Human Needs in a Complex Technological World Cambridge MA MIT Press © LGChan
 Lecture 1.2
Systems Architecture vs System Engineering
Difference between Systems Architecting and System Engineering

Systems Architecture is a complex process of creating and building systems

architecture which takes into the viewpoints of various stakeholders, both
technical and social, under constraints imposed by the defined boundary of the
system
An Overall Process

Systems Engineering is the application of scientific and mathematical principles

to the design, manufacture, and operation of efficient and economical
combinations of interacting elements that accomplish a defined objective
A Specialised Process

10
Optional Video: Systems Engineer vs System Architect https://www.youtube.com/watch?v=wWnESjf4ajQ © LGChan
 Lecture 1.3
Heuristics
What are the qualities of Heuristics?
o It is informal or pragmatic approach based on experience and learned knowledge
o It must make sense in the original context and beyond (example: wise sayings)
o It is be easily understood and rationalized in a few minutes (think proverbs)

Why use Heuristics ? (Leveraging on Heuristics)

o More efficient because it saves time and cost from experimenting what other people have
done
o Learned from other people successes and mistakes
o Choose from best designs
o Appropriate for socio-technical systems which are complex and cannot be easily modelled
and quantify

6
© LGChan
 Lecture 1.4
What is Systems Dynamics?

System dynamics is an approach to understanding behavior of complex non-linear systems

over time, using feedback loops, time delays, stocks and flows that affect the behavior of the
entire system

Mental models are constructed to represent the causal effect mechanics of the system
behavior in the real world

2
© LGChan
 Lecture 1.4
Feedback in Systems Dynamics
Dynamic equilibrium
The condition in which the state of a stock (its level or its size) is steady and
unchanging, despite inflows and outflows
This is possible only when all inflows equal all outflows

2 Main Type of Feedbacks

Positive Feedback or Reinforcing Feedback loop
It is an amplifying or enhancing feedback loop which further destabilizes the system
It reinforces by itself the direction of change. These are vicious cycles

Negative Feedback or Balancing Feedback loop

It is a stabilizing, goal-seeking, self correcting or regulating feedback loop
It opposes, or reverses, whatever direction of change is imposed on the system

6
© LGChan
 Lecture 1.4
Feedback in Systems Thinking
Systems Thinking employ feedback loops at multiple stages

Feedback is used to ensure that the actual direction corresponds to the desired
direction

Feedback is the starting point of learning process because it provides for the
detection of mistakes
o Without learning, similar mistakes are repeated leading to wasted resources
o With learning, individuals and organizations become more efficient and productive

16
© LGChan
 Lecture 1.4
System Archetypes
System Archetypes are system structures that produce common patterns of
problematic behaviour across many different types of systems

Archetypes are often called “traps” because they’re extremely common, and yet
policymakers struggle to identify them early and deal with them effectively

Question: Name a system thinking approach that employ system archetypes

Answer: Heuristics

17
© LGChan
 Lecture 2.1
What is System Architecture?
A system architecture is analogous to an architectural style in buildings

It consists of a few key features and rules for combining them so that architectural integrity/concept is
preserved

In most system designs, typical architecture patterns are used to produce system architecture
An innovative system will require a new system architecture to be created

A system architecture is determined by:

o A set of element types

o A physical layout of the elements indicating their interrelationships
o A set of constraints surrounded by the environment
o A set of interaction mechanisms

6
© LGChan
 Lecture 2.1
Function
Where does Function come from?
Function is the result of “process interacting with operand”

What is an Operand?
An operand is the object of a process or operation:
“something” on which an operation is performed
An operand is also “one of the inputs (quantities) for an operation”
An operand is a “thing” that is being “acted upon”

What is a Process?
A process is a pattern of activity or transformation that is undergone by operands
This process is allowed when there is an interaction between the elements

12
© LGChan
 Lecture 2.1
Functional Architecture

Functional Architecture
a set of logical activities or functions that are arranged in a specific order and,
when activated, achieves a set of activity (functional) requirements

How do we draw a Functional Architecture?

From Functional Flow Block Diagram (FFBD)
By dividing and allocating the functional requirements into different
sub-functions and modes of operation

24
© LGChan

Form
o Physical or Informational
representation of a system
o Stable and Independent existence
o Form is made up of elements of a
system and there is relationship
between the elements of the system
o Example: structure, module,
component
Lecture 2.1
Function
o An activity, operation, or
transformation of a system
o Contributes to performance of system
o Function is made up of processes
o Function is executed by Form
o Function emerges from interaction of
elements in the system
o Example: behavior, response, output
29
© LGChan
 Lecture 2.1
Mapping Functions to Physical Components
Many to One One to One

Ingredients Pan Kneader Motor Heater Controller Housing

Preparing X X X
Fermentation X X X X X
Kneading 1 X X X X X
Rising X X X
Kneading 2 X X X X X
Baking X X X X
Cooling X X X

Many to Many

36
© LGChan

Systems Interactions and Interfaces
Internal Interactions within the System of Interest These
are Processes performed among system elements
External Interactions with the System Environment
These are Inputs or Outputs at the system interfaces located at the system boundary
Bread Machine
Internal Interactions Ingredients Mixture
Motor and Kneader
Pan and Heater
Controller and Motor and Heater
External Interactions (Input) Ingredients into Pan
User input Controller
External Interactions (Output) Bread out from Pan
Lecture 2.1
Trading Firm (Amazon)
Sales and Warehouse
Warehouse and Account
Account and Purchase
Logistics and Warehouse
Customer to Sales
Supplier to Logistics
Purchase to Supplier
Warehouse to Customer

ALL Interactions take place … at Systems Interfaces

ALL Processes take place ….… inside the Systems
3
© LGChan
 Lecture 2.1
Systems Interfaces
Interfaces are the points of contact between interacting system elements and other subsystems
(internal interface) or environment (external interface) at the system boundaries

o Interfaces embed component parts or subcomponents within the physical architecture

Example Bread Machine : Controller Online Seller (Amazon)

Hide Complexity Sequence of operations
Stabilize System One control for motor and heating
– reduce mistakes
Integration, Design Designer focus on hardware only
Uncertainty Controller may fail
Customer can purchase
easily from overseas
Trading firm takes care of
logistics problem
Trading firm can source from
many suppliers
Uncertainty in supply and
demand

4
© LGChan
 Lecture 2.2
Dependency Structure Matrix
Two Types of DSM
Dependency Structure Matrix (DSM) Component Based
Shows interactions with interfaces between elements in the system

Design Structure Matrix (DSM) Process or Tasks activities

Shows order of processes or tasks in the system operation
Applications
1. To explore the sequence/order of processes and feedback in the Systems
2. To investigate
a) Interaction of System Elements/Subsystems with each other
b) Dependency of Systems Elements/Subsystems among each other
c) Emerging Behaviour of Interacting Processes
(especially in concurrent processes and poorly structured Systems)
3. To design for partitioning and modularization of the Systems

Other Types of DSM

Two Dimension Matrix: Subsystems vs Processes, Subsystems vs Subsystems, Processes vs Processes
Three Dimension Matrix: Subsystems vs Processes vs Subsystems
6
© LGChan
 Lecture 2.2
Logical Architecture

The proper order and arrangement of functions and processes

of operations in Design Structure Matrix creates the
Logical Architecture of the System

Logical Architecture embeds the systematic design of Functional

Architecture and Physical Architecture which makes the System
behave and satisfy User requirements

18
© LGChan
 Lecture 2.2
Interactions 3a – Dependency of Components (Bread Machine)

Ingredients Pan Kneader Controller Motor Heater Housing

Ingredients X X X
Pan 1 X X X X
Kneader 2 1 X X X X
Controller 1 X X X X
Motor 1 1 X X
Heater 3 1 X X
Housing 4 3 3 1 1 X

Scale
1 Very High Dependency with diagonal cells
2 High Dependency with diagonal cells Upper Triangular Matrix is a Inverse of
3 Moderate Dependency with diagonal cells Lower Triangular Matrix
4 Low Dependency with diagonal cells
5 Very Low Dependency with diagonal cells (not shown)

25
© LGChan
 Lecture 2.2
Physical Architecture

The proper order and arrangement of components in

Dependency Structure Matrix creates the
Physical Architecture of the System

Physical Architecture ensures that the interfaces and connections

are in proper locations to allow Logical Architecture to carry out
the functions and processes uninterrupted

27
© LGChan
 Lecture 2.2
Interactions 4 – Clustering and Partition (Bread Machine)
Clustering is the grouping of components in tightly knitted groups
Partitioning is re-arranging components into clusters or modules
Ingredients Pan Kneader Controller Motor Heater Housing
Ingredients X X X

source: dependency of components

Pan X X X X
Kneader X X X X
X X X X
Controller
X X
Motor
X X
Heater
X
Housing
Kneading Module Baking Module

Several components are grouped together as Modules

Each module produce a specific function
o Kneading Module: kneading function
o Baking Module: baking function

Interface between the 2 modules is at Controller Element and Motor Element

Can you find any feedback among the Component Elements in the System? 36
© LGChan
 Lecture 2.3
Abstraction
Definition
Abstraction (or “construct”) is a process by which concepts are derived from the usage and classification of
literal ("real" or "concrete") concepts, first principles, or other methods (Wiki)

Abstraction is a representation in terms of presumed essentials, with a corresponding suppression of the

non-essentials (Rechtin Maier 2009)

Use of Abstraction in Systems Architecting

o Abstraction is used to identify and construct elements and subsystems with the required properties
express through their interfaces
o Abstraction hides the complexity inside a system (from a certain viewpoint) and facilitates the reuse of a
system (from the class and properties)
o Abstraction enables designers of a system to think at a higher level
o designers do not have to deal with a lot of complex details
o designers can focus on overall architecture and spend more time in producing better designs

3
© LGChan
 Lecture 2.3
Views and Viewpoints
A View is a description of the entire system from the perspective of a set of related concerns (IEEE 1471-
2000)

A view
o a representative model which share the attributes, properties that are relevant to the same concerns of
the client
o technical (engineering), functional (capability), operational (process), strategic (business), etc.

A Viewpoint is template, pattern, or specification for constructing a view

The purpose of views and viewpoints is to enable engineers to

o comprehend very complex systems by making it simply to understand
o organize the elements of the problem
o Identify and solve problems around domains of expertise and to separate concerns

9
© LGChan
 Lecture 2.3
Partitioning

Partitioning is to divide the Systems into Sub-Systems (or Clusters or

Modules) of specific interests
(eg functions, properties, location, etc) for strategic design and analysis

Two general methods of partitioning:

Decomposition Layering
14
© LGChan
 Lecture 2.3
Partitioning - Decomposition
Decomposition is a process to separate into component parts or elements
into simpler compounds (usually called modules).
Decomposition break down the complexity of the subsystem in the module

Each Module has specific functions or relationships or physical properties

(that is, each module has certain common properties as determined by the
system designer)

Each level of abstraction reveals more details (more abstract) or less details
(less abstract) about the overall systems

Decomposition is commonly used in product architecture

(example: modular design)
15
© LGChan
 Lecture 2.3
Partitioning - Layering
Layering is a specific form of partitioning by using Point of Views

Layering helps to keep the architecture with functions or behaviour

which are focused to satisfy the user requirements at each layer
(that is, each layer addresses a particular point of view to satisfy a user specific
requirement)

Layering is commonly used in

o software programming
(example: middleware, user interface, office applications)
o computer systems
(example: kernel, operating systems, storage, network)
17
© LGChan
 Lecture 2.3
How to Partition – General Approach
Identify Specific Functions or Relationships
Search for system elements or technologies able to perform
functions and physical interfaces to carry input-output and control
flows

1. Partition using Same Criteria of Functional Elements

Partition (functions, scenarios, input-outputs, signals, etc) into clusters,
modules or sub-systems using the given criteria and allocate partitioned sets
to system elements

2. Partition to Facilitate Production And Testing

Sub-systems should be independent as possible for production and testing

3. Partition for Minimal Interface Contact

Use a configuration which minimizes communications

20
© LGChan
 Lecture 2.3
Systems Architecting – Modeling
System Architecting is the process of defining the Systems Architecture
It converts abstract ideas, visions, and concepts into physical, functional, or behavioral realization

Definition
A model is an approximation, representation, or idealization of selected aspects of the structure,
behavior, operation, or other characteristics of a real-world process, concept, or system (IEEE
610.12-1990)

Modeling is the creation of abstractions or representations of the system to predict and analyze
performances, costs, schedules, and risks and to provide guidelines for systems research,
development, design, manufacture, and management

What is a Reductionist Model?

A reductionist model describes a system by describing its parts and their interactions
It uses an analogy between the components of the model and the components of the system,
and describes how the system functions based on the interaction of its elements
23
© LGChan
 Lecture 3.1
Scope of Activities in Creating Systems Architecture
1. Elicitation from Stakeholders
Define the architecture purpose, value, constraints, and decisions it will
support
2. Needs and Requirements
Obtain system requirements in order to define and identify architectural
viewpoints
3. CONOPS
Create the Concept of Operations
4. Viewpoints
Identify upstream and downstream views of stakeholders
5. Functional Analysis
Logical sequencing/interaction of functions or logical elements
6. Partitioning
Determine functions and decompose/layer into models and subsystems
7. Functional Allocation
Allocate functionality to models, interfaces, subsystems
Mapping and allocating physical architecture to functional architecture
using specifications in technical architecture
33
© LGChan
 Lecture 3.1
Scope of Activities in Creating Systems Architecture
8. Architecture Creation
Analyze and Evaluate the Architecture
9. Iteration
Refine, update and evaluate alternative design solutions in an iterative
way throughout various viewpoints
10. Integration
Integrate the selected architectural solutions (architecture descriptions)
into an architecture framework
11. Architecture Description
Document and Maintain the Architecture
12. Technical Performance Measures
Ensure system integrity and consistently during implementation and
quality of the system to be delivered
13. Validation and Verification
Establish traceability between requirements and system elements
Ensure solution meets client requirements

34
© LGChan
 Lecture 3.1
Needs and Requirements
Needs and Requirement
Requirements provide an overall view of the purpose and mission of the system

Two Types of Requirements

a) Stakeholders requirements and business or mission requirements
b) System requirements, which describe the functions which the system as a whole
should fulfill in order to satisfy the stakeholder requirements and are expressed in an
appropriate set of viewpoints, and non-functional requirements expressing the
required levels of safety, security, reliability, etc.

Viewpoints
o Use appropriate architecture views for various stakeholders in creating systems
architecture because their requirements and needs may be different

Classification of Needs - MOSCOW How to translate

oMust Have o requirements to functions?

Should Have o
Could Have
o Would Not Have

35
© LGChan
 Lecture 3.1
Establishing Goals with Problem Statement
Problem Statement
Problem statement defines the boundary and clarifies the requirements of the systems

To … [achieve a solution goal] …

By …. [performing a function}
Using … [a form]
Example: To [solve traffic congestion] by [limiting number of cars] using [COE pricing]

The problem statement is revised several times to make requirements and goals clearer

Problem
Statement
Elicitation
Requirements
Identify
Requirements and
Goals
Requirements
Analysis Systems
Architecture 36
© LGChan
 Lecture 3.1
Functional Analysis

Functional analysis is the systematic process of identifying, describing, and

relating the functions a system must perform in order to be successful

Functional Analysis Tools

o Functional Analysis System Technique (FAST)
o Visual layout (Tree Diagram) of a Product Functions
o Starts with the Basic Function, and builds to the right with supporting or
Secondary Functions
o Functional Flow Block Diagrams (FFBDs)
o Use to show the sequence of all functions to be accomplished by a system

37
© LGChan
 Lecture 3.1
Functional Allocation
Functional Allocation
o Assignment or matching of functions in functional architecture to components (physical or
process) in physical architecture to enable the transformation of input to output
o Mapping of functional architecture with physical architecture is made possible with technical
architecture (based on technical specifications)

Mapping Functional Architecture with Physical Architecture

o Identify Relationships of properties of components with functions
o Match of interfaces based on relationships between functional architecture and physical
architecture
o Use specifications and standards with well documented interface properties
Function 1 System 1

Function 2 Subsystem 2
Functional A Physical Ar
Architecture rchitecture
Component 3
Function 3

Component 4 22
© LGChan
 Lecture 3.1
Operational Feasibility

Systems will perform in operation as intended in an

effective and efficient manner in response to the
stakeholders requirements and usage

Requirements for feasibility are expressed in a number of

“ilities” that often showed up after a system has been put
to its initial use

33
(Ref: de Weck 2011 Engineering Systems-Meeting Human Needs in a Complex Technological World Cambridge MA MIT Press) © LGChan
 Lecture 3.1
Good Operational Architecture 1

Loose Coupling between Systems

o Systems can be altered without the changes necessarily affecting other functions
Example: plug and play, where systems are so independent that they can be changed without
affecting the overall system behaviour
o Optimal coupling reduces the interfaces of modules and the resulting complexity of the
system

Tight Cohesion within Modules

o A module with high degree of cohesion is preferred because it has simple interfaces and less
complex architecture structure
o It is easier to isolate problems and make maintenance simple
Example: a module that performs a single function (one-to-one functions) has a high cohesion,
whereas a low cohesion module (one-to-many functions) which perform multiple tasks makes
repair more difficult because of interactions between sub-systems

40
© LGChan
 Lecture 3.1
Good Operational Architecture 2

Modularity of components
o Systems boundaries are aligned to generic functionality, commercial standards and market-
leading component systems wherever possible
o Makes individual systems easier to build and maintain, encourages interoperability and eases
the difficulty of modifying parts
Example: using a common Technical Reference Model for design

Partitioning (Decomposition)
o Separate architecture between more volatile fast-moving system elements (uncertain) and
more stable and long-lasting ones (typically infrastructure)
Example of IT: procuring communications and common support as a service, while allowing
more agile and hands-on approaches at the applications levels
Example of Physical Systems such as aircraft and cars: design physical platform in such a way
as to allow incorporation of multiple generations of electronic and computing subsystems
over system or product lifetime. This allows adaption to later changes in context of use.
41
© LGChan
 Lecture 3.1
Good Operational Architecture 3

Composability Design
o Allowing systems to be put together in the most number of operational configurations, largely
as a response to future uncertainty
Example: planning for flexibility in performance of systems in a number of possible missions
and technical configurations at design stage

Interfaces
o These must be identified and agreed – technically and contractually – and rigorously tested

Documentation
o Record systems architecture and re-use successful design patterns for future designs

42
© LGChan
 Lecture 3.2
Hatley-Pirbhai (H/P) Method
H/P integrated modelling method is a tool for creating systems architecture
It can link both hardware and software systems in the systems architecting
It is used in a real time, reactive system which senses and reacts to events in the physical world
Applications: automobile, military avionics, manufacturing robots, vending machines

H/P method defines a system through two primary models:

o behavioral model (Requirements Model)
o model of form (Architecture Model)

Ref: Hatley D, Pirbhai, I (1988) Strategies for Real Time System Specification. Dorset House, New York 7
Ref: Hatley D, Hruschka, Pirbhai (2000) Process for System Architecture and Requirements Engineering. Dorset House, New York © LGChan
 Lecture 3.2
Architectural Framework
Architecture Framework
o set of standards that prescribes a structured approach, products, and principles for developing a
system architecture
o reference model to organize the various elements of the architecture of a system into
complementary and consistent predefined views allowing to cover all the scope of Systems
Architecture (SEBOK Part 3)
o established common practice for creating, interpreting, analyzing and using architecture
descriptions within a particular domain of application or stakeholder community (ISO/IEC/IEEE
42010 Conceptual Model of Architecture Description)
o skeletal structure that defines suggested architectural artifacts, describes how those artefacts are
related to each other, and provides generic definitions for what those artefacts might look like

Examples of Common Architectural Frameworks

o Defence Framework: US DoD Architecture Framework (DoDAF), United Kingdom’s Ministry of
Defence Architecture Framework (MODAF)
o Non-Defence Framework: The Open Group Architecture Framework (TOGAF), Zachman
Framework

18
© LGChan
 Lecture 3.2
Architectural Description
Definition
Architecture Description refers to artifacts (things) used to express and
document the reasoning, procurement, development, construction, and
operation of architectures
An architectural description can be a physical model, written report, data flow
block diagram, or set of procedures

23
(Source: HP -Sections of an architecture document) © LGChan
 Lecture 6.1
Three Types of Complexity
Structural Complexity
Structural complexity looks at how many different ways system elements can be combined and their relationships
It is related to the potential for the system to adapt to external needs

Dynamic Complexity
Dynamic Complexity has a time element in the system which can be observed when system is used to perform
particular tasks in an environment
The ways in which systems interact in the short term is directly related to system behaviour,
the longer term effects of using systems in an environment is related to system evolution.

Socio-Political Complexity
Socio-political Complexity considers the effect of individuals or groups of people on complexity
People-related complexity has two aspects:
o perception of a situation as complex or not, due to multiple stakeholder viewpoints within a system context
and social or cultural biases which increases complexity
o “irrational” behavior of an individual or the swarm behavior of many people behaving individually in ways
that make sense
Emergent behaviour is unpredicted and counterproductive

46
Source: SEBOK
© LGChan
 Emergence
Emergence is the phenomenon where a non predetermined outcome, such as a structure or a state, is
reached progressively following multiple self-organisation acts of the system

https://www.youtube.com/watch?v=16W7c0mb-rE 13
© LGChan
 Lecture 6.2
What is Self Organized Criticality?

Self Organized Criticality (SOC)

Self-organized criticality is the tendency of some systems to evolve toward, and stay in,
a critical state, and stays there, without external control

SOC is caused by an abrupt disturbance in a system around an attractor which results

from a build-up of events without external stimuli
SOC is typically observed in slowly driven non-equilibrium dynamic systems with
many extended degrees of freedom and a high level of nonlinearity

34
© LGChan
 Lecture 6.3
Properties of Complex Adaptive Systems

1. Decentralization
2. Non-Linearities
3. Emergent phenomena
4. Competition and Co-Operation
5. Adaptation
6. Specialization and Modularity
7. Many Interacting Parts
8. Dynamic Change

4
© LGChan
 Lecture 6.3
Complexity Issues

Complex behaviour originates from the operation of simple underlying rules (Simon’s conjecture)
Sometimes, deducing behaviour from rules is not possible
There is no practical way to study the network of causality in detail
Therefore, we need ways to synthesize understanding from large state spaces and multidimensional
meshes

Common Approach
Simplify, or reduce, the subjective complexity so that the problem and the system are understandable
1. Identify the kinds of complexity of the system and its environment
2. Create appropriate new ways to think about complexity that are appropriate for the solution methods
Evolve and publicize solution methods to deal with different types of complexity in different situations

16
© LGChan
 Lecture 6.4
Approaches to Managing Engineering Complexity

Architecture Solution and Design Model

Complexity in Complexity in Complexity in System Complexity in System

Environment Problem/Mission Design and Development Deployment and
Operation
Include both positive Use solution elements Emphasize selection of
and negative feedbacks which are adaptable robust and adaptive Use self-organizing and
to compensate for non- and reconfigurable elements and self-repairing elements
linearities and runaway structures over
system behaviour Design to achieve optimizing to meet Model the cost of
scenarios rather than current requirements change, benefits, and
requirements balance
Satisfice at system level

17
© LGChan
 Lecture 7.1
Three Types of Modularity 1
1 Modularity in Use
o User can combine several functions or physical objects and use them,
choose them when buying, or upgrade them together

o Modularity in use is associated with two effects:

– User Level: it allows for customization, that is, users can mix and match independent
elements to establish a final product that matches their particular preferences
(example: accessories in cameras, Swiss Army knife)
– Organizations Level: modularity increases innovation, it allows manufacturers to
experiment independently with new products and concepts, as long as these conform to
established standards
(example: modular platform design)

52
Ref: Baldwin, Carliss ; Clark, K (2000) Design Rules Cambridge Mass. MIT Press © LGChan
 Lecture 7.1
Three Types of Modularity 2
2 Modularity in Design
o Designer can design each function separately and place in one physical object, or
several functions and their objects are combined and designed together
Example: a system is decomposed into subsystems or modules using design rules
created by the designer
o Standardization is the result of designs come into common use, and there is no further
change in the design
Example: camera lens and flash mount are designed to specifications

3 Modularity in Production
o Manufacturer can assemble a group of functions or physical objects or buy these as a package
o Example in manufacturing:
Complex products are divided into production process using separate process modules
(example: assembly line for mass production, Intel chip fabrication plant)
Modules can be outsourced to other suppliers for production when they can be specified
precisely

53
Ref: Baldwin, Carliss ; Clark, K (2000) Design Rules Cambridge Mass. MIT Press © LGChan
 Lecture 7.1
Two Types of Product Architectures
Modular Product Architecture
o Functional partitioning into discrete, scalable, reusable modules consisting of isolated, self-
contained functional elements
o Rigorous use of well-defined modular interfaces, including descriptions of module
functionality
o Ease of change to achieve technology transparency and, to the extent possible, make use of
industry standards for key interfaces
o Modular architecture sub optimize performance and increases costs because of redundancy
o Capability to assemble modules

Integral Product Architecture

o Functional elements are interconnected by multiple chunks, or a chunk may implement
many functions
o Interactions between chunks (sub-modules) are poorly defined (no clear divisions exist
between components)
o Integral architecture generally increases performance and reduces costs for any specific
product model
o Capability to integrate components

54
© LGChan
 Lecture 7.1
Advantages and Disadvantages of Modular Architecture
Advantages Disadvantages

o Facilitates product change and product o Easier to reverse engineer

variety o Modular products tend to sub-optimal
– modules can easily be upgraded, o Design costs are higher
degraded, and added-on
o Reduced performance
– modules can easily be reused or replaced
o Decoupled design teams
o Modular products can be quickly
reconfigured to meet changing market o Requires clear definition of interfaces
requirements o Expensive Tooling
o Improves economies of scale through o Longer planning/lead time
component and module sharing across o Redundancy in design
products (economies of scope)
o Increased flexibility
o Independent testing
o Mass production and Outsourcing

55
© LGChan

Advantages and Disadvantages of Integral Architecture
Advantages
o Facilitates the optimization of holistic
performance characteristics and
those that are driven by the size,
shape, and mass of a product
o Minimizes redundancy through
function sharing
o Minimizes number of parts which
must be assembled
Lecture 7.1
Disadvantages
o Difficult to upgrade and reconfigure
o Customized production needed
o Adjusting or “fine-tuning” a single
function can be more complex and
difficult
o Late testing
o Components and modules cannot be
easily replaced if worn or broken
o Tightly coupled design teams
56
© LGChan
 Lecture 7.1
Principles of Good Modular Architecture Design 1

Reduce Coupling (Low or Loose Coupling)

o Coupling is relationship/interaction between modules (externally)
o Design modules so that coupling between them is minimized (minimize interfaces)
o Changes in module changes do not affect other modules
• Reduce dependencies between modules

Tight Cohesion (High Cohesion)

o Cohesion is relationship/interaction within modules (internally)
o Module should encapsulate some well-defined,
high degree of coherent piece of functionality

57
© LGChan
 Lecture 7.1
Principles of Good Modular Architecture Design 2
Explicit Interfaces
o Make all dependencies between modules explicit (no hidden coupling)

Small interfaces
o Keep the interfaces minimal
• Combine many functions into single modules
• Divide large interfaces into several interfaces

Isolate Volatility
o Identify areas of the design subject to uncertain changes and isolate them

Provide for Growth

o Identify certain portions of the design that are likely to expand or progress in a predictable way

Align with Organization Boundaries

o Align the design teams with product architecture to simplify communication during development

58
© LGChan
 Lecture 7.2
Two Types of Platform Strategy
Platform Strategy is a planning approach to maximize product development
and market leverage from common technology

Top-down Strategy Approach (Proactive) Bottom-up Strategy Approach (Reactive)

A company strategically manages and A company redesigns/consolidates a group of
develops a family of products based on a distinct products by standardizing
product platform and its module- and/or components to improve economies of scale
scale-based derivatives and reduce inventory

Example: Example:
power tools (drills), aircraft design, prefabricated houses, semiconductors,
consumer appliances (vacuum cleaners, electronic components
toothbrush), consumer electronics (Ref Works: D. Rosen, S. Kota, K. Ishii, Z. Siddique)
(walkman, cameras)
(Ref Works: K. Otto, K. Ulrich, K. Wood, K. Ishii, M. Tseng)

4
© LGChan
 Lecture 7.2
Platform Planning Process 2
Product Plan
o roadmap: establish which products to offer
over a period of time
o comes from the company’s overall plan
o addresses customer profile and needs

Differentiation Plan Commonality Plan

o specify how products will be differentiated o quantity commonality among products and
by differentiating attributes which components/modules will be shared
o quantifiable differentiable attributes for o estimated cost of developing and producing
comparison each product

10
© LGChan
 Lecture 7.2
Late Point Differentiation Application
How to use Late Point Differentiation?
too early
o Differentiating elements of the product
must be concentrated in one or a few
modules (starting module)
o Product and production process must
be designed so that the differentiating Early Differentiation
modules can be added to the product near
the end of the supply chain
Differentiated Product Feature Option Common Product

Advantages of Late Point

o Reduced inventories
o More easily respond to demand variation
and customer requirements
o Easier to Control Design
o Examples:
packaging colors, Zara, HP printers, Dell
computers
Late Differentiation
22
© LGChan
 Lecture 8.1
System Engineering Waterfall
Process Model
o Sequential Model
o Activities followed each other step by step
o Feedback are adjustment of inputs from a
preceding step to resolve unexpected
problems before proceeding to the
subsequent step
o Similar to system life cycle structure

Waterfall Model Application

orequirements are very well known, clear and fixed
oproduct definition is stable
o technology is understood
o Project is short
o resources and expertise are available freely

62
© LGChan
 Lecture 8.1

Classic Waterfall Intersecting Waterfall

Requirements Requirements Requirements

Design Design Design

Implementation Implementation

Verification Verification Verification

Maintenance Maintenance Maintenance

Product Manufacturing
Development Process

63
© LGChan
 Lecture 8.1
System Engineering “Vee” Process
Model
Feedback

Process flows down with decomposition/

definition
Process flows up with integration/verification
Testing/Feedback at each level

V-shaped model Application

o small to medium sized projects
o requirements are clearly defined and fixed.
o resources and expertise are available freely
Traceability

64
© LGChan
 Lecture 8.1
System Engineering Spiral Process
Model
o Incremental Development Model
o Adaptation of waterfall model
o Risk Driven Approach
o Iterative feedback

Spiral Model Application

o when costs and risk evaluation is important
o medium to high-risk projects
o users are unsure of their needs
o requirements are complex
o new product line
o significant changes are expected

65
© LGChan
 Lecture 8.2
Principle 1 Kaizen
The term Kaizen is derived from two Japanese characters:
改善 kai, meaning “change” and zen meaning “continuous improvement”
Literal translation Kaizen means “good change”

Kaizen is a problem solving process for continuous improvement

A “zero investment cost” improvement requires participation of all affected departments in the
activities to find the most creative solutions for the best improvement for all

Basic principles of Kaizen approach

o Standardizing a process so that it’s repeatable and organized
o Focusing on measurability and evaluating progress using data
o Comparing results against your requirements (did you deliver on your promise?)
o Innovating new and better ways to achieve similar results
o Responding to changing circumstance and evolving your methods over time

19
© LGChan
 Lecture 8.2
PDCA (plan-do-check-act) – Continuous Improvement
PDCA (plan-do-check-act) is an iterative four-step management method used for control and continual
improvement of processes and products
It is also known as the Deming circle/cycle/wheel, the Shewhart cycle, PDSA (plan–do–study–act)
PDCA process is similar to Kaizen process

Plan Create a plan for change, identifying specifically what you want to change
Analyze the situation: Try to understand what the current situation is:
Talk to people. Visit shop floor and observe (Genchi Genbutsu). Collect data.
Define the steps you need to make the change, and predict the results of the change

Do Carry out the plan in a trial or test environment, on a small scale, under controlled conditions
Create a standard, train the workers

Check Examine the results of your trial. Verify that you’ve improved the process
(Study) If you have, consider implementing it on a broader scale
If you haven’t improved the process, go back and try again

Act Implement the changes you’ve verified on a broader scale

Update the standard operating procedures
Congratulate and Celebrate with the team
22
Reference : https://www.allaboutlean.com/pdca/
© LGChan
 Lecture 8.2
Principle 2 Heijunka (平準化) – Production Smoothing
Heijunk is a method used in Just in Time production to smooth the quantity of production
over a fixed period of time

Heijunka is also known in other terms as Production Smoothing, Production Levelling,

Production Balancing and Level Loading

LEVELLING
Smoothing of
Heijunka goals Volume Production
o Stabilizes production volume and variety in an even in order to reduce
Variation
manner during the period
o Ensures high order fulfilment rate of orders
o Reduces the non-value added portion of the process
cycle time (production lead time) Heijunka
o Removes the waste of items in queue and inventory
STANDARDIZING
Reduce the SEQUENCING
Variation in the Mixing types of
way the work is work processes
carried out

28
© LGChan
 Lecture 8.2
Example : Heijunka (平準化) – Production
Smoothing
Example
A factory has a monthly demand of 1400 units Product A and 200 units Product B. Establish a production
schedule for the factory

Establish the daily requirement for each product type

Product A 1400/20 = 70 units (assuming 20 work days)
Product B 200/20 = 10 units
Total daily production = 80 units

Calculate the Build Ratio and production frequency for each type of product
Based on the lowest unit demand of product to be manufactured (this is 10 units of Product B)
Product A 70/10 = 7
Product B 10/10 = 1
Total production frequency = 8

Build production schedule cycle

BAAAAAAABAAAAAAAB (1 unit of Product B to be produced and 7 units of product A)

29
© LGChan
 Lecture 8.2
Principle 3 Standardized Work
Standard work is…
o Foundation of Lean
o Safest, highest quality, and most efficient way known to perform a particular task and process
o The only acceptable way to do the task and process
o Continually improved

Why standard work?

o Focuses on the employee, not the equipment or materials
o Reduces variation, increases consistency
o Improvements will not be sustained without it

3 critical elements in Standard Work

1. Satisfy Customer demand
2. The most efficient work routine (steps)
3. Efficient Cycle times (task and wait time combined)

32
© LGChan

What are Causes of Waste
Mura (inconsistency)
Mura uneven, irregular, erratic,
斑 Inconsistency, variation, inconsistent
unevenness
Lecture 8.3
o Uneven customer demand
o Uneven distribution of work load
o
o
Inconsistent quality of supplies and tools
Irregular schedule of work

o People working too fast or hard to keep up with

Muri (overburden) demand
無理 Muri unreasonable, impossible, o
o
People working long hours to make up for lost time
Running machines too fast to meet production
Overburden or stressing excessive
targets
people, equipment or
o Overloading machines to increase output
system o Skipping maintenance to reduce downtime

Muda (waste)
無駄 Muda futile, useless, pointless o Any activity that does not produce value in the
system
Waste of 7 forms

How to overcome Mura Use Muri to work harder

How to overcome Muri Work smarter not harder 2
Adapted from TUM
 Lecture 8.3
What are the 7 Wastes and How to Eliminate
MUDA (7 Forms)
Waiting (W) Operator waiting (from poor layout of process)
Over Production (O) Producing more than needed. Overproduction causes other wastes, like inventory
Rework/Defects (R) Failure to meet specifications results in rework and scrap
Motion (M) Operator motion that does not add value
Over Processing (O/P) Any process that does not add value
Inventory (I) Inventory waiting anywhere takes up space, costs money, gets damaged
Transport (T) Movement of product between processes. (poor layout of process)

Remember WORMPIT or TIM WOOD

Type 1 muda is non-value added BUT necessary

Transport, Motion, Waiting, Over Processing

Type 2 is non-value added AND unnecessary

Inventory, Defects, Over Production

3
Adapted from TUM
 Lecture 8.3
Key Concepts of Lean Manufacturing

1. Create Continuous Flow in production process

2. Increase Flexibility to meet Customer Demand
3. Eliminate waste through Quality and Quantity Control
4. Pull Production through the Process
5. Continuous Improvement in the System
o Culture
o Continuous Monitoring and Reporting
o Involvement from Everyone

5
© LGChan
 Lecture 8.6
Comparison of Toyota Production System and Lean
Method Toyota Production System Lean (1988)1 Lean (1996)2
Designer Industrial Engineers Mechanical Engineers Social Scientists
Goal Cost Reduction Quality Productivity Maximum Customer Value
Productivity Improvement
Principles Continuous Improvement Continuous Specify Value
Respect for People Improvement Identify Value Stream
Flow, Pull, Perfection

Normal Condition Flow Flow Perfect Processes

Improvement Focus Human Technical Technical
Teaching Method Genba Kaizen Team Leader Classroom
Objective Waste, Unevenness, Inventories Value Creating Activities
Unreasonableness
Desired Outcome Customer Satisfaction Survival Plant High Perfect Value
Performance

1. Lean 1988 Taiichi Ohno. The Toyota Production System. Productivity Press. 1988
2. Lean 1996 Womack, Jones. Lean Thinking. Simon and Schuster. 1996
6
Source: https://bobemiliani.com/comparing-tps-and-lean/ © LGChan

Push vs Pull Systems
Push System
Based on forecasted demand that is completed
and sent to the next work station or in the case
of the final work station is pushed to finished
goods inventory
Push Strategy
production processes with long lead times,
accurate demand forecasts, large number of
products produced on common production
processes, low demand uncertainty, and a
diverse customer base
Push Tools and Techniques Material
Planning and Procurement Material
Resources Planning
Lecture 8.6
Pull System
Based on requirements of subsequent work station:
o Each succeeding workstation pulls (demands) output
from previous workstation as needed
o Next work station determines when and how much
output is requested
o Output from final workstation is pulled by customer
demand or the master production schedule
Pull Strategy
highly repetitive production processes and
well‐defined work flows of standardized items
(need for tighter control of inventory and output
at the work stations)
high demand uncertainty
Pull Tools and Techniques
Shop Floor Scheduling
Just-In-Time/ Kanban / Lean tools 30
© LGChan
 Lecture 8.6
Lean Manufacturing Techniques
In this Section the Slides in this focus on techniques found in Two Pillars of Toyota Production Systems

TPS House
Goal : Highest Quality, Lowest Cost, Shortest Lead Time , Highest Morale
Jikoda
Just-In-Time People and (Autonomation)
Teamwork
Just-In- Continuous Flow
Stop Notify Defects
Self Inspection

Time
Takt Time
Rapid Changeover
Pull System
Continuous
Solving Root Causes
Empowerment Jidoka
Improvement
Production Waste Reduction
Heijunka Standardized Work Kaizan
Stability

Just In Time Techniques Jidoka Techniques

1. Gemba Kanri 1. Autonomation
2. Set-up Time Reduction 2. Fool Proofing – Poka Yoke
3. Pull Scheduling
4. Cellular Manufacturing
5. I,U,S Shaped Material Flow 8
© LGChan
 Lecture 9.1
Little’s Law
Little's Law is a theorem from queuing theory which states that
the average number of customers L in a system (over some interval) is equal to
their average arrival rate R , multiplied by their average time in the system T
John D.C. Little
I = Inventory (MIT) 1954, 1961
R = Throughput rate, or Flow Rate
I=RxT T = Flow Time, time it takes a flow unit to complete a process
note: some texts use T as “lead time” or “cycle time” which is incorrect

Applications
R or TH = throughput (arrival rate)
TH is the velocity or speed of production and is calculated by determining how many items are produced and dividing it by the
length of time it took to produce them

T or CT = cycle time (average time in the system)

CT is the time it takes to complete the production cycle or the average time it takes to produce one unit

I or WIP = work in process (average number of units or customers in a system)

WIP is the number of items currently in production or being serviced in some way

Throughput TH = WIP/CT
Cycle Time CT = WIP/TH
WIP WIP = CT x TH 77
© LGChan
 Lecture 9.1
Example 2: Little’s Law and Bottleneck

Design Dye Fabric Cutting Sewing Shirt

5 min/shirt 4 min/shirt 6 min/shirt

Dye Fabric Cutting Sewing System Capacity

Throughput 5 min/shirt 4 min/shirt 6 min/shirt
Processing Capacity (R) 12 shirts/hr 15 shirts/hr 10 shirts/hr 10 shirts/hr

Average Processing Time, T = 5 + 4 + 6 = 15 minute per shirt = 15/60 = 0.25 shirt/hr

Work in Progress in the System using Little Law, WIP or I = R x T = 10 x 0.25 = 2.5 shirts/hr

This Production Process is uneven because the cycle time of the 3 processes are not synchronize
o Dye Fabric and Cutting machines are not fully utilized in the production
o Work in Progress accumulate at Sewing, when Dye Fabric and Cutting are fully utilized
The bottleneck is Sewing process
78
© LGChan
 Lecture 9.1
Application of Kingman Equation in Lean Production
Kingman Equation, from mathematical queuing theory, provides an
approximation of the waiting time of the parts for a single process based on its
utilization and variance
John Kingman, 1961

Variation in arrival units =
Variation in processing time =
=
p average processing time for a resource
=
u Resource Utilization
= Flow Rate/ Resource Capacity
(ie 100%>resource capacity > demand rate)
v = Variability Factor
variation in arrival of units
= variation in processing times
1 + [change in arrive/average arrival]
1 + [change in processing time/average processing time]
79
© LGChan
 Lecture 9.1
Utilization with New Demand

o Given that there is enough capacity on average to

meet demand (capacity > demand rate)
o With variability, there is an exponential increase in the
queue time (Twait) with increasing capacity utilization
o Roughly at 80% utilization the queues become critical
o When Utilization → 100%, Twait approaches infinity

How to Reduce Waiting Time

o Reducing process time, p, through process improvement and
elimination of waste will reduce queuing
o Keep utilization as low as possible, to keep u/(1-u) as low as possible
o Reduce arrival variation (e.g. scheduling slots/appointments) and
processing time variation (eg. Standard Work)

80
© LGChan
 Lecture 9.2
Constraints
A constraint can be a thing, process, person, structure, object that prevents the flow of value to the customer
Any system can produce only as much as its critically constrained resource
Maximum speed of the process is the speed of the slowest operation
Any improvements will be wasted unless the bottleneck is relieved

Internal Constraints External Constraints

Process constraints: Machine time, maintenance Material Constraints: Insufficient supply
Policy constraints: No overtime, no budget Market Constraints: Insufficient demand

Constraint
A Pull System

60 units 70 units 40 units 60 units

per day per day per day per day
Maximum Throughput = 40 units per day
9
© LGChan
 Lecture 9.2
Measuring Performance in Theory of Constraints
1 Throughput
The rate at which the system generates money through sales (value added)

Only Money generated by the system and into the organization are included
Throughput = Sales Revenue – Cost of Goods Sold

Not Throughput:
Investment in Machinery, Finished Goods in Warehouse not sold, Work in Process, Raw Materials

2 Inventory (sometimes known as Investment)

All the money the system has invested in purchasing things which it intends to sell
In Theory of Constraints, Inventory is a “liability” (not an asset) because it is not producing revenue until it is
sold
Raw materials, work in process, finished goods and scrap are “Inventory”

3 Operating Expenses
All the money the system spends in order to turn inventory into throughput
All employee time is “OE” (through salaries and wages: direct, indirect, operating, etc.)
Depreciation of a machine is “Operating Expenses”
Operating supplies are “Operating Expenses” 14
© LGChan
 Lecture 9.2
Financial Implications of Improvements from Theory of Constraints
Improvements Changes and Impacts
Throughput Inventory Op Expense Net Profit Return on Inventory Cash Flow
Increase No change No change Increase Increase Increase
No change No change Decrease Increase Increase Increase
No change Decrease* No change No change Increase Increase

* Note : if the carrying cost of inventory decreases, then net profit will increase
Video (5:22) https://www.youtube.com/watch?v=07EgECNPd8k

Rank the Order of Importance of Improvements in Theory of Constraints?

1. Throughput
2. Inventory or Assets
3. Operating Expenses

Why Do We Need Inventory To Protect Throughput?

We need inventory to protect throughput, because there are statistical fluctuations
(uncertainties) and dependent resources (cellular manufacturing)
15
© LGChan
 Lecture 9.2
Performance Management: How to Improve Throughput Value
Throughput Value Sales − Direct Material Costs
per factory hour = Usage of bottleneck in hours (factory hours)

This enables businesses to take short-term decisions when a resource is in scarce supply
Factory hours are measured in terms of use of the bottleneck resource.

Throughput Value per factory hour

Throughput Ratio (TAR) =
Cost per factory hour
The higher the ratio, the more profitable the company.
If a product has a ratio of less than one, you lose money every time a product is made

How to Increase Throughput Value

o Increase selling price of the product
o Reduce material cost per unit
o Reduce factory cost
o Improve productivity at the bottleneck 17
© LGChan
 Lecture 10.3
Agile Manifesto
Agile Manifesto

4 Values in Agile:
1. Individuals
2. Product
3. Customer
4. Change

Agile Value and Focus Traditional Value and Focus

1.Individuals and Interactions 1. Processes and Tools
2.Working Software Product 3. 2. Comprehensive Documentation
4. Customer Collaboration 3. Contract Negotiation
Responding to Change 4. Following a Plan

while there is value in the items on the right, we value the items on the left more
 Lecture 10.3
Scrum Framework (3 – 3 – 5)
3 Roles : 5 Ceremonies (Events) :
Product Owner, Scrum Master, Team Sprint, Sprint Planning, Sprint Review, Sprint Retrospective, Daily Scrum Meeting

3 Artifacts (list of work to be done or deliverable) :

Product Backlog, Sprint Backlog, and Burndown Chart
 Lecture 10.3
Scrum Roles
Product Owner Team
Responsibilities The Team self-organizes to get the work done
o product backlog and priority o 5-10 people committed to project
o business value of the project o Cross-functional : generalising specialists, eg QA,
o profitability of the product (ROI) Programmers, UI Designers, etc.
o Define the features of the product o Members should be full-time : May be exceptions
o Decide on release date and content (eg., System Admin, etc.)
o Prioritize features according to market value o Teams are self-organizing
o Adjust features and priority every iteration, as needed o Membership can change only between sprints
o Accept or reject work results o Deliver value in small chunks within every sprint,
focused on customer, build in quality
Scrum Master
Scrum Master represents management to the project
and ensures that the team is functional and productive
o Responsible for enacting Scrum values and practices
o Removes impediments
o Ensure that the team is fully functional and
productive
o Enable close cooperation across all roles and
functions
o Shield the team from external interferences 20
© LGChan
 Lecture 10.3
Advantages and Disadvantages of Scrum
Advantages of Scrum Disadvantages of Scrum

More transparency and project visibility Risk of scope creep

Daily stand-up meetings improves workflow Some Scrum projects can experience scope creep due
to a lack of specific end date

Increased team accountability Team requires experience and commitment

Self organization seeks best approach Team needs to commit to the daily Scrum meetings and
to stay on the team for the duration of the project.

Easy to accommodate changes Wrong Scrum Master can ruin everything

With short sprints and constant feedback, it’s easier to If the Scrum Master tries to control the team, the
cope with and accommodate changes project will fail.

Increased cost savings Poorly defined tasks can lead to inaccuracies

Constant communication ensures the team is aware of If the initial goals are unclear, planning becomes
all issues and changes as soon as they arise, helping to difficult and takes more time
lower expenses and increase quality
 Lecture 11.1
Social Systems
Characteristics
Socio-technical systems are technical works involving the participation of groups of people in
ways that significantly affect the architectures and design of those works
(Rechtin Maier 2009)

Main Features of Socio-Technical Systems

1. They are collective operational tasks
2. They contain social and technical sub-systems
3. They are open systems (strongly interacting with their environments)
4. Non deterministic (changing human environment) and emergent properties (evolving)
5. Concept of the system being an unfinished system

Examples
intelligent transport system, telecommunications system, public health systems,
education systems, electrical power distribution system, Toyota production systems

89
© LGChan
 Lecture 11.1
Five Key Characteristics of Open Socio-Technical Systems
1. Systems should have inter-dependent sub-systems which allow various users to
interact and design solutions to satisfy their different requirements

2. Systems should adapt to and pursue goals in external environments

3. Systems have an internal environment comprising separate but inter-dependent

technical and social subsystems

4. Systems have equi-finality

Meaning : systems goals can be achieved by more than one means.
This implies that there are many possibilities and design choices to be made during
system development

5. System performance relies on the joint optimisation of the technical and social
subsystems
Focusing on one of these systems to the exclusion of the other is likely to lead to
degraded system performance and utility
Source : Baxter Sommerville 2011 Socio-technical systems-From design methods to systems engineering. Interacting with Computers 10
© LGChan
 Lecture 11.3
Leveraging Architectures in Innovative Builder Systems
1 Incremental Development for Existing Customer
o Using existing architectures to produce variations and extensions of existing customers
o Low risk because of proven architecture
o Adopt Platform Design
(Example: coffee makers, electric shavers, vacuum cleaners)
(Iridium Example: use technology for high-speed data satellites, M-Star)

2 New Markets for Existing Products

o Using existing architectures to enter new or uncertain markets
o New applications of existing products in new markets
(Example: GoPro camera – camera for action photography)
(Iridium Example: unserved markets in Africa, disaster relief operators)

3 New Products and New Markets

o Novel architectures looking for new markets
o Creating Disruptive Technology
(Example: new computer hardware creates newer and better software applications)
block chain technology creates crypto currency to replace bank transactions)
3
© LGChan
 Lecture 11.3
Leveraging Architectures in Innovative Builder Systems
4 Technology Substitution within Existing Systems
o Upgrading old technology in existing system
o Easy for software systems (using update patches released online)
o Difficult for hardware systems required making changes in production or assembly

New
Penetration/
Disruptive
Substitution

Markets

Existing
Platform/
NA
Substitution

Existing New
Products

5 Uncertainty of End Purpose

o Architecture solutions looking for a problem
Example: Google “moon shot projects”
Mars mission
4
© LGChan