Conference PaperPDF Available

Methodologies Supporting the Management of Business Software Systems Development and Enhancement Projects Functional Scope.

Authors:

Abstract

In the Polish practice of Business Software Systems (BSS) Development and Enhancement Projects (D&EP) execution one may commonly find many negative phenomena leading to the high scale of their failure, resulting in substantial financial losses. Most frequently occurring phenomena of this type include: deliberate lowering of planned BSS execution costs by offerors in order to win contract, uncontrolled increase in client’s functional requirements as to the project product not being correspondingly reflected in the costs of project execution as well as non-rational ex ante and ex post product pricing. What contributes to the limitation of these phenomena is proper management of the functional scope of such projects. In this paper the author presents in a synthetic way her own model of BSS D&EP functional assessment, verified in practice, against a background of the existing methodologies of the project functional scope management, i.e., southernSCOPE and northernSCOPE, proving its advantage over them.
Methodologies Supporting the Management of Business
Software Systems Development and Enhancement Projects
Functional Scope
Beata Czarnacka-Chrobot
Department of Business Informatics, Warsaw School of Economics, Warsaw, Poland
Abstract - In the Polish practice of Business Software
Systems (BSS) Development and Enhancement Projects
(D&EP) execution one may commonly find many negative
phenomena leading to the high scale of their failure,
resulting in substantial financial losses. Most frequently
occurring phenomena of this type include: deliberate
lowering of planned BSS execution costs by offerors in
order to win contract, uncontrolled increase in client’s
functional requirements as to the project product not being
correspondingly reflected in the costs of project execution
as well as non-rational ex ante and ex post product pricing.
What contributes to the limitation of these phenomena is
proper management of the functional scope of such projects.
In this paper the author presents in a synthetic way her own
model of BSS D&EP functional assessment, verified in
practice, against a background of the existing
methodologies of the project functional scope management,
i.e., southernSCOPE and northernSCOPE, proving its
advantage over them.
Keywords: business software systems development and
enhancement projects, software functional size
measurement methods, southernSCOPE, northernSCOPE,
Software projects Functional Assessment Model
(SoftFAM)
1 Introduction
In practice of the Business Software Systems (BSS)
Development and Enhancement Projects (D&EP) execution,
not only in Poland, there are two types of client-provider
contracts that decidedly dominate at the moment, namely:
fixed price contract and time and material contract.
Meanwhile data resulting from the analysis of BSS D&EP
being accomplished in Poland indicate that in 2006-2007
approx. 50% of such projects went over the planned
completion time while approx. 40% exceeded the estimated
budget [1, pp. 470-472]. These data are similar as to the
general conclusions – to the results coming from the
Standish Group studies on the effectiveness of application
software development projects worldwide [2, p. 1]. What’s
more, employing such contracts results in the fact that the
differences in costs being spent by various organizations on
similar applications may be even fifteen fold [3, p. 1].
Thus one may formulate a hypothesis that these most
popular types of contracts have disadvantageous influence
on the effectiveness of BSS D&EP execution. They promote
some negative phenomena, being common in Poland, among
which are the following:
Practice consisting in deliberate lowering of BSS
development/enhancement costs by offerors in order to
win contract for product development/enhancement (the
so-called “price-to-win” approach), which is a result of
rewarding the cheapest offers.
Phenomenon consisting in clients extending the required
functionality during the project lifecycle (the so-called
“scope creep”) without effects of such change being
correspondingly reflected in the project execution costs.
Practice consisting in provider actually delivering
product of lower functionality than that required within
fixed price contracts.
Phenomenon consisting in provider actually delivering
functionality – many a time lower than the required one
– at the cost higher than the expected one, which usually
occurs in the case of time and material contracts, as they
promote extending of the project duration.
Thus ex ante as well as ex post pricing of the BSS
dedicated to the client’s needs should be based on its size:
required size in the case of ex ante pricing and actually
delivered size in the case of ex post pricing. Consequently,
work costs per unit should be related to the product size unit
and not to the time unit this is what makes pricing have
objective and reliable character. It requires the appropriate
measure of software size to be implemented, which may be
acquired on the basis of the software Functional Size
Measurement (FSM) concept, having been recently
normalized by the ISO/IEC.
Set of rules regarding software FSM was included to the
six-part ISO/IEC 14143 norm [4]. In this standard the
functional size is understood as „size of the software derived
by quantifying the Functional User Requirements”, while
Functional User Requirements (FUR) stand for the „sub-set
of the User Requirements describing what the software does,
in terms of tasks and services” [4, Part 1, p. 2]. Currently the
FSM methods having been normalized by the ISO/IEC
include: the International Function Point Users Group
(IFPUG) Functional Size Measurement Method (FSMM) -
standardized in the ISO/IEC 20926 norm [5]; the United
Kingdom Software Metrics Association (UKSMA) FSMM -
normalized in the ISO/IEC 20968 norm [6]; the Netherlands
Software Metrics Association (NESMA) FSMM -
standardized in the ISO/IEC 24570 norm [7]; the Common
Software Measurement International Consortium
(COSMIC) FSMM - normalized in the ISO/IEC 19761 norm
[8]; and the Finnish Software Metrics Association (FiSMA)
FSMM - standardized in the ISO/IEC 29881 norm [9].
The FSM concept constitutes basis of the
southernSCOPE and northernSCOPE methodologies
supporting the management of BSS D&EP functional scope,
i.e., scope measured on the basis of functional size of their
product.
2 The southernSCOPE and
northernSCOPE methodologies
The southernSCOPE methodology ([3][10]) is derived
from the SCUD (Software Charged by Unit Delivered)
methodology, having been developed by the State
Government of Victoria (Australia) in the second half of the
90s. of the last century. It was intended to support clients
when it came to the pricing of software systems being
developed for their needs. What drove its development was
not only the enormous spending on products of this type but
also the results of the Standish Group studies on the scale of
failure in the accomplishment of projects aimed at their
development. What was considered the cause of this status
quo was the fact that in the area of software systems D&EP
execution the methods of measurement of such projects’
result (product) were not employed only until recently – its
pricing used to be based on ineffective approach consisting
in the measurement of inputs (resources) to this process.
According to the authors of the methodology, the
appearance of FSM methods has diametrically changed this
situation while the development of repositories with
benchmarking data based on these methods - e.g., the
International Benchmarking Standards Group (ISBSG)
repository [11] or Software Productivity Research repository
[12] - allows for making more and more accurate estimation
of such projects’ costs on the basis of FSMM. They also
deliver the new knowledge of comparative character - the
result is the possibility to ensure more and more effective
management of their scope.
Thus the SCUD methodology was aimed at changing the
approach to the project product pricing: what was suggested
instead of payment based on fixed price contract or time and
material contract was the pricing based on unit cost
calculated with regard to the functionality unit. After several
years of employing such pricing, both in public as well as in
private sector, independent study aimed to evaluate the
effects of applying this methodology had been carried out
([13][14, pp. 26–27, 30]). It turned out that each of the
analysed projects, having been accomplished with the use of
the SCUD methodology, ended successfully, was
controllable by client while the products delivered met
clients’ requirements and expectations. These studies also
indicate that product pricing based on its functional size
results in reducing the average project budget overrun: as
showed by these studies, in traditional approaches it
amounts to 80-90% on average whereas in the case of
pricing based on functional size the average budget overrun
oscillates around 10% only. This is the result of the latter
approach minimising typical fundamental causes of
exceeding the costs of project activities. One of the ISBSG
reports [15, pp. 2, 4–5] confirms these results too: in the
situation where the methods based on product functional
size are employed in making cost estimation, in 90% of the
cases the estimates differ from the actual costs not more
than by 20%, and among these very cases 70% are accurate
to within 10%. In 2000, after slight modifications to the
SCUD rules, the name of the methodology was changed into
southernSCOPE.
Fundamental assumptions of southernSCOPE
methodology read as follows:
Price to be paid by client for software being
accomplished within D&EP depends directly on the
functional size of project product.
Estimates are being derived throughout the project’s life
cycle.
Structure of changes management promotes proper
management of changes being introduced by client to
the functional requirements.
Person responsible for the scope management, the so-
called scope manager, ascribed key role in this
methodology, should work independently.
Practice shows that the discussed methodology proves
useful in the case of projects aimed at developing or
enhancing BSS, regardless of whether or not they have
internal or external character. As conditions of the effective
use of this approach are being met in their case; among these
conditions are:
Accomplishment of project within the planned and
controlled budget is of key significance, if not a priority,
to a client.
There is an acceptance for the methods of product
functional size measurement.
Functional user requirements can be specified on the
level of detailness suitable for the FSMM.
There is a possibility to reduce the number of changes to
the required product functionality appearing upon
completion of the requirements specification phase.
In 2007, the FiSMA organisation published the rules of
northernSCOPE methodology [16], developed on the basis
of southernSCOPE approach and being very close to it. It is
based on somewhat different processes, taking place in
different order. Moreover, in northernSCOPE methodology
the scope manager is ascribed even higher responsibility
he should additionally cooperate with client on defining and
analysing quality requirements with regard to the project.
What’s more, in this methodology one may identify the
influence of FSM method developed by FiSMA, in which
layered architecture (as in the COSMIC method) may be
distinguished, as the requirements towards the product need
to be previously divided into sub-projects, for which the
estimates are then being calculated.
3 The Software project Functional
Assessment Model
3.1 Assumptions for the full version of
SoftFAM
Concurrently with the above methodologies the author of
this paper proposed and verified her own model, designed
for the functional assessment of BSS D&EP, named
SoftFAM (Software projects Functional Assessment Model)
[17, pp. 305-395]. Functional Assessment (FA) of project is
understood by the author as its ex ante and ex post
evaluation carried out on the basis of FSM concept. Key
attributes of FA include: product functional size (FS), work
effort which needs to be spent on FS
development/enhancement (E), and functional productivity
(P) understood as the ratio of product functional size to the
work effort on FS development/enhancement (FS/E), or
being inversion of functional productivity - work effort
necessary to achieve functionality unit (E(u)=E/FS) that
determines work cost per FS unit (thus measured with
regard to the product size unit, not to the work time unit).
The SoftFAM may occur in the form of full model as
well as in one of the simplified variants thus it has a
modular character. The following assumptions were
explicitly included to the full variant of the model:
1. Functional assessment consists of at least three stages:
1.1. Initial functional assessment (FA1). It may take
place as soon as at the stage of initiating BSS
D&EP thanks to the functional size early
estimation rule, having been derived on the basis
of benchmarking data [18, p. 11] (the so-called
calculations of Function Points Zero FP0). Yet
more accurate estimates are received at the
analysis stage where the fundamental FUR are
known – they are based on the calculations of FP1
(Function Points One), for which, according to the
rules of FSM methods, estimation error up to
±30% is allowed. Estimation made at this very
stage should be sufficient for initial planning of
project attributes, making initial decision on
investment, choosing execution variant as well as
for choosing group of providers’ offers. Further
analytical works involve substantial means which,
according to the ISBSG report [19, pp. 1–3], make
up even up to approx. 27% of the effort spent
during the entire project cycle and thus it is
worthwhile to make use of the possibility to
rationalize of these activities and decisions already
at this very stage.
1.2. Detailed functional assessment (FA2). For the
second time estimation should be carried out when
detailed FUR specification is already known,
which is upon completion of the analytical stage.
At this stage estimations are based on calculating
FP2 (Function Points Two), in case of which – in
accordance with the FSM methods rules
estimation error should not exceed ±10%. Thus,
what should be done is a correction of the initially
estimated required functional size and based on
this the required effort and functional
productivity. This correction results not only from
the fact of FUR changing since the moment of
calculating FP1 but also from the change of the
error range allowed for FS at this very stage and
consequently – also for the attributes estimated on
the basis of FS. Based on estimations being
derived at this stage, another functional
assessment of the previously selected group of
providers’ offers should be made so that as a result
at most several potential product providers will be
chosen following the criteria of such assessment.
Selecting one of these providers may depend on
other criteria as well – they should regard first of
all fulfilling of client’s non-functional
requirements. It is important that the required
product functional size as well as the offered and
approved work cost per functionality unit are
reflected in provider’s formal commitment to a
client, which means formal ex ante pricing of the
project product.
1.3. Final functional assessment (FA3). For the third
time functional assessment should be made upon
completion of development/enhancement
activities in order to measure the actually
delivered FS, which is meant to lead first of all to
the ex post pricing of product on the basis of this
size and the approved work cost per functionality
unit as well as it is to be used to verify degree of
FUR accomplishment by a provider, who thus
gains possibility to enhance his software
processes. Data obtained this way should be then
stored by provider in the organisational
benchmarking data repository, especially designed
for this very purpose. This is meant for deriving
and verifying dependencies being specific to given
project organisation but also for enhancing FSM
methods and effort estimation models. At this
stage calculations should take into account the fact
that since the moment of making FP2 calculations
FUR might have changed. Thus the value of all
required attributes needs to be updated.
2. All required (FSr, Er, Pr), offered (FSo, Eo, Po) and
realised (FSre, Ere, Pre) attributes should be included
to the relevant tolerance intervals, dependent on the
functional assessment stage, which normalize the
ranges of allowed values. The need of taking them into
account results both from the limited possibilities to
derive accurate estimates, particularly at the initial
assessment stage, being caused first of all by the BSS
D&EP execution conditions changing over time, as
well as by analytical needs. Tolerance intervals should
promote rational delineating of required and offered
attributes values. They read as follows:
2.1. Product functional size – both required by a client
(FSr) as well as offered (FSo) and realised (FSre)
by a provider – must be within the range allowed
for FSr, i.e., [FSmin, FSmax], where: FSmin –
stands for minimum while FSmax stands for
maximum required functional size. Defining of
FSmax results from the fact that, as showed by the
Standish Group studies, only about 20% of
functions and features specified get ever used [2,
p. 1]. Thus delineating the maximum expected
functional size reduces the risk of delivering
needless functionality.
2.2. Work effort both expected by a client (Er) as
well as offered (Eo) and realised (Ere) by a
provider must be within the range allowed for
Er, i.e., [Emin, Emax], where: Emin stands for
minimum while Emax stands for maximum
effort expected by a client. Emin should not be
lower than the effort enabling for delivering
minimum required functional size (FSmin).
2.3. Functional productivity – both required by a client
(Pr) as well as offered (Po) and realised (Pre) by a
provider must be within the range allowed for
Pr, i.e., [Pmin, Pmax], where: Pmin - stands for
minimum while Pmax - stands for maximum
productivity required by a client. Having Pmax
defined is useful for rational provider offer
selection, i.e., from the point of view of limiting
the risk of choosing the offer where the
productivity would be defined as overstated value.
Since such situation would mean that in fact the
effort per functionality unit is likely to be
exceeded, which would entail the risk of
delivering product having functional size lower
than the allowed one as the provider would be
probably trying not to go over the offered effort.
In addition, delineating Pmax is conducive to the
increased probability of delivering product of
sufficient quality.
Fulfilling these conditions ensures:
Rationality of client requirements with regard to
the functional assessment attributes.
Conformity of the potential providers offers with
rational client requirements concerning functional
assessment attributes.
Conformity of the accomplished project with
client requirements concerning functional
assessment attributes.
3.2 Simplified variants of SoftFAM
The full variant of SoftFAM comprises at least two
stages of estimation (FA1, FA2), within which the ranges of
allowed values for functional attributes are being used. Due
to the modular character of the presented model there is also
the possibility to use its simplified variants, which may be
considered for applying in practice keeping in mind,
however, the increase of risk caused by such simplification.
Simplified variants of the full SoftFAM include (see Table
1):
Variant A: approach consisting in resigning from FA1.
This variant – although the ultimate choice of provider is
made following the same criterion as in the case of full
model entails losing some benefits being, among
others, the possibility of making rational investment
decision about engaging in project works and selecting
project execution variant in the initial phase as well as
the possibility of justifying necessary investment
expenses and planning the project as early as at the stage
of analysis in its lifecycle. These decisions and activities
are postponed therefore there exists the risk of losing
significant efforts having been spent on complete
execution of analytical phase in case of potential
resignation from project being a result of assessment
made at the FA detailed stage (FA2). However, one may
consider employing this approach with regard to the
projects towards which the arbitrary decisions on the
need for their execution were made.
Variant B: approach consisting in resigning from FA2.
In the case of this approach, the ultimate selection of
offer and ex ante product pricing is made on the basis of
the group of offers being evaluated at the FA initial
stage (FA1). Thus the simplification of the assessment
procedure takes place at the cost of lower level of
satisfying client’s analytical needs with regard to the
evaluated offers. It may result in choosing unsuitable
product provider and in the wrong pricing – because of
not taking into account for the assessed attributes values
having been corrected after detailing client’s
requirements out as well as because of accepting large
tolerance intervals for functional attributes.
Variant C: approach consisting in quitting intervals of
allowed values for the expected functional attributes. In
this variant at least two stages of estimation are
maintained yet the intervals of allowed values for the
expected attributes are leaved out. In fact it means that
required functional size (FSr) and required functional
productivity (Pr) are considered as minimum allowed
values whereas the required work effort (Er) as a
maximum allowed value. Thus it is assumed that there is
no risk of overstating the two first attributes and
understating the third attribute, what relates to some
negative consequences, including first of all the
possibility of deliberate lowering the effort per
functionality unit. As a result it may lead in reality to its
probable exceeding and/or to delivering product of
functional size being lower than the required one and/or
being of insufficient quality. In the case of this approach,
project execution offer will be regarded as complying
with client’s requirements if the offered functional size
(FSo) is not lower than the required one, the offered
effort (Eo) does not exceed the required effort whereas
the offered functional productivity (Po) is at least at
parity with the required one. Analogous conditions apply
to the analysis of conformity of the realized functional
attributes (FSre, Ere, Pre) to the client’s expectations.
Variant D: approach consisting in quitting intervals of
allowed values for the expected functional attributes and
resigning from FA1. This approach is a combination of
variant C and variant A – with all the consequences
resulting from it.
Variant E: approach consisting in quitting intervals of
allowed values for the expected functional attributes and
resigning from FA2. This variant, on the other hand, is a
combination of variant C and variant B. The variant
due to its consequences – should be regarded as
simplified to the largest extent and is characterised by
the highest risk. This variant appears closest to the
mentioned methodologies supporting project scope
management, that is to the southernSCOPE and
northernSCOPE.
Table 1. The SoftFAM – full variant vs. simplified variants
SoftFAM FA1 FA2 FA3 Tolerance
intervals
Full variant Carried out Carried out Carried out Applied
Variant A Nonexistent Carried out Carried out Applied
Variant B Carried out Nonexistent Carried out Applied
Variant C Carried out
in a
simplified
form
Carried out in
a simplified
form
Carried out
in a
simplified
form
Nonexistent
Variant D Nonexistent Carried out in
a simplified
form
Carried out
in a
simplified
form
Nonexistent
Variant E Carried out
in a
simplified
form
Nonexistent Carried out
in a
simplified
form
Nonexistent
Source: Author’s own study.
As indicated by the analysis, fundamental advantage of
the presented variants is a simplification of the functional
assessment process although, according to the author,
activities making up the full SoftFAM are rather not overly
complicated and laborious, especially in the situation where
there are many FSM supporting tools (see e.g., [20, pp. 123-
124]). At the same time, however, simplification of the
assessment process takes place at the cost of lower level of
satisfying client’s analytical needs with regard to the
functional attributes, which increases the risk of failing to
achieve goals having been set for this very assessment.
Level of satisfying client’s analytical needs decreases with
gradual resignation from, initially, one of the two stages of
assessment, next from the intervals of allowed values for
functional size, effort and functional productivity, and then
with omitting both aspects of the FA. Assessment will be
more detailed if a client resigns from the initial stage of
estimation thus, however, increasing the risk of making non-
rational investment decision due to the estimates being
delayed in relation to the possibilities.
In general, use of simplified solutions carries higher risk
of making erroneous decision. Thus, the model of BSS
D&EP functional assessment should be „as simple as
possible yet not simpler”, which should be kept in mind
whenever employing the simplified approaches.
3.3 Verification of SoftFAM
Due to the limited volume of the paper it will only
feature conclusions coming from the SoftFAM verification.
The SoftFAM verification was based on the case study of a
dedicated BSS being developed for the needs of Polish
affiliated sales department of international motor concern
and presented widely in [21]. The verification conclusions
prove that using full variant of SoftFAM allows limiting the
following negative phenomena:
Deliberate lowering of BSS delivery costs by offerors –
thanks to ex ante and ex post product pricing based on
the required (ex ante pricing) and actually delivered (ex
post pricing) product functional size and work cost per
functionality unit having been mutually and formally
agreed at the stage of provider selection.
Clients increasing the required functionality during the
project without relevant reflecting of this change’s
consequences in the execution costs thanks to the
monitoring of each change in product functional size and
ability to determine this change’s influence on total
work costs on the basis of the formally agreed work cost
per functionality unit.
Provider in reality delivering product having
functionality lower than the required one within the
fixed price contracts – client is not obligated to pay for
the functionality, which had not been delivered as the ex
post product pricing is based on its actually delivered
functional size.
Provider delivering functionality (many a time also
being lower than the required one) at costs being higher
than those expected, which usually takes place in the
case of time and material contracts client does not
settle the payment on the basis of project duration but on
the basis of actually delivered product functional size
and formally agreed work cost per functionality unit.
This is possible thanks to the following rules being used
in the SoftFAM:
Adopting the allowed tolerance intervals for required,
offered and realised FA attributes.
When choosing offers for project execution, preferring
the highest allowed productivity (the lowest allowed
effort per functionality unit) instead of the cheapest
offers.
Taking into account the influence of changes in FUR
being made during the project lifecycle on product
functional size, work effort and functional productivity.
Ex ante and ex post pricing of product based on the
required and actually delivered product functional size
as well as mutually agreed work cost per functionality
unit.
Verification of the full SoftFAM indicates that it
promotes both fundamental factors of the effective
execution of BSS SD&EP [2, pp. 2–4] – as it contributes to
getting client involved in the project and to the proper
management of project scope, as well as to achieving most
of the functional measurement goals mentioned in the
ISO/IEC 14143 norm, especially in the area of project
management [4, Part 6, pp. 9–10].
On the other hand, verification of the simplified variants
of the SoftFAM proved that applying them entails the
following risk [17, p. 390]:
Variant A: using it entails the risk of making wrong
investment decision by a client due to overly high
estimated work costs and/or overly long time of project
lifecycle the decision made at the FA1 stage could lead
to giving up the project or to quitting some of the
functional requirements, or possibly to delaying their
execution.
Variant B: using it entails the risk of choosing wrong
provider and the risk of understated product pricing and
therefore the risk of failing to deliver required
functionality and/or to deliver product of insufficient
quality.
Variant C: as above since without verification of
maximum allowed level for the offered functional
productivity one should expect higher risk of lowering
the effort per functionality unit, which on the other hand
increases the probability of exceeding it as well as
failing to deliver required functional size and/or to
deliver product of insufficient quality.
Variant D: see variant A and variant C.
Variant E: see variant B and variant C.
4 Concluding remarks
Due to the unsatisfactory effectiveness of BSS D&EP
execution in practice, not only in Poland, there is a
significant need for the rationalization of practical activities
and business decisions made with regard to these projects
both on the side of providers as well as clients
commissioning projects of this type. Increasing this
effectiveness requires first off all better management of such
projects’ scope. Proper planning and control of project scope
needs objective and reliable measurement of key project
attributes: its effort, costs and duration. Also, measurement
of these attributes is of significance to a client, as it
constitutes grounds for the rational investment decision
about getting involved in BSS development or enhancement
project. Whereas proper measurement of key project
attributes is not possible without objective and reliable
measurement of its product’s size, which thus makes it
become significant factor promoting the effectiveness of
these projects’ execution. Thus far the only standardized
concept of software product size measurement has been
FSM concept; 5 methods based on FSM were normalized
too.
It is worth using the capabilities offered by FSMM for
the BSS D&EP assessment from the perspective being
critical to a client, that is from functional perspective.
Therefore the author made an attempt to develop model of
BSS D&EP functional assessment that would allow for
assessing the effectiveness of their execution both ex ante as
well as ex post. Results of the verification of the proposed
SoftFAM in its full variant prove that it allows for the
rationalization of specified practical activities and business
decisions based on its criteria:
Practical activities include: setting of client’s rational
requirements concerning functional attributes, evaluation
of potential providers’ offers with regard to these
attributes, comparison of execution variants from the
perspective of the estimated work costs, rational ex ante
and ex post pricing of project product as well as
improving of prognoses concerning future projects by a
project provider.
Among business decisions being supported by proposed
model one should mention: client’s investment decision
on getting engaged in project having expected functional
attributes, selection of the offer best suited to his
requirements concerning functional attributes as well as
decision about work cost per functionality unit offered
by potential providers.
What’s more, results of the SoftFAM verification also
indicate that formal product pricing should base on the
required size (ex ante pricing) and actually delivered size
(ex post pricing) of this product expressed in functionality
units as well as on the agreed work cost unit measured with
regard to the functional size unit.
Thanks to the mentioned options the BSS D&EP
functional assessment model in its full variant promotes
reducing of some negative phenomena commonly occurring
in practice of such projects execution, having
disadvantageous influence on their effectiveness.
Advantage of the full version of SoftFAM over
southernSCOPE and northernSCOPE methodologies results
from the fact of the model adopting two significant
assumptions, not being explicitly specified in these
methodologies, namely:
Need to apply upper bounds of the allowed tolerance
intervals for required, offered and realised functional
size and functional productivity and lower bounds for
work effort.
Need to employ at least two stages of estimation: first
one for proper assessment of the investment decision
rationality while second stage in order to choose
suitable software product provider.
Therefore, comparing to these methodologies, using full
SoftFAM reduces the risk of choosing inappropriate
provider and the risk of lowered product pricing and
consequently, it reduces the chance of failing to deliver
required functionality and/or to deliver product of
insufficient quality. On the other hand, modular character of
SoftFAM enables for choosing its variant being most
suitable to a given situation – it may be a version based on
the simplest criteria, closest to the southernSCOPE and
northernSCOPE methodologies.
5 References
[1] M. Dyczkowski. “Ocena przebiegu i efektow
przedsiewziec informatycznych. Wybrane wyniki badan
porownawczych z lat 2004–2007” [“Evaluation of the
course and effects of IT projects. Selected results of
comparative studies over the years 2004-2007”]; in:
Systemy wspomagania organizacji SWO'2007
[Organisation Support Systems SWO’2007], T. Porebska-
Miac, H. Sroka, Eds., Prace Naukowe Akademii
Ekonomicznej w Katowicach, pp. 465-474, Katowice, 2007.
[2] Standish Group. “CHAOS Summary 2009”, West
Yarmouth, Mass., 2009.
[3] State Government of Victoria. “southernSCOPE,
Reference Manual”, Version 1, Government of Victoria,
Melbourne, 2000.
[4] ISO/IEC 14143 Information Technology Software
measurement Functional size measurement Parts 1–6,
ISO, Geneva, 1998-2007.
[5] ISO/IEC 20926 Software engineering – IFPUG 4.1
Unadjusted functional size measurement method – Counting
practices manual, ISO, Geneva, 2003.
[6] ISO/IEC 20968 Software engineering – Mk II Function
Point Analysis Counting practices manual, ISO, Geneva,
2002.
[7] ISO/IEC 24570 Software engineering – NESMA
functional size measurement method version 2.1
Definitions and counting guidelines for the application of
Function Point Analysis, ISO, Geneva, 2005.
[8] ISO/IEC 19761 Software engineering – COSMIC-FFP
– A functional size measurement method, ISO, Geneva, 2003.
[9] ISO/IEC 29881 Information Technology Software
and systems engineering – FiSMA 1.1 functional size
measurement method, ISO, Geneva, 2008.
[10] State Government of Victoria. “Acquiring Custom-
Build Software Policy”, Government of Victoria,
Melbourne, 2000.
[11] International Software Benchmarking Standards Group.
“Release 10 Repository Demographics”, ISBSG, Hawthorn,
VIC, 2007.
[12] T.C. Jones. “Software Estimating Rules of Thumb”,
Version 3, Software Productivity Research, 2007.
[13] Sage Technology. “Report on the SCUD Methodology
Review”, 2000.
[14] P.R. Hill. Some practical uses of the ISBSG history
data to improve Project Management”, ISBSG,
Hawthorn, VIC, 2007.
[15] International Software Benchmarking Standards Group.
“The ISBSG Report: Software Project Estimates How
accurate are they?”, ISBSG, Hawthorn, VIC, 2005.
[16] Finnish Software Metrics Association. “nothernSCOPE
– customer-driven scope control for ICT projects”, FiSMA,
2007.
[17] B. Czarnacka-Chrobot. “Wymiarowanie funkcjonalne
przedsiewziec rozwoju systemow oprogramowania”
[“Functional Measurement of Business Software Systems
Development and Enhancement Projects”], Warsaw School
of Economics Publishing House, Warsaw, 2009.
[18] “Practical Project Estimation (2nd edition): A
Toolkit for Estimating Software Development
Effort and Duration”, P.R. Hill, Ed., ISBSG,
Hawthorn, VIC, 2005.
[19] International Software Benchmarking Standards Group.
“The ISBSG Special Analysis Report: Planning Projects
Project Phase Ratios”, ISBSG, Hawthorn, VIC, 2007.
[20] B. Czarnacka-Chrobot. “The Role of Benchmarking
Data in the Software Development and Enhancement
Projects Effort Planning”; in: New Trends in Software
Methodologies, Tools and Techniques, Proceedings of the
8th International Conference SOMET’2009, H. Fujita, V.
Marik, Eds., Frontiers in Artificial Intelligence and
Applications, vol. 199, pp. 106-127, IOS Press, Amsterdam-
Berlin-Tokyo-Washington, 2009.
[21] B. Czarnacka-Chrobot. “Rational Pricing of Business
Software Systems on the Basis of Functional Size
Measurement: a Case Study from Poland”; in: Proceedings
of the 7th Software Measurement European Forum (SMEF),
Rome, June 2010 (in press).
... Here is why the FSM concept constitutes basis of the southernSCOPE [13] and northernSCOPE [26] methodologies, supporting the management of BSS D&EP functional scope, i.e., scope measured on the basis of functional size of their product. Fundamental assumptions of these methodologies read as follows (see also [27]): ...
... • There is a possibility to reduce the number of changes to the required product functionality appearing upon completion of the requirements specification phase. Concurrently, with the above methodologies, the author of this paper proposed [27] and verified [28] her own model, designed for the functional assessment of BSS D&EP, named SoftFAM (Software projects Functional Assessment Model). Functional Assessment (FA) of project is understood by the author as its ex ante and ex post evaluation carried out on the basis of FSM concept. ...
... Due to the modular character of the presented model there is also the possibility to use its simplified variants, which may be considered for applying in practice keeping in mind, however, the increase of risk caused by such simplification. As indicated by the analysis in [27], level of satisfying client's analytical needs decreases with gradual resignation from, initially, one of the two stages of assessment, next from the intervals of allowed values for functional size, effort and functional productivity, and then with omitting both aspects of the FA. Assessment will be more detailed if a client resigns from the initial stage of estimation thus, however, increasing the risk of making non-rational investment decision due to the estimates being delayed in relation to the possibilities. ...
Article
Full-text available
Execution of Business Software Systems (BSS) Development and Enhancement Projects (D&EP) encounters many problems, leading to the high scale of their failure, which then is reflected in considerable financial losses. One of the fundamental causes of such projects' low effectiveness are improperly derived estimates for their costs and time. In their case, the budget and time frame are determined by the effort being spent on activities needed to deliver product that would be meeting client's requirements. Meanwhile, objective and reliable effort estimation still appears to be a great challenge, what in the author's opinion is caused by effort estimation based on resources, while such planning activity should base on the required software product size, which determines work effort. Estimation of BSS size requires using of the suitable software size measure, which has been sought for several decades now. What's more, it is worth using the capabilities offered by such measure for the BSS D&EP assessment from the perspective being critical to a client, that is from functional perspective. Thus this paper analyses capabilities, being significant from the economic point of view, of taking advantage of suitable approach to the BSS size measurement, what should contribute to the better understanding of the importance of this issue, still being underestimated by business managers – as in the subject literature this issue is usually considered from the technical point of view. Meanwhile, suitable BSS size measurement should constitute the basis for rational activities and business decisions not only for providers, but also for clients needs. Keywords-business software systems development and enhancement projects; effectiveness; software size measures; functional size measurement; functional assessment; Software projects Functional Assessment Model (SoftFAM) I. SCALE OF FAILURES IN THE BUSINESS SOFTWARE SYSTEMS DEVELOPMENT AND ENHANCEMENT PROJECTS EXECUTION In practice, the execution of software Development and Enhancement Projects (D&EP), particularly those delivering Business Software Systems (BSS) as a product, encounters many problems, which makes fulfilling of client requirements still appear a big challenge for companies dealing with this kind of business (see also [1]). This may be proved by the unsatisfactory effectiveness of such projects, revealed by numerous analyses, which manifests itself in the high scale of their failure. The Standish Group, the US institution providing research reports on this issue from 15 years, estimates that now only 32% of application D&EP worldwide turn out successful while products delivered as a result of nearly 45% of them lack on average 32% of the required functions and features, the planned time of product delivery is exceeded by nearly 80% on average and the estimated budget -by approx. 55% on average [2]. Also, it is worth mentioning the research carried out by government agencies in the USA indicating that 60% of software systems development projects overrun the planned completion time, 50% of these projects overrun the estimated costs while in the case of 46% of them the delivered products turn out useless [3]. Similar – as to the general conclusion – data result from the analysis of IT projects being accomplished in Poland, which was carried out by M. Dyczkowski, indicating that in 2006-2007 approx. 48% of such projects went over the planned completion time while approx. 40% exceeded the estimated budget [4]. Analyses by T.C. Jones plainly indicate that those software D&EP, which are aimed at delivery of business software systems, have the lowest chance to succeed [5]. The Panorama Consulting Group, when investigating in their 2008 study the effectiveness of ERP (Enterprise Resource Planning) systems projects being accomplished worldwide revealed that 93% of them were completed after the scheduled time while as many as 68% among them were considerably delayed comparing to the expected completion time [6]. Merely 7% of the surveyed ERP projects were accomplished as planned. Comparison of actual versus planned expenses has revealed that as many as 65% of such projects overran the planned budget. Only 13% of the respondents expressed high satisfaction with the functionality implemented in final product while in merely every fifth company at least 50% of the expected benefits from its implementation were said to be achieved. Meanwhile (see also [4][7]): • BSS are one of the fundamental IT application areas. • BSS development or enhancement often constitutes serious investment undertaking. • In practice, COTS (Commercial-Off-The-Shelf) BSS rarely happen to be fully tailored to the particular client business requirements therefore their customisation appears vital.
... Concurrently with the southernSCOPE and northernSCOPE methodologies, the author of this paper proposed and veri¯ed in practice her own concept, designed for the functional assessment of BSS D&EP (see [4] and [5] for more details). Functional Assessment (FA) of project is understood by the author as its ex ante and ex post evaluation carried out on the basis of FSM concept and methods. ...
... What's more, the modular character of the presented concept enables to choose its most suitable variant to a given situation. This may be a version based on the simplest criteria, closest to the southernSCOPE and northernSCOPE methodologies (see [4] for more details). ...
Article
Full-text available
Each rational investment decision, including those made by clients with regard to Business Software Systems (BSS) Development and Enhancement Projects (D&EP), should meet two measurable criteria: effectiveness and economic efficiency. However, in the case of BSS D&EP, the assumption concerning the measurability of these criteria is often treated as controversial. Meanwhile, the so-called concept of BSS D&EP Functional Assessment (FA), proposed by the author and verified in practice, allows for using the potential offered by the Functional Size Measurement (FSM) concept and methods in the area of the quantitative evaluation of these two criteria. Thus, the paper aims at presenting and proving the capabilities of using the functional assessment concept in the quantitative evaluation of BSS D&EP effectiveness and economic efficiency. Linking FSM issues with managerial aspects through the FA concept may contribute to a better understanding of the FSM importance, which is still underestimated by business managers, as in the subject literature this issue is usually considered from a technical perspective. Meanwhile, BSS D&EP FA can constitute the basis for rational decisions not only for BSS providers, but also for BSS clients. These issues classify into economics problems of software engineering research and practice.
... Assumptions for the SoftFAM model were presented in [23]. Due to the limited length of the paper we present here only conclusions coming from the verification of the model (for more details see [24]). ...
Article
Full-text available
Dedicated software systems hold a character of individual solutions that entail particular problems with regard to their cost estimation. Thus for many years now objective and reliable approaches to the cost estimation of such systems have been sought out so that they could provide the possibility to make rational investment decisions concerning those sys-tems. The purpose of this paper is to bring in the approach to cost estimation of dedicated software systems that has been recently growing in global popularity, using it as a background for presenting conclusions resulting from practical verification of author's own model of dedicated software system cost estimation based on that approach.
Conference Paper
Full-text available
Execution of Business Software Systems (BSS) Development and Enhancement Projects (D&EP) encounters many problems, leading to the high scale of their failure, which then is reflected in considerable financial losses. One of the fundamental causes of such projects' low effectiveness are improperly derived estimates for their costs and time. In their case, the budget and time frame are determined by the effort being spent on activities needed to deliver product that would be meeting client's requirements. Meanwhile, objective and reliable effort estimation still appears to be a great challenge, what in the author's opinion is caused by effort estimation based on resources, while such planning activity should base on the required software product size, which determines work effort. Estimation of BSS size requires using of the suitable software size measure, which has been sought for several decades now. This paper analyses capabilities, being significant from the economic point of view, of employing suitable approach to the BSS size measurement, what should contribute to the better understanding of the importance of this issue, still being underestimated by business managers - as in the subject literature this issue is usually considered from the technical point of view. Meanwhile, suitable BSS size measurement should constitute the basis for rational activities and business decisions not only for providers, but also for clients needs.
ResearchGate has not been able to resolve any references for this publication.