Theory of Constraints in Software Engineering
| Line 17: | Line 17: | ||
{| class="wikitable" | {| class="wikitable" | ||
| − | |||
! scope="row" colspan="2"| The Five Focusing Steps | ! scope="row" colspan="2"| The Five Focusing Steps | ||
|- | |- | ||
! scope="row"| Identify | ! scope="row"| Identify | ||
| − | |Identify the current constraint (the single part of the process that limits the rate at which the goal is achieved) | + | |Identify the current constraint (the single part of the process that limits the rate at which the goal is achieved). |
|- | |- | ||
! scope="row"|Exploit | ! scope="row"|Exploit | ||
| − | |Make quick improvements to the throughput of the constraint using existing resources (i.e. make the most of what you have) | + | |Make quick improvements to the throughput of the constraint using existing resources (i.e. make the most of what you have). |
|- | |- | ||
! scope="row"|Subordinate | ! scope="row"|Subordinate | ||
| − | |Review all other activities in the process to ensure that they are aligned with and truly support the needs of the constraint | + | |Review all other activities in the process to ensure that they are aligned with and truly support the needs of the constraint. |
|- | |- | ||
! scope="row"|Elevate | ! scope="row"|Elevate | ||
| − | |If the constraint still exists (i.e. it has not moved), consider what further actions can be taken to eliminate it from being the constraint. Normally, actions are continued at this step until the constraint has been “broken” (until it has moved somewhere else). In some cases, capital investment may be required | + | |If the constraint still exists (i.e. it has not moved), consider what further actions can be taken to eliminate it from being the constraint. |
| + | Normally, actions are continued at this step until the constraint has been “broken” (until it has moved somewhere else). | ||
| + | In some cases, capital investment may be required. | ||
|- | |- | ||
! scope="row"|Repeat | ! scope="row"|Repeat | ||
| − | |The Five Focusing Steps are a continuous improvement cycle. Therefore, once a constraint is resolved the next constraint should immediately be addressed. This step is a reminder to never become complacent – aggressively improve the current | + | |The Five Focusing Steps are a continuous improvement cycle. Therefore, once a constraint is resolved the next constraint should immediately be addressed. |
| + | This step is a reminder to never become complacent – aggressively improve the current constraint… | ||
| + | and then immediately move on to the next constraint. | ||
|} | |} | ||
| + | === The Thinking processes === | ||
| + | The thinking processes are composed of cause-effect tools along with necessary condition thinking tools and a set of logic rules. Three of the diagrams that are going to be introduced use cause-and-effect logic which strives to first identify the root causes of undesirable effects and then remove the undesirable effects without creating new ones. The other two, that will be introduced, use necessary condition thinking, in order to achieve one condition the other one has to occur [6]. | ||
| + | When using the thinking processes the following three questions are answered: | ||
| + | # What needs to be changed? | ||
| + | #What should it be changed to? | ||
| + | #What actions will cause the change? | ||
| − | |||
=== Throughput Accounting === | === Throughput Accounting === | ||
Revision as of 09:43, 15 September 2016
Theory of Constraints (TOC) is a methodology invented by Dr. Eliyahu M. Goldratt, a scientist, physicist, author, educator and consultant [3]. With the methodology the most important limiting factor, that hinders a goal to be achieved, is identified and then that factor (i.e. constraint) is improved until it is no longer the limiting factor. Since Goldratt introduced the Theory of Constraints in his bestselling 1984 novel, “The Goal”, the methodology has continued to evolve and develop into many different fields including Software Engineering.[2]
The goals of Software Engineering is the creation of software systems that meet the needs of customers and are efficient, maintainable and reliable in addition the systems should meet project schedules and budgets along with being produced in an economical way [1, p21]. Applying analogous set of approaches to the development of software, one can expect the production of software that meets the goals of Software Engineering [1, p22].
This article will introduce how Theory of Constraints can be used in Software Engineering along with guidance to apply the methodology.
Contents |
Theory of Constraints
Before improving a system or any part of it, one must define system’s global goal and the measurements that will enable him to judge the effect of any subsystem and any local decision on the goal. When measurements have been defined, the factor that limits the system to reach its goal can be found; constraint [5, page 5].
Theory of Constraints (TOC) is a methodology that is used to identify the most important constraints in a system and then improving the constraint until it is no longer the limiting one. According to TOC every complex system consists of multiple linked activities and one of these activities is a constraint upon the whole system.
Theory of Constraints provides powerful set of tools to achieve the ultimate goal of companies: Make profit.
The Five Focusing Steps
TOC provides the Five Focusing Steps to identify and eliminate the constraints, the steps are described in the table below:
| The Five Focusing Steps | |
|---|---|
| Identify | Identify the current constraint (the single part of the process that limits the rate at which the goal is achieved). |
| Exploit | Make quick improvements to the throughput of the constraint using existing resources (i.e. make the most of what you have). |
| Subordinate | Review all other activities in the process to ensure that they are aligned with and truly support the needs of the constraint. |
| Elevate | If the constraint still exists (i.e. it has not moved), consider what further actions can be taken to eliminate it from being the constraint.
Normally, actions are continued at this step until the constraint has been “broken” (until it has moved somewhere else). In some cases, capital investment may be required. |
| Repeat | The Five Focusing Steps are a continuous improvement cycle. Therefore, once a constraint is resolved the next constraint should immediately be addressed.
This step is a reminder to never become complacent – aggressively improve the current constraint… and then immediately move on to the next constraint. |
The Thinking processes
The thinking processes are composed of cause-effect tools along with necessary condition thinking tools and a set of logic rules. Three of the diagrams that are going to be introduced use cause-and-effect logic which strives to first identify the root causes of undesirable effects and then remove the undesirable effects without creating new ones. The other two, that will be introduced, use necessary condition thinking, in order to achieve one condition the other one has to occur [6].
When using the thinking processes the following three questions are answered:
- What needs to be changed?
- What should it be changed to?
- What actions will cause the change?
Throughput Accounting
Theory of Constraints in Software Engineering
- The methodology is connected to Software Engineering and explained how it can be used in Software Engineering
(Extra) When applying TOC the constraints that cause inventory or buffer have to be identified and managed. Inventory in Software Engineering can be expressed in different ways, depending on the software methodology used. A unit of inventory could be, for instance:
- A Use Case in UDP [a.k.a. RUP].
- A Story Point in XP (eXtreme Programming).
- A Feature in FDD (Feature-Driven Development).
- A Backlog Item in Scrum.
- A Function Point in traditional SDLC structured methods.
[4]
Applying TOC in Software Engineering
- The steps in applying TOC are explained and connected to Software Engineering
