IMPLEMENTING A VALUE-BASED APPROACH TO

SOFTWARE PROCESS AND PRODUCT ASSESSMENT

Pasi Ojala

Nokia Ltd., Hintanmutka 17 A 6, Oulu, Finland

Keywords: Software process improvement, assessment, value, worth, cost and Value Engineering.

Abstract: Recently more and more attention has been focused on the costs of SPI as well as on the cost-effectiveness

and productivity of softwar

e development. This study outlines the main concepts and principles of a value-

based approach and presents an industrial case where value assessment based on value-based approach has

been used in practise. The results of the industrial case show that even though there is still much to do in

making the economic-driven view complete in software engineering, the value-based approach outlines a

way towards a more comprehensive understanding of it. For companies the value assessment offers useful

help when struggling with cost-effectiveness and productivity related problems.

1 INTRODUCTION

Using the framework presented by Koskela &

Huovila (1997), the value-based approach is

understood in this study as a process. The main

principle of this process is to eliminate value losses

in software development, products, processes and

SPI. It uses economic-driven tools, which are based

on economic studies including, for example, the

areas of cost estimation, cost calculation (for

example ABC and life cycle costing) and investment

calculation. The value-based approach prefers

calculating costs instead of estimating them, and

also considers software development and SPI as

investments, on which it is possible to spend too

much money. In practice, the value-based approach

takes care that the customer requirements are met in

the best possible manner, ensuring quality, timeli-

ness and value in products as well as in processes,

over their entire life cycle. In particular, the aim of

ensuring quality connects it to the other methods

aiming for quality improvement.

The value-based approach also indicates a

clear

dependency between the process and products. It

sees that we need to develop and optimize process

activities so that processes produce the products

needed. Furthermore, it sees that we must analyze

products in order to reveal problems in processes

and develop processes from the product point of

view as well. This is vitally important, especially for

companies respecting customer opinions and aiming

to optimize costs in their processes, because the

customers are the ones paying for the products and

product-related services, and companies have to

allocate all costs to products to be able to price them.

The happier the customer is, the more worth he sees

in buying the products from us. It is also clear that

when we know our process and product costs, worth

and value, our ability to estimate, budget and control

future risks will improve significantly.

Therefore it is surprising that several studies in

he area neglect the importance of product value by

assuming that it is only achieved by improving

processes. It is also just as surprising that many

researchers do not examine the value of SPI itself.

Studies are mostly carried out on assessing the value

of processes, if they are carried out at all, but the

improvement decision and initiative itself, which in

many companies is difficult to make, is not consid-

ered from a value point of view at all. To be

effective, the value-based approach to successful

software engineering should evaluate processes and

products as well as the economical benefits of

starting and implementing their improvement.

Regarding to value-based approach the purpose of

this study is to collect experiences of using Value

Assessment for products and processes in using

industrial case.

329

Ojala P. (2007).

IMPLEMENTING A VALUE-BASED APPROACH TO SOFTWARE PROCESS AND PRODUCT ASSESSMENT.

In Proceedings of the Second International Conference on Software and Data Technologies - SE, pages 329-332

DOI: 10.5220/0001323703290332

 SciTePress

2 VALUE ASSESSMENT FOR

PRODUCTS AND PROCESSES

There are four ways to enhance a standard software

process assessment using Value Engineering (VE)

(Ojala, 2000, Ojala 2004, Ojala 2006). The first

possibility includes an addition of defined VE

process into the existing process models of used

capability assessment method (for example in

CMMI or SPICE).

The second possibility covers Value Assessment

for processes defined in used process model. The

main idea of this enhancement is to run through all

defined VE phases and as part of it calculate costs,

worth and value for each assessed process existing

in used process model.

The third possibility includes Value Assessment

for processes without process model. The purpose of

this enhancement is to find out from company’s own

defined process descriptions all process practises

which are then examined from cost, worth and value

point of views using VE process.

The fourth possibility includes Value Assessment

of a product. This enhancement examines Value of

product components and requirements and reveals

value improvement possibilities in them.

3 VALUE ASSESSMENT FOR

PROCESSES AND PRODUCTS:

COMPANY A

3.1 Background

Value assessment was implemented in Company A

in fall 2004. Because company did not know

whether its cost accounting would be able to provide

the necessary cost data for all processes and product

components, one purpose of the assessment was also

to help to give information on how to build a cost

accounting system for tracking process and product

costs using identifiers.

The main problem presented by Company A was

that there was no real understanding of all the

product environments and their profitability and

value. Some processes were attached to value

assessment, because Company A saw that they were

closely related to product development, and value

information was needed for them as well.

The definition value=worth/cost was discussed,

and it was seen as extremely important to find out

which components of the product gave the best

value to the vendor without neglecting customer

needs. Since there were several customers for the

product in question, it was not possible to include all

customers in the assessment. Therefore, Company A

decided to base worth calculations on ideal produc-

tion costs, which represented the cheapest way of

building a product or running a process.

3.2 Information

The overall goal of product development was to

produce different versions of the product for

different operating system environments, using the

same base code. Unfortunately, this was not possible

because, in practice, there was always a small part of

the product that had to be coded separately for each

operating system environment.

Company A had a strong interest in analyzing

cost and worth in its product requirements and

architectural product components for further product

development work. However, when planning the

assessment it was considered obvious that Company

A does not have cost accounting system for

architectural components, and simple estimation, not

based on real calculated cost, was not considered to

be good enough. Therefore it was decided that value

indexes would be calculated for the prioritized

requirements and component-level assessment

would be postponed to the following year, when cost

accounting would be able to produce the necessary

component-level cost information. Value

calculations for product platforms were done using

estimates for following operating systems:

• Windows, Linux, Solaris and HP (easy)

• QNK (difficult)

• UX (very difficult).

The value assessment for processes was based on

the company’s own process descriptions as company

saw it more interesting than reference model based

assessment. The processes selected for value

assessment included architectural design, design,

code implementing and testing.

3.3 Function Analysis

Platform-level value indexes (Figure 1) indicate that

the easiest platforms produce the greatest value.

Since the value indexes for the other platforms are

below 1.0, these platforms do not produce as much

money as they cost. Generally, it was recommended

to Company A to avoid using a lot of resources on

this kind of products where value is below 1.0.

However, it was also advised that if the Company A

wanted to move into new markets, it might

occasionally be necessary to create poor value for a

ICSOFT 2007 - International Conference on Software and Data Technologies

330

certain time. In Company A’s situation, this was not

the case.

Value indexes for processes (Figure 2) clearly

show that Company A creates most value in design

and architectural design. However, Company A

should start to look for value improvement

possibilities mostly in coding and testing. These

processes create more costs than worth.

Value in platforms

0.0

0.2

0.4

0.6

0.8

1.0

1.2

1.4

1.6

1.8

WIN,LIN,SOL,HP

(easy)

QNK(difficult) UX(very difficult)

Requirement

Val u

Value index

Figure 1: Value in platforms.

Value in processes

0.00

0.20

0.40

0.60

0.80

1.00

1.20

rin

De s

tin

Component

Val u

Value

index

Figure 2: Value in processes

3.4 Creativity

Since value determination had been performed for

both products and processes, it was decided that both

aspects would also be brainstormed. In addition, it

was decided that the requirements for a new cost

accounting system would also be discussed. All

participants were asked to list product-related

improvement proposals first, process-related

improvement proposals second and cost accounting-

related improvement proposals third.

The main ideas were classified in three

categories, and included:

Products:

- Someone should be responsible for discussing a

move to easier platforms, with customers using

“difficult” and “very difficult” platforms.

- The company should announce that it will no

longer make products for “difficult” platforms.

- The company should not implement all new

features in platforms which it considers

“difficult”, and some features should be

implemented significantly later.

Processes:

- The project managers and testing manager

should organize a workshop in which the most

time-consuming work practices would be listed.

Cost accounting:

- Accounting identifiers should be created to

follow costs in all platforms and main practises.

- Reporting schedules, and templates should be

created for cost accounting and value-monitoring

needs.

- The working hour tracking system should be

improved, to include all value creation-related

areas.

3.5 Evaluation

During the evaluation phase all the ideas presented

were analyzed and evaluated. It was decided that

there was no need to create weighted criteria in

prioritizing improvement proposals. It was proposed

that all of the ideas should be implemented, except

the one suggesting that the company should

announce that it would no longer support all

platforms. This idea was not widely supported

because it was considered to be against the

company’s strategy and customer service principles.

3.6 Development

Product-related value

According to the benefit analysis, product-related

benefits would be achieved if customers changed

their platforms from “difficult” or “very difficult”

platforms to easier ones. Some customers had

already indicated that this would be possible in the

near future, but Company A had not been active in

supporting it. It was estimated that within a one year

timeframe, 60 percent (AV=average, C=customer,

V=vendor) of customers could change platform, to

an “easy” one. It was further estimated that if not all

the new, minor improvements were implemented,

the costs involved in “difficult” and “very difficult”

platforms would decrease by 25 percent. The total

cost savings were estimated at around 50 percent.

Process-related value

Project managers and the testing manager organized

workshops with their teams to discuss the most time-

IMPLEMENTING A VALUE-BASED APPROACH TO SOFTWARE PROCESS AND PRODUCT ASSESSMENT

331

consuming work practices. Based on these

workshops participants generated improvement

proposals related to processes:

• Each design should be inspected by another

designer, who should send design comments,

before the inspection, to the project manager,

who acts as a chairman in inspection meetings.

• Security testing should be given to test

engineers, who have a better understanding of

it.

• The test manager should organize module test

training for designers and nominate test

engineers for each project.

• Testing plans should be inspected by a test team

before testing.

It was estimated that the proposed improvements

would reduce coding costs by 10 percent over a one-

year period. In testing, the cost reduction was

estimated at around 15 percent.

Cost accounting system

The third selected value improvement area included

the cost accounting system. Since Company A

already had appropriate cost accounting software, it

was considered possible to use it for the required

cost accounting purposes. It was calculated that it

would take one person one week to implement the

identifiers and train the needed bill approvers in the

new practices.

3.7 Presentation

The results of this value assessment for processes

and products, including cost accounting system

improvement opportunities, were presented to the

top-level management. Since the proposed

improvements only reduced costs, the top-level

management decided to put them into use.

Company A was satisfied with the results of

value assessment. However, they announced that

since there was no proper time-keeping and cost

accounting system in place before the assessment, a

new assessment, using the new information, would

be carried out in the following year.

4 CONCLUSIONS

In conclusion, the value-based approach to software

engineering appreciates the clear dependency be-

tween process and product. It helps in developing

and even optimizing process activities, while

ensuring that processes still produce the services and

products needed. Furthermore, it analyzes products

to reveal problems in processes, and develops

processes from a product point of view. This is

vitally important, especially for companies who

respect customer opinions and aim to optimize costs

in their processes. Customers pay for products and

services, and companies have to allocate all costs to

products to be able to price them. The happier the

customer is, the more worth he will see in buying a

given product.

Perhaps the most significant risk of drawing

false conclusions regarding to the presented case

study is in understanding the ideal cost that the

company had defined for products and processes.

This does not necessarily represent the average

opinion of all customers well enough, since it is

based on the company’s own estimate. The use of

ideal cost is perhaps even riskier when analyzing the

products, because customers usually have a clear

opinion of their worth. In the case of processes, the

company’s own estimates of worth are perhaps more

valid, since the customer does not usually see all

processes as their main interest for “buying”,

whereas the company wants to manage them

efficiently

REFERENCES

Dell’ Isola, A., 1997. Value Engineering: Practical

Applications…for design, Construction, Maintenance

& Operations. Kingston (MA), R.S Means Company,

Inc.

Koskela, L., Huovila, P., 1997. “On foundations of

Concurrent Engineering in Construction CEC’97.

London, 3-4 July. London, The Institution of

Structural Engineers: 22-23.

Ojala. P., 2000. Enhancing Software Process Improvement

Using Value Engineering. Working Paper. Series B.

University of Oulu.

Ojala, P., 2004. Combining Capability Assessment and

Value Engineering: a BOOTSTRAP example.

Proceedings of the Profes 2004. 5

International

Conference. Kansai City, Japan, April.

Ojala, P., 2006. Implementing a Value-Based Approach to

Software assessment and Improvement. Doctoral

dissertation. University of Oulu, 2006.

ICSOFT 2007 - International Conference on Software and Data Technologies

332