Cost Estimation for the Software Operation Phase (SW Project Cost Estimation Guide 2023)
1. Overview
A. Definition
Under the "Software Project Cost Estimation Guide (2023 revision)," this is a standardized method that estimates the cost of the SW operation phase (maintenance and operation) on the basis of measurable indicators such as functional size, input effort, and service level (SLA), thereby providing a reasonable basis for procurement and contracting.
The total cost of ownership (TCO) of software does not end at a single point in time when it is developed. Rather, a system actually creates value during the long operation and maintenance period after delivery, and much research and practical experience holds that 60-80% of the total lifecycle cost of software occurs in the operation phase. Nevertheless, for a long time the operation cost was often set with a weak basis, "conventionally as a certain percentage of the development cost."
Such arbitrary estimation produces distortions in two directions. On one side, low-price competition sets the cost too low, so that sufficient manpower cannot be deployed, and as a result a vicious cycle arises in which failure response is delayed and quality declines. On the other side, the cost is overstated without basis and the budget is wasted. When neither the client nor the contractor can explain "why this amount," disputes are inevitably frequent.
The cost estimation guide is precisely a device for reducing this arbitrariness. This guide, which the Korea Software Industry Association (KOSA) revises and publishes every year, standardizes the method so that, just as development cost is estimated on a function point (FP) basis, the operation phase is likewise estimated on the basis of the quantitative indicators of size, effort, and SLA. In other words, its core purpose is to make it possible to explain "how much to pay" not by bargaining power but by measured values.
B. Distinguishing Maintenance from Operation
The guide divides the operation phase into two activities of completely different character. Maintenance is the activity of fixing defects in delivered application SW (defect repair) and improving or repairing small-scale functions in line with changes in laws and systems or user requirements. This burden is generally proportional to the size (function points) of the SW under management. The more numerous and complex the functions of a system, the more there is to fix and the more improvement requests there are.
By contrast, SW operation is the activity of constantly monitoring the system so that it runs stably 24 hours a day, responding immediately when a failure occurs, and managing configuration, backup, and performance. This burden depends less on the size of the SW than on how many people are stationed at what service level (SLA). No matter how small a system is, if uninterrupted (24×365) monitoring is required, shift personnel are needed; conversely, even a large system needs fewer people if it runs unattended at night.
Because the cost drivers of the two activities differ, lumping them into a single estimation formula inevitably produces distortion. Measuring maintenance, which is proportional to size, by manpower alone underestimates the improvement burden of large systems, and measuring operation, which is proportional to manpower, by size alone fails to reflect high-availability requirements. Therefore the guide presents different methods: for maintenance a rate method (development cost × rate), for operation input effort (M/M × unit price), and for the reality where the two are mixed a separation of fixed and variable costs. Below we examine each method together with its principle.
2. The Overall Framework of Operation-Phase Cost Estimation
First, seeing the overall structure of how the operation-phase cost divides into branches makes it easy to understand where each individual estimation formula fits.
flowchart TD
OP["SW operation-phase cost"] --> MA["Maintenance<br/>proportional to size"]
OP --> OPR["SW operation<br/>proportional to manpower"]
MA --> R1["Application SW rate method<br/>re-estimated development cost × rate"]
MA --> R2["Commercial/open-source SW maintenance<br/>rate based on purchase price"]
OPR --> M1["Input effort method<br/>M/M × labor unit price"]
OPR --> M2["Fixed / variable cost<br/>mixed settlement"]
In this framework, the left branch (maintenance) is one where "the size of what has been built" determines the cost, and the right branch (operation) is one where "the people stationed and the service level" determine the cost. Beyond this, the 2023 revision broadened its scope to also cover commercial-SW and open-source-SW maintenance costs, security-continuity service costs, and the integrated operation and maintenance cost framework that bundles multiple systems and operates them together. In other words, it is evolving in a direction that reflects the reality of many intertwined services rather than a single individual system.
The core is the principle "measure with a ruler that matches the character." One must first discern whether an activity is proportional to size, proportional to manpower, or varies with the volume of requests, and then choose the estimation formula that matches it, so that the cost and the actual requirement align. From the next section onward, three representative methods are explained in turn.
3. Application SW Rate-Method Maintenance Cost
flowchart LR
D["Development cost re-estimation<br/>based on current FP and unit price"] --> A["Apply adjustment coefficients<br/>difficulty and SLA"]
A --> R["Multiply by maintenance rate (%)"]
R --> C["Annual maintenance cost"]
The rate-method maintenance cost is obtained by multiplying the re-estimated development cost by a maintenance rate (%). It looks simple on the surface, but for this method to hold, two premises are required. The first is that the maintenance burden is proportional to SW size, and the second is that this size can be converted into the monetary unit of development cost. When both premises hold, the rate method becomes the most convenient and least disputed method.
The most important concept here is "development cost re-estimation." This is the value obtained by recalculating, in terms of current-standard function points (FP) and cost per FP, the cost that would be incurred if the SW already in operation were built again now. The reason for not simply using the development cost actually incurred in the past is that, over time, unit prices may have risen or functions may have been added or removed so that the size itself may have changed. Re-estimation objectively re-measures "the current size."
The maintenance rate multiplied here is normally based on a level of 10-15%, but is adjusted by reflecting adjustment coefficients such as service level, difficulty, and failure-response time targets. For example, a system that must respond immediately even at night and on holidays has its rate raised, while a stable system with almost no changes has it lowered. Concretely, if the re-estimated development cost is 1 billion won and the rate is 12%, the annual maintenance cost is calculated at about 120 million won. If an adjustment coefficient is added for a 24-hour response requirement and the rate becomes 15%, it becomes about 150 million won. Because it thus relies on the objective indicator of size, the estimation process is transparent and there is little room for dispute.
However, the rate method also has limits. For a stable system that is large in size but in practice is hardly touched, the rate method can produce overstatement, and conversely for a system that is small in size but flooded with change requests, it produces understatement. Therefore, in practice the rate method is taken as the base, but the rate is adjusted on the basis of actual change history, or it is used in parallel with the variable-cost method explained later.
| Item | Content |
|---|---|
| Formula | Maintenance cost = development cost (re-estimated) × maintenance rate (%) |
| Rate | Reflects service-level and difficulty adjustment coefficients (normally around 10-15%) |
| Re-estimation | Re-measures size on the basis of current function points and unit price |
| Premise | The maintenance burden is proportional to SW size (function points) |
| Characteristics | Size-based, convenient and objective, little room for dispute |
4. SW Operation Input-Effort Estimation Method
Operation cost is reasonably estimated not by size but by how many people are actually deployed and how much. This is because activities such as constant monitoring and failure response require a fixed number of staff on duty whether the SW is large or small. For example, an uninterrupted monitoring position is maintained only when "a person is at that position," regardless of system size. Because operation is thus intrinsically labor-intensive, its cost driver is manpower rather than size.
Therefore the estimation formula takes the form operation cost = input effort (M/M) × labor unit price + direct expenses + profit. Here M/M (Man-Month) is an effort unit meaning the amount one person works in one month, and the labor unit price is based on the average wage by SW-engineer grade (figures published by Statistics Korea and the association). The input effort is estimated by comprehensively considering the size of the operation target, the volume of work to be handled, and the SLA (availability and response-time targets).
The SLA in particular greatly influences the effort. For example, even a system for which 1-2 people suffice if it only responds on weekday daytime (8×5) will need 4-5 people or more for shift work once the requirement rises to 24-hour uninterrupted (24×365) monitoring. Even for the same system, if the SLA target rises from 99% availability to 99.9%, the response and reserve personnel increase and the effort grows. Concretely, if 3 people are stationed and the grade-average labor unit price is 6 million won per month, labor cost alone is at the level of 18 million won per month and 216 million won per year, to which expenses and profit are added.
The strength of this method is that it reflects the actual character of operation as it is. This is because it honestly quantifies the "cost that must be stationed," which cannot be explained by size. Its weakness, on the other hand, is that the input-effort estimation depends heavily on negotiation, so that if the basis for work volume and SLA is not made clear, room for dispute still remains. Therefore, at contracting one must specify concretely such indicators as the monitoring time zone, the target response time, and the monthly volume of cases handled.
| Item | Content |
|---|---|
| Formula | Operation cost = input effort (M/M) × labor unit price + expenses and profit |
| Input-effort estimation | Based on operation work volume, SLA, and target size |
| Labor unit price | Based on average wage by SW-engineer grade |
| Premise | The operation burden is proportional to input manpower rather than to size |
| Characteristics | Based on actual input, suited to the character of constant operation |
5. Fixed-Cost/Variable-Cost Estimation Method
flowchart LR
T["Operation cost"] --> F["Fixed cost<br/>constant operation staff"]
T --> V["Variable cost<br/>demand-based work"]
F --> B["Monthly fixed amount guaranteed"]
V --> S["Settlement by actual performance"]
Real operation work is a mixture of two parts of different character. One is the "always needed part," which occurs on a fixed basis every month, like constant monitoring, basic maintenance, and periodic inspection. The other is the "part that occurs only on request," whose timing and volume fluctuate, like function improvement, large-scale failure response, and handling of temporary loads. Lumping these two into a single method makes the actual requirement and the cost diverge.
Therefore the guide has the constant-character fixed cost (monthly fixed amount) and the variable cost linked to requests and work volume estimated separately. The fixed cost stably guarantees a predictable base cost so that the contractor can maintain minimum manpower, and the variable cost is settled only to the extent actually incurred so that the client does not pay unnecessary cost. In other words, this separation is a design that seeks to capture both predictability (fixed cost) and fairness (variable cost) at the same time.
In practice, a mixed method is usually used in which the fixed cost is placed as the skeleton and the variable cost is layered on top. For example, the monthly base monitoring and maintenance cost is set as a fixed cost of 20 million won, and function-improvement requests are estimated per case or by input M/M and settled separately as variable cost. This way, a stable cost is guaranteed in normal times, and in a month requiring large-scale improvement the actual work volume is added, so both sides can be satisfied. However, if the variable-cost settlement criteria (what counts as variable, how to price the unit) are not made clear in the contract, conflict may instead grow through negotiation for every single case.
| Category | Content | Character |
|---|---|---|
| Fixed cost | Constant operation staff and basic maintenance cost | Monthly fixed amount, predictable |
| Variable cost | Cost linked to requests and work volume, such as improvement and failure | Settlement by actual performance |
| Application | Fixed + variable mix according to service characteristics | Fairness and flexibility |
6. Comparison of the Three Methods and Application Cases
The three methods are not in a relation of superiority but are tools chosen according to what the cost driver of the target work is. The rate method is suited when the cost driver is size, input effort when it is manpower, and fixed + variable when demand fluctuation is large. Using the wrong ruler produces distortion. For example, if labor-intensive 24-hour monitoring is measured only by the rate method, the cost is set low on the grounds of small size and the necessary shift personnel cannot be secured.
Let us contrast the three types with concrete cases. First, maintenance of the application SW of a large administrative information system that has vast functions but does not change often is suited to the rate method. Because it is large in size and the improvement burden is proportional to size, one estimates 1.2 billion won per year by applying a rate of 12% to a re-estimated development cost of 10 billion won. Second, a public-facing service that is medium in size but for which uninterrupted, immediate response is essential (e.g., an online civil-complaint portal) is suited to input effort. If 5 people are stationed for 24-hour shifts and the grade-average labor is 6 million won per month, labor cost alone is estimated at the level of 360 million won per year. Third, a system whose operation is stable in normal times but which is flooded with large-scale reorganizations whenever policy changes is suited to fixed + variable. A fixed monitoring cost of 20 million won per month is set, and reorganization projects are settled separately as variable cost.
| Method | Suitable situation | Cost driver | Representative case |
|---|---|---|---|
| Rate method | Size-proportional maintenance | SW size (FP) | Large administrative information system |
| Input effort | Labor-intensive constant operation | Input manpower and SLA | Uninterrupted public-facing service |
| Fixed + variable | Work with large demand fluctuation | Constant + request volume | System with frequent policy-linked reorganization |
7. Advanced: Recent Trends in the Cost Framework
The cost estimation guide is not a fixed document but a living standard revised every year in line with industry change. In the 2023 revision (published 2023.12.08), the types were subdivided to include not only rate-method maintenance cost but also commercial-SW and open-source-SW maintenance cost, and security-continuity service cost. This reflects the reality that, in addition to self-developed SW, commercial packages and open source are mixed, and it had each estimated separately, whether as a rate based on purchase price or license, or as a cost for security-patch support.
The most notable change is the reflection of the shift to cloud and SaaS, and of integrated operation and maintenance. In the past each system was operated under an individual contract, but recently the form of bundling multiple systems and operating and maintaining them integrally as a single project has increased. Accordingly, the association presented a cost framework for SaaS-adoption projects and a cost-estimation method for integrated operation and maintenance projects, so as to reflect the economies of scale of integrated operation and the common infrastructure rather than an individual sum. In a cloud environment, because infrastructure cost changes to a usage-based (pay-per-use) basis, the cost framework too tends to move from a fixed-manpower center to a service and usage center.
From the exam-answer perspective, if one writes along the axes of "why operation cost must be quantified" (blocking the vicious cycle of low-price bidding and quality decline), "the difference between maintenance and operation" (cost driver: size vs. manpower), and "the criteria for choosing among the three methods," and adds cloud, SaaS, and integrated operation as recent trends, it becomes a deep essay.
8. Considerations and Implications
- Choosing the method that matches the character: The rate method suits maintenance with clear size proportionality, input effort suits labor-intensive operation, and a fixed + variable mix suits work with large demand fluctuation. Forcing a single all-purpose formula produces low-price or overstatement distortion, so before procurement one must first discern the cost driver of the target work.
- SLA- and work-volume-based quantification: Only by specifying the cost basis in measurement indicators such as SLA (availability and response time) and monthly volume of cases handled can the vicious cycle of low-price bidding and quality decline be broken. Concretizing deliverables, input plans, and settlement criteria in the contract prevents disputes over interpretation.
- Making public SW costs realistic and the ecosystem: The intent of the guide is to make costs realistic so as to raise both the treatment of SW engineers and SW quality together. This is not a mere budget issue but is directly tied to the sustainability of the SW industry ecosystem, and if low-price practices become entrenched they lead to an exodus of excellent talent.
- Responding to the shift to cloud and integrated operation: As SaaS and cloud expand and cost changes to pay-per-use, and as integrated operation of multiple systems increases, one must prepare for the transition from fixed-manpower-centered estimation to service- and usage-centered estimation. For integrated operation, contract design that uses economies of scale while clarifying where responsibility lies is the key.
- The legal character of the guide and room for negotiation: The cost estimation guide is not a mandatory regulation but a standard of advisory character, so there is still room for negotiation over the rate, adjustment coefficients, and labor unit price. Therefore it is effective only when one takes the guide as a basis but supplements it with adjustments suited to the project's characteristics and clear contract clauses.
References
- Korea Software Industry Association (KOSA), Software Project Cost Estimation Guide: https://www.sw.or.kr/site/sw/ex/board/List.do?cbIdx=276
- SW Project Cost Estimation Guide (2024 revision), IITP: https://www.iitp.kr/kr/1/knowledge/organScrapView.it?masterCode=publication&searClassCode=K_OGS_01&identifier=02-004-240513-000022
In one line: SW operation-phase cost is fundamentally about quantifying according to the cost driver — estimating maintenance, which is proportional to size, by the rate method (development cost × rate) and operation, which is proportional to manpower, by input effort (M/M × unit price), and dividing constant costs as fixed cost and work-volume-linked costs as variable cost — and recently the cost framework is evolving to also reflect commercial SW, open-source SW, cloud, and integrated operation.