1. 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. 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 over 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. Interesting comparisons of resolution results, cost overrun, time overrun, and expected ROI, made by the Standish Group with regard to three types of order processing application D&EP[7], are presented in Table 1 (see also[8]).

Meanwhile:

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.

Table 1. Comparisons of Resolution Results, Cost Overrun, Time Overrun, and Expected ROI for Three Types of Order Processing Application D&EP Resolution New application development Package application with modifications Application modernization Resolution results comparison Successful 4% 30% 53% Challenged 47% 54% 39% Failed 49% 16% 8% Cost overrun comparison Below 20% 43% 22% 46% 20% to 50% 21% 36% 29% 51% to 100% 10% 29% 14% Over 100% 26% 13% 11% Avarage overrun 44% 47% 34% Time overrun comparison Below 20% 38% 27% 59% 20% to 50% 19% 32% 21% 51% to 100% 30% 31% 12% Over 100% 13% 10% 8% Avarage overrun 44% 45% 29% Expected ROI comparison High 11% 34% 52% Average 66% 57% 37% Low 23% 9% 11% Source:[7, pp. 4-6].

Rational ex ante and ex post valuation of unique (at least partially) BSS, being of key significance to clients, encounters serious problems in practice.

From the provider’s perspective, the discussed type of IT projects is particularly difficult in terms of management, which basically results in their exceptionally low effectiveness as compared to other types of IT projects.

2. Losses Caused by the Low Effectiveness of Business Software Systems Development and Enhancement Projects Execution

Low effectiveness of BSS D&EP execution leads to the substantial financial losses, on a worldwide scale estimated to be hundreds of billions of dollars yearly, sometimes making even more than half the funds being invested in such projects. The Standish Group estimates that these losses – excluding losses caused by business opportunities lost by clients, providers losing credibility or legal repercussions – range, depending on the year considered, from approx. 20% to even 55% of the costs assigned for the execution of the analyzed projects types (see e.g.,[9,10]). On the other hand, analyses of The Economist Intelligence Unit which studied the consequences of BSS D&EP delay indicate that there is strong correlation between delays in delivery of software products and services and decrease in profitability of a company therefore failures of BSS D&EP, resulting in delays in making new product and services available and in decreasing the expected income represent threat also to the company’s business activity[11]. Meanwhile,”The costs of these (...) overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable, but could easily be in the trillions of dollars.[For instance - B.C.C.] the failure to produce reliable software to handle baggage at the new Denver airport is costing the city $1,1 million per day.”[12].

If direct losses caused by abandoning the BSS D&EP result from erroneous allocation of financial means, usually being not retrievable, in the case of overrunning the estimated time and/or costs, however, they may result from delay in gaining the planned return on investment as well as from decreasing it (necessity to invest additional funds and/or cutting on profits due to the overrunning of execution time and/or delivery of product incompatible with requirements).

According to the Standish Group analyses, yearly spendings on application software D&EP in the USA range from approx. 250 to approx. 350 billion USD. In this type of projects, average yearly cost of development works alone ranges from approx. 0,4 to approx. 1,6 million USD, what indicates that they are usually serious investment undertakings. Spendings on such projects may considerably exceed the expense of building offices occupied by companies commissioning them, and in extreme cases, even 50-storey skyscraper, roofed football stadium, or cruising ship with a displacement of 70.000 tons[13]. Yet quite often client spends these sums without supporting their decision on getting engaged in such investment by proper analysis of the costs, based on the rational, sufficiently objective and reliable grounds. The above situation manifests itself in the difference in costs spent by various organizations on similar applications that may be even fifteen fold[14].

The above unequivocally implies a significant need to rationalize practical activities and business decisions made with regard to BSS D&EP, which is only possible when taking into account factors showing influence on this effectiveness. Author’s analysis, which concerned numerous studies on factors of BSS D&EP effectiveness, available in the subject literature, leads to the conclusion that among fundamental factors are:

1) Proper project management, including: realistic planning, with particular consideration given to the reliable and objective estimates for key project attributes (work effort, execution time and cost), and proper project scope management, above all consisting in undertaking small projects, that is projects whose product is characterised by relatively small size. Both these factors require product size measurement.

2) Authentic involvement of client in the project – both users and managers. Thus product size measurement should be carried out by taking into consideration mainly the perspective of the client of BSS being developed, that is with the use of product size units that are of high significance to him.

Therefore if fundamental opportunity to increase the chance for effective execution of the discussed types of projects and to decrease the losses caused by low effectiveness lies in accurate estimates of their key attributes, in undertaking small projects and in client’s involvement then what appears to be significant factor of BSS D&EP success is objective and reliable measurement of their product size, with particular consideration given to client’s perspective. ”Measurement of software size (...) is as important to a software professional as measurement of a building (…) is to a building contractor. All other derived data, including effort to deliver a software project, delivery schedule, and cost of the project, are based on one of its major input elements: software size.”[15, p. 149].

3. Business Software Systems Size Measures

All paragraphs One of the fundamental causes of low BSS D&EP success rate are improperly derived estimates for their costs and time. In the case of such projects the budget and time frame are determined by the effort being spent on activities needed to deliver product, which would meet client’s requirements. However, sufficiently objective and reliable BSS D&EP effort estimation still appears to be a great challenge to the software engineering. In the author’s opinion the main reason for this problem is effort estimation made on the basis of resources whereas such planning activity should ground on the required software product size, which determines the work effort.

Table 2. Synthetic Comparison of Software Size Measures Requirement towards measures Programming units Construction complexity units Functionality units Unequivocalness of definition Freedom in formulating definitions (differences as big as even 5:1) Depending on the method In methods normalized by ISO/IEC Possibility to make reliable prognosis on the size relatively early in the life cycle Possibility to calculate programme length only for the existing code None – with regard to programming units and object points As early as at the stage of requirements specification Base for the reliable evaluation of the all phases work effort Final programme length does not fully reflect the whole work done Final software size does not fully reflect the whole work done Relatively high reliability as early as at the stage of requirements specification Software size being independent of the technology employed Programme length determined by the language employed Size being dependent on the technology employed Size depends on functional user requirements Possibility to compare software written in different languages Lack of such direct possibility Lack of such direct possibility Size doesn’t depend on the language used Measuring size in units being of significance to a client No significance to a client Secondary significance to a client Measurement from the point of view of a client Possibility to compare delivered size vs. required size Inability to make reliable prognosis Inability to make reliable prognosis Thanks to the possibility of making reliable prognosis Possibility to measure all software categories Yes Depending on the method Depending on the method Easiness of use Yes No No

Basic approaches to the size measurement of every software product may be reduced to perceiving it from the perspective of:

Length of programmes, measured by the number of the so-called programming (volume) units. These units most of all include source lines of code, but number of commands, number of machine language instructions are also taken into account. However, these units measure neither size of the programmes nor their complexity but only the attribute of “programme length” yet thus far these are them that in practice have been employed most often with regard to the software size[15, p. 149].

Software construction complexity, measured in the so-called construction complexity units. Most of hundreds of such measures having been proposed are limited to the programme code yet currently these units are used mainly in the form of object points[15, pp. 155-156]. These points are assigned to the construction elements of software (screens, reports, software modules) depending on the level of their complexity.

Functionality of software product, expressed in the so-called functionality units. They most of all include function points, but also variants based on them such as: full function points, feature points, or use case points. These points are assigned to the functional elements of software (functions and data needed to complete them) depending on the level of their complexity – not to the construction elements as it was the case of object points.

Synthetic comparison of various software size measures against a background of key requirements set for such measures were presented in Table 2.

4. Standardization of Functional Size Measurement

Many years’ verification of reliability and objectivity of various approaches towards software size measurement showed that what for now deserves standardization is just the concept of software size measurement based on its functionality – being an attribute of first priority to the client (see also[8]). The concept of the so-called software Functional Size Measurement (FSM) was normalized in the six-part standard ISO/IEC 14143[16]. First of all, this standard specifies definition of functional size, which 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”[16, Part 1]. Hence functional requirements in this norm, due to their importance and need to ensure objectivism of measurement, are treated disjointly when combined with other requirements of non-functional character. The elementary unit of FUR used for measurement purposes is called Base Functional Component (BFC). The example of a FUR could be “Maintain Customers”, which may consist of the following BFC: “Add a new customer”, “Change customer details” and “Delete a customer”[16, Part 1]. On the other hand, Functional Size Measurement Method (FSMM) in the discussed standard was defined as a specific FSM implementation defined by a set of rules, which conforms to the mandatory features of such measurement.

According to the ISO/IEC 14143 norm the process of using FSMM should comprise the following steps[16, Part 1]: (1) defining the scope of FSM, (2) identifying the FUR contained within the scope of FSM, (3) identifying the BFC contained within the FUR, (4) classifying the BFC with regard to their type, (5) assigning appropriate value to each BFC, and (6) calculating functional size.

There are about 25 variants of the FSM techniques having been developed, however only five of them have been now acknowledged by the ISO/IEC as conforming to the rules laid down in the ISO/IEC 14143 norm and certified as international standard, namely: (1) International Function Point Users Group (IFPUG) method, which is approved in the ISO/IEC 20926 standard[17]; (2) Mark II (MkII) function point method proposed by the United Kingdom Software Metrics Association (UKSMA), which offers more detailed measurement comparing to the IFPUG method and is normalized in the ISO/IEC 20968 standard[18]; (3) Netherlands Software Metrics Association (NESMA) function point method, being the simplified version of IFPUG method, which is approved in the ISO/IEC 24570 standard[19]; (4) Common Software Measurement International Consortium (COSMIC) method, which is certified in the ISO/IEC 19761 standard[20]; and (5) FSM method developed by the Finnish Software Metrics Association (FiSMA), which is normalized in the ISO/IEC 29881 standard[21].

The first three methods listed above are accepted by the ISO/IEC not in full versions, as proposed by the organizations developing them, but in part, however in the most important part with respect to the software functional size measurement[16, Part 6] – that is why they are called the first-generation FSMM. In the approaches proposed by IFPUG, UKSMA and NESMA these methods involve also delineating of the so-called Value Adjustment Factor (VAF), which is supposed to adjust functional size being measured with the use of Unadjusted Function Points (UFP) to the environment of specified project by taking technical and quality requirements (i.e., requirements of non-functional character) into consideration[22, Part 5]. Yet this part of these methods has not been approved by the ISO and IEC – as these organizations’ assumptions exclude the fact of FSM depending on requirements of this type. On the other hand, the COSMIC and FiSMA methods were recognized as international standard entirely[16, Part 6][21] – that is why they are called the second-generation FSMM.

FSM methods accepted by ISO/IEC differ in terms of software measurement capabilities with regard to various categories of software (i.e., so-called functional domains). Thus prior to choosing given method one should assess its adequacy to the type of software product. In the ISO/IEC 14143 norm it is stated, that[16, Part 6]:

There are no functional domains constraints for the accepted part of the IFPUG and NESMA methods, although they were developed as intended for measurement of BSS functional size, nor for the FiSMA method.

The UKSMA method is adequate for the measurement of any type of software provided that the so-called logical transactions may be identified in it. The rules were developed as intended for BSS therefore the method supports neither complex algorithms characteristic of scientific and engineering software nor the real-time systems.

The COSMIC method is adequate for: data-driven systems (i.e., BSS), time-driven systems (i.e., real-time systems), and hybrid solutions combining both the above (e.g., real-time systems of airline tickets booking). On the other hand there are constraints for software with complex mathematical algorithms or with other specialized and complex rules (e.g., expert, simulation, weather forecasting systems) and for software processing continuous variables (e.g., computer games, musical instruments software).

The ISO/IEC 14143 norm adheres to the ISO/IEC 15939 standard[23], determining general rules and procedures for the software measurement process in compliance with the ISO/IEC 15288 norm[24], which, on the other hand, defines processes of the system’s life cycle. One of the steps of the size measurement process defined in the ISO/IEC 15939 standard is procedure of selecting a method that will be used to measure its size. According to this procedure, selection of FSM method being best tailored to the client’s needs should consist of the following activities: (1) characteristics of organizational units of software user with regard to the measurement process, (2) identification of their information needs towards measurement process, and (3) selection of appropriate FSMM on the basis of prospective methods identification (for more details see[25]).

Requirements towards appropriate FSM method vary depending on the organization’s character. For example, financial institutions usually choose the method, which correctly measures the BSS while chemical company, by reason of its basic activity, would rather require measurement method being suitable for the real-time systems. Choosing method adequate to the needs would also depend on how its result is planned to be used. If an organization intends to use the measurement results also for the purpose of comparing its productivity against industry data, it is recommended to choose the method being relatively popular in the given industry, for which such data exist. In the case it only needs cursory, rough estimation of functional size, the requirements towards appropriate method of its measurement will get reduced.

ISO and IEC allow for selecting method other than the methods approved by them yet they recommend that it conforms to definitional part of the ISO/IEC 14143 norm. It is also recommended to carry out measurement with the use of relevant supporting tools (see e.g.,[26]).

5. Business Software Systems Functional Size Measurement

Thus to measure BSS functional size one may use all FSMM normalized by the ISO/IEC. What’s more, this is the need to measure BSS size that was at the basis of FSM concept and methods development. In the context of their FSM it is assumed that software systems of this type are characterized by the following properties ([27], see also[8]):

Basic purpose of BSS is to acquire, collect and make available data concerning business activity to support this very activity by: keeping data in the ordered way, enabling execution of various inquiries and delivering information supporting the decision-making.

Functionality of BSS usually is dominated by the need to collect business data of differentiated level of structure complexity and to ensure their integrity and availability in the long run.

Overwhelming majority among the so-called functional users of BSS are persons (in contrast to things: other software, devices, hardware) who usually enter into direct interaction with the system through the input/output devices. It means that considerable part of functionality is directed towards right proceedings in case of mistakes being made by this type of users and towards helping to use BSS efficiently. If other, equivalent applications or their components cooperate with the measured system, then they also – next to persons – are functional users of this application.

Different BSS may cooperate (e.g., exchange data) either on-line or in a batch mode.

In BSS data are usually collected historically, i.e., after the events that took place in real world, taking into consideration the time of current answer and the fact it is given by a person. Data may be processed also in the batch mode. As a rule BSS do not include software used to drive the real-world events in the real time, which is characteristic of real-time systems although it happens that they receive data in the real time (e.g., prices on the market) – as a result they are forced to respond in similar way.

Business rules governing data manipulation may be sometimes complicated however BSS rarely include a large number of complex mathematical algorithms.

BSS usually reside in one layer of software, however application layer software depends on software located in other layers (e.g., operating system, device drivers) – otherwise it could not have been used.

BSS perceived by functional users being persons as an individual application in fact may consist of several equivalent components. Thus separate measurement for each of them may turn out necessary. This applies to the situation where the goal of the product FSM is to get its size for the effort estimation while each component is based on different execution technology.

All FSM methods normalized by the ISO/IEC allow, among others, for:

Expressing BSS size from the perspective of its functionality - software attribute being of first priority to the client, what promotes his involvement in the project – and this is a fundamental factor of BSS D&EP success (see e.g.,[2][9][10]).

Comparing the actually delivered BSS size with the size required by client, what enables to evaluate the realized project with regard to the actual value of product delivered (for more details see[28]).

Making BSS size independent of technology used in the project execution – since functional size reflects actual capabilities of the system, which are independent of programming language used.

The way of calculating BSS size that is independent of the development methodology and of the project’s life cycle models as well as of project constrains and developer’s experience[29].

Obtaining sufficiently objective and reliable estimates not only for BSS size, but also for D&EP work effort, cost and completion time relatively early in the project’s life cycle[30] – since early estimates of BSS functional size can be based on incomplete FUR (see e.g.,[26,29]).

Estimating size, effort, cost and time of each change to the BSS functional user requirements.

Determining the effort, cost and time of all project stages - since the BSS size is based on FUR and these are them that decide on the effort.

Obtaining appropriate economic indicators - since the use of BSS functional size indicates increased productivity in case of the reduction of total costs, resulting from using more efficient programming language (withdrawing the paradox of software size programming units).

Supporting CMMI-DEV (Capability Maturity Model Integration for Development[31]) - since the FSM is a factor that makes it easier for an organization to achieve subsequent levels of maturity[32].

The FSMM standardized by the ISO/IEC provide sufficiently objective and reliable basis for BSS D&EP effort, budget and time frame estimating. Results of numerous surveys, including e.g., those carried out by the State Government of Victoria[14] and International Software Benchmarking Standards Group[30], indicate that BSS D&EP in case of which the FSMM were used for effort planning, are characterised by relatively accurate estimations. Studies by the State Government of Victoria indicate that pricing of BSS on the basis of product size expressed in functionality units results in reducing the average budget overrun to less than 10% – comparing with current average budget overrun amounting to approx. 55%[2]. The ISBSG report confirms these results: in the situation where the methods based on product functional size are employed in making cost estimation, in 90% of cases the estimates differ from the actual costs not more than by 20%, and among these very cases 70% are accurate to within 10%. Also analysis of the results of 25 studies concerning the reliability of the most important BSS D&EP effort estimation methods revealed that currently the highest accuracy of effort estimations is delivered by the extrapolation methods based on software product size expressed in functionality units[26].

6. The IFPUG Method versus COSMIC Method

The two most popular normalized FSMM dedicated to business software systems are IFPUG method and COSMIC method. There are obviously certain similarities between them, which most of all include (see e.g.,[8][33][34][35]):

Common FSM concept, based on similar understanding of the measurement purpose and scope as well as definition of the measured software boundaries.

The rules of both methods are based on similar, yet not identical, meaning of the terms related to data. What also is convergent is the concept of data transformation as well as of users perceived as recipients of the measured software functionality.

Occurrence of two phases of measurement: identification of elements, on the basis of which the functional size is determined, and actual measurement, in which they are mapped into this numerically-expressed size. In the IFPUG method, the first of these phases is not described explicite yet it assumes that the measurement is based on the FUR - data models, functions/processes models or windows, screens, forms and reports designs may also be used for this purpose. In the phase of actual measurement, the explicitly described rules of this method are employed towards these elements. In the COSMIC method, the measurement phase proceeds solely on the basis of FUR.

Similar way of expressing FUR. In both methods, FUR are expressed by means of BFC. In the approach developed by IFPUG there are 5 types of BFC: Internal Logical Files (ILF), External Interface Files (EIF), External Inputs (EI), External Outputs (EO), and External inQuiries (EQ)[17], whereas in the COSMIC method there are 4 types of BFC: entry, exit, read, and write[20]. However, there is no simple analogy between them as in the COSMIC method data are not measured explicite and they are not distinguished as a type of BFC.

Both approaches, although in a different way, meet the requirements imposed on FSM methods in the ISO/IEC 14143 norm therefore both were recognized as international standards of FSM (the IFPUG method not in full version - see[17] vs.[22]).

Differences between the discussed methods mostly concern the following:

Rules of measurement. Fundamental difference in this respect is the fact that the IFPUG method includes general system characteristics (VAF), representing the influence of technical and quality requirements (i.e., requirements of non-functional character) on functional size. This is the reason why this approach has not been approved by ISO/IEC entirely, however taking them into account in calculations is not necessary. What’s more, studies have revealed low practical usefulness of VAF to increasing the quality of prognoses. Characteristics of this type do not exist in the COSMIC method where measurement is based solely on FUR.

Size boundaries for processes/functions. In the IFPUG method, the size of all five BFC is arbitrarily limited thus the software size depends on their number. While in the COSMIC approach there is no upper limit for the process size as it is determined by the number of data movements. On the other hand, the size of COSMIC data movement is 1 CFP (COSMIC Function Point) and does not depend on data to which it pertains, which is the case of processes in the IFPUG method.

Data inclusion manner. In the IFPUG method, data are included in calculations in a twofold way: separately as internal/external logical files and as file type referenced affecting the process size. In the case of COSMIC method, data are included with each data movement of read or write type of BFC. Thus the use of IFPUG method requires constructing of data model, which in the COSMIC approach is not indispensable however proves useful. In the IFPUG method, data model also provides basis for early estimates while in the COSMIC approach this is process model that is employed for the approximation purposes.

Benchmarking data resources. Current version of the largest repository with benchmarking data concerning software FSM, that is repository of International Software Benchmarking Standards Group (ISBSG)[36], includes data in nearly 80% pertaining to the software products being measured with the use of IFPUG method while in only 8% to those measured with the use of COSMIC method.

Moreover, in the subject literature, however, in most cases being supported by COSMIC, the following features of this method are pointed out as deciding on its advantage over IFPUG method:

Broader range of application. The IFPUG method was developed in order to measure BSS, however in its current version no constraints with regard to the measurement of other functional domains were imposed by ISO/IEC. Meanwhile it is often argued that this method does not prove useful in the case of real-time systems size measurement – unlike COSMIC method[34]. According to the author of this paper, such conclusion goes too far both from theoretical and practical point of view although measurement of this type of software using IFPUG method undoubtedly is more complicated as compared to the COSMIC method and therefore it may be less accurate. In publications on the IFPUG method one may find not only the rules but also the examples of employing it in the measurement of real-time systems size (see e.g.,[37]).

Compliance with object-oriented analysis and programming. In this case it is argued that if the COSMIC method was developed much later than IFPUG method it then takes into account modern techniques of FUR description and systems construction, paying attention mostly to the object-oriented approach[38]. However, this in no way proves that there is no possibility to calculate functional size using object-oriented approach to the development based on the IFPUG method – rules of the method and practical examples do indicate such a possibility exists (see e.g.,[39]).

Broader measurement perspective. With the use of IFPUG method, functional size is measured from the perspective of end user while with the use of COSMIC method – from the point of view of the so-called functional user that next to an end user includes also developers, who perceive other applications and devices interacting with the measured software[34]. Perspective limited to an end user only carries some danger of skipping in the calculations of such functionality, which is imperceptible to an end user, however on condition that it is assumed that only a user being a person can be a recipient of functionality. Meanwhile, recognizing the IFPUG method as complying with the ISO/IEC 14143 standard means that definition of user it currently employs is consistent with this notion’s definition included in this norm, wherein a user is understood not only as a person but also as a thing (e.g., other applications, devices) that interacts with the measured software[16, Part 1].

COSMIC approach assumes that typical software is made of layers, for which the rules of proceedings were expressed explicite therefore this method can be used to measure complex, layered architectures[29].

In COSMIC approach there are no artificial limits imposed on the size of functional process, that’s why the integrity of measure is very good, while in the IFPUG method artificial limits (e.g., weights) limit the size of BFC, so the integrity is limited[29].

Possibility of faster delivery of results. COSMIC method happens to be regarded as more intuitive, more concise and simpler than IFPUG approach, which should result in quicker delivery of the measurement outcome. Yet this has not been confirmed by the surveys, which indicated that there are no significant differences in the quickness of measurement made with the use of both methods[35]. What is more, even authors of the COSMIC method admit that in case one needs quick measurement with low-quality user requirements, it is simpler (and quicker) to employ IFPUG method – which results from the limited scope of its BFC size, which are easier to be predicted correctly[38]. In this situation using the COSMIC method would require an expert in order to obtain result on the same level of reliability, while this would increase the effort of measurement process. It is worth noting that it applies to the possibility of employing both methods for the estimation purposes: in the original COSMIC method there are limited possibilities to carry out approximate calculations at the early stage of the project’s life cycle, or the way of obtaining such calculations is time-consuming, which results from the necessity to base on FUR specification of high level detailness. However, there are some its variants that allow for early estimates of functional size on the basis of incomplete FUR (e.g., Object-Based Approach, Story-Based Approach, and Event-Based Approach)[29].

7. Functional Assessment of Business Software Systems Development and Enhancement Projects

It is worth taking advantage of the capabilities offered by software FSM to the assessment of BSS D&EP from the perspective being fundamental to a client – that is from functional perspective (see also[40]).

7.1. SouthernSCOPE and NorthernSCOPE Methodologies

Here is why the FSM concept constitutes basis of the southernSCOPE[14] and northernSCOPE[41] methodolo

-gies, 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:

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 methodologies prove 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 these approaches 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.

Concurrently, with the above methodologies, the author of this paper proposed[42] 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. 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)[43], 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).

7.2. Assumptions for SoftFAM

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[26][44] (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[45] - 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 organizational benchmarking data repository, especially designed for this very purpose. This is meant for deriving and verifying dependencies being specific to given project organization 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]. 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.

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. As indicated by the analysis in[42], 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.

7.3. Verification of SoftFAM

The verification of the full variant of SoftFAM was based on the case study of a dedicated BSS being developed from scratch for the needs of Polish affiliated sales department of some international motor concern and presented widely in[28].

Results of the verification indicate that SoftFAM allows for ex ante and ex post assessment of BSS D&EP effectiveness, and it also supports ex ante and ex post analysis of BSS D&EP economic efficiency. As these results prove that functional assessment allows rationalizing certain practical activities as well as business decisions made on the basis of its criteria. Among such activities are: specification of rational client requirements concerning key project attributes (product size, project work effort, cost and time), evaluation of potential providers offers, comparison of execution variants from the point of view of estimated work costs and the economic efficiency, indicating variant having highest potential efficiency, rational ex ante and ex post pricing of project product as well as enhancing prognosis concerning future projects by project provider. Among business decisions being supported by functional assessment should be mentioned: client’s investment decision about going into the execution of project having expected attributes, selection of the offer being most adequate to his requirements concerning these attributes as well as selection of execution variant having highest economic efficiency.

Moreover, results of the verification also indicate that formal pricing of BSS D&EP product should base on the required size (ex ante pricing) and on the actually delivered size (ex post pricing) of this product expressed with the use of functionality units and on the work costs per unit being measured with regard to the product size unit – and not on the fixed price contracts nor time and material contracts, most often occurring in the project practice, not only in Poland[15, p. 250], which promote exceeding of the BSS D&EP execution costs.

Because of the above capabilities, the SoftFAM allows for reducing some of the negative phenomena commonly occurring in the Polish practice of such projects execution, showing negative influence on their effectiveness and also on their real efficiency, namely:

Deliberate lowering of BSS delivery costs by providers in order to win contract for product development (the so-called “price-to-win” technique for product pricing) – thanks to ex ante and ex post product pricing based on the required and actually delivered 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 lifecycle without relevant reflecting of this change’s consequences in the execution costs – as a result of monitoring 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 full variant of 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 fundamental factors of the effective execution of BSS D&EP[2] – 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[16, Part 6].

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 as well as the risk of lowered ex ante and overstated ex post 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.

8. Usage of Functional Size Measurement Methods by Polish Business Software Systems Providers

A necessary condition for taking advantage of BSS D&EP functional assessment is to employ software FSM methods (see also[40]). Meanwhile, the author’s studies, whose results were widely presented in[4], indicate that the level of using these methods among Polish BSS providers, although growing, still leaves a lot to be desired.

Surveys that aimed at analysing the level of using the software FSMM by the Polish BSS providers as well as the reasons behind this status quo, were conducted against a background of author’s own research concerning the usage of BSS D&EP effort estimation methods. The use of both types of methods was examined in two cycles: at the turn of the year 2005/2006, being the time of economic prosperity, and next at the turn of the year 2008/2009, that is in the initial stage of crisis and increased investment uncertainty associated with it (in order to observe changes, the author originally intended the research to be repeated after 5 years, however radical change in the economic situation worldwide and in Poland persuaded her to undertake it 2 years earlier).

Both research cycles were completed using the method of diagnostic survey: the first cycle analysed responses given in 44 questionnaires (52 questionnaires were sent out) while the second cycle – responses given in 53 questionnaires (62 questionnaires were sent out). Questionnaires were distributed among various Polish dedicated BSS providers, both internal (IT departments in organizations) as well as external (for the most part from SME sector), providing systems for the needs of financial institutions (banks, insurance) departments, trading companies and public administration institutions. In both cycles the overwhelming majority of responses were answered by IT managers or project managers. Each questionnaire included about 30 questions validated by experts; most questions were of open or semi-open character and were divided into two main groups: concerning the usage of the effort estimation methods (answered by all respondents) and concerning the usage of the FSMM (answered only by the respondents familiar with FSMM). It should be stressed that the research was limited only to organizations dealing with D&EP, whose products are dedicated BSS – thus analysis included neither software maintenance, support and integration projects, software package acquisition and implementation projects, nor other software

products types.

In the context of the subject matter analysed in this paper fundamental conclusions from these surveys read as follows:

Considerable part of the respondents declares they do not commonly employ any of the methodology-based approaches to the BSS D&EP effort estimation, in most cases pointing to the “price-to-win” technique as the preferred estimation approach (not methodology-based) when providing software systems for government institutions (because of legal regulations). However, the level of using the BSS D&EP effort estimation methods has increased over the analysed time (from 45% to 53% of the surveyed providers).

In both research cycles the respondents declared rather widespread usage of at least one of the effort estimation methods, mostly pointing to the expert methods (first cycle: 36%, second cycle: 43% of all respondents), which are burdened with high risk (tests show that the ratio of the effort estimates, being calculated by different experts for the same project may be 1:6 or even 1:12 at the worst[4]).

FSM methods still place at the penultimate position among five analysed methods used for BSS D&EP effort estimation by the surveyed providers, however the level of using them has increased in the second research cycle (from 20% to 26% of all respondents).

In both research cycles relatively low popularity of the FSMM results mostly from insufficient familiarity with such methods, but the FSMM awareness has increased over the analysed time (from 27% to 34% of all respondents).

Percentage of the respondents using FSM methods versus those familiar with them has increased slightly too (from 75% to 78%), which means that the overwhelming majority of those familiar with the FSMM are also employing them.

In both research cycles as the main purpose of using the FSM methods was considered product size estimation in order to effectively estimate the effort, costs and time frame for the initiated project.

In both research cycles as the main advantages of the FSM methods were considered the methods objectivity and high usefulness, including most of all possibility to employ them at initial project stages at sufficient accuracy level of estimates, which helps increase the effectiveness of delivering the required functionality on time and within the planned budget. Disadvantages of the FSM methods include first of all high level of difficulty in using them.

As indicated by the above, in the case of all respondents the main reason for relatively low popularity of the FSM methods is that none of the BSS D&EP effort estimation methods is used commonly as well as insufficient familiarity with these methods, whereas among respondents using estimation methods – insufficient awareness of FSMM and at the same time familiarity with other methodology-based approaches. Among providers declaring familiarity with the FSM methods the main reason why they quitted using them is their high difficulty level.

The FSM methods stayed practically unknown in Poland until the recession in IT branch that took place in the first years of the 21st century. Although the level of using these methods can be hardly considered high, increase in their popularity, however, may be possibly explained by the four main factors, namely:

Increasing care about financial means in the times after recession mentioned above (including current crisis where it appears even somewhat stronger).

Growing competition on the market and increasing market globalization level.

Growing awareness of clients therefore greater requirements concerning providing justification for the project costs and completion time offered by providers.

Standardization of the FSM concept and its several methods by the ISO/IEC.

It is hard to compare conclusions coming from the above analysis with the results of other studies carried out worldwide in this area, as the author heard no about studies having similar goals. Yet the fundamental conclusion brought by these surveys agrees with the general conclusion drawn by the Software Engineering Institute (SEI) on the basis of the research attempted to answer the question about today’s approach to the measurement of software processes and products: “From the perspective of SEI's Software Engineering Measurement and Analysis (SEMA) Group, there is still a significant gap between the current and desired state of measurement practice. (…) Generally speaking, based on the results of this survey, we believe that there is still much that needs to be done so that organizations use measurement effectively to improve their processes, products, and services.”[46].

The research will be continued to keep observing the changes while the research area will be extended as much as possible to other Polish dedicated BSS providers and other economic BSS D&EP aspects.

9. Conclusions and Future Work

Summing up it should be stated that the importance of suitable BSS size measurement being significant from the economic point of view results first of all from the necessity to (see also[8] and[40]):

1) Increase effectiveness of BSS D&EP execution and reduce losses caused by their low effectiveness. Accurate ex ante assessment of project product size, cost and time increases the chance to reach its goal, i.e., on-time delivery of BSS being consistent with client’s business requirements without budget overrun. Since the more accurate estimation the lower the risk to go beyond estimates in reality. What’s more, such assessment enables to get information about resources that are necessary to deliver product having required functions and features – and it should allow for quitting projects, for which the chance of execution with the resources available proves low, or for correcting resources designed for the projects so that they are closest to the estimated values. Down to the more accurate investment decisions made on the basis of measurable, objective and reliable criteria it is possible to reduce losses caused not only by

abandoned projects and by large scale of overrunning the time and costs of their execution but also resulting from business opportunities lost by clients as a result of delivering products not meeting their requirements.

2) Rational ex ante and ex post pricing of BSS D&EP product. In the Polish practice of the BSS D&EP execution there are two types of client-provider contracts that definitely dominate at the moment, they are: fixed price contract and time and material contract. In the first case price of the project product is calculated on the basis of the assumed fixed costs, which were agreed following the requirements specification. In contracts of another type calculation of the product price is based on the agreed rate for work hour being spent by product provider. It means that work cost per unit is measured not with regard to the unit of product size but with regard to the unit of work time, and therefore this is work time – instead of required or actually delivered product size – that determines the total work costs. Project execution with ex post pricing of actually delivered product is still rare, at least in Poland, where we deal with low (however growing) level of the so-called “measurement culture” in software engineering, especially from the functional point of view. Both these approaches to the BSS pricing promote overrunning of budget designed for delivering of product that would meet client’s requirements. In case of client-provider contracts based on hourly work rate the provider could extend the time of product execution. Also, there is no guarantee that even extending this time excessively and thus leading to the uncontrolled increase in costs the provider would deliver product of required functionality. In case of fixed price contracts, apart from likely situation where the actually delivered product size may be smaller than the required one, there is also another problem that arises: providers manifest strong resistance to any extension of requirements, being so characteristic of BSS D&EP due to the changeability of business environment. Thus the contracts of this type may prevent cost overrun yet on the other hand they do not guarantee delivering of product having required functions and features at this very cost. Therefore ex ante and ex post pricing of the BSS, being developed or enhanced, should be based on its size: required (estimated) in the case of ex ante pricing and actually delivered (measured) in the case of ex post pricing. Consequently, work costs per unit should be related to the product size unit and not to the work time unit. This is what makes pricing have objective and reliable character, as client will get possibility to plan the cost of project execution depending on the outcome this project is expected to bring and, as a consequence of its execution, will pay for the actually delivered size of product and not for his requirements, which provider failed to fulfil (in case of fixed price contracts) or for the provider’s extra work time (in case of time and material contracts). It requires adequate measure of software size to be implemented, which may be acquired on the basis of the software functional size measurement concept, having been recently normalised by the ISO/IEC.

3) Proper control over the BSS D&EP execution. Measuring product size and project attributes during project execution helps perceive discrepancies between the reality and the plan, respond to potential threats on a current basis, prevent risk factors and monitor the areas of critical significance.

4) Collecting historical data for BSS D&EP estimation purposes. Measurement of the accomplished BSS D&EP attributes allows for deriving dependencies indispensable for making accurate estimation of similar projects in the future thus leading to the enhancement of estimation models that are based on such dependencies.

5) Improvement of BSS D&EP products and processes. Capability to measure software quality (e.g., reliability, what requires knowing the product size) allows to specify client’s quality requirements with the use of quantitative criteria, to carry out measurable assessment of product quality during project lifecycle, thus making it possible to verify whether its level is satisfactory, what may result in undertaking improvement activities, as well as to make quality assessment of the final product. On the other hand, SPA/SPI (Software Process Assessment/Software Process Improvement) models (e.g., CMMI) are based on the assumption that better software product is achieved by means of the improved software processes[31], whose quality too requires to be assessed. In these models higher and higher importance is attached to the software products and processes measurement.

The ISO/IEC standards for the software product functional size measurement, like the ISO/IEC 14143 norm for the FSM concept, adhere to other standards. The ISO/IEC 15939 offers help in defining the set of measures being adequate to the specific informational needs yet it neither provides the list of such measures nor it recommends specific set of measures for the D&EP. Therefore one may find the opinion that although employing of rules described in this standard is necessary for the measurement process implementation in the organization, these rules per se, however, are not sufficient for this purpose[47]. Thus this standard should be linked with other normalized measurement approaches, e.g., the IFPUG method or the COSMIC method.

As indicated by the above analyses, it is hard to unequivocally decide on the advantage of the COSMIC method over the IFPUG method (or inversely) – both have strengths and drawbacks, coming up in the specified problem areas, both have supporters and adversaries. Most probably, COSMIC approach will not totally replace the IFPUG method in the nearest future as this first-generation method has proved being sufficiently objective and reliable approach, at least with regard to the business software systems[48]. Since both approaches prove useful to BSS, this is not the author’s intention to solve this dilemma. In any case, from the perspective of requirements made for the methods of BSS size measurement there are no significant differences between the COSMIC and IFPUG method. Generally speaking, functional size obtained with the use of both methods constitutes sufficiently appropriate measure of BSS size and the basis for the estimation of BSS D&EP work effort, cost and duration. These methods, however, are not free of disadvantages therefore they need further improvement, which should benefit to higher accuracy of prognoses being obtained through the methods. Yet the differences between them are significant enough so that they cause problems in proper conversion of their results (for more details see[8]).

From the point of view of software organizations the measurement of products and processes should be a standard practice: estimating and measuring product size, process effort, cost and time enable for more effective business activity. Estimating and measurement prove being very important also from the point of view of these organizations’ clients, who should be given grounds for making rational investment decision and consequently for choosing variant promoting minimisation of costs at the assumed level of effects (required product size), possibly maximisation of effects (achievable product size) at the assumed costs level (if unexceedable costs were determined a priori). Moreover, experience in the Polish market (yet not only in this one) indicates that in the practice of BSS D&EP we still cannot speak about the balance of power between a provider and client. The former often dictates conditions of cooperation, many a time making use of client ignorance, especially with regard to the BSS pricing, imposing – if only client allows for it – contract conditions being favourable for himself.

Change of this situation is possible owing to employing suitable approach to the BSS size measurement, that is functional approach, and thanks to taking advantage of the capabilities offered by FSM concept and methods for the BSS D&EP assessment from the perspective being of key significance to a client. Therefore the author made an attempt to develop SoftFAM – the model of BSS D&EP functional assessment that would allow for evaluating the effectiveness of their execution, both ex ante as well as ex post, and for supporting ex ante and ex post analysis of BSS D&EP economic efficiency. The SoftFAM verification results prove that such model allows rationalizing certain practical activities and business decisions made on the basis of its criteria, as well as it allows for reducing some of the negative phenomena commonly occurring in the practice of such projects execution, not only in Poland.

Undoubtedly, the issue of BSS size measurement is important both for pragmatic as well as for theoretical reasons. Pragmatic reasons rise from the need to increase effectiveness of the execution of BSS D&EP. On the other hand, theoretical reasons are provoked by the need to satisfy requirements of software engineering as a discipline of knowledge – without the possibility of measurement of its basic objects, ensuring objective and reliable analytical criteria, it is hard to regard it as a discipline having scientific grounds. Hence strong significance of appropriate software products’ size measurement methods arises, especially with regard to BSS having the lowest chance to succeed.