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
t
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
Copyright
c
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 As 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
e
Value index
Figure 1: Value in platforms.
Value in processes
0.00
0.20
0.40
0.60
0.80
1.00
1.20
A
rc
hi
te
c
tu
rin
g
De s
ig
ni
n
g
C
o
di
n
g
T
e
s
tin
g
Component
Val u
e
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
th
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