lecture requirements engineering · lecture requirements engineering by gerrit muller university of...
TRANSCRIPT
Lecture Requirements Engineeringby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
This article describes the Requirements Engineering session part of the SoftwareEngineering block in the OOTI curriculum of the Technical University Eindhoven.The focus of this course is on capturing and managing requirements. The notionof key drivers and story telling will be introduced as a means to capture andmanage. During the course an exercise is used based on video distribution viasatellite. The students have to elicit the requirements for the required systems,working in teams of 4 students. Every student writes an individual report aboutthe exercise.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: finishedversion: 1.1
block 2; actual current case of OOTI education
block 1; teacher provides case
What are requirements, black box, SMART
Customer and Application view, Story telling
Financial viewpoint, Presentation to management
Discussion of requirement specification per team
Documentation How-to Coaching and discussion
Presentation project case to management team
homework: make requirement specification
homework: improve requirement specification
homework: make presentation outline
homework: make presentation
1/2 day
1/2 day
1/2 day
1/2 day
1/2 day
1/2 day
individual report
Program
time subject
Session 1 What are requirements, black box, SMART
Session 2 Customer and Application view, Story telling
Session 3 Discussion of requirement specification per team
Session 4 Financial viewpoint, Presentation to management
Session 5 Documentation How-to, Coaching and discussion session
Session 6 Presentation of project case to management team
Lecture Requirements Engineering2 Gerrit Muller
version: 1.1September 9, 2018
OOTICprogramTable
Schedule
block 2; actual current case of OOTI education
block 1; teacher provides case
What are requirements, black box, SMART
Customer and Application view, Story telling
Financial viewpoint, Presentation to management
Discussion of requirement specification per team
Documentation How-to Coaching and discussion
Presentation project case to management team
homework: make requirement specification
homework: improve requirement specification
homework: make presentation outline
homework: make presentation
1/2 day
1/2 day
1/2 day
1/2 day
1/2 day
1/2 day
individual report
Lecture Requirements Engineering3 Gerrit Muller
version: 1.1September 9, 2018
OOTICschedule
Case Instructions
1. Block 1 session 1: Make an initial requirements specification2. Block 1 session 2: Improve and complete requirements specification3. Block 2 session 4: Make an outline of a presentation of maximum 10 minutes,
target audience: management team of your company4. Block 2 session 5: Prepare and exercise presentation5. Block 2 session 6: Write an individual report reflecting on: requirement speci-
fication, management presentation, lessons learned and how to do it nexttime.
Lecture Requirements Engineering4 Gerrit Muller
version: 1.1September 9, 2018
OOTICcaseInstructionList
Case: Recommended Steps
1. Make a black box view of the system
2. Make some initial drafts and designs to explore the problem.
3. Make a story which helps to understand the products, make sure to use thecriterions for a story.
4. Look from all stakeholder points of view towards the problem and identify whatthey need and what they expect.
5. Analyze the information obtained so far and extract the underlying require-ments.
6. Abstract the key drivers behind the requirements.
7. Make a top-down description of the requirements.
Lecture Requirements Engineering5 Gerrit Muller
version: 1.1September 9, 2018
OOTICcaseListOfSteps
Case: Questions for Individual Report
• What are the most important lessons you learned from these exercise(requirement specification, management presentation)?
• Which roles did the members of the group play during the exercise?• How would you approach such a problem the next time?• Which stakeholders understand your group presentation? Are they happy
with the presentation?
Lecture Requirements Engineering6 Gerrit Muller
version: 1.1September 9, 2018
OOTICcaseIndividualQuestions
Submission of Homework
Homework instructions
specification minimum 4 hours work/person, maximum 8 hours
maximum 6 A4 pages
presentation minimum 2 days work/ person, maximum 5 days
filename: [OOTI<year>] spec|presentation <team id>.<version number>
e.g. [OOTI2008] spec team1.1.doc
all team members on front page
email to:
subject: [OOTI<year>] spec|presentation <team id>
from/cc: <all email addresses of team members>
when: 48 hours before next lecture
<gerrit muller gmail com>
Lecture Requirements Engineering7 Gerrit Muller
version: 1.1September 9, 2018
OOTIChomeworkInstructions
Module Requirementsby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
This module addresses requirements: What are requirements? How to find,select, and consolidate requirements?
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: conceptversion: 1.4
Fundamentals of Requirements Engineeringby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
Requirements engineering is one of the systems engineering pillars. In thisdocument we discuss the fundamentals of systems engineering, such as thetransformation of needs into specification, the need to prescribe what rather thanhow, and the requirements when writing requirements.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: conceptversion: 0.1
system seen as black box
inputs outputsfunctions
quantified characteristics
restrictions, prerequisites
boundaries, exceptions
standards, regulations
interfaces
Definition of “Requirement”
Requirements describing the needs of the customer:
Customer Needs
Requirements describing the needs of the company
itself over the life cycle: Life Cycle Needs
Requirements describing the characteristics of the
final resulting product: Product Specification
The requirements management process recursively
applies definition 2 for every level of decomposition.
Fundamentals of Requirements Engineering10 Gerrit Muller
version: 0.1September 9, 2018
REQdefinition
Flow of Requirements
What
What
How
customer needs:
What is needed by the customer?
product specification:
What are we going to realize?
system design:
How are we going to realize the product?
What
How
What
How
What
How
What are the subsystems we will realize?
How will the subsystems be realized?
What
How
What
How
What
How
What
How
What
How
What
How
up to "atomic" components
choices
trade-offs
negotiations
Fundamentals of Requirements Engineering11 Gerrit Muller
version: 0.1September 9, 2018REQwhatWhatHow
System as a Black Box
system seen as black box
inputs outputsfunctions
quantified characteristics
restrictions, prerequisites
boundaries, exceptions
standards, regulations
interfaces
Fundamentals of Requirements Engineering12 Gerrit Muller
version: 0.1September 9, 2018
REQsystemAsBlackBox
Stakeholders w.r.t. Requirements
Policy and Planning
(business, marketing,
operational managers)
customer
(purchaser, decision maker, user, operator, maintainer)
company
Product Creation Process
(project leader, product
manager, engineers, suppliers)
Customer-Oriented Process
(sales, service, production,
logistics)
People, Process, and Technology management process
(capability managers, technology suppliers)
Fundamentals of Requirements Engineering13 Gerrit Muller
version: 0.1September 9, 2018
REQstakeholders
The “Formal” Requirements for Requirements
Specific
Unambiguous
Verifiable
Quantifiable
Measurable
Complete
Traceable
Fundamentals of Requirements Engineering14 Gerrit Muller
version: 0.1September 9, 2018
REQrequirementsForRequirementsList
The Requirements to Enable Human Use
Accessible
Understandable
Low threshold
Fundamentals of Requirements Engineering15 Gerrit Muller
version: 0.1September 9, 2018
REQrequirementsFromHumans
Short introduction to basic “CAFCR” modelby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
The basic “CAFCR” reference model is described, which is used to describea system in relation to its context. The main stakeholder in the context is thecustomer. The question “Who is the customer?” is addressed.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: draftversion: 0.4
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
drives, justifies, needs
enables, supports
Customer
objectives
Application Functional Conceptual Realization
The “CAFCR” model
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
drives, justifies, needs
enables, supports
Customer
objectives
Application Functional Conceptual Realization
Short introduction to basic “CAFCR” model17 Gerrit Muller
version: 0.4September 9, 2018
CAFCRannotated
Integrating CAFCR
Customer
objectives
Application Functional Conceptual Realization
intention
constraintawareness
objectivedriven
contextunderstanding
oppor-tunities
knowledgebased
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
Short introduction to basic “CAFCR” model18 Gerrit Muller
version: 0.4September 9, 2018
MSintegratingCAFCR
CAFCR can be applied recursively
System
(producer)
Customer
BusinessDrives
Enables
Customer's
Customer
BusinessDrives
Enables
ConsumerDrives
Enables
Value Chain
larger scope has smaller
influence on architecture
Short introduction to basic “CAFCR” model19 Gerrit Muller
version: 0.4September 9, 2018
CAFCRrecursion
Market segmentation
geographical
business model profit, non profit
examples
economics
USA, UK, Germany, Japan, China
high end versus cost constrained
consumers youth, elderly
segmentation
axis
outlet retailer, provider, OEM, consumer direct
Short introduction to basic “CAFCR” model20 Gerrit Muller
version: 0.4September 9, 2018
BCAFCRcustomerSegmentation
Example of a small buying organization
decision maker(s) purchaser
maintainer
operator
user
CEO
CFO
CTO
CIO
department head
Who is the customer?
CMO
CEO: Chief Executive Officer
CFO: Chief Financial Officer
CIO: Chief Information Officer
CMO: Chief Marketing Officer
CTO: Chief Technology Officer
Short introduction to basic “CAFCR” model21 Gerrit Muller
version: 0.4September 9, 2018
BCAFCRwhoIsTheCustomer
CAFCR+ model; Life Cycle View
Customer
objectives
Application Functional Conceptual Realization
Life cycleoperations
maintenance
upgrades
development
manufacturing
installation
sales, service, logistics, production, R&D
Short introduction to basic “CAFCR” model22 Gerrit Muller
version: 0.4September 9, 2018
BCAFCRplusLifeCycle
Key Drivers How Toby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
The notion of ”business key drivers” is introduced and a method is described tolink these key drivers to the product specification.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: draftversion: 0.2
Safety
Effective
Flow
Smooth
Operation
Environment
Reduce accident rates
Enforce law
Improve emergency
response
Reduce delay due to accident
Improve average speed
Improve total network throughput
Optimize road surface
Speed up target groups
Anticipate on future traffic condition
Ensure traceability
Ensure proper alarm handling
Ensure system health and fault indication
Reduce emissions
Early hazard detection
with warning and signaling
Maintain safe road
condition
Classify and track dangerous
goods vehicles
Detect and warn
noncompliant vehicles
Enforce speed compliance
Enforce red light compliance
Enforce weight compliance
Key-drivers Derived application drivers Requirements
Automatic upstream
accident detection
Weather condition
dependent control
Deicing
Traffic condition
dependent speed control
Traffic speed and
density measurement
Note: the graph is only partially elaborated
for application drivers and requirements
Cameras
Example Motorway Management Analysis
Safety
Effective
Flow
Smooth
Operation
Environment
Reduce accident rates
Enforce law
Improve emergency
response
Reduce delay due to accident
Improve average speed
Improve total network throughput
Optimize road surface
Speed up target groups
Anticipate on future traffic condition
Ensure traceability
Ensure proper alarm handling
Ensure system health and fault indication
Reduce emissions
Early hazard detection
with warning and signaling
Maintain safe road
condition
Classify and track dangerous
goods vehicles
Detect and warn
noncompliant vehicles
Enforce speed compliance
Enforce red light compliance
Enforce weight compliance
Key-drivers Derived application drivers Requirements
Automatic upstream
accident detection
Weather condition
dependent control
Deicing
Traffic condition
dependent speed control
Traffic speed and
density measurement
Note: the graph is only partially elaborated
for application drivers and requirements
Cameras
Key Drivers How To24 Gerrit Muller
version: 0.2September 9, 2018
COVmotorwayManagementKeyDrivers
Method to create Key Driver Graph
• Build a graph of relations between drivers and requirements
by means of brainstorming and discussions
• Define the scope specific. in terms of stakeholder or market segments
• Acquire and analyze facts extract facts from the product specification
and ask why questions about the specification of existing products.
• Iterate many times increased understanding often triggers the move of issues
from driver to requirement or vice versa and rephrasing
where requirements
may have multiple drivers
• Obtain feedback discuss with customers, observe their reactions
Key Drivers How To25 Gerrit Muller
version: 0.2September 9, 2018
TCAFkeyDriverSubmethod
Recommendation for the Definition of Key Drivers
• Use short names, recognized by the customer.
• Limit the number of key-drivers minimal 3, maximal 6
for instance the well-known main function of the product• Don’t leave out the obvious key-drivers
for instance replace “ease of use” by
“minimal number of actions for experienced users”,
or “efficiency” by “integral cost per patient”
• Use market-/customer- specific names, no generic names
• Do not worry about the exact boundary between
Customer Objective and Applicationcreate clear goal means relations
Key Drivers How To26 Gerrit Muller
version: 0.2September 9, 2018
TCAFkeyDriverRecommendations
Transformation of Key Drivers into Requirements
Key
(Customer)
Drivers
Derived
Application
Drivers
Requirements
Customer
What
Customer
How
Product
What
Customer
objectives
Application Functional
goal means
may be skipped or
articulated by several
intermediate steps
functions
interfaces
performance figures
Key Drivers How To27 Gerrit Muller
version: 0.2September 9, 2018
REQfromDriverToRequirement
Requirements Elicitation and Selectionby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
An elicitation method for needs is described using many different viewpoints. Aselection process with a coarse and a fine selection is described to reduce thespecification to an acceptable and feasible subset.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: draftversion: 0 bottom-up
top-down
key-drivers(customer, business)
roadmap(positioning and trends in time)
competition(positioning in the market)
"ideal" reference design
prototyping, simulation(learning vehicle)
bottom-up(technological opportunities)
existing systems
operational drivers(logistics, production, etc.)
NeedsContinued
Product Creation
Process
Feedback
regulations
Complementary Viewpoints to Capture Requirements
bottom-up
top-down
key-drivers(customer, business)
roadmap(positioning and trends in time)
competition(positioning in the market)
"ideal" reference design
prototyping, simulation(learning vehicle)
bottom-up(technological opportunities)
existing systems
operational drivers(logistics, production, etc.)
NeedsContinued
Product Creation
Process
Feedback
regulations
Requirements Elicitation and Selection29 Gerrit Muller
version: 0September 9, 2018
REQviewpoints
Requirement Selection Process
customer needs
operational needs
roadmap
strategy
competition
selection process
product specification
need
characterization
requirement
phasing
Technology, People, Process
costs and constraints
Requirements Elicitation and Selection30 Gerrit Muller
version: 0September 9, 2018
REQselection
Simple Qualification Method
important
urgent
effort
value
do
don't discuss
discuss
do
don't discuss
discuss
Requirements Elicitation and Selection31 Gerrit Muller
version: 0September 9, 2018
REQqualitativeSelectionMatrix
Examples of Quantifiable Aspects
• Value for the customer
• (dis)satisfaction level for the customer
• Selling value (How much is the customer willing to pay?)
• Level of differentiation w.r.t. the competition
• Impact on the market share
• Impact on the profit margin
Use relative scale, e.g. 1..5 1=low value, 5 -high value
Ask several knowledgeable people to score
Discussion provides insight (don't fall in spreadsheet trap)
Requirements Elicitation and Selection32 Gerrit Muller
version: 0September 9, 2018MPBAvalueCriteria
Exercise Requirements Capturing
• Determine the key drivers for one particular product family.• Translate these drivers into application drivers and derive from them the
requirements.
Exercise Requirements Capturing33 Gerrit Muller
version: 0September 9, 2018
MREQexercise
Needs and Requirements
Needs, Specification, RequirementsRequirements describing the needs of the customer:
Customer Needs
Requirements describing the needs of the company
itself over the life cycle: Life Cycle Needs
Requirements describing the characteristics of the
final resulting product: Product Specification
The requirements management process recursively
applies definition 2 for every level of decomposition.
Flow of RequirementsWhat
What
How
customer needs:
What is needed by the customer?
product specification:
What are we going to realize?
system design:
How are we going to realize the product?
What
How
What
How
What
How
What are the subsystems we will realize?
How will the subsystems be realized?
What
How
What
How
What
How
What
How
What
How
What
How
up to "atomic" components
choices
trade-offs
negotiations
Requirements for Requirements
Specific
Unambiguous
Verifiable
Quantifiable
Measurable
Complete
Traceable
Enable Human Use
Accessible
Understandable
Low threshold
Exercise Requirements Capturing34 Gerrit Muller
version: 0September 9, 2018
CAFCR, Customer Key Driver Graph
CAFCR+ ModelCustomer
objectives
Application Functional Conceptual Realization
Life cycleoperations
maintenance
upgrades
development
manufacturing
installation
sales, service, logistics, production, R&D
Iterate over Views
Customer
objectives
Application Functional Conceptual Realization
intention
constraintawareness
objectivedriven
contextunderstanding
oppor-tunities
knowledgebased
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
Example Key Driver Graph
Safety
Effective
Flow
Smooth
Operation
Environment
Reduce accident rates
Enforce law
Improve emergency
response
Reduce delay due to accident
Improve average speed
Improve total network throughput
Optimize road surface
Speed up target groups
Anticipate on future traffic condition
Ensure traceability
Ensure proper alarm handling
Ensure system health and fault indication
Reduce emissions
Early hazard detection
with warning and signaling
Maintain safe road
condition
Classify and track dangerous
goods vehicles
Detect and warn
noncompliant vehicles
Enforce speed compliance
Enforce red light compliance
Enforce weight compliance
Key-drivers Derived application drivers Requirements
Automatic upstream
accident detection
Weather condition
dependent control
Deicing
Traffic condition
dependent speed control
Traffic speed and
density measurement
Note: the graph is only partially elaborated
for application drivers and requirements
Cameras
Complementary Viewpoints
bottom-up
top-down
key-drivers(customer, business)
roadmap(positioning and trends in time)
competition(positioning in the market)
"ideal" reference design
prototyping, simulation(learning vehicle)
bottom-up(technological opportunities)
existing systems
operational drivers(logistics, production, etc.)
NeedsContinued
Product Creation
Process
Feedback
regulations
Exercise Requirements Capturing35 Gerrit Muller
version: 0September 9, 2018
Story How Toby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
A story is an easily accessible story or narrative to make an application live. Agood story is highly specific and articulated entirely in the problem domain: thenative world of the users. An important function of a story is to enable specific(quantified, relevant, explicit) discussions.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: conceptversion: 1.2
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
story caseanalyze
design
designanalyze
design
a priori solution knowledgemarket
vision
Customer
objectives
Application Functional Conceptual Realization
From story to design
Customer
What
Customer
How
Product
What
Product
How
What does Customer need
in Product and Why?
story caseanalyze
design
designanalyze
design
a priori solution knowledgemarket
vision
Customer
objectives
Application Functional Conceptual Realization
Story How To37 Gerrit Muller
version: 1.2September 9, 2018
SHTfromStoryToDesign
Example story layout
A day in the life of Bob
bla blah bla, rabarber music
bla bla composer bla bla
qwwwety30 zeps.
nja nja njet njippie est quo
vadis? Pjotr jaleski bla bla
bla brree fgfg gsg hgrg
mjmm bas engel heeft een
interressant excuus, lex stelt
voor om vanavond door te
werken.
In the middle of the night he
is awake and decides to
change the world forever.
The next hour the great
event takes place:
This brilliant invention will change the world foreverbecause it is so unique and
valuable that nobody beliefs the feasibility. It is great and WOW at the same time,
highly exciting.
Vtables are seen as the soltution for an indirection problem. The invention of Bob will
obsolete all of this in one incredibke move, which will make him famous forever.
He opens his PDA, logs in and enters his provate secure unqiue non trivial password,
followed by a thorough authentication. The PDA asks for the fingerprint of this little left
toe and to pronounce the word shit. After passing this test Bob can continue.
draft or sketch of
some essential
applianceca. half a page of
plain English text
Yes
or
No
that is the question
Story How To38 Gerrit Muller
version: 1.2September 9, 2018
SHTexampleStoryLayout
Points of attention
• purpose
• scope
• viewpoint, stakeholders
• visualization
• size (max 1 A4)
• recursive decomposition, refinement
What do you need to know for
specification and design?
“umbrella” or specific event?
Define your stakeholder and viewpoint
f.i. user, maintainer, installer
Sketches or cartoon
Helps to share and communicate ideas
Can be read or told in few minutes
Story How To39 Gerrit Muller
version: 1.2September 9, 2018SHTattentionPoints
Criteria for a good story
• accessible, understandable
• valuable, appealing
• critical, challenging
• frequent, no exceptional niche
• specific
"Do you see it in front of you?"
attractive, important
"Are customers queuing up for this?"
"What is difficult in the realization?"
"What do you learn w.r.t. the design?"
names, ages, amounts, durations, titles, ...
"Does it add significantly to the bottom line?"
Customer
objectives
Application
Functional
Conceptual
Realization
Customer
objectives
Application
Application
Application
Story How To40 Gerrit Muller
version: 1.2September 9, 2018
SHTcriterionsList
Example of a story
Betty is a 70-year-old woman who lives in Eindhoven. Three years ago her husband passed
away and since then she lives in a home for the elderly. Her 2 children, Angela and Robert,
come and visit her every weekend, often with Betty’s grandchildren Ashley and Christopher.
As so many women of her age, Betty is reluctant to touch anything that has a technical
appearance. She knows how to operate her television, but a VCR or even a DVD player is
way to complex.
When Betty turned 60, she stopped working in a sewing studio. Her work in this noisy
environment made her hard-of-hearing with a hearing-loss of 70dB around 2kHz. The rest of
the frequency spectrum shows a loss of about 45dB. This is why she had problems
understanding her grandchildren and why her children urged her to apply for hearing aids two
years ago. Her technophobia (and her first hints or arthritis) inhibit her to change her hearing
aids’ batteries. Fortunately her children can do this every weekend.
This Wednesday Betty visits the weekly Bingo afternoon in the meetingplace of the old-folk’s
home. It’s summer now and the tables are outside. With all those people there it’s a lot of
chatter and babble. Two years ago Betty would never go to the bingo: “I cannot hear a thing
when everyone babbles and clatters with the coffee cups. How can I hear the winning
numbers?!”. Now that she has her new digital hearing instruments, even in the bingo
cacophony, she can understand everyone she looks at. Her social life has improved a lot and
she even won the bingo a few times.
That same night, together with her friend Janet, she attends Mozart’s opera The Magic Flute.
Two years earlier this would have been one big low rumbly mess, but now she even hears the
sparkling high piccolos. Her other friend Carol never joins their visits to the theaters. Carol also
has hearing aids, however hers only “work well” in normal conversations. “When I hear music
it’s as if a butcher’s knife cuts through my head. It’s way too sharp!”. So Carol prefers to take
her hearing aids out, missing most of the fun. Betty is so happy that her hearing instruments
simply know where they are and adapt to their environment.
source: Roland Mathijssen
Embedded Systems Institute
Eindhoven
Story How To41 Gerrit Muller
version: 1.2September 9, 2018
SHTexample
Value and Challenges in this story
Challenges in this story:
Intelligent hearing instrument
Battery life at least 1 week
No buttons or other fancy user interface on the hearing instrument,
other than a robust On/Off method
The user does not want a technical device but a solution for a problem
Instrument can be adapted to the hearing loss of the user
Directional sensitivity (to prevent the so-called cocktail party effect)
Recognition of sound environments and automatic adaptation (adaptive
filtering)
source: Roland Mathijssen, Embedded Systems Institute, Eindhoven
Conceptual
Realization
Customer
objectives
Application
Value proposition in this story:
quality of life:
active participation in different social settings
usability for nontechnical elderly people:
"intelligent" system is simple to use
loading of batteries
Story How To42 Gerrit Muller
version: 1.2September 9, 2018
SHTexampleCriteria
Module Management Presentationby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
This module addresses the presentation of architectural issues to highermanagement teams.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: draftversion: 1.1
Simplistic Financial Computations for System Architects.by Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
This document explains how simple financial estimates can be made by systemarchitects. These simplistic estimates are useful for an architect to performsanity checks on proposals and to obtain understanding of the financial impactof proposals. Note that architects will never have full fledged financial controllerknow how and skills. These estimates are zero order models, but real businessdecisions will have to be founded on more substantial financial proposals.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: preliminarydraftversion: 1.3
sales volumein units
$
income
expenses
break even
point
profit
expected
sales volume
fixe
d c
ost
s
variable
Product Margin = Sales Price - Cost
material
labour
miscellaneous
margin
cost
pri
ce
sale
s p
rice
Cost per product,
excluding fixed costs
Margin per product.
The margin over the sales volume,
must cover the fixed costs, and generate profittransportation, insurance,
royalties per product, ...
purchase price of components may cover
development cost of supplier
retailer margin
and costs
stre
et p
rice
Simplistic Financial Computations for System Architects.45 Gerrit Muller
version: 1.3September 9, 2018
SFCmargin
Profit as function of sales volume
sales volumein units
$
income
expenses
break even
point
profit
expected
sales volume
fixe
d c
ost
s
variable
Simplistic Financial Computations for System Architects.46 Gerrit Muller
version: 1.3September 9, 2018
SFCprofitAndSalesVolume
Investments, more than R&D
research and development
NRE: outsourcing, royalties
marketing, sales
training sales&service
financing
including:
staff, training, tools, housing
materials, prototypes
overhead
certification
strategic choice:
NRE or per product
business dependent:
pharmaceutics industry
sales cost >> R&D cost
often a standard staffing rate is used
that covers most costs above:
R&D investment = Effort * rate
Simplistic Financial Computations for System Architects.47 Gerrit Muller
version: 1.3September 9, 2018
SFCinvestments
Income, more than product sales only
products
options,
accessories
other recurring
income
services
sales priceoption * volumeoption
sales priceproduct * volume product
incomeservice
options
services
content, portal
updates
maintenance
license fees
pay per movie
Simplistic Financial Computations for System Architects.48 Gerrit Muller
version: 1.3September 9, 2018
SFCincome
The Time Dimension
Q1
100k$
-
-
-
(100k$)
(100k$)
investments
sales volume (units)
material & labour costs
income
quarter profit (loss)
cumulative profit
Q3
20k$
30
600k$
1500k$
880k$
1480k$
Q2
60k$
30
600k$
1500k$
840k$
600k$
Q1
100k$
20
400k$
1000k$
500k$
(240k$)
Q4
100k$
10
200k$
500k$
200k$
(740k$)
Q3
500k$
2
40k$
100k$
(440k$)
(940k$)
Q2
400k$
-
-
-
(400k$)
(500k$)
cost price / unit = 20k$
sales price / unit = 50k$
variable cost = sales volume * cost price / unit
income = sales volume * sales price / unit
quarter profit = income - (investments + variable costs)
Simplistic Financial Computations for System Architects.49 Gerrit Muller
version: 1.3September 9, 2018
SFCtiming
The “Hockey” Stick
profit
loss
time
(1M$)
(0.5M$)
0.5M$
1M$
Simplistic Financial Computations for System Architects.50 Gerrit Muller
version: 1.3September 9, 2018
SFChockeyStick
What if ...?
profit
loss
time
(1M$)
(0.5M$)
0.5M$
1M$delay of 3 months
early more expensive
product + follow-on
original model
Simplistic Financial Computations for System Architects.51 Gerrit Muller
version: 1.3September 9, 2018
SFChockeyStickWhatIf
Stacking Multiple Developments
-2
-1
0
1
2
3
4
5
6
7
8
9
1 2 3 4 5 6 7 8 9 10 11 12 13 14
cumulative 1
cumulative 2
cumulative 3
cumulative 4
cumulative total
M€
quarter
Simplistic Financial Computations for System Architects.52 Gerrit Muller
version: 1.3September 9, 2018
SFCmultipleDevelopments
Fashionable financial yardsticks
Return On Investments (ROI)
Net Present Value
Return On Net Assets (RONA)
turnover / fte
market ranking (share, growth)
R&D investment / sales
cash-flow
leasing reduces assets, improves RONA
outsourcing reduces headcount, improves this ratio
"only numbers 1, 2 and 3 will be profitable"
in high tech segments 10% or more
fast growing companies combine profits with negative cash-flow,
risk of bankruptcy
Simplistic Financial Computations for System Architects.53 Gerrit Muller
version: 1.3September 9, 2018
SFCyardsticks
How to present architecture issues to higher managementby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
Architects struggle with their visibility at higher management echelons. Theintrovert nature of architects is a severe handicap. Participation of architectsin management teams is important for balanced technical sound decisions andstrategy. Improved managerial communication skills of architects are required.This article describes how to give a more effective presentation to highermanagement teams. Subjects discussed are the preparation, content and form,do and don’t advise.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: conceptversion: 0.1
Market drivers Options Typical performance
Bill of material Schedule
Power budget
fte's profit-investment
Operating principle worst-case performance
Power details
cost ttm wow DRM
integration multiple suppliers nifty features fashionable design Hollywood pact standards
MPEG4 MP3 color display ePen GPS sensor GSM UTMS BT 802.11b
A B A B
load
trans
fer/s
ec
infra sensor display power total
A B
7 6
20 3
36
8 8
17 4
37
302 304 310 318 326
A
302 304 308 322 326
B
330
infra sensor display power total
A B
7 6
20 3
36
8 8
17 4
37
infra control display appl total
A B
2 6 6 3
17
8 4 8 3
23
salesprice cost/p units sales costs investment profit
A B
10M 3M 2M 5M
10 3
1M 10M
4M 3M 3M
10 4
1M
A B
load
trans
fer/s
ec
infra sensor display power total
A B 7 6
20 3
36
8 8
17 4
37
infra sensor display power total
A B 7 6
20 3
36
8 8
17 4
37
infra sensor display power total
A B 7 6
20 3
36
8 8
17 4
37
backup material
recommendation recommendation:
select A
follow up: allocate Jan, Piet, Klaas
per 1/11 go/nogo 1/1/03
mention the red information only
Architectural issues related to managerial viewpoints
management
technology
market organizational
! issues
logistics
financial
How to present architecture issues to higher management55 Gerrit Muller
version: 0.1September 9, 2018
AMIintroduction
Characteristics of managers in higher management teams
common characteristics
+ action-oriented
+ solution rather than problem
+ impatient, busy
+ want facts not beliefs
+ operate in a political context + bottom-line oriented:
profit, return on investment, market share, etc.
highly variable characteristics
? technology knowledge from extensive to shallow
? style from power play to inspirational leadership
How to present architecture issues to higher management56 Gerrit Muller
version: 0.1September 9, 2018
AMImanagementCharacteristics
How to prepare
content
+ gather facts
+ perform analysis
+ identify goal and message
+ make presentation
+ polish presentation form
understand audience
+ gather audience background
+ analysis audience interests
+ identify expected responses
+ simulate audience, exercise presentation
mutual interaction
Always prepare with small team!
70% of effort
30% of effort
How to present architecture issues to higher management57 Gerrit Muller
version: 0.1September 9, 2018
AMIpreparation
Recommended content
+ clear problem statement (what, why)
+ solution exploration (how)
+ options, recommendations
+ expected actions or decisions
supported by facts and figures
How to present architecture issues to higher management58 Gerrit Muller
version: 0.1September 9, 2018
AMIcontent
Mentioned info, shown info and backup info
Market drivers Options Typical performance
Bill of material Schedule
Power budget
fte's profit-investment
Operating principle worst-case performance
Power details
cost ttm wow DRM
integration multiple suppliers nifty features fashionable design Hollywood pact standards
MPEG4 MP3 color display ePen GPS sensor GSM UTMS BT 802.11b
A B A B
load
trans
fer/s
ec
infra sensor display power total
A B
7 6
20 3
36
8 8
17 4
37
302 304 310 318 326
A
302 304 308 322 326
B
330
infra sensor display power total
A B
7 6
20 3
36
8 8
17 4
37
infra control display appl total
A B
2 6 6 3
17
8 4 8 3
23
salesprice cost/p units sales costs investment profit
A B
10M 3M 2M 5M
10 3
1M 10M
4M 3M 3M
10 4
1M
A B
load
trans
fer/s
ec
infra sensor display power total
A B 7 6
20 3
36
8 8
17 4
37
infra sensor display power total
A B 7 6
20 3
36
8 8
17 4
37
infra sensor display power total
A B 7 6
20 3
36
8 8
17 4
37
backup material
recommendation recommendation:
select A
follow up: allocate Jan, Piet, Klaas
per 1/11 go/nogo 1/1/03
mention the red information only
How to present architecture issues to higher management59 Gerrit Muller
version: 0.1September 9, 2018
AMIinfoTypes
Form is important
presentation material
+ professional
+ moderate use of color and animations
+ readable
+ use demos and show artifacts but stay yourself, stay authentic
presenter's appearance
+ well dressed
+ self confident but open
poor form can easily distract from purpose and content
How to present architecture issues to higher management60 Gerrit Muller
version: 0.1September 9, 2018
AMIform
Don’t force your opinion, understand the audience
do not do
- preach beliefs + quantify, show figures and facts
- underestimate technology knowledge of managers
+ create faith in your knowledge
- tell them what they did wrong + focus on objectives
- oversell + manage expectations
How to present architecture issues to higher management61 Gerrit Muller
version: 0.1September 9, 2018
AMIdoAndDont
How to cope with managerial dominance
do not do
- let one of the managers hijack the meeting
+ maintain the lead
- build up tensions by withholding facts or solutions
+ be to the point and direct
- be lost or panic at unexpected inputs or alternatives
+ acknowledge input, indicate consequences (facts based)
How to present architecture issues to higher management62 Gerrit Muller
version: 0.1September 9, 2018
AMIdoAndDontMore
Exercise presentation to higher management
+ Bring a clear architecture message to
+ a Management team at least 2 hierarchical levels higher
+ with 10 minutes for presentation including discussion (no limitation on number of slides)
* architecture message = technology options in relation with market/product
* address the concerns of the management stakeholders : translation required from technology issues into business consequences (months, fte's, turnover, profit, investments)
How to present architecture issues to higher management63 Gerrit Muller
version: 0.1September 9, 2018
AMIexercise
Exercise schedule
prepare in team of 4 1 2 1 2
present and discuss feedback
3 4 3 4
13:30 17:00 14:00 15:00 16:00
How to present architecture issues to higher management64 Gerrit Muller
version: 0.1September 9, 2018
AMIexerciseSchedule
Simplistic Financial Computations
Product Margin = Sales Price - Cost
material
labour
miscellaneous
margin
cost
pri
ce
sale
s p
rice
Cost per product,
excluding fixed costs
Margin per product.
The margin over the sales volume,
must cover the fixed costs, and generate profittransportation, insurance,
royalties per product, ...
purchase price of components may cover
development cost of supplier
retailer margin
and costs
stre
et p
rice
Profit as function of sales volume
sales volumein units
$
income
expenses
break even
point
profit
expected
sales volume
fixe
d c
ost
s
variable
Hockey stick and scenarios
profit
loss
time
(1M$)
(0.5M$)
0.5M$
1M$delay of 3 months
early more expensive
product + follow-on
original model
intentionally left blank
Summary Module Management Presentation65 Gerrit Muller
version: 0.1September 9, 2018
Presentation to Management
Managerial Viewpointsmanagement
technology
market organizational
! issues
logistics
financial
Prepare Content, Understand Audience
content
+ gather facts
+ perform analysis
+ identify goal and message
+ make presentation
+ polish presentation form
understand audience
+ gather audience background
+ analysis audience interests
+ identify expected responses
+ simulate audience, exercise presentation
mutual interaction
Always prepare with small team!
70% of effort
30% of effort
Show underlying info
Market drivers Options Typical performance
Bill of material Schedule
Power budget
fte's profit-investment
Operating principle worst-case performance
Power details
cost ttm wow DRM
integration multiple suppliers nifty features fashionable design Hollywood pact standards
MPEG4 MP3 color display ePen GPS sensor GSM UTMS BT 802.11b
A B A B
load
trans
fer/s
ec
infra sensor display power total
A B
7 6
20 3
36
8 8
17 4
37
302 304 310 318 326
A
302 304 308 322 326
B
330
infra sensor display power total
A B
7 6
20 3
36
8 8
17 4
37
infra control display appl total
A B
2 6 6 3
17
8 4 8 3
23
salesprice cost/p units sales costs investment profit
A B
10M 3M 2M 5M
10 3
1M 10M
4M 3M 3M
10 4
1M
A B
load
trans
fer/s
ec
infra sensor display power total
A B 7 6
20 3
36
8 8
17 4
37
infra sensor display power total
A B 7 6
20 3
36
8 8
17 4
37
infra sensor display power total
A B 7 6
20 3
36
8 8
17 4
37
backup material
recommendation recommendation:
select A
follow up: allocate Jan, Piet, Klaas
per 1/11 go/nogo 1/1/03
mention the red information only
Form, do and do not
presentation material
+ professional
+ moderate use of color and animations
+ readable
+ use demos and show artifacts but stay yourself, stay authentic
presenter's appearance
+ well dressed
+ self confident but open
poor form can easily distract from purpose and content
Summary Module Management Presentation66 Gerrit Muller
version: 0.1September 9, 2018
Module Supporting Processesby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
This module addresses supporting processes, for instance documentation,templates, and reviewing.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: draftversion: 1.4
Granularity of Documentationby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
The design of documentation is discussed, with emphasis on the requirements,the need for decomposition, the measures needed to maintain overview andcriteria for granularity.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: conceptversion: 1.2
compound document
document
structure
overview
document
document
document
document
document
Requirements for the Entire Documentation Structure
Accessibility for the readers
Low threshold for the readers
Low threshold for the authors
Completeness
Consistency
Maintainability
Scalability
Evolvability
Process to ensure the quality of the information
Granularity of Documentation69 Gerrit Muller
version: 1.2September 9, 2018
DGrequirementsStructure
Requirements from Reader Point of View
Convenient
viewing
printing
searching
easy
fast
Granularity of Documentation70 Gerrit Muller
version: 1.2September 9, 2018
DGrequirementsReader
Requirements per Document
High cohesion (within the unit)
Low coupling (outside of the unit)
Accessibility for the readers
Low threshold for the reader
Low threshold for the author
Manageable steps to create, review, and change
Clear responsibilities
Clear position and relation with the context
Well-defined status of the information
Timely availability
Granularity of Documentation71 Gerrit Muller
version: 1.2September 9, 2018
DGrequirementsUnit
Accessibility Requirements
Ease of reading, “juiciness”
High signal-to-noise ratio: information should not be hidden in a
sea of words.
Understandability
Reachability in different ways, e.g., by hierarchical or full search
Reachability in a limited number of steps
Granularity of Documentation72 Gerrit Muller
version: 1.2September 9, 2018
DGrequirementsAccessibility
Responsibility Requirements
single author
limited amount of reviewers
Granularity of Documentation73 Gerrit Muller
version: 1.2September 9, 2018
DGrequirementsResponsibility
Scalability Requirements
well defined documentation structure
overview specifications at higher
aggregation levels
recursive application of structure and
overview
delegation of review process
Granularity of Documentation74 Gerrit Muller
version: 1.2September 9, 2018
DGrequirementsScalability
The Stakeholders of a Single Document
specification
implementation
des
crib
es
author
producerconsumer
context
interacts with
inte
ract
s with
architect
or editor
is responsible
for technical
Project
leader
is responsiblefor time, budget, result
others
writes
uses realizesstake-
holder
artifact
relation
legend
Granularity of Documentation75 Gerrit Muller
version: 1.2September 9, 2018
DGdocumentationRoles
Decomposition of Large Documents
compound document
document
structure
overview
document
document
document
document
document
Granularity of Documentation76 Gerrit Muller
version: 1.2September 9, 2018
DGcompoundDocument
Documentation Tree by Recursive Decomposition
compound document
compound
document
compound
document compound document
overview
document
structure
overview
atomic
documentdocument
structure
overview
document
structure
overview
document
structure
atomic
document
atomic
document
compound
document
compound
document
Granularity of Documentation77 Gerrit Muller
version: 1.2September 9, 2018
DGdocumentRecursion
Payload: the Ratio between Content and Overhead
title
identification
author
distribution
status
review
history
changes
front page
meta information
max 2 pages
diagrams
tables
lists
and ca 50%
text
1. aap
2. noot
3. mies
contents
2..18 pages
Granularity of Documentation78 Gerrit Muller
version: 1.2September 9, 2018
DGpayload
LEAN and A3 Approach to Supporting Processesby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
LEAN product development is in the process and means area pragmatic. Lowtech tools, such as paper, pen and magnets, with very direct interaction are used.For communication the use of single A3-size documents is promoted, becausethis is a manageable amount of information.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: draftversion: 0.1
A3 architecture overview of the Metal Printer (all numbers have been removed for competitive sensitivity)
process steps
metal printing cell
Fluidic
subsystem
chamber
bottom chuck
electronics
infrastructure
process
power
supply
1
3
2
4
5electronics
infrastructure1 5granite
ZUBA
stage
frame
base frame +
x, y, stage
stage
control
ZUBA
control
optics
stagescoop
cameravision
op
tics s
tag
e
co
ntr
ol
vision
control
6
7
8
9
1
0
cabling
covers and
hatches
ventilation
air flow
contamination
evacuation
sensors
measurement
frame
machine
control
"remote"
electronics rack
10
11
12
13
14
15
?
metal printer back side metal printer front sideintegrating
subsystems
metal printer subsystems
tprepare
= tclose doors
+ tmove to proximity
tprint
= tp,prepare
+ tp,align
+ tchamber
(thickness) + tp,finalize
tfinalize
= tmove to unload
+ topen doors
tprint
= tp,overhead
+ Ctransfer
*thickness
2. Align
3. Move to proximity
4. Process
6. Open doors
1. Close doors
5. Move substrate unloading position
talign
tchamber
note: original diagram was annotated with actual performance figures
for confidentiality reasons these numbers have been removed
metal printer
functional flow formula print cycle time
key performance parameters
metal printer subsystems, functions, and cycle time model
metal printing cell: systems and performance model
back-end factory: systems and process model
pattern quality
cost per layer
environmental
impact
design enablinge.g. CD, separation
pattern
resolution
X-section control
accuracy overlay
high MTBF
early delivery
vs
volume production
uptime
throughput
operational
costs
system cost
electric power
clean water
elyte
N2, air
disposal water, air, ...
reliability
integral costs
consumables
waste
contamination
and climate
partial graph
many nodes
and connections
are not shown
customer key drivers
Customer key-drivers and Key Performance Parameters
Document meta-information
author
version
date last update
scope
statusGerrit Muller
0.1
August 3, 2010
system and supersystem
preliminary draft
metal printing time-line
min. line width
overlay
throughput
MTBF
a m
b m
c WPH
d hr
wafer size
power
clean room class
floor vibration class
200, 300 mm
x kW
throughput
1. inspection
2. seed sputter
3. metal print
4. seed etch
wafer
waferseed
wafer
Cu
wafer
5. coat/develop dielectricswafer
6. exposure or CMP for polymer viaswafer
7. E-test
spin coated
polymer
per waferthroughput in minutes
1
t
1
3..4
1..2
dual layer only
robot
prefill
master
FOUP
wafer
FOUP
wafer
FOUPflip
prealignclean
wafer
clean
master
metal
printer
robot
prealign
clean
master
prefill
clean wafer
0 100b 200b
wafer
with
ICs
back-end factory
expose
wafer
stepper
expose
wafer
stepper
metal
printer
advanced
process
control
logistics &
automation
power
chemicals
climate
infrastructure
computing &
networking
infrastructure
metrologymask
power, chemicals
consumables, waste
ICs
REX
wafer fab
(front end)
Characteristics of LEAN
A holistic, systems approach to product development
including people, processes, and technology.
Multi-disciplinary from the early start, with a drive to be fact based.
Customer understanding as the the starting point.
Continuous improvement and learning as cultural value.
Small distance between engineers and real systems, including
manufacturing, sales and service and the system of interest.
LEAN and A3 Approach to Supporting Processes80 Gerrit Muller
version: 0.1September 9, 2018
LEANcharacteristics
Example of A3 Architecture Overview
A3 architecture overview of the Metal Printer (all numbers have been removed for competitive sensitivity)
process steps
metal printing cell
Fluidic
subsystem
chamber
bottom chuck
electronics
infrastructure
process
power
supply
1
3
2
4
5electronics
infrastructure1 5granite
ZUBA
stage
frame
base frame +
x, y, stage
stage
control
ZUBA
control
optics
stagescoop
cameravision
op
tics s
tag
e
co
ntr
ol
vision
control
6
7
8
9
1
0
cabling
covers and
hatches
ventilation
air flow
contamination
evacuation
sensors
measurement
frame
machine
control
"remote"
electronics rack
10
11
12
13
14
15
?
metal printer back side metal printer front sideintegrating
subsystems
metal printer subsystems
tprepare
= tclose doors
+ tmove to proximity
tprint
= tp,prepare
+ tp,align
+ tchamber
(thickness) + tp,finalize
tfinalize
= tmove to unload
+ topen doors
tprint
= tp,overhead
+ Ctransfer
*thickness
2. Align
3. Move to proximity
4. Process
6. Open doors
1. Close doors
5. Move substrate unloading position
talign
tchamber
note: original diagram was annotated with actual performance figures
for confidentiality reasons these numbers have been removed
metal printer
functional flow formula print cycle time
key performance parameters
metal printer subsystems, functions, and cycle time model
metal printing cell: systems and performance model
back-end factory: systems and process model
pattern quality
cost per layer
environmental
impact
design enablinge.g. CD, separation
pattern
resolution
X-section control
accuracy overlay
high MTBF
early delivery
vs
volume production
uptime
throughput
operational
costs
system cost
electric power
clean water
elyte
N2, air
disposal water, air, ...
reliability
integral costs
consumables
waste
contamination
and climate
partial graph
many nodes
and connections
are not shown
customer key drivers
Customer key-drivers and Key Performance Parameters
Document meta-information
author
version
date last update
scope
statusGerrit Muller
0.1
August 3, 2010
system and supersystem
preliminary draft
metal printing time-line
min. line width
overlay
throughput
MTBF
a m
b m
c WPH
d hr
wafer size
power
clean room class
floor vibration class
200, 300 mm
x kW
throughput
1. inspection
2. seed sputter
3. metal print
4. seed etch
wafer
waferseed
wafer
Cu
wafer
5. coat/develop dielectricswafer
6. exposure or CMP for polymer viaswafer
7. E-test
spin coated
polymer
per waferthroughput in minutes
1
t
1
3..4
1..2
dual layer only
robot
prefill
master
FOUP
wafer
FOUP
wafer
FOUPflip
prealignclean
wafer
clean
master
metal
printer
robot
prealign
clean
master
prefill
clean wafer
0 100b 200b
wafer
with
ICs
back-end factory
expose
wafer
stepper
expose
wafer
stepper
metal
printer
advanced
process
control
logistics &
automation
power
chemicals
climate
infrastructure
computing &
networking
infrastructure
metrologymask
power, chemicals
consumables, waste
ICs
REX
wafer fab
(front end)
LEAN and A3 Approach to Supporting Processes81 Gerrit Muller
version: 0.1September 9, 2018
LEANoverviewA3
multiple related views
digestable
(size limitation)
quantifications
practical
close to stakeholder experience
one topic
per A3
capture
"hot" topics
source: PhD thesis Daniel Borches http://doc.utwente.nl/75284/
LEAN and A3 Approach to Supporting Processes82 Gerrit Muller
version: 0.1September 9, 2018
LAWFleanArchitecting
Light Weight Review Processby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
A light weight review process is described that can be used for documents madeduring product creation. This review process is focused on improving the contentsof specifications as early as possible. The process is light weight to increase thelikelihood that it is performed de facto instead of pro forma.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: preliminarydraftversion: 0
draft
authorized
concept
final review= final check contents
authorization= check process
consultation
& review
- wide group of people,
with an active concern or
an expected contribution;
- many iterations
- multiple media:
+ meetings,
+ on paper
+ informal et cetera
specification specific Change Control Board
4 peoples/roles:
1 producer
1 consumer
1 context
1 independent
by "lowest" operational manager:
project leader, subsystem PL, ...
change
request
the author is responsible
for contents and
organization of the flow
(consults and review)
criteria for reviewers:
+ know how
+ critical
+ sufficient time
Product Life Cycle and Change Management
product
creation
production
used by customers
yearsmicro specification control board project team present
specification = communications means
very dynamic, many changes
light weight review processSCB
maintenance control boardno project team any more
documentation = organizational memory
changes only to cope with logistics or safety problems
Light Weight Review Process84 Gerrit Muller
version: 0September 9, 2018
LWRlifeCycle
Light Weight Specification Review Process
draft
authorized
concept
final review= final check contents
authorization= check process
consultation
& review
- wide group of people,
with an active concern or
an expected contribution;
- many iterations
- multiple media:
+ meetings,
+ on paper
+ informal et cetera
specification specific Change Control Board
4 peoples/roles:
1 producer
1 consumer
1 context
1 independent
by "lowest" operational manager:
project leader, subsystem PL, ...
change
request
the author is responsible
for contents and
organization of the flow
(consults and review)
criteria for reviewers:
+ know how
+ critical
+ sufficient time
Light Weight Review Process85 Gerrit Muller
version: 0September 9, 2018LWRstateDiagram
Template How Toby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
The introduction of a new process (way of working) is quite often implementedby supplying ready-to-go tools and templates. This implementation mainly servesthe purpose of a smooth introduction of the new process.Unfortunately the benefits of templates are often cancelled by unforeseen side-effects, such as unintended application, inflexibility, and so on. This intermezzogives hints to avoid the Template Trap, so that templates can be used moreeffectively to support introduction of new processes.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: draftversion: 1.6
Header
Body
Header
Footer
Body
Title Author
Abstract
Title, Date
Page, Author
1 Introduction 2 Scope
Title Author
Body
Title, Date
Page, Author
Body
Title, Date
Page, Author
3 Design
Title, Date
Page, Author
17 Interfaces
..
recommended template type
layout only
prescribing contents
meta information
Rationale for Templates
• Low threshold to apply a (new) process (1)
• Low effort to apply a (new) process (2)
• No need to know low level implementation details (3)
• Means to consolidate and reuse experiences (4)
Template How To87 Gerrit Muller
version: 1.6September 9, 2018
TemplatesRationaleList
Bogus Arguments for Templates
• Obtain a uniform look (5)
• Force the application of a (new) process (6)
• Control the way a new process is applied (7)
Template How To88 Gerrit Muller
version: 1.6September 9, 2018
BogusRationaleTemplates
Forces of Change: Action = - Reaction
counteract
induces
Reaction
New Process
Support
Net change = all Forces
Template How To89 Gerrit Muller
version: 1.6September 9, 2018THTchangeVectors
Template as Support for Process
principle process procedure tool
formalism
template
abstract specific and executable
drives
is
elaborated
in
is
supported
by
Template How To90 Gerrit Muller
version: 1.6September 9, 2018
SAPabstractionHierarchy
Types of Templates
Header
Body
Header
Footer
Body
Title Author
Abstract
Title, Date
Page, Author
1 Introduction 2 Scope
Title Author
Body
Title, Date
Page, Author
Body
Title, Date
Page, Author
3 Design
Title, Date
Page, Author
17 Interfaces
..
recommended template type
layout only
prescribing contents
meta information
Template How To91 Gerrit Muller
version: 1.6September 9, 2018
THTtypes
Recommendation
template type context knowhow value
layout only no low
meta information process high
prescribing content process and domain constraining• Use templates for meta-information.
• Use checklists for structure and contents.
Template How To92 Gerrit Muller
version: 1.6September 9, 2018
Template Development
Templates are an optimization of the Copy Paste Modify pattern:• Look for a similar problem
• Copy its implementation
• Modify the copy to fulfil the new requirements
Template How To93 Gerrit Muller
version: 1.6September 9, 2018
Spiral model: Use before Re-use
Implement document
Use Evaluate
Extract template
Template How To94 Gerrit Muller
version: 1.6September 9, 2018
THTdevelopmentSpiral
Example Guidelines Meta Information(1)
Mandatory per page:• Author
• Title
• Status
• Version
• Date of last update
• Unique Identification
• Business Unit
• Page number
Template How To95 Gerrit Muller
version: 1.6September 9, 2018
Example Guidelines Meta Information(2)
Mandatory per document:• Distribution (Notification) list
• Reviewers and commentators
• Document scope (Product family, Product, Subsystem, Module as far asapplicable)
• Change history
Template How To96 Gerrit Muller
version: 1.6September 9, 2018
Example Guidelines Meta Information(3)
Recommended Practice:• Short statement on frontpage stating what is expected from the addressed
recipients, for example:
• Please send comments before february 29, this document will be reviewedon that date
• This document is authorized, changes are only applied via a changerequest
• See Granularity of Documentation [?] for guidelines for modularization andcontents
Template How To97 Gerrit Muller
version: 1.6September 9, 2018
Template Pitfalls
• Author follows template instead of considering the purpose of the document.
• Template is too complex.
• There is an unmanageable number of variants.
• Mandatory use of templates results in:
• no innovation of templates (= no learning)
• no common sense in deployment
• strong dependency on templates
Recommendation:• Enforce the procedure (what)
• Provide the template (how) as supporting means.
Template How To98 Gerrit Muller
version: 1.6September 9, 2018
Summary
• Templates support (new) processes
• Use templates for layout and meta information support
• Do not use templates for documents structure or contents
• Stimulate evolution of templates, keep them alive
• Keep templates simple
• Standardize on what (process or procedure), not on how (tool and template)
• Provide (mandatory) guidelines and recommended practices
• Provide templates as a supportive choice, don’t force people to use templates
Template How To99 Gerrit Muller
version: 1.6September 9, 2018
TemplateSummaryList
System Integration How-Toby Gerrit Muller University of South-Eastern Norway-NISE
e-mail: [email protected]
Abstract
In this document we will discuss the full integration flow. We will discuss the goalof integration, the relation between integration and testing, what is integrationand how to integrate, an approach to integration, scheduling and dealing withdisruptive events, roles and responsibilities, configuration management aspects,and typical order of integration problems occurring in real life.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí projectphilosophy is to improve by obtaining frequent feedback. Frequent feedback is pursued by anopen creation process. This document is published as intermediate or nearly mature versionto get feedback. Further distribution is allowed as long as the document remains completeand unchanged.
September 9, 2018status: conceptversion: 0.2
measure
alignment
signal
exposemeasure
alignment
signal
position x,y
destination
measure
x,y source
position
x,y source
measure x,y
destinationalign source
destination
adjust light
source
adjust lens
focus
process
measure
correlate
stage
source
correlate
stage
destination
calibrate
x,y
measurement
control x,y
destination
qualify
Typical Concurrent Product Creation Process
design
0.
feasibility
1.
definition
2.
system
design
3.
engineering
4.
integration
& test
5.
field
monitoring
6.
product operational
life cycle
-1
strategy
integrate test
requirements and
specification
policy
testintegratedesignrequirementspolicy
System Integration How-To101 Gerrit Muller
version: 0.2September 9, 2018
SINTproductCreationProcess
Zooming in on Integration and Tests
0.
feasibility
1.
definition
2.
system
design
3.
engineering4.
integration & test
5.
field
monitoring
6.
product operational
life cycle
integratebeta
test
system
test
alpha
test
gamma
test
System Integration How-To102 Gerrit Muller
version: 0.2September 9, 2018
SINTtesting
Integration Takes Place in a Bottom-up Fashion
component
system function
product
subsystem
integratealpha
test
context
System Integration How-To103 Gerrit Muller
version: 0.2September 9, 2018
SINTlevels
Transition from Previous System to New System
existing base system
new HW subsystem
SW dev system
test HW subsystem
test SW for new HW subsystem
new application
existing base system
integrate subsystem
SW dev system test and refine application
integrate and refineapplication
adopt existing base SW
new base system test new base systemintegrate HW
system
integrate
system
SW for new HW subsystem
adopt existing base SW
existing new
2 partial
systems for
SW testing
2 existing
base
systems
new base
systems
time
integrated
system
application integration
new subsystem
integration
System Integration How-To104 Gerrit Muller
version: 0.2September 9, 2018CVintegrationPlan
Alternatives to Integrate a Subsystem Early in the Project
(modified)
existing
subsystems
(prototype)
new
subsystems
to-be-integrated
subsystem
physical
environment
simplecomplex
virtual
spectrum
virtual environment
stubssimulated
subsystems
physical
simulated
physical
reality
System Integration How-To105 Gerrit Muller
version: 0.2September 9, 2018SINTenvironments
Stepwise Integration Approach
Determine most critical system performance parameters.
Identify subsystems and functions involved in these parameters.
Work towards integration configurations along these chains of
subsystems and functions.
Show system performance parameter as early as possible;
start with showing "typical" system performance.
Show "worst-case" and "boundary" system performance.
Rework manual integration tests in steps into automated regression
tests.
Monitor regression results with human-driven analysis.
1
7
5
3
2
6
4
Integrate the chains: show system performance of different parameters
simultaneously on the same system. 8
System Integration How-To106 Gerrit Muller
version: 0.2September 9, 2018
SINTapproach
Order of Functions Required for the IQ of a Waferstepper
measure
alignment
signal
exposemeasure
alignment
signal
position x,y
destination
measure
x,y source
position
x,y source
measure x,y
destinationalign source
destination
adjust light
source
adjust lens
focus
process
measure
correlate
stage
source
correlate
stage
destination
calibrate
x,y
measurement
control x,y
destination
qualify
System Integration How-To107 Gerrit Muller
version: 0.2September 9, 2018
SINTorder
Roles and Responsibilities During the Integration Process
project leader
organization
resources
schedule
budget
systems architect/
engineer/integrator
system requirements
design inputs
test specification
schedule rationale
troubleshooting
participate in test
system tester
test
troubleshooting
report
engineers
design
component test
troubleshooting
participate in test
machine owner
maintain test model
support test
logistics and
administrative support
configuration
orders
administration
System Integration How-To108 Gerrit Muller
version: 0.2September 9, 2018
SINTroles
Simplified Process Diagram
company customer
Customer-Oriented Process
sales logistics production
Product Creation Process
Tech
nic
al P
rod
uct
D
ocu
men
tati
on
(TP
D)
supplier
goods
specs
Customer-
Oriented
Process
Product
Creation
Process
orders Operation
Processproduct
order
Purchasing
Processtender
TPD
req
uir
emen
ts
life
cycle
goods flow
System Integration How-To109 Gerrit Muller
version: 0.2September 9, 2018
SINTprocessDecomposition
Configuration Management Entities
companysupplier
Customer Oriented Process
Customer
Oriented
Process
goods flow
customer
sales logistics production
Product Creation Process
Tech
nic
al P
rod
uct
D
ocu
men
tati
on
(TP
D)
goods
specs
Product
Creation
Process
orders Operation
Processproduct
order
Purchasing
Processtender
TPD
req
uir
emen
ts
life
cycleTPD TPD
test models
test models
specifications
components
content of
pipelineproducts
product
tender
dataphysical
entitylegend
System Integration How-To110 Gerrit Muller
version: 0.2September 9, 2018
SINTconfigurationManagement
Typical Order of Integration Problems
1. The (sub)system does not build.
2. The (sub)system does not function.
3. Interface errors.
4. The (sub)system is too slow.
5. Problems with the main performance parameter, such as image quality.
6. The (sub)system is not reliable.
System Integration How-To111 Gerrit Muller
version: 0.2September 9, 2018
SINTproblems
Exercise Documentation
Make a design for the documentation structure of the case, take into account a.o.:• target audience per documentation module
• lifecycle
• author
• size (budget)Present (max 1 flip) the proposed documentation structure and the rationale.
Summary Module Supporting Processes112 Gerrit Muller
version: 0.2September 9, 2018
MSPexercise
Documentation
Requirements Entire DocumentationAccessibility for the readers
Low threshold for the readers
Low threshold for the authors
Completeness
Consistency
Maintainability
Scalability
Evolvability
Process to ensure the quality of the information
Requirements per DocumentHigh cohesion (within the unit)
Low coupling (outside of the unit)
Accessibility for the readers
Low threshold for the reader
Low threshold for the author
Manageable steps to create, review, and change
Clear responsibilities
Clear position and relation with the context
Well-defined status of the information
Timely availability
Decompose Large Documents
compound document
document
structure
overview
document
document
document
document
document
Recursive Decomposition
compound document
compound
document
compound
document compound document
overview
document
structure
overview
atomic
documentdocument
structure
overview
document
structure
overview
document
structure
atomic
document
atomic
document
compound
document
compound
document
Summary Module Supporting Processes113 Gerrit Muller
version: 0.2September 9, 2018
Documentation
Maximize Payload
title
identification
author
distribution
status
review
history
changes
front page
meta information
max 2 pages
diagrams
tables
lists
and ca 50%
text
1. aap
2. noot
3. mies
contents
2..18 pages
A3smultiple related views
digestable
(size limitation)
quantifications
practical
close to stakeholder experience
one topic
per A3
capture
"hot" topics
source: PhD thesis Daniel Borches http://doc.utwente.nl/75284/
Light Weight Review
draft
authorized
concept
final review= final check contents
authorization= check process
consultation
& review
- wide group of people,
with an active concern or
an expected contribution;
- many iterations
- multiple media:
+ meetings,
+ on paper
+ informal et cetera
specification specific Change Control Board
4 peoples/roles:
1 producer
1 consumer
1 context
1 independent
by "lowest" operational manager:
project leader, subsystem PL, ...
change
request
the author is responsible
for contents and
organization of the flow
(consults and review)
criteria for reviewers:
+ know how
+ critical
+ sufficient time
intentionally left blank
Summary Module Supporting Processes114 Gerrit Muller
version: 0.2September 9, 2018
Systems Integration
Integration Starts at Feasibility
design
0.
feasibility
1.
definition
2.
system
design
3.
engineering
4.
integration
& test
5.
field
monitoring
6.
product operational
life cycle
-1
strategy
integrate test
requirements and
specification
policy
testintegratedesignrequirementspolicy
Bottom-up
component
system function
product
subsystem
integratealpha
test
context
Alternatives for Early Integration
(modified)
existing
subsystems
(prototype)
new
subsystems
to-be-integrated
subsystem
physical
environment
simplecomplex
virtual
spectrum
virtual environment
stubssimulated
subsystems
physical
simulated
physical
reality
Propagation of Configuration Issuescompanysupplier
Customer Oriented Process
Customer
Oriented
Process
goods flow
customer
sales logistics production
Product Creation Process
Tech
nic
al P
rod
uct
D
ocu
men
tati
on
(TP
D)
goods
specs
Product
Creation
Process
orders Operation
Processproduct
order
Purchasing
Processtender
TPD
req
uir
emen
ts
life
cycleTPD TPD
test models
test models
specifications
components
content of
pipelineproducts
product
tender
dataphysical
entitylegend
Summary Module Supporting Processes115 Gerrit Muller
version: 0.2September 9, 2018