Problem & WorkDecomposition

Dr. I. B. Lal
L. N. Mishra College of Business Management
LECTURE 3: Understanding the Problem
and Dividing the Work
 Topics

Labor Division vs. Expertise Division

Reducing Inter-team Communication

Decomposition by Partitioning vs. Projection

Key message:
Divide the work by the problems that you want to solve,
not by the expertise in software tools:
The problem provides the purpose to the expert knowledge.
Expert knowledge is a resource to be managed, based on the problem needs.

3
 Why We Want To
Subdivide Problems/Projects
 “…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.”—


– It may be that a solution cannot be made by a single person (“hands limitation”)

or cannot be comprehended by a single person (“mind limitation”)
– Different team members can focus on different sub-problems and not worry about
everything
– Different ways of dividing the work—which are better or best?
• This depends on the problem, which can be discovered only by iterating creative and evaluative steps
– Therefore the developer team must be agile—ready to reconfigure and reassign the work as insights are
gained from the experience of testing their ideas in practice

“When we think what we might have accomplished if we had been able to devote this time to experiments, we feel very sad, but it 4
is always easier to deal with things than with men, and no one can direct his life entirely as he would choose.” —Wilbur Wright
5
 Effort Division vs. Expertise Division

Effort (subproblems solved/features implemented)

Expertise (skills/tools/algorithms)

Division by expertise

Division by subproblems

6
 Mirroring Hypothesis
a.k.a. Conway's Law

– “organizations which design systems ... are constrained to
produce designs which are copies of the communication
structures of these organizations”
Developer organization: Software modules:

Mirroring
communication
structures


– If the developer team’s structure is mirroring the product structure,
then the product structure should also be mirroring the structure of
the user group that will use this product
• Spatial structure: different user roles and their relationships
• Temporal structure: user (or users) in different contexts over time
7
How Beginners Divide the Work



– One sub-group is assigned to “write documentation”

User Interface Business Logic Database/

Documentation
and Algorithms Network

– Separation of concerns is impossible

8
Example: Restaurant Automation
Requirements




9
 Example: Restaurant Automation
Decomposition by Partitioning the Solution
Developer Team α Developer Team β

Subgroup α-RED Subgroup α-GREEN Subgroup α-BLUE Subgroup α-PURPLE

Business Logic Database/

User Interface Documentation 10
a.k.a. “Front end” and Algorithms Network
a.k.a. “Backend”
Example: Restaurant Automation
Communication Overhead
Developer Team α Developer Team β

Function-1:
{ description }
Function-2:
Interface for { description } Tables for
what functions? … what data?
What to
write about?

Business Logic Database/

User Interface Documentation 11
and Algorithms Network
Example: Restaurant Automation
Drawbacks of Team α Approach



– The time to implementation depends on the slowest sub-group

– Most time spent in communication and “documentation writing”
– No time for creative software development

– If any sub-group doesn’t deliver, the whole project fails


 I did all coding!

Superhero
 Identifying Subproblems
by Spatial Structure of User Roles
Example: Restaurant Automation
Floor Staff Kitchen Staff Management

• Available
• Occupied Table
- Departure estimate reservations
• Dirty
Host Table
occupancy

Payments Inventory Employee

information
Busboy Chef Manager

Menu

Statistics

Orders
Rationale:
If the developer team’s structure is mirroring the product structure,
Waiter then the product structure should also be mirroring the structure of 13
the user group whose work this product will support
 Example: Restaurant Automation
Decomposition by Projection to Sub-problems
Developer Team α Developer Team β

 Subgroup Subgroup Subgroup

β-RED β-GREEN β-BLUE
– Instead of horizontal slicing (by
solution),
we have vertical slicing—
”stacks” (by sub-problems)
Customer-facing
sub-problem

Kitchen-related
sub-problem

 Management-
related
sub-problem
14
Shared Infrastructure
 Example: Restaurant Automation
Decomposition by Projection
Developer Team α Developer Team β


Subgroup Subgroup Subgroup
What do we have β-RED β-GREEN β-BLUE
in common?

Customer-facing
sub-problem


Kitchen-related
sub-problem

Management-
related
sub-problem
15
Shared Infrastructure
Example: Restaurant Automation
Benefits of Team β Approach


– Every sub-group can have implementation feedback as soon as their part is working


–  more time to focus on creative software development


16
 Identifying Subproblems
by User Context
Example: Safe Home Access

User User User

Arriving/Departing at Home Remote

User Authorized users User User

& Valid keys

Access Device
history status

Rationale:
If the developer team’s structure is mirroring the product structure,
then the product structure should also be mirroring the structure of
the user contexts whose work this product will support 17
 Why Communication Required by
Problem-based < Solution-based ?

Problem-based Solution-based
work organization: work organization:

(a) (b)

Sub-problem 1 Sub-problem 2 Sub-problem 3

User Business Logic Database/

Documentation
Interface and Algorithms Network
User
Interface (sub-system 1) (sub-system 2) (sub-system 3) (sub-system 4)

Business Logic
and Algorithms

Database/
Network

Documentation

18
Shared Infrastructure
What is “Shared Infrastructure”?


– A relational database, so the whole team needs to
design the shared tables
– Data items communicated via messages, so the whole
team needs to discuss the communication protocol and
message format
– “Services” accessed by method calls, e.g., data
analysis, pattern recognition, user authentication, etc.
– Software configuration management (SCM) system
19
Divide Work by Problem vs. by Solution


– 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)
– Advantages: Short time to feedback from implementation, mutually independent between the sub-groups
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


– Advantage: everyone can focus on one area of expertise
– Drawbacks:
• Long time to implementation and lack of early feedback
• 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!

20
 Counterexample?


– They did all the work of analysis and design and arrived at
commonly-accepted standards of subsystem designs!
21
 Counterexample Rebuttal (1)


 Counterexample Rebuttal (2)



23
Student Project Organization
 Step 1: Form Sub-groups

 


– “Requirements projection” through the development

lifecycle, from requirements, through design, to code
Step 2: Divide Work to Sub-groups


Step 2: Divide Work to Sub-groups
 Notes on Teamwork


– Typical symptom: team member is not responding to emails or

phone calls


Proposal Preparation Notes (1)



Proposal Preparation Notes (2)

– Therefore, review the existing state-of-the-art and

explain how different or better your proposed system
will be
– Explain why you believe your system will help achieve
the goals that you set. To make your claims credible,
cite exiting studies or other sources
Q: divide responsibilities based on
expertise?




Q: divide responsibilities based on
expertise?

– Advantages:
• Increased productivity:
Minimizes the amount of communication needed to coordinate the
work
• Failure resilience:
Reduces the dependency on other team members—if they fail to
deliver, you can still succeed and demonstrate your mini-project
• Ownership visibility:
Each mini-project can be demonstrated alone
(If expert-based, who demonstrates UI, or dBase, or …?)
… but I don’t know everything!?

– Seek help in areas of weakness, and provide help to

others in your areas of strength
 Going Forward …

– Anticipate potential problems with other “mini-projects”

within your project
[ Recall the airline safety instruction: “Put your own oxygen mask
before assisting others.” ]


34