Software Engineering Body of Knowledge (v3) (2014) (811503), страница 57
Текст из файла (страница 57)
The success of a software product, service, and solution depends on good business management. Yet, in many companies andorganizations, software business relationships tosoftware development and engineering remainvague. This knowledge area (KA) provides anoverview on software engineering economics.Economics is the study of value, costs,resources, and their relationship in a given contextor situation.
In the discipline of software engineering, activities have costs, but the resultingsoftware itself has economic attributes as well.Software engineering economics provides a wayto study the attributes of software and softwareprocesses in a systematic way that relates themto economic measures. These economic measurescan be weighed and analyzed when making decisions that are within the scope of a software organization and those within the integrated scope ofan entire producing or acquiring business.Software engineering economics is concernedwith aligning software technical decisions withthe business goals of the organization.
In alltypes of organizations—be it “for-profit,” “notfor-profit,” or governmental—this translates intosustainably 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 hasbeen formulated in a way to address all types oforganizations independent of focus, product andservice 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 businessviability of a software project and the resultingproduct. Often engineers wonder whether suchconcerns apply at all, as they are “only engineers.” Economic analysis and decision-makingare important engineering considerations becauseengineers are capable of evaluating decisions bothtechnically and from a business perspective.
Thecontents of this knowledge area are important topics for software engineers to be aware of even ifthey are never actually involved in concrete business decisions; they will have a well-rounded viewof business issues and the role technical considerations play in making business decisions. Manyengineering proposals and decisions, such as makeversus buy, have deep intrinsic economic impactsthat should be considered explicitly.This KA first covers the foundations, key terminology, basic concepts, and common practicesof software engineering economics to indicatehow decision-making in software engineeringincludes, or should include a business perspective. It then provides a life cycle perspective,highlights risk and uncertainty management, andshows how economic analysis methods are used.Some practical considerations finalize the knowledge area.12-112-2 SWEBOK® Guide V3.0Figure 12.1.
Breakdown of Topics for the Software Engineering Economics KASoftware Engineering Economics 12-3BREAKDOWN OF TOPICS FORSOFTWARE ENGINEERING ECONOMICSThe breakdown of topics for the Software Engineering Economics KA is shown in Figure 12.1.1. Software Engineering EconomicsFundamentals1.1. Finance[1*, c2]Finance is the branch of economics concernedwith issues such as allocation, management,acquisition, and investment of resources.
Financeis an element of every organization, includingsoftware engineering organizations.The field of finance deals with the concepts oftime, 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. Thisholds 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, anorganization must• identify organizational goals, time horizons,risk factors, tax considerations, and financialconstraints;• identify and implement the appropriate business strategy, such as which portfolio andinvestment decisions to take, how to managecash flow, and where to get the funding;• measure financial performance, such ascash flow and ROI (see section 4.3, Returnon Investment), and take corrective actionsin case of deviation from objectives andstrategy.1.2. Accounting[1*, c15]Accounting is part of finance. It allows peoplewhose money is being used to run an organizationto know the results of their investment: did theyget 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 organizationsas well as “for-profit” organizations, it translatesinto sustainably staying in business.
The primaryrole of accounting is to measure the organization’s actual financial performance and to communicate financial information about a businessentity to stakeholders, such as shareholders,financial auditors, and investors. Communicationis generally in the form of financial statementsthat show in money terms the economic resourcesto be controlled. It is important to select the rightinformation that is both relevant and reliable tothe user. Information and its timing are partiallygoverned by risk management and governancepolicies.
Accounting systems are also a richsource 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 andplans 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 outof a business, project, or financial product over agiven period.
The concepts of cash flow instancesand cash flow streams are used to describe thebusiness perspective of a proposal. To make ameaningful business decision about any specificproposal, that proposal will need to be evaluatedfrom a business perspective. In a proposal todevelop and launch product X, the payment fornew software licenses is an example of an outgoing cash flow instance.
Money would need to bespent to carry out that proposal. The sales incomefrom product X in the 11th month after marketlaunch is an example of an incoming cash flow12-4 SWEBOK® Guide V3.0Figure 12.2. A Cash Flow Diagraminstance. Money would be coming in because ofcarrying out the proposal.The term cash flow stream refers to the set ofcash flow instances over time that are caused bycarrying out some given proposal. The cash flowstream is, in effect, the complete financial pictureof that proposal. How much money goes out?When does it go out? How much money comesin? When does it come in? Simply, if the cashflow stream for Proposal A is more desirable thanthe cash flow stream for Proposal B, then—allother things being equal—the organization is better off carrying out Proposal A than Proposal B.Thus, the cash flow stream is an important inputfor investment decision-making.
A cash flowinstance is a specific amount of money flowinginto or out of the organization at a specific timeas a direct result of some activity.A cash flow diagram is a picture of a cash flowstream. It gives the reader a quick overview ofthe financial picture of the subject organization orproject. Figure 12.2 shows an example of a cashflow diagram for a proposal.1.5. Decision-Making Process[1*, c2, c4]If we assume that candidate solutions solve agiven technical problem equally well, why shouldthe organization care which one is chosen? Theanswer is that there is usually a large difference in the costs and incomes from the differentsolutions.
A commercial, off-the-shelf, objectrequest broker product might cost a few thousanddollars, but the effort to develop a homegrownservice that gives the same functionality couldeasily cost several hundred times that amount.If the candidate solutions all adequately solvethe problem from a technical perspective, thenthe selection of the most appropriate alternativeshould be based on commercial factors such asoptimizing total cost of ownership (TCO) ormaximizing 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 lifetimeROI (see section 4.3, Return on Investment).A systematic process for making decisions willachieve transparency and allow later justification.
Governance criteria in many organizationsdemand selection from at least two alternatives.A systematic process is shown in Figure 12.3.It starts with a business challenge at hand anddescribes 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 differentorder and often several of the steps can be donein parallel.
The important thing is to be sure thatSoftware Engineering Economics 12-5Figure 12.3. The Basic Business Decision-Making Processnone of the steps are skipped or curtailed. It’s alsoimportant to understand that this same processapplies at all levels of decision making: from adecision as big as determining whether a softwareproject should be done at all, to a deciding on analgorithm or data structure to use in a softwaremodule.
The difference is how financially significant the decision is and, therefore, how mucheffort should be invested in making that decision. The project-level decision is financially significant and probably warrants a relatively highlevel of effort to make the decision. Selecting analgorithm is often much less financially significant and warrants a much lower level of effort tomake the decision, even though the same basicdecision-making process is being used.More often than not, an organization couldcarry out more than one proposal if it wantedto, and usually there are important relationshipsamong proposals.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
