Theory of Constraints in Software Engineering

From apppm
(Difference between revisions)
Jump to: navigation, search
(→‎Annoted Bibliography)
Line 281: Line 281:
 
== Annoted Bibliography ==
 
== Annoted Bibliography ==
 
<span style="color:red">THIS WILL BE FINISHED AFTER FIRST PEER REVIEW</span>
 
<span style="color:red">THIS WILL BE FINISHED AFTER FIRST PEER REVIEW</span>
−
 
−
* <ref name="TOCMAN">McMullen, Jr., Thomas B. "Introduction to the Theory of Constraints (TOC) Management System", ''APICS'' Pub.1998</ref>
 
  
 
* <ref name="Lean"> Unknown. [http://www.leanproduction.com/theory-of-constraints.html "Theory of Constraints"], ''Lean Production'', Date unknown. Retrieved on 10 September 2016. </ref>
 
* <ref name="Lean"> Unknown. [http://www.leanproduction.com/theory-of-constraints.html "Theory of Constraints"], ''Lean Production'', Date unknown. Retrieved on 10 September 2016. </ref>

Revision as of 22:48, 16 September 2016

Theory of Constraints (TOC) is a methodology invented by Dr. Eliyahu M. Goldratt a scientist, physicist, author, educator and consultant[1]. 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.[3] Applying analogous set of approaches to the development of software, one can expect the production of software that meets the goals of Software Engineering. [3]

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 constraint that limits the system to reach its goal can be found. [4]

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 . Three of these tools will be introduced in the following chapter.

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 [2]
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 (TPs) are composed of cause-effect tools along with necessary condition thinking tools and a set of logic rules. When the constraint is caused by polices or behaviors, or in other more complex situations, the constraint may be harder to pinpoint, and in such cases the TPs are more useful in deciding what to change and what to change to. The Five Focusing steps focus on the constraint while the TPs focus on the factors that are currently preventing the system from achieving its goals. The Thinking Processes focus on the factors that are currently preventing the system from achieving its goals. By identifying symptoms within the system, the TPs provide evidence that the system is not performing as desired [5].

According to Kim, Mabin and Davies the original suite of Thinking Processes comprises five logic diagrams and a set of logic rules but in recent years’ development of variant Thinking Processes tools has created a need for clarity about the nature and use of such tools among academics, practitioners and particularly newcomers [6]. Therefore, the original five diagrams will be focused on in this chapter.

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 tools use necessary condition thinking: in order to achieve target A we must have B [5].

When using the thinking processes the following three questions are answered:

  1. What needs to be changed?
  2. What should it be changed to?
  3. What actions will cause the change?

Examples of tools that have been formalized as a part of the Thinking Processes are described in the table below along with their objectives:

Diagram Description Objective
Current Reality Trees (CRT) The CRT is constructed from top-down, where undesirable effects are identified and traced back to their root cause with cause-and-effect logic. The CRT is designed to answer the question What to change? The tool is particularly effective tool if the constraint is a policy as opposed to a physical limitation of the existing system [6].
  • Provide the basis for understanding complex systems
  • Identify undesirable effects exhibited by a system
  • Relate undesirable effects through a logical chain of cause and effect to root causes
  • Identify, where possible, a core problem that eventually produces 70% or more of the system’s undesirable effects.
  • Determine at what points the root causes and/or core problem lie beyond one's span of control or sphere of influence
  • Isolate those few causative constraints)that must be addressed in order to realize the maximum improvement of the system
  • Identify the one simplest change to make that will have the greatest positive impact on the system.[6]
Evaporating Clouds (EC) When the CRT has been used to identify what to change, the EC is used to identify a solution to what should be changed to, to eliminate undesirable effects. Two opposing needs are identified and the common goal that both are trying to fulfill.... TO BE FINISHED
  • Confirm that the conflict exists
  • Identify the conflict perpetuating a major problem
  • Resolve conflict
  • Avoid compromise
  • Create solutions in which both sides win
  • Create new ‘breakthrough’ solutions to problems
  • Explain in depth why a problem exists
  • Identify all assumptions underlying problems and conflicting relationships. [6]
Future Reality Trees (FRT) Once a solution has been identified with the EC method next step is to start building the Future Reality Tree (FRT). The diagram shows the future state and identifies what to change along with its impact on the future of the organization. FRT is designed and considered to test the solution, using the effect-cause-effect method.
  • Enables effectiveness testing of new ideas before committing resources to implementation
  • Determines whether proposed system changes will produce the desired effects without creating negative side effects
  • Reveals through negative branches, whether (and where) proposed changes will create new or collateral problems as they solve old problems, and what additional actions are necessary to prevent any such negative side effects from occurring
  • Provides a means of making beneficial effects self-sustaining through deliberate incorporation of positive reinforcing loops
  • Provides a means of assessing the impacts of localized decisions on the entire system
  • Provides an effective tool for persuading decision makers to support a desired course of action
  • Serves as an initial planning tool.[6]
Prerequisite Trees (PRT) When identification of what to change and what to change to has been done, the implementation of the solution is next. Prerequisite Trees are used to identify obstacles that prevent the solution from the EC to be implemented. The goal is to identify the critical elements, or obstacles, standing in the way of reaching the objective.
  • To identify obstacles preventing achievement of a desired course of action, objective, or injection (solution idea arising from the Evaporating Cloud)
  • To identify the remedies or conditions necessary to overcome or otherwise neutralise obstacles to a desired course of action, objective or injection
  • To identify the required sequence of actions needed to realise a desired course of action
  • To identify and depict unknown steps to a desired end when one does not know precisely how to achieve them[6]
Transition Trees The transition trees help to determine the actions necessary to implement the solution.
  • Provide a step by step method for action implementation
  • Enable effective navigation through a change process
  • Detect deviation in progress toward a limited objective
  • Adapt or redirect effort, should plans change
  • Communicate the reasons for action to others
  • Execute the injections developed in the EC or FRT
  • Attain the intermediate objectives identified in a PRT
  • Develop tactical action plans for conceptual or strategic plans
  • Preclude undesirable effects from arising out of implementation. [6]

The Throughput Accounting

Throughput Accounting is TOC´s approach to accounting, a decision tool designed to ensure decisions that might have financial impact take a holistic perspective and do not optimize on metric or area of the business at the expense of the whole. Throughput accounting takes a decision regarding the constraint and values it according to financial terms because it acknowledges that the constraint determines capacity, hence profit potential of the company.[7] Cost accounting is known to perform gross margin analysis at the product level while Throughput Accounting determines profitability at the system level and looks at the production process to be a single system that must be optimized. Irrespective of the number of units created, Throughput Accounting assumes most production costs are required to maintain a system of production along with assuming most production costs do not vary directly with incremental production of a single product.

Constraints

Constraints are like said before, anything that prevents the organization from making progress towards its goal. Constraints can take many forms other than equipment and there are differing opinions how to categorize them, one approach is shown in the table below:

Categorized constraints [2]
Constraint Description
Physical Typically equipment, but can also be other tangible items, such as material shortages, lack of people, or lack of space.
Policy Required or recommended ways of working. May be informal (e.g. described to new employees as “how things are done here”). Examples include company procedures (e.g. how lot sizes are calculated, bonus plans, overtime policy), union contracts (e.g. a contract that prohibits cross-training), or government regulations (e.g. mandated breaks).
Paradigm Deeply ingrained beliefs or habits. For example, the belief that “we must always keep our equipment running to lower the manufacturing cost per piece”. A close relative of the policy constraint.
Market Occurs when production capacity exceeds sales (the external marketplace is constraining throughput). If there is an effective ongoing application of the Theory of Constraints, eventually the constraint is likely to move to the marketplace.

Theory of Constraints in Software Engineering

Theory of Constraints was first introduced in relation to manufacturing where the goal is to identify bottlenecks in the production line but since the method has been applied in engineering, project management, sales, accounting and other business processes. In manufacturing, the constraint can be found where there are queues of Work In Progress (WIP) in front of specific equipment and therefore causes extra inventories. In Software Engineering, the whole idea is to identify and manage what causes the inventory, but what is inventory in Software Engineering?

The list of client-value functionality that Software Developers have to solve is an inventory in Software Engineering. [8]

Inventory in Software Engineering can be expressed in different ways, depending on the software methodology used. A unit of inventory could be, for instance:

Applying Theory of Constraints in Software Engineering

According to David J. Anderson, producing and holding too much inventory is much worse in software because of the perishable nature of the inventory where requirements can go stale because of changes in the market or the fickle nature of the customer. Requirements have time value i.e. they have time to market value. With time, the throughput from the transformation of the requirement into working code decreases, specially when requirements are replaced by change requests for new requirements with a current market value. Requirements that become stale are pure waste [9].

In this chapter the applying of the theory will be explained through Five Focusing Steps and Throughput Accounting in relevance to Software Engineering

Five Focusing Steps

1. Identify the system´s constraints

The first thing to do in order to use Theory of Constraints to improve a system is to identify the constraints and prioritize them according to their impact on the goal. As said before, constraints can take many forms and the most known constraints are bottlenecks, the physical constraint and therefore it can be a good idea to start identifying them.

According to David J. Anderson it is generally assumed that there is only one global system constraint at any given time [9].

Once a constraint has been identified, a decision must be made on how to minimize its constraining ability on the system. The constraint must be fully utilized and according to David J. Anderson; every unit of production lost in the constraint is a unit lost in the whole system [9].

2. Decide how to exploit the system´s constraints

When the constraints have been identified and prioritized and a decision about how they are going to be managed has been decided the vast majority of the system´s resources that are not constraints have to be managed also [4].

The objective with this step is to make the most of what you have and maximize throughput of the constraint using currently available resources. The step focuses on quick wins and rapid relief; leaving more complex and substantive changes for later. [2]

In the following table items that could improve constraint are described in general:

General description [2]
Item Description
Buffer Create a suitably sized inventory buffer immediately in front of the constraint to ensure that it can keep operating even if an upstream process stops.
Quality Check quality immediately before the constraint so only known good parts are processed by the constraint.
Continuous Operation Ensure that the constraint is continuously scheduled for operation (e.g. operate the constraint during breaks, approve overtime, schedule fewer changeovers, cross-train employees to ensure there are always skilled employees available for operating the constraint).
Maintenance Move routine maintenance activities outside of constraint production time (e.g. during changeovers).
Offload (Internal) Offload some constraint work to other machines. Even if they are less efficient, the improved system throughput is likely to improve overall profitability.
Offload (External) Offload some work to other companies. This should be a last resort if other techniques are not sufficient to relieve the constraint.

David J. Anderson suggested to use exploit Software Developers, that work 8 hours per day, as resources in the following ways:

  • Always have pool of development tasks ready to be done for the developer
  • Protect the developer from interruptions by providing a communication structure that minimizes the lines of communication
  • Provide quiet environment for working to protect the developer from distraction
  • Provide the best Software Development tools available to further exploit the developer
  • Provide support staff for nonproductive activities (progress reporting, time-tracking and more) - Non value-added work is waste
  • Provide adequate training in the technologies being used
  • Provide team of colleagues to support and help resolve difficulties
  • Requirements she is given are of good quality [2]

If the actions taken in this step solve the constraint, next step is step five, otherwise continue to step three.

3. Subordinate everything else to the above decision

The primary objective in step three is to support the needs of the constraint and the focus in on non-constraint equipment [2].

Some useful techniques for this step include:

Useful techniques [2]
Item Description
DBR Implement DBR (Drum-Buffer-Rope) on the constraint as a way of synchronizing the manufacturing process to the needs of the constraint.
Priority Subordinate maintenance to the constraint by ensuring that the constraint is always the highest priority for maintenance calls.
Sprint Add sprint capacity to non-constraint equipment to ensure that interruptions to their operation (e.g. breakdowns or material changes) can quickly be offset by faster operation and additional output.
Steady Operation Operate non-constraint equipment at a steady pace to minimize stops. Frequent inertial changes (i.e. stops and speed changes) can increase wear and result in breakdowns.

If constraints should be fully exploited in Software Engineering the developers should not be loaded with any more than they can reasonably handle. So the rest of the system of software production must be subordinated to this notion.

4. Elevate the system´s constraints

In step 4 the objective is to elevate the constraint and might require more substantive changes. Investment of time and/or money is something that might need to elevate the constraint. [2].

Elevating a software developer from a constraint can be done in various ways. According to David J. Anderson the most obvious way used in the software industry is unpaid overtime, therefore the constraint in stretched. Managers could also hire more developers or introduce shift working or even use a better developer [9].

5. If in the previous steps a constraint has been brokes, go back to step one, but do not allow inertia to cause a system constrain

Throughput Accounting (TA)

In traditional accounting, inventory is an asset. That often drives undesirable behavior at companies to manufacture items that are not truly needed because it generates a "paper profit" based on inventory that may or may not ever be sold. Since the Theory of Constraints considers inventory to be a liability, Throughput Accounting is used because it attempts to eliminate harmful distortions introduced in traditional accounting practices.[8]

Core measures in Throughput Accounting are the following

Core Measures in TA [8]
Measures Equation
Throughput T = Revenue - Totally Variable Expenses
Net Profit NP = Throughput - Operating Expenses
Return on Investment ROI = Net Profit / Investment

According to Steve Tendon, to make the correct decision, you need a positive answer to one of these three questions:

  • Does it increase throughput?
  • Does it reduce operating expenses?
  • Does it increase the return on investment? [8]

Positive business decision can be taken if the action considered increases throughput, decreases operating expenses or increases return on investment. [8]

Throughput Accounting for Software Engineering has been defined the following way:

  • Throughput: is the rate of cash generated through delivery of working code into production […] It is computed as sales price minus direct costs, such as packaging, delivery, installation, training, support, and networking.
  • Investment: is all money invested in software production systems plus money spent to obtain ideas for client-valued functionality. It thus includes software development tools and requirements gathering. […]
  • Operating Expense: is all money spent to produce working code from ideas. It is primarily direct labor of software engineers, but it also includes selling, general, and administrative costs. [8]

By gathering requirements rapidly yet a ...TO BE CONTINUED!

Limitations and advantage

THIS WILL BE FINISHED AFTER FIRST PEER REVIEW

Annoted Bibliography

THIS WILL BE FINISHED AFTER FIRST PEER REVIEW

References

  1. ↑ McMullen, Jr., Thomas B. "Introduction to the Theory of Constraints (TOC) Management System", APICS Pub.1998
  2. ↑ 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Unknown. "Theory of Constraints", Lean Production, Date unknown. Retrieved on 10 September 2016.
  3. ↑ 3.0 3.1 3.2 Braude, Eric J. & Bernstein, Michael E. "SOFTWARE ENGINEERING Modern Approaches", Waveland press, INCUnited States of America 2016.
  4. ↑ 4.0 4.1 4.2 Goldratt, Eliyahu M. "What is this thing called THEORY OF CONSTRAINTS an how should it be implemented?", ', Croton-on-Hudson, North River, New York 1990
  5. ↑ 5.0 5.1 5.2
  6. ↑ 6.0 6.1 6.2 6.3 6.4 6.5 6.6 6.7 Kim, Seonmin & Mabin, Victora J. & Davies, John. "The theory of constraints thinking processes: retrospect and prospect", International Journal of Operations & Production Management, Vol. 28 Iss: 2, pp.155 - 184, Published 2008. Retrieved on 13 September 2016.
  7. ↑ 7.0 7.1 Tarantino, Anthony & Cernauskas, Deborah "Risk Management in Finance: Six Sigma and Other Next-Generation Techniques", John Wiley & Sons, Inc, 2009, chapter 21
  8. ↑ 8.0 8.1 8.2 8.3 8.4 8.5 8.6 8.7 Tendon, Steve. "Theory of Constraints and Software Engineering", The TameFlow Chronologist, Published July 27th 2012. Retrieved on 13 September 2016.
  9. ↑ 9.0 9.1 9.2 9.3 9.4 Anderson, David J. "AGILE MANAGEMENT FOR SOFTWARE ENGINEERING: Applying the Theory of Constraints for Business Results", Prentice Hall PTR United States of America, September 17 2003. Retrieved on 10 September 2016
Retrieved from "http://wiki.doing-projects.org/index.php?title=Theory_of_Constraints_in_Software_Engineering&oldid=25103"
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox