Difference between revisions of "Chapter 12: Software Engineering Economics"

From SWEBOK
Jump to: navigation, search
(Valuation)
(Product)
Line 377: Line 377:
 
==Life Cycle Economics==
 
==Life Cycle Economics==
 
===Product===
 
===Product===
 +
{{RightSection|{{referenceLink|number=2|parts=c22}} {{referenceLink|number=3|parts=c6}}}}
 +
A product is an economic good (or output) that is
 +
created in a process that transforms product factors
 +
(or inputs) to an output. When sold, a product
 +
is a deliverable that creates both a value and
 +
an experience for its users. A product can be a
 +
combination of systems, solutions, materials,
 +
and services delivered internally (e.g., in-house
 +
IT solution) or externally (e.g., software application),
 +
either as-is or as a component for another
 +
product (e.g., embedded software).
 +
 +
===Project===
 +
{{RightSection|{{referenceLink|number=2|parts=c22}} {{referenceLink|number=3|parts=c1}}}}
 +
A project is “a temporary endeavor undertaken
 +
to create a unique product, service, or result”.1
 +
In software engineering, different project types
 +
are distinguished (e.g., product development,
 +
outsourced services, software maintenance, service
 +
creation, and so on). During its life cycle, a
 +
software product may require many projects. For
 +
example, during the product conception phase,
 +
a project might be conducted to determine the
 +
customer need and market requirements; during
 +
maintenance, a project might be conducted to
 +
produce a next version of a product.

Revision as of 13:49, 27 August 2015

Acronyms
EVM
Earned Value Management
IRR
Internal Rate of Return
MARR
Minimum Acceptable Rate of Return
SDLC
Software Development Life Cycle
SPLC
Software Product Life Cycle
ROI
Return on Investment
ROCE
Return on Capital Employed
TCO
Total Cost of Ownership
Introduction

Software engineering economics is about making decisions related to software engineering in a business context. The success of a software product, service, and solution depends on good business management. Yet, in many companies and organizations, software business relationships to software development and engineering remain vague. This knowledge area (KA) provides an overview on software engineering economics. Economics is the study of value, costs, resources, and their relationship in a given context or situation. In the discipline of software engineering, activities have costs, but the resulting software itself has economic attributes as well. Software engineering economics provides a way to study the attributes of software and software processes in a systematic way that relates them to economic measures. These economic measures can be weighed and analyzed when making decisions that are within the scope of a software organization and those within the integrated scope of an entire producing or acquiring business. Software engineering economics is concerned with aligning software technical decisions with the business goals of the organization. In all types of organizations — be it “for-profit,” “notfor- profit,” or governmental — this translates into sustainably staying in business. In “for-profit” organizations this additionally relates to achieving a tangible return on the invested capital — both assets and capital employed. This KA has been formulated in a way to address all types of organizations independent of focus, product and service portfolio, or capital ownership and taxation restrictions. Decisions like “Should we use a specific component?” may look easy from a technical perspective, but can have serious implications on the business viability of a software project and the resulting product. Often engineers wonder whether such concerns apply at all, as they are “only engineers.” Economic analysis and decision-making are important engineering considerations because engineers are capable of evaluating decisions both technically and from a business perspective. The contents of this knowledge area are important topics for software engineers to be aware of even if they are never actually involved in concrete business decisions; they will have a well-rounded view of business issues and the role technical considerations play in making business decisions. Many engineering proposals and decisions, such as make versus buy, have deep intrinsic economic impacts that should be considered explicitly. This KA first covers the foundations, key terminology, basic concepts, and common practices of software engineering economics to indicate how decision-making in software engineering includes, or should include a business perspective. It then provides a life cycle perspective, highlights risk and uncertainty management, and shows how economic analysis methods are used. Some practical considerations finalize the knowledge area.

Breakdown of Topics for Software Engineering Models and Methods

The breakdown of topics for the Software Engineering Economics KA is shown in Figure 12.1.

Figure 12.1: Breakdown of Topics for the Software Engineering Economics KA

1 Software Engineering Economics Fundamentals

1.1 Finance

[1, c2]

Finance is the branch of economics concerned with issues such as allocation, management, acquisition, and investment of resources. Finance is an element of every organization, including software engineering organizations. The field of finance deals with the concepts of time, money, risk, and how they are interrelated. It also deals with how money is spent and budgeted. Corporate finance is concerned with providing the funds for an organization’s activities. Generally, this involves balancing risk and profitability, while attempting to maximize an organization’s wealth and the value of its stock. This holds primarily for “for-profit” organizations, but also applies to “not-for-profit” organizations. The latter needs finances to ensure sustainability, while not targeting tangible profit. To do this, an organization must

  • identify organizational goals, time horizons, risk factors, tax considerations, and financial constraints;
  • identify and implement the appropriate business strategy, such as which portfolio and investment decisions to take, how to manage cash flow, and where to get the funding;
  • measure financial performance, such as cash flow and ROI (see section 4.3, Return on Investment), and take corrective actions in case of deviation from objectives and strategy.

1.2 Accounting

[1, c15]

Accounting is part of finance. It allows people whose money is being used to run an organization to know the results of their investment: did they get the profit they were expecting? In “for-profit” organizations, this relates to the tangible ROI (see section 4.3, Return on Investment), while in “not-for-profit” and governmental organizations as well as “for-profit” organizations, it translates into sustainably staying in business. The primary role of accounting is to measure the organization’s actual financial performance and to communicate financial information about a business entity to stakeholders, such as shareholders, financial auditors, and investors. Communication is generally in the form of financial statements that show in money terms the economic resources to be controlled. It is important to select the right information that is both relevant and reliable to the user. Information and its timing are partially governed by risk management and governance policies. Accounting systems are also a rich source of historical data for estimating.

1.3 Controlling

[1, c15]

Controlling is an element of finance and accounting. Controlling involves measuring and correcting the performance of finance and accounting. It ensures that an organization’s objectives and plans are accomplished. Controlling cost is a specialized branch of controlling used to detect variances of actual costs from planned costs.

1.4 Cash Flow

[1, c3]

Cash flow is the movement of money into or out of a business, project, or financial product over a given period. The concepts of cash flow instances and cash flow streams are used to describe the business perspective of a proposal. To make a meaningful business decision about any specific proposal, that proposal will need to be evaluated from a business perspective. In a proposal to develop and launch product X, the payment for new software licenses is an example of an outgoing cash flow instance. Money would need to be spent to carry out that proposal. The sales income from product X in the 11th month after market launch is an example of an incoming cash flow instance. Money would be coming in because of carrying out the proposal.

The term cash flow stream refers to the set of cash flow instances over time that are caused by carrying out some given proposal. The cash flow stream is, in effect, the complete financial picture of that proposal. How much money goes out? When does it go out? How much money comes in? When does it come in? Simply, if the cash flow stream for Proposal A is more desirable than the cash flow stream for Proposal B, then—all other things being equal—the organization is better off carrying out Proposal A than Proposal B. Thus, the cash flow stream is an important input for investment decision-making. A cash flow instance is a specific amount of money flowing into or out of the organization at a specific time as a direct result of some activity. A cash flow diagram is a picture of a cash flow stream. It gives the reader a quick overview of the financial picture of the subject organization or project. Figure 12.2 shows an example of a cash flow diagram for a proposal.

Figure 12.2: A Cash Flow Diagram

1.5 Decision-Making Process

[1, c2, c4]

If we assume that candidate solutions solve a given technical problem equally well, why should the organization care which one is chosen? The answer is that there is usually a large difference in the costs and incomes from the different solutions. A commercial, off-the-shelf, objectrequest broker product might cost a few thousand dollars, but the effort to develop a homegrown service that gives the same functionality could easily cost several hundred times that amount.

If the candidate solutions all adequately solve the problem from a technical perspective, then the selection of the most appropriate alternative should be based on commercial factors such as optimizing total cost of ownership (TCO) or maximizing the short-term return on investment (ROI). Life cycle costs such as defect correction, field service, and support duration are also relevant considerations. These costs need to be factored in when selecting among acceptable technical approaches, as they are part of the lifetime ROI (see section 4.3, Return on Investment). A systematic process for making decisions will achieve transparency and allow later justification. Governance criteria in many organizations demand selection from at least two alternatives.

A systematic process is shown in Figure 12.3. It starts with a business challenge at hand and describes the steps to identify alternative solutions, define selection criteria, evaluate the solutions, implement one selected solution, and monitor the performance of that solution.

Figure 12.3 shows the process as mostly stepwise and serial. The real process is more fluid. Sometimes the steps can be done in a different order and often several of the steps can be done in parallel. The important thing is to be sure that none of the steps are skipped or curtailed. It’s also important to understand that this same process applies at all levels of decision making: from a decision as big as determining whether a software project should be done at all, to a deciding on an algorithm or data structure to use in a software module. The difference is how financially significant the decision is and, therefore, how much effort should be invested in making that decision. The project-level decision is financially significant and probably warrants a relatively high level of effort to make the decision. Selecting an algorithm is often much less financially significant and warrants a much lower level of effort to make the decision, even though the same basic decision-making process is being used.

More often than not, an organization could carry out more than one proposal if it wanted to, and usually there are important relationships among proposals. Maybe Proposal Y can only be carried out if Proposal X is also carried out. Or maybe Proposal P cannot be carried out if Proposal Q is carried out, nor could Q be carried out if P were. Choices are much easier to make when there are mutually exclusive paths—for example, either A or B or C or whatever is chosen. In preparing decisions, it is recommended to turn any given set of proposals, along with their various interrelationships, into a set of mutually exclusive alternatives. The choice can then be made among these alternatives.

Figure 12.3: The Basic Business Decision-Making Process

1.6 Valuation

[1, c5, c8]

In an abstract sense, the decision-making process— be it financial decision making or other— is about maximizing value. The alternative that maximizes total value should always be chosen. A financial basis for value-based comparison is comparing two or more cash flows. Several bases of comparison are available, including

  • present worth
  • future worth
  • annual equivalent
  • internal rate of return
  • (discounted) payback period.

Based on the time-value of money, two or more cash flows are equivalent only when they equal the same amount of money at a common point in time. Comparing cash flows only makes sense when they are expressed in the same time frame.

Note that value can’t always be expressed in terms of money. For example, whether an item is a brand name or not can significantly affect its perceived value. Relevant values that can’t be expressed in terms of money still need to be expressed in similar terms so that they can be evaluated objectively.

1.7 Inflation

[1, c13]

Inflation describes long-term trends in prices. Inflation means that the same things cost more than they did before. If the planning horizon of a business decision is longer than a few years, or if the inflation rate is over a couple of percentage points annually, it can cause noticeable changes in the value of a proposal. The present time value therefore needs to be adjusted for inflation rates and also for exchange rate fluctuations.

1.8 Depreciation

[1, c14]

Depreciation involves spreading the cost of a tangible asset across a number of time periods; it is used to determine how investments in capitalized assets are charged against income over several years. Depreciation is an important part of determining after-tax cash flow, which is critical for accurately addressing profit and taxes. If a software product is to be sold after the development costs are incurred, those costs should be capitalized and depreciated over subsequent time periods. The depreciation expense for each time period is the capitalized cost of developing the software divided across the number of periods in which the software will be sold. A software project proposal may be compared to other software and nonsoftware proposals or to alternative investment options, so it is important to determine how those other proposals would be depreciated and how profits would be estimated.

1.9 Taxation

[1, c16, c17]

Governments charge taxes in order to finance expenses that society needs but that no single organization would invest in. Companies have to pay income taxes, which can take a substantial portion of a corporation’s gross profit. A decision analysis that does not account for taxation can lead to the wrong choice. A proposal with a high pretax profit won’t look nearly as profitable in posttax terms. Not accounting for taxation can also lead to unrealistically high expectations about how profitable a proposed product might be.

1.10 Time-Value of Money

[1, c5, c11]

One of the most fundamental concepts in finance—and therefore, in business decisions— is that money has time-value: its value changes over time. A specific amount of money right now almost always has a different value than the same amount of money at some other time. This concept has been around since the earliest recorded human history and is commonly known as time-value. In order to compare proposals or portfolio elements, they should be normalized in cost, value, and risk to the net present value. Currency exchange variations over time need to be taken into account based on historical data. This is particularly important in cross-border developments of all kinds.

1.11 Efficiency

[2, c1]

Economic efficiency of a process, activity, or task is the ratio of resources actually consumed to resources expected to be consumed or desired to be consumed in accomplishing the process, activity, or task. Efficiency means “doing things right.” An efficient behavior, like an effective behavior, delivers results—but keeps the necessary effort to a minimum. Factors that may affect efficiency in software engineering include product complexity, quality requirements, time pressure, process capability, team distribution, interrupts, feature churn, tools, and programming language.

1.12 Effectiveness

[2, c1]

Effectiveness is about having impact. It is the relationship between achieved objectives to defined objectives. Effectiveness means “doing the right things.” Effectiveness looks only at whether defined objectives are reached—not at how they are reached.

1.13 Productivity

[2, c23]

Productivity is the ratio of output over input from an economic perspective. Output is the value delivered. Input covers all resources (e.g., effort) spent to generate the output. Productivity combines efficiency and effectiveness from a valueoriented perspective: maximizing productivity is about generating highest value with lowest resource consumption.

2 Life Cycle Economics

2.1 Product

[2, c22] [3, c6]

A product is an economic good (or output) that is created in a process that transforms product factors (or inputs) to an output. When sold, a product is a deliverable that creates both a value and an experience for its users. A product can be a combination of systems, solutions, materials, and services delivered internally (e.g., in-house IT solution) or externally (e.g., software application), either as-is or as a component for another product (e.g., embedded software).

2.2 Project

[2, c22] [3, c1]

A project is “a temporary endeavor undertaken to create a unique product, service, or result”.1 In software engineering, different project types are distinguished (e.g., product development, outsourced services, software maintenance, service creation, and so on). During its life cycle, a software product may require many projects. For example, during the product conception phase, a project might be conducted to determine the customer need and market requirements; during maintenance, a project might be conducted to produce a next version of a product.