Based-on slide Ivan Marsic
Rekayasa Perangkat Lunak
Untuk SISTEM KOMPUTER
Kuliah 4: Memahami Masalah dan
Membagi Pekerjaan
Mohammad Iqbal
Based-on slide Ivan Marsic
Topik
Dekomposisi : Partitioning vs. Projection
Divisi pekerja
Mengurangi komunikasi intra-team
Permasalahan umum Software Engineering
2
Mengapa Harus membagi
Problem/Proyek
“…main value [of social skills] lies in the relationship
between colleagues: people who can divide up tasks
quickly and effectively between them form more
productive teams.”—David Deming (Harvard U. & NBER)
Strategi umum problem-solving :
“divide-and-conquer”
Divisi pekerja pada tim developer
Mendukung fleksibilitas dan evolusi masa datang
dengan memisah-kan bagian yang tidak berhubungan,
sehingga dapat diselesaikan secara individual
(“Pemisahan konsentrasi pekerjaan”)
– Different team members can focus on different sub-problems and
not worry about everything
3
4
Bagaimana Pemula membagi
Pekerjaannya
List the components of the system-to-be
Each sub-group of one or more team members
is assigned a different component to develop
– One or more team members is assigned to
“write documentation”
User Interface
Business Logic
and Algorithms
Database/
Network
Documentation
“Chain” organization—every link is critical
If any link fails, the whole project fails
– Separation of concerns is impossible
5
Dekomposisi:
Projection vs. Partitioning
Projection:
:Partitioning
Projection-based decomposition helps us understand the components
in the context of their use, relative to other parts of the system.
6
Contoh : Otomatisasi Dekomposisi
Restoran dengan Teknik Partitioning
Developer Team Φ
Developer Team α
Subgroup α-RED
User Interface
Subgroup α-GREEN
Business Logic
and Algorithms
Subgroup α-BLUE
Subgroup α-PURPLE
Database/
Network
Documentation
7
Contoh : Otomatisasi Restoran
Beban Komunikasi
Developer Team Φ
Developer Team α
Interface for
what functions?
User Interface
Function-1:
description
Function-2:
description
…
Business Logic
and Algorithms
Tables for
what data?
Database/
Network
What to
write about?
Documentation
8
Contoh : Otomatisasi Restoran
Kekurangan Pendekatan Team α
Communication overhead:
– Most time spent in communication and “documentation
writing”
– No time for creative software development
Failure-prone:
– If any sub-group doesn’t deliver, the whole project fails
Each student learns only one aspect of
software development
Ownership fuzzy or one “leader”
claims all the credit
I did all coding!
Superhero
Contoh : Otomatisasi Dekomposisi
Restoran dengan Teknik Projection
Developer Team Φ
Developer Team α
Different way of
“slicing” the project:
Subgroup Subgroup Subgroup
Φ-RED
Φ-GREEN Φ-BLUE
– Instead of horizontal
slicing, we have vertical
slicing—”stacks”
Customer-related
functions
Each “stack” can be
done independently of
other stacks,
as a mini-project
Separation of concerns!
Kitchen-related
functions
Managementrelated
functions
Shared Infrastructure
10
Contoh : Otomatisasi Dekomposisi
Restoran dengan Teknik Projection
Developer Team Φ
Developer Team α
Team communication is
simple:
What do we have
in common?
They only need to define
shared interfaces (“APIs”)
and can focus on creative
software development
What is inside of each
“stack” is not discussed
with other sub-teams
—for others, the contents
of your “stack” is hidden—
they see a black box with
defined interface / APIs
(“information hiding”)
Subgroup Subgroup Subgroup
Φ-RED
Φ-GREEN Φ-BLUE
Customer-related
functions
Kitchen-related
functions
Managementrelated
functions
Shared Infrastructure
11
Contoh : Otomatisasi Restoran
Kelebihan Pendekatan Team Φ
Increased productivity:
Minimizes the amount of communication needed to coordinate the work
– more time to focus on creative software development
Failure resilience:
Reduces the dependency on other team members—if they fail to deliver,
you can still succeed and demonstrate your mini-project
(Unlike chain-organization, where a link failure leads to project failure,
each “stack” can succeed independently of others)
Each student learns all aspects of software development
Ownership visibility:
Each mini-project can be demonstrated alone
(If expert-based, who demonstrates UI, or dBase, or …?)
Customer friendly:
The customer (or class instructor) knows whom to talk about every
aspect of a given functional feature
Requirements traceability, from inception to implementation
12
Apakah “Shared Infrastructure”?
Needs to be discovered, as we will learn in
subsequent lectures
May be a relational database, so whole team
needs to discuss together the design of the
shared tables
May be data items communicated via messages
May be “services” accessed by method calls
13
Membagi Pekerjaan dengan Problem
atau dengan Solusi
By problem: Different team members responsible to solve different sub-problems or
develop different “features” of the system
–
–
–
Suitable for any level of expertise, particularly if uncertain about other team members’ skills and ability
to deliver on time ( highly recommended for novices/students)
Advantage: dependency on other team members is reduced—the development of different features
can progress independently, at their own pace
Drawback: Potential redundancies because different teammates may need to develop same/similar
parts to make their “feature” work independently of others
By solution: Different team members responsible for different parts of the system
–
–
Advantage: everyone can focus on one area of expertise
Drawbacks:
•
•
–
–
–
Developers need to know a lot about the solution (i.e., parts of the “system” and their relationships) before detailed analysis of
the sub-problems.
If solution parts are not precisely specified, there will be a great uncertainty about interfacing the parts and integrating into the
whole system.
Suitable for highly-experienced specialists, not for beginners (i.e., not for students), working on a
familiar problem
Always watch for fallback solutions in case some parts are not ready on time or problematic
Right now, you have no “area of expertise”—otherwise you wouldn’t be a student in this class!
14
Contoh Yang Berlawanan
Car subsystems -- different companies
produce different subsystems!
Why cannot we do the same?!
… but, you are not at this level of
understanding of your problem!
15
Tanggapan Pada Contoh Yang
Berlawanan (1)
Actually, you are at this level of understanding
of your problem:
Tanggapan Pada Contoh Yang
Berlawanan (2)
Before we could do this…
…there was a lot of trial-and-error
and each subsystem evolved independently
to solve a different sub-problem
Reliable 3rd-party providers of precisely-defined subsystems!
17
Dekomposisi Problem
System requirements provide the “projection axes” for problem decomposition
—different subsets of requirements identify different sub-systems.
18
Dekomposisi Problem
We assume that the computer/software helps the user
to achieve a business goal in the problem domain
Problem domains can be virtual (e.g., text documents,
relational databases), or physical world (a device to
control, a person to notify and prompt to action)
Problem types:
1. Transforming one virtual object to another (document format
conversion, e.g., from MS Word to PDF)
2. Modifying a virtual object (e.g., document editing)
3. Automatically controlling behavior of a physical object (e.g.,
thermostat)
4. Manually controlling behavior of a physical object (e.g., drone
flying)
5. Observing behavior of a physical object (e.g., traffic monitoring)
19
Kebutuhan Sistem Umum
REQ-1: Map input data to output data as said by
given rules
REQ-2: Allow repository (or document) editing,
where “repository” is a collection of data
REQ-3: Automatically control a physical
object/device
REQ-4: Interactively control a physical
object/device
REQ-5: Monitor and display information about an
object
Only a “5-dimensional” problem space!
(Problem complexity can vary independently along each dimension)
Note:
These “typical requirements” will be discussed further under “Problem Frames”
Problem Umum Software Eng.
1. User works with computer system
(problem domain is “virtual”, not physical)
1.a) System transforms input document to output document
REQ-1: Map input data to output
data as said by given rules
IN doc
User
System
OUT doc
1.b) User edits information stored in a repository
System
System
REQ-2: Allow repository editing, where
“repository” is a collection of data
Repository
User
2. Computer system controls the (physical) problem domain
(user not involved)
System
REQ-3: Automatically control
a physical object/device
Problem domain
3.a) System observes the problem domain and displays information
3. Computer system intermediates between
the user and the problem domain
REQ-5: Monitor and display
information about an object
User
User
System
Problem domain
System
Problem domain
3.b) System controls the problem domain as commanded by the user
REQ-4: Interactively control
a physical object/device
21
User
System
Problem domain
Contoh : Dekomposisi Problem
[ Case Study 1: Safe Home Access ]
• REQ1: keep door locked and auto-lock
Required Behavior
• REQ2: lock when “LOCK” pressed
Commanded Behavior
• REQ3: unlock when valid key provided
• REQ4: allow mistakes but prevent dictionary attacks
• REQ5: maintain a history log
Information Display (database is the “display”)
• REQ6: adding/removing users at runtime
Simple Editing
• REQ7: configuring device activation preferences
• REQ8: inspecting the access history
• REQ9: filing inquiries
Simple Editing
Simple Editing
Information Display
Contoh : Dekomposisi Problem
[ Case Study 2: Investment Fantasy League ]
•
REQ1: view market prices and volumes
•
REQ2: place a trade
•
REQ3: execute trades when conditions matched
Information Display
– Domains: exchange, display
Simple Editing
– Domains: investor, tradable-securities, pending-trades
– Domains: exchange, pending-trades
•
REQ4: generate periodic report
•
REQ5: generate leaderboard
•
REQ6: view leaderboard
•
REQ7: start a trading group/clique
•
REQ8: invite to a trading group/clique
– Domains: portfolio, report
Transformation
Transformation
– Domains: all-portfolios, leaderboard
– Domains: leaderboard, display
Information Display
– Domains: investor, group
– Domains: investor, friends, group
Required Behavior
Simple Editing
Commanded Behavior
Untuk SISTEM KOMPUTER
Kuliah 4: Memahami Masalah dan
Membagi Pekerjaan
Mohammad Iqbal
Based-on slide Ivan Marsic
Topik
Dekomposisi : Partitioning vs. Projection
Divisi pekerja
Mengurangi komunikasi intra-team
Permasalahan umum Software Engineering
2
Mengapa Harus membagi
Problem/Proyek
“…main value [of social skills] lies in the relationship
between colleagues: people who can divide up tasks
quickly and effectively between them form more
productive teams.”—David Deming (Harvard U. & NBER)
Strategi umum problem-solving :
“divide-and-conquer”
Divisi pekerja pada tim developer
Mendukung fleksibilitas dan evolusi masa datang
dengan memisah-kan bagian yang tidak berhubungan,
sehingga dapat diselesaikan secara individual
(“Pemisahan konsentrasi pekerjaan”)
– Different team members can focus on different sub-problems and
not worry about everything
3
4
Bagaimana Pemula membagi
Pekerjaannya
List the components of the system-to-be
Each sub-group of one or more team members
is assigned a different component to develop
– One or more team members is assigned to
“write documentation”
User Interface
Business Logic
and Algorithms
Database/
Network
Documentation
“Chain” organization—every link is critical
If any link fails, the whole project fails
– Separation of concerns is impossible
5
Dekomposisi:
Projection vs. Partitioning
Projection:
:Partitioning
Projection-based decomposition helps us understand the components
in the context of their use, relative to other parts of the system.
6
Contoh : Otomatisasi Dekomposisi
Restoran dengan Teknik Partitioning
Developer Team Φ
Developer Team α
Subgroup α-RED
User Interface
Subgroup α-GREEN
Business Logic
and Algorithms
Subgroup α-BLUE
Subgroup α-PURPLE
Database/
Network
Documentation
7
Contoh : Otomatisasi Restoran
Beban Komunikasi
Developer Team Φ
Developer Team α
Interface for
what functions?
User Interface
Function-1:
description
Function-2:
description
…
Business Logic
and Algorithms
Tables for
what data?
Database/
Network
What to
write about?
Documentation
8
Contoh : Otomatisasi Restoran
Kekurangan Pendekatan Team α
Communication overhead:
– Most time spent in communication and “documentation
writing”
– No time for creative software development
Failure-prone:
– If any sub-group doesn’t deliver, the whole project fails
Each student learns only one aspect of
software development
Ownership fuzzy or one “leader”
claims all the credit
I did all coding!
Superhero
Contoh : Otomatisasi Dekomposisi
Restoran dengan Teknik Projection
Developer Team Φ
Developer Team α
Different way of
“slicing” the project:
Subgroup Subgroup Subgroup
Φ-RED
Φ-GREEN Φ-BLUE
– Instead of horizontal
slicing, we have vertical
slicing—”stacks”
Customer-related
functions
Each “stack” can be
done independently of
other stacks,
as a mini-project
Separation of concerns!
Kitchen-related
functions
Managementrelated
functions
Shared Infrastructure
10
Contoh : Otomatisasi Dekomposisi
Restoran dengan Teknik Projection
Developer Team Φ
Developer Team α
Team communication is
simple:
What do we have
in common?
They only need to define
shared interfaces (“APIs”)
and can focus on creative
software development
What is inside of each
“stack” is not discussed
with other sub-teams
—for others, the contents
of your “stack” is hidden—
they see a black box with
defined interface / APIs
(“information hiding”)
Subgroup Subgroup Subgroup
Φ-RED
Φ-GREEN Φ-BLUE
Customer-related
functions
Kitchen-related
functions
Managementrelated
functions
Shared Infrastructure
11
Contoh : Otomatisasi Restoran
Kelebihan Pendekatan Team Φ
Increased productivity:
Minimizes the amount of communication needed to coordinate the work
– more time to focus on creative software development
Failure resilience:
Reduces the dependency on other team members—if they fail to deliver,
you can still succeed and demonstrate your mini-project
(Unlike chain-organization, where a link failure leads to project failure,
each “stack” can succeed independently of others)
Each student learns all aspects of software development
Ownership visibility:
Each mini-project can be demonstrated alone
(If expert-based, who demonstrates UI, or dBase, or …?)
Customer friendly:
The customer (or class instructor) knows whom to talk about every
aspect of a given functional feature
Requirements traceability, from inception to implementation
12
Apakah “Shared Infrastructure”?
Needs to be discovered, as we will learn in
subsequent lectures
May be a relational database, so whole team
needs to discuss together the design of the
shared tables
May be data items communicated via messages
May be “services” accessed by method calls
13
Membagi Pekerjaan dengan Problem
atau dengan Solusi
By problem: Different team members responsible to solve different sub-problems or
develop different “features” of the system
–
–
–
Suitable for any level of expertise, particularly if uncertain about other team members’ skills and ability
to deliver on time ( highly recommended for novices/students)
Advantage: dependency on other team members is reduced—the development of different features
can progress independently, at their own pace
Drawback: Potential redundancies because different teammates may need to develop same/similar
parts to make their “feature” work independently of others
By solution: Different team members responsible for different parts of the system
–
–
Advantage: everyone can focus on one area of expertise
Drawbacks:
•
•
–
–
–
Developers need to know a lot about the solution (i.e., parts of the “system” and their relationships) before detailed analysis of
the sub-problems.
If solution parts are not precisely specified, there will be a great uncertainty about interfacing the parts and integrating into the
whole system.
Suitable for highly-experienced specialists, not for beginners (i.e., not for students), working on a
familiar problem
Always watch for fallback solutions in case some parts are not ready on time or problematic
Right now, you have no “area of expertise”—otherwise you wouldn’t be a student in this class!
14
Contoh Yang Berlawanan
Car subsystems -- different companies
produce different subsystems!
Why cannot we do the same?!
… but, you are not at this level of
understanding of your problem!
15
Tanggapan Pada Contoh Yang
Berlawanan (1)
Actually, you are at this level of understanding
of your problem:
Tanggapan Pada Contoh Yang
Berlawanan (2)
Before we could do this…
…there was a lot of trial-and-error
and each subsystem evolved independently
to solve a different sub-problem
Reliable 3rd-party providers of precisely-defined subsystems!
17
Dekomposisi Problem
System requirements provide the “projection axes” for problem decomposition
—different subsets of requirements identify different sub-systems.
18
Dekomposisi Problem
We assume that the computer/software helps the user
to achieve a business goal in the problem domain
Problem domains can be virtual (e.g., text documents,
relational databases), or physical world (a device to
control, a person to notify and prompt to action)
Problem types:
1. Transforming one virtual object to another (document format
conversion, e.g., from MS Word to PDF)
2. Modifying a virtual object (e.g., document editing)
3. Automatically controlling behavior of a physical object (e.g.,
thermostat)
4. Manually controlling behavior of a physical object (e.g., drone
flying)
5. Observing behavior of a physical object (e.g., traffic monitoring)
19
Kebutuhan Sistem Umum
REQ-1: Map input data to output data as said by
given rules
REQ-2: Allow repository (or document) editing,
where “repository” is a collection of data
REQ-3: Automatically control a physical
object/device
REQ-4: Interactively control a physical
object/device
REQ-5: Monitor and display information about an
object
Only a “5-dimensional” problem space!
(Problem complexity can vary independently along each dimension)
Note:
These “typical requirements” will be discussed further under “Problem Frames”
Problem Umum Software Eng.
1. User works with computer system
(problem domain is “virtual”, not physical)
1.a) System transforms input document to output document
REQ-1: Map input data to output
data as said by given rules
IN doc
User
System
OUT doc
1.b) User edits information stored in a repository
System
System
REQ-2: Allow repository editing, where
“repository” is a collection of data
Repository
User
2. Computer system controls the (physical) problem domain
(user not involved)
System
REQ-3: Automatically control
a physical object/device
Problem domain
3.a) System observes the problem domain and displays information
3. Computer system intermediates between
the user and the problem domain
REQ-5: Monitor and display
information about an object
User
User
System
Problem domain
System
Problem domain
3.b) System controls the problem domain as commanded by the user
REQ-4: Interactively control
a physical object/device
21
User
System
Problem domain
Contoh : Dekomposisi Problem
[ Case Study 1: Safe Home Access ]
• REQ1: keep door locked and auto-lock
Required Behavior
• REQ2: lock when “LOCK” pressed
Commanded Behavior
• REQ3: unlock when valid key provided
• REQ4: allow mistakes but prevent dictionary attacks
• REQ5: maintain a history log
Information Display (database is the “display”)
• REQ6: adding/removing users at runtime
Simple Editing
• REQ7: configuring device activation preferences
• REQ8: inspecting the access history
• REQ9: filing inquiries
Simple Editing
Simple Editing
Information Display
Contoh : Dekomposisi Problem
[ Case Study 2: Investment Fantasy League ]
•
REQ1: view market prices and volumes
•
REQ2: place a trade
•
REQ3: execute trades when conditions matched
Information Display
– Domains: exchange, display
Simple Editing
– Domains: investor, tradable-securities, pending-trades
– Domains: exchange, pending-trades
•
REQ4: generate periodic report
•
REQ5: generate leaderboard
•
REQ6: view leaderboard
•
REQ7: start a trading group/clique
•
REQ8: invite to a trading group/clique
– Domains: portfolio, report
Transformation
Transformation
– Domains: all-portfolios, leaderboard
– Domains: leaderboard, display
Information Display
– Domains: investor, group
– Domains: investor, friends, group
Required Behavior
Simple Editing
Commanded Behavior