Free Iec Standards Pdf Download
Low effectiveness of the software development and enhancement projects is one of the fundamental reasons why for a few dozens of years the software engineering has been in search of objective and reliable approaches to the measurement of various attributes of software processes and products. Some of the undertakings have only just gained recognition, which may be proved by the fact that the latest version of the CMMI model (CMMI for Development released in 2006) was strongly focused on measurement as well as that the ISO with IEC have recently established a dozen or so international standards for this very measurement, regarding software products in particular. Also, intensive works on other norms are continued by these standardization organizations. Undoubtedly, this reflects the increasing acceptance for this subject matter yet the number and diversity of formal approaches may pose serious obstacle to the appropriate --from the point of view of specific needs --choice of such approaches. Thus in this paper we have gathered, synthetically characterised as well as linked and classified part of such approaches, that is the ISO/IEC standards.
Discover the world's research
- 20+ million members
- 135+ million publications
- 700k+ research projects
Join for free
The ISO/IEC Standards for the Software
Processes and Products Measurement
Beata CZARNACKA-CHROBOT1
Faculty of Business Informatics, Warsaw School of Economics, Warsaw, Poland
Abstract. Low effectiveness of the software development and enhancement
projects is one of the fundamental reasons why for a few dozens of years the
software engineering has been in search of objective and reliable approaches to the
measurement of various attributes of software processes and products. Some of the
undertakings have only just gained recognition, which may be proved by the fact
that the latest version of the CMMI model (CMMI for Development released in
2006) was strongly focused on measurement as well as that the ISO with IEC have
recently established a dozen or so international standards for this very
measurement, regarding software products in particular. Also, intensive works on
other norms are continued by these standardization organizations. Undoubtedly,
this reflects the increasing acceptance for this subject matter yet the number and
diversity of formal approaches may pose serious obstacle to the appropriate – from
the point of view of specific needs – choice of such approaches. Thus in this paper
we have gathered, synthetically characterised as well as linked and classified part
of such approaches, that is the ISO/IEC standards.
Keywords. Software engineering, measurement process, software process
measurement, software product measurement, ISO/IEC standards
Introduction
Using formal approaches – whether in the form of commonly recognised models or
official standards - in the practice of software engineering is of great significance to the
software projects stakeholders. It helps build clients' trust in potential providers thus
making it easier to choose product supplier on the basis of the objective and reliable
criteria. It may also constitute formal requirement resulting from the adopted rules or
other regulations (e.g. prerequisite to participate in tender, clause in a contract) as well
as it may constitute informal requirement stemming from clients' preference for
companies holding certificates in given area. Thus, if software organizations want to
gain competitive advantage, or sometimes even remain on the market, they should be
motivated to implement the so-called good practices being included in such standards
or models and to undergo certification processes, which would be beneficial not only to
their clients but also to these companies themselves. This is because they sort out
activities of such organizations, rationalize planning which is based on reliably
collected benchmarking data thus reducing the difference between the estimated and
actual values, they allow to control the key attributes on a current basis which makes it
1 Corresponding Author: Beata Czarnacka-Chrobot, Al. Niepodległości 164, 02-554 Warsaw, Poland; e-mail:
bczarn@sgh.waw.pl.
possible to increase the swiftness of reaction to the undesired situations, they also allow
to increase a chance to deliver products of respectable quality, to identify areas that are
in need of improvement therefore reducing the uncertainty of functioning and
improving both its effectiveness and organization's image on the market [1, pp. 162-
163, 166]. Although implementation of formal approaches quite often requires
considerable expenditure, it may at first introduce some constraint to the flexibility of
action, it requires relatively frequent adjustment to the subsequent upgraded versions
while certificates neither guarantee effective fulfilment of client's requirements nor
they are a necessary prerequisite for it – they, however, undoubtedly contribute to this
strongly.
Whereas the measurement of software processes and products is an area of
software engineering, which L. Buglione and A. Abran not long ago used to describe as
„rather immature in terms of knowledge maturity" [2, p. 84], at the same time pointing
out that the desired and dynamic changes have just begun in this very area. In their
opinion, which later was confirmed by the empirical research [3], until quite recently
this area has not adhered to the criteria of the so-called rule of general acceptance,
having been formulated by the Project Management Institute (PMI) in the PMBOK
(Project Management Body of Knowledge) and then adopted by the IEEE (Institute of
Electrical and Electronics Engineers) Computer Society in the SWEBOK (Software
Engineering Body of Knowledge). According to this rule: "generally accepted means
that the knowledge and practices described are applicable to most project most of the
time, and that there is widespread consensus about their value and usefulness. " [4, p.
3]. As argued by the authors, the basic way of changing this status quo is to develop
formal approaches to the software processes and products measurement, which would
constitute a source of knowledge thanks to which the above mentioned rule would
become applicable to this software engineering area over time.
What is more, formal approaches to the software processes and products
measurement promote critical success factors for the measurement programme
implementation in the organization. It is of fundamental significance in view of the fact
that, as estimated by H. Rubens, approx. 80% of the attempts to implement
programmes of this type end up with failure [5, p. 1]. In this case success is understood
as a situation where such programme is functioning in the organization for minimum 2
years and has an effect on business decisions made in this organization. Basic causes of
failures in this respect are of organizational nature. Most of all they include: lack of
connection between measurement programme and business company goals, decision-
makers' incomprehension of such programme, opposition to the programme
implementation due to probability of revealing management mistakes, perceiving such
programme as costly, and identifying it with benchmarking data collecting whereas
benefits brought about by the implementation of measurement procedures result from
decisions and actions undertaken in response to the analysis of such data and not from
collecting these data as such. Therefore among success factors being critical to the
measurement programme implementation should be listed most of all its
implementation in the form of formal process, with respectable human resources,
budget and time being ascribed to it, as well as with clearly defined programme
objectives, being connected with organizational business goals [6, pp. 129-131].
Due to the above mentioned reasons over the last couple of years could have been
observed significant intensification of works aimed to take in the best practices
regarding software processes and products measurement within the already existing
models (e.g. Cap ability Maturity Model Integration - CMMI [7] [8]) or to express them in the form of
new standards, pertaining to this subject matter to different, also highly detailed degree.
Various formal approaches have developed as a result of these works, offering varied
perspectives for this very area, and being de facto the effect of a few dozens of years of
searching for and developing sufficiently objective and reliable proceedings with
regard to the discussed subject and filling an important gap in the theory and practice of
software engineering. It is worth noting that to a higher degree they now tend to
concentrate on the software product itself, which in fact constitutes the aim of software
processes being undertaken while not that recently such approaches had been criticised
for concentrating almost exclusively on the process [9, p. 111].
On the basis of the classification proposed by K. Richins [10, p. 3.259], formal
approaches to the software processes and products measurement may be divided into:
•Approaches setting directions for proceedings thus ensuring proper course of
the measurement process, which do not hold official status of international
standard yet as a rule are successfully used in practice in given application
areas. Development of this type of structuralized approaches is being
supported by the initiatives such as e.g. Software Engineering Measurement
and Analysis (SEMA) Group, undertaken within the Software Engineering
Institute (SEI), or Measurement Working Group (MWG) performing within
the International Council on System Engineering (INCOSE), as well as by
various government directives (e.g. [11]). As indicated by the SEI studies [3,
p. 18], approach being used in practice to the largest extent in this type of
measurement proves the so-called Measurement and Analysis Process Area of
the CMMI model [7] [8].
•Approaches officially recognised as international standards, which to lower or
higher degree relate to measurement. Since the measurement processes in
software engineering are being attributed higher and higher significance, a
considerable progress has taken place over the last few years in the
standardization of approaches to this issue, which may be proved, among
others, by the international norms having been published jointly by the
International Organization for Standardization (ISO) and International
Electrotechnical Commission (IEC). The idea of this paper is to present them
in a synthetic way and dividing them into the following three categories:
1) ISO/IEC standards including the measurement
2) ISO/IEC standards dedicated to the measurement
3) ISO/IEC standards dedicated to the measurement
methods.
1. The ISO/IEC Standards Including the Measurement
Basic standard in this category is the ISO/IEC 90003 norm [12], which describes the
most popular international quality standard ISO 9001 in the context of various software
processes execution. It identifies the requirements for the quality management system,
which should be considered when acquiring, supplying, developing, operating, and
maintaining the applications, as well as during accomplishment of supporting services
associated with these processes. It presents them independently of technology, life
cycle models, developmental processes, sequence of actions, and organizational
structure. Rules of proceedings featured in it are dedicated to software products being
part of the commercial contracts with other organization, to the software intended for
the market, software used to support organizational processes, embedded software, as
well as to the software services. This norm is supplemented with additional, more
detailed standards, in particular: ISO/IEC 12207, ISO/IEC 15504, ISO/IEC 14598, that
also belong to the group of standards including the measurement, and ISO/IEC 15939
and ISO/IEC 9126, which are standards dedicated to the measurement (see p. 2).
The ISO/IEC 12207 norm [13] defines the required structure of the software life
cycle processes by determining activities within these processes and their tasks (life
cycle – processes – activities – tasks). In this norm the processes were classified as
basic (acquisition, supply, development, operation and maintenance of product),
supporting (documentation, management, configuration, ensuring quality, verification,
validation, reviews, audit and problem solving), and organizational (management,
infrastructure, improvement and training). Activities, defined as necessary,
recommended and allowed, are divided into actions of software producer and actions of
client acquiring the system containing software, independent software product, and
software services. Thus this norm establishes processes concerning development and
acquisition of software, which should be assessed in compliance with models designed
for particular processes (e.g. SPICE – see below, CMMI Continuous Representation
[7]). So, the norm is a high-level document as it does not determine the assessment
model hence it usually needs to be supplemented with other norms and/or methods.
By means of the ISO/IEC 15504 standard [14], called SPICE (Software Process
Improvement and Capability Determination), one may assess every process being
realized within the company, concerning producing of software product (defined in the
ISO/IEC 12207 norm). It generalizes the best features of various models (e.g. CMMI
and ISO 90003) thus providing pattern for the assessment of such process. This pattern
may be used by organizations involved in planning, management, monitoring,
controlling and improvement of the processes of acquisition, supply, development, use,
evolution and support of products and services. The described standard defines
primarily the requirements for the execution of assessment process, which ensure that
the results of such assessment are objective, impartial, consistent, repeatable, and
representative of the processes being assessed. They are employed to improve process
and describe its capability level, for which a measurement scheme was also defined.
Analysis of the obtained results allows to identify strong and weak points as well as
risks relating to the processes, and this proves helpful in improving these processes and
in determining capability level of software producer, being of fundamental significance
to the choice of software supplier. The organizational process dedicated to the
measurement (ORG.5) is distinguished explicitly in the norm; it also includes an
exemplary model of process assessment. However this standard does not specify
measures but rather criteria for process verification.
In the ISO/IEC 14598 standard [15], on the other hand, the process of making
evaluation of software product was normalised, with particular emphasis put on
planning and management of this process as well as documenting it; it also introduced
division into processes designed for developers, clients and evaluators. It should be
used jointly with the below presented ISO/IEC 9126 standard (see p. 2).
The above standards (ISO/IEC 14598 and ISO/IEC 9126) are connected with the
part of the series of ISO/IEC 250xx standards, being dedicated to the quality evaluation
of and quality requirements for the software product, which is called SQuaRE
(Software Product Quality Requirements and Evaluation). For the time being this
connection applies particularly to the following norms of the series: ISO/IEC 25000
[16] and ISO/IEC 25001 [17]. The ISO/IEC 25000 standard, presenting overall
characteristics and guidelines for the entire series of norms concerning SQuaRE, brings
also an explanation of the process of shifting away from older norms - ISO/IEC 14598
and ISO/IEC 9126 - to the new approach as well as the way they were used in the
previous form. On the other hand, the ISO/IEC 25001 standard normalizes planning
and management of quality requirements for software product in such a way that it
ensures appropriate specification of requirements and evaluation. Thus both these
norms may be classified into standards, which to some degree include the
measurement. While the ISO/IEC 25010 norm [18], concerning the SQuaRE quality
model, is under development now, as is the ISO/IEC 25040 standard [19], which is
assumed to include reference model for the evaluation process. The necessity of
making objective evaluation of software product quality is mentioned also in the
ISO/IEC 25030 norm [20], which focuses on the processes of defining and analysing
of software quality requirements; here it is also being pointed out that ambiguities in
these requirements usually lead not only to different interpretations but also to different
evaluations. Therefore this norm is aimed to increase quality of the specification of
software product quality requirements.2
2. The ISO/IEC Standards Dedicated to the Measurement
This category of standards most of all include the ISO/IEC 15939 norm [21]
determining general procedures for the software measurement process in compliance
with the ISO/IEC 15288 standard [22] which, on the other hand, defines processes of
the system's life cycle. The ISO/IEC 15939 norm defines measurement process
adequate to the system and software engineering thus broadening the SPICE
organizational process dedicated to the measurement (ORG.5) by describing it with the
use of the model determining activities and tasks being included in such process. They
are required to appropriately specify the necessary management information, define the
ways of using measures and analysis results as well as determine the way of validating
them. The norm identifies the process supporting defining of the appropriate set of
measures pertaining to the specific informational needs as well as it determines
activities and tasks being indispensable to the effective identification, definition,
selection, use and improvement of the measurement process within its general structure
on the level of the organization or project. The proposed measurement process holds
flexible character therefore it may be easily tailored to the diverse needs of various
users. This standard also defines terms related to the measurement, used in the software
engineering.
The ISO/IEC 15939 norm contains also description of the procedure of selecting
software product measure, which requires three steps: characteristics of organizational
units, identification of their informational needs, and as a result selection of applicable
measure. This way it offers help in defining of 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 software development/enhancement
project. Therefore one may find the opinion that although employing rules described in
the discussed standard is necessary for the measurement process implementation in the
organization, these rules per se, however, are not sufficient for this purpose [23, p.
2 This list does not exhaust the series of ISO/IEC 250xx norms (e.g. see p. 3).
111]. Thus some proposals [23, pp. 111-130] have appeared, suggesting to link this
standard with other measurement approaches, e.g. with CMMI model, being now
strongly focused on the measurement, which is helpful in the planning of this process,
as well as to employ the discussed norm along with relevant benchmarking data
repositories, allowing for the building of estimation models, e.g. offered by
International Software Benchmarking Standards Group (ISBSG) [24].
Another standard in this group is the ISO/IEC 9126 norm [25], in the first part
presenting model of software product quality while in the next three parts – the set of
metrics designed to evaluate its particular attributes, that is functionality, usability,
reliability, performance, maintainability, and portability. This evaluation holds indirect
character as in reality this is more detailed attributes, i.e. the so-called
subcharacteristics that are being evaluated. Although this standard, like ISO/IEC 14598
(see p. 1), probably will be soon replaced with the part of the new series concerning
SQuaRE, it is worth to mention the metrics being proposed in this standard due to the
uniqueness of such approach [1, p. 85].
The ISO/IEC 9126 standard comprises software quality evaluation using three
types of metrics, namely: internal metrics – designed to measure software product
itself, external metrics – which measure behaviour of the system including software,
and quality in use metrics – which are aimed to measure effects of using software in
the specific context of its application. Quality in use metrics are used only in the real
environment of system operation since they are designed to measure degree of actual
fulfilment of given users' requirements by the product supplied. What is being taken
into account here is achieving by end users goals regarding effectiveness, productivity,
safety and satisfaction relating to the use of software in the specific real context of its
application. On the other hand, external metrics are designed to measure product
quality by evaluating its performance in the environment whose part this product
constitutes therefore in the environment including other system elements (e.g. other
software). Thus they may be used not earlier than during testing and using of the
evaluated product. Internal metrics, on the other hand, may be used somewhat earlier,
when the product is not yet a executable software – they make it possible to measure
quality of intermediate results thus allowing to predict the quality of end product,
recognize potential problems and initiate adequate actions in response to these
problems, and as a result assess this quality.
Metrics proposed in the discussed standard do not constitute the exhaustive set, as
it is mentioned explicitly3. However, for developers, evaluators, quality managers and
those acquiring software products it may provide basis for choosing metrics, which are
useful, among others, in defining requirements, product evaluation or measurement of
particular quality aspects.
There is an assumption in the ISO/IEC 9126 norm that the quality of software
product is determined by the quality of software process. Taking this point of view it
should be stated that improvement of product quality requires enhancement of process
quality [26, p. 115]. Thus when applying this norm one should also employ models
designed for the evaluation and enhancement of software process, among which may
be found the CMMI, SPICE as well as the ISO/IEC 90003 standard.
The ISO/IEC 25020 norm [27] comprises reference model for the measurement of
software product quality characteristics, which are going to be defined in the ISO/IEC
3 It contains the list of more than 200 quality metrics.
2501x standard, still under development 4. It establishes requirements for the selection
and construction of software quality measures, presents criteria for such selection as
well as criteria for choosing quality measure elements proposed in the ISO/IEC 25021
norm (see below). It is intended to be used along with other standard being still
developed - ISO/IEC 25040, which will describe reference model for the process of
software quality evaluation, as well as with the above mentioned ISO/IEC 25030
standard.
For the needs of the SQuaRE model the ISO/IEC 25021 norm [28] defines the set
of elements of software product quality measurement, which should be used in its life
cycle. Although some these elements may be applied as independent quality measures,
their basic purpose, however, is to provide components serving as a base for building
other measures for SQuaRE, so far having been described in the ISO/IEC 9126
standard (parts 2-4). Thus the ISO/IEC 25021 norm establishes the relationship
between the ISO/IEC 9126 and the following series of standards for SQuaRE. It shows
the relationship between the quality measures elements and the quality measures,
characteristics and subcharacteristics having been defined in this older norm. Similar to
the above described norm of this series, this norm too should be applied along with the
norms: ISO/IEC 25040 and ISO/IEC 25030.
Among standards dedicated to the measurement is rated also the six-part norm
ISO/IEC 14143 [29], concerning the so-called Functional Size Measurement (FSM) of
software products. First version of this standard was published at the end of the 90s of
the last century however its intensive development has taken place in the recent years,
when the first part of the discussed norm was revised too (in 2007). Firstly the ISO/IEC
14143 standard specifies definition of functional size, which is understood as „size of
the software derived by quantifying the Functional User Requirements" [29, Part 1, p.
2]. 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" [29,
Part 1, p. 2]. 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. Thus this standard normalizes the
concept of the software products FSM; wherein, among others, it:
•provides key definitions, characteristics and requirements for FSM
•gives guidance on how to use FSM to support management of software
development, enhancement and maintenance projects
•defines Functional Size Measurement Method (FSMM) as a specific
implementation of FSM defined by a set of rules, which conforms to the
mandatory features of such measurement
•allows users to choose FSMM which is best tailored to their needs
•features description of software classes (e.g. business applications, real time
systems, scientific software), the so-called functional domains, for which
possibility of using FSMM is declared
•comprising the rules of selecting, among FSMM standardized by the ISO/IEC
(see p. 3), the method which would be suitable for given functional domain
•recommends steps of the FSMM using process.
Thus software functional size measurement supports [29, Part 6, pp. 9-10]:
4 The software product quality model by itself will be described, as already mentioned, in the ISO/IEC 25010
norm. It is soon going to replace the first part of the ISO/IEC 9126 norm.
•Project management by enabling one to: make project resource forecasting,
monitor progress of the project, manage the changes in the software product
size, determine degree to which the supplied product meets FUR, make post-
mortem project analysis and compare its attributes with other projects
•Performance management by: productivity management of software
development, enhancement and maintenance, quality management (especially
of software reliability), management of organizational maturity and process
capability, allowing for determining organizational software asset value in
order to estimate cost of its potential replacement, reengineering, or
outsourcing, allowing for making prognosis on budget necessary to maintain
software, and management of software supply contracts.
3. The ISO/IEC Standards Dedicated to the Measurement Methods
At the moment this group of standards includes only software product functional size
measurement methods. After about 30 years of improving various techniques of
software FSM five of them (out of over 20 [30, p. 77]) have been acknowledged by the
ISO/IEC as conforming to the rules laid down in the ISO/IEC 14143 norm and have
taken on the form of the following standards:
•ISO/IEC 20926 [31], in which was approved the function point method in the
version developed by the International Function Point Users Group (IFPUG)
•ISO/IEC 20968 [32], describing the function point analysis in the Mk II
(Mark II) version, having been developed by the United Kingdom Software
Metrics Association (UKSMA)
•ISO/IEC 24570 [33], in which was approved the FSM method in the version
proposed by the Netherlands Software Metrics Association (NESMA)
•ISO/IEC 19761 [34], normalizing the method of Full Function Points (FFP)
in the version developed by the Common Software Measurement International
Consortium (COSMIC)
•ISO/IEC 29881 [35], in which was normalized the FSMM developed by the
Finnish Software Metrics Association (FiSMA).
The ISO/IEC standards for the software FSMM, like the ISO/IEC 14143 norm,
adhere to the ISO/IEC 15939 standard, which determines the general rules for software
measurement process (see p. 2).
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 as it concerns the software FSM. On the other hand the
COSMIC and FiSMA methods were recognized as international standard entirely.
The FSM methods accepted by the ISO/IEC differ in terms of software
measurement capabilities with regard to different functional domains. Therefore prior
to choosing given method one should firstly evaluate its adequacy to the type of
software product, whose functional size is going to be measured. Most important
information relating to the above, resulting from the norms describing these methods, is
presented in Table 1.
Table 1. The ISO/IEC standards for the software FSMM versus functional domains
Method Functional domains specified in the
norm Constraints indicated in the norm
ISO/IEC 20926 -
IFPUG method All software classes None
ISO/IEC 20968 -
UKSMA method
For any type of software provided that
the so-called logical transactions may be
identified in it (the rules were developed
as intended for business software).
The rules support neither complex
algorithms characteristic of
scientific and engineering software
nor the real-time systems.
ISO/IEC 24570 –
NESMA method All software classes None
ISO/IEC 19761 -
COSMIC-FFP
method
- Data-driven systems, e.g.
business applications for
banking, insurance,
accounting, personnel
management
- Real-time systems (time-
driven systems), e.g.
telephone exchange
systems, embedded
software, process control,
operation systems
- Hybrid solutions combining
both above, e.g. real-time
systems of airline tickets
booking.
- Systems with complex
mathematical algorithms or with
other specialised and complex
rules (e.g. expert, simulation, self-
learning systems)
- Systems processing
continuous variables (audio,
video)
- For above-mentioned
domains it is possible to modify
the method so that it may be used
locally.
ISO/IEC 29881 -
FiSMA method All software classes None
Source: Author's own study based on [29, Part 6, pp. 5, 18-20].
4. Relationships between Formal Approaches to the Measurement
Main relationships between the principal ISO/IEC standards concerning
measurement of software processes and products along with their relations to the
CMMI model are presented in Figure 1.
As already mentioned, the SEI studies reveal that the awareness of importance of
software products and processes measurement is strongly affected by the CMMI
model. This is particularly its latest version, i.e. CMMI for Development that considers
measurement to be essential to achieving the next, higher level of organization maturity
and processes capability [7, pp. 33-38]. The higher the level of maturity, the stronger
its orientation towards quantitative approach. In CMMI for Development, one of 22
process areas is dedicated to Measurement and Analysis5 . It is assigned to the second
maturity level (i.e. managed). Explicit distinction of this process area assures managers
there is a need to carry out measurement process in order to improve software
development process – earlier versions of this model lacked such clear, autonomous,
consistent and broad approach [8, p. 20-21].
5 This process area has been worked out in close cooperation with specialists from ISO, IFPUG and Practical
Software and Systems Measurement Support Center.
Whereas analyses indicate that for companies at the initial CMMI maturity level
one of the reasons why they have difficulty in achieving the second level is lack of
software measurement procedures while one of the measures being skipped most often
is the measure concerning software product size [36, p. 22]. Thus the ISO/IEC 14143
norm along with the selection of FSM method being best tailored to the given
functional domain (see Table 1) may be very helpful. On the other hand, studies by M.
Brown and D. Goldenson [37] reveal that in practice problems with software products
and processes measurement exist regardless of organization maturity level: firstly –
they are noted on each level, secondly – their structure appears very similar for each of
the levels. At the two uppermost maturity levels somewhat bigger difficulties are
declared for the software products measurement while lower – for the software
processes measurement. It proves usefulness of standards being presented in the paper.
Figure 1. Main relationships between the ISO/IEC standards concerning software processes and products
measurement and their relation with the CMMI model.
Source: Author's own study with the use of [10, p. 3.260].
Integration of activities covered by the measurement is aimed to support, among
others, objective planning, including estimation of software development, enhancement
and maintenance project attributes, tracking down actual course of project with regard
to its compliance with plans and purposes as well as identifying and solving various
problems related to the measurement process that appear. Thus in organizations
characterized by high maturity of measurement process [38] [39]:
•Cost and time of project completion is estimated more accurately and this
being thanks to the proper collecting of reliable benchmarking data:
organizations at the uppermost maturity level practically do not exceed
estimates whereas initial maturity level organizations exceed the time by
150% on average and the cost by approx. 200% on average
Software
Measurement
Process
Software
Process
Assessment
Process
Software Quality
Management
System
Software Life
Cycle
Processes
nt
Process
Software
Measurement
Process
Software Process
Assessment
Organizational
Measurement
Process
Software
Measurement
Process
System Life
Cycle
Processes
Measurement
Process
Software
Product FSM
Software Product Quality
Evaluation/Measurement 90003
(9001)
15288
1220714598
9126
14143
15504
15939
CMMI
25000
25001
25030
25010
25040
25020
25021
20926
20968
24570
19761
29881
Standards including the measurement Standards dedicated to the measurement
Standards dedicated to the measurement methods Standards under development
•Quality of products increases because of lower faults number and this being
thanks to the control of these faults taking place as soon as at the earliest
phases of project's life cycle, which results in lower cost of handling them:
average cost of correcting faults in organizations at the uppermost level is
approx. 4% of total software development cost while in organizations at the
initial level it amounts to over 50% of such cost
•Cost of software development falls in relation to the lower cost of improving
bad quality of products: average cost of developing one function is more than
3 times lower in organizations at the uppermost level comparing to the cost in
organizations at the initial level
•Productivity increases as a result of decline in the above mentioned unit costs
•Lower number of faults in products and therefore shortening the time needed
for correcting them results in shortening the time of products completion.
5. Concluding Remarks
As indicated by the above considerations, the presented classification of ISO/IEC
norms concerning measurement in software engineering may be specified by bringing
it to the following categories characterised by the increasing level of detailness6 :
1) Standards including the measurement, concerning:
•measurement process (ISO/IEC norms: 12207, 15288, 14598)
•software process measurement (ISO/IEC norms: 90003, 15504)
•software product measurement (ISO/IEC norms: 25000, 25001, 25030).
2) Standards dedicated to the measurement, concerning:
•measurement process (ISO/IEC 15939 norm)
•software product measurement (ISO/IEC norms: 9126, 25020, 25021,
14143).
3) Standards dedicated to particular methods of software product functional size
measurement (ISO/IEC norms: 20926, 20968, 24570, 19761, 29881).
Thus part of the listed standards is focused explicitly on the measurement (norms
in the second and third category) while other standards approach this process as one of
the recommended categories of actions (first category). What's more, some of them are
of general character, i.e. they normalize the measurement process itself while others are
focused on the measurement of software products or measurement of software
processes. Additionally, in case of products one may distinguish standards concerning
their quality as well as those concerning their functional size. Classification of the
published ISO/IEC standards with regard to the subject of evaluation is given in Table
2.
Table 2. Published ISO/IEC standards concerning software process and product measurement by standard
category and evaluation subject
Standard category Measurement
process
Software process Software product
Quality Quality Functional size
Standards including
the measurement
12207, 15288,
14598
90003, 15504 25000, 25001,
25030
6 The list given below does not include standards which has not yet been published.
Standards dedicated to
the measurement
15939 9126, 25020,
25021
14143
Standards dedicated to
the measurement
methods
20926, 20968,
24570, 19761,
29881
Source: Author's own study.
Generally, process of selecting and applying standards for software processes
and/or products measurement should take into account the following steps:
•Defining needs and goals of measurement in accordance with organizational
business needs and goals (e.g. cutting down on costs/time of product delivery,
increase in productivity, delivery of high-quality products, accurate project
estimation)
•Selecting standard including/dedicated to the measurement process in the
context of measurement needs and goals
•Selecting the suitable standard including the measurement of software process
quality and/or including/dedicated to the measurement of software product
quality and/or dedicated to the measurement of software product functional
size – depending on measurement needs and goals
•When choosing standard for software product quality, selecting the right
SQuaRE standard (see p. 1 and 2), while in the case of choosing standard for
software product functional size, selecting standard normalizing the FSM
method adequate to the given functional domain (see Table 1)
•Carrying out measurement in order to get information being essential to make
rational business decisions.
Relationships between ISO/IEC standards and CMMI models presented in Figure
1 as well as classification of standards discussed in the paper featured in Table 2 are
meant to facilitate selection of a norm or group of norms being adequate to the given
organization needs. As mentioned in the introduction, using them is one of the key
success factors of the measurement programme implementation in organization, aimed
to improve software processes and products by means of increasing the project
productivity and products quality, which allows for faster and cheaper delivery of
higher functionality [6]. Observations of P. Morris has been confirmed also by D.
Longstreet [40, p. 14], who pointed out that the phenomenon described as Hawthorne
effect7 occurs also in software engineering: measurement programme implementation
among software development teams in most cases also leads to the increase in work
productivity – due to their awareness of the fact they participate in such programme
and have influence on it. Practical formal approaches usefulness is confirmed also by
one of the ISBSG reports [41, p. 3]: projects in which the above described ISO/IEC
norms are employed show higher productivity. Also Standish Group [42, p. 3] among
software development and enhancement projects key success factors mentions the
formal approaches use. Thus implementation of formal approaches compliant with an
organization business needs and goals may be regarded as an investment in the
software processes and products improvement.
7 It was first observed in the USA at the turn of 20s and 30s of the last century and resulted from the fact of
group of people being aware of taking part in an experiment – in this particular case this awareness gave rise
to the increase in work productivity.
Every organization, however, has to compare benefits coming from the
implementation of any formal approach against the costs of implementation. Such
approaches are complex and not very flexible, which many a time requires extension of
the bureaucratic control. As a result their implementation requires considerable
resources and costs, which for small and medium-sized organizations in particular
constitutes factor limiting the use of these approaches. For instance, cost of the
ISO/IEC 90003 norm implementation is estimated to be a few dozen Euros [43].
Additionally, in the beginning the formal approaches implementation often slows down
the software processes, which many a time makes users feel reluctant to use them. It
also happens that they start living their own life, independently of the project realities
while their complexities cause that sometimes in practice one loses sight of their
fundamental purpose: high quality of software product, which is to be delivered as a
result of the effective process, in return getting its theoretical compliance with model
maturity. That's why solutions meant as a counterweight to formalized approaches
appeared; they are the so-called agile methodologies, whose general assumption is
effective creation of properly functioning software thanks to focusing on purely
construction-related activities and minimizing of other activities. Yet with such
methodologies one resigns from benefits coming from disciplined and systematic use
of good practices or from the transfer of knowledge and skills between projects.
Summing up it should be stated that significant progress in the development of
new formal approaches to the measurement, particularly for software products, has
taken place over the last few years. On the basis of this observation Buglione and
Abran have underlined that such unanimous international acknowledgment represents
„strong evidence of increased "generally accepted" recognition for a number of
software measurement topics" [2, p. 91].
References
[1] A. Kobyliński, Modele jakości produktów i procesów programowych (The Programming Product and
Processes Quality Models), Monografie i Opracowania 539, OW-SGH, Warsaw, 2005.
[2] L. Buglione, A. Abran, The Software Measurement Body of Knowledge, Proceedings of 1st Software
Measurement European Forum (SMEF), Rome, 2004.
[3] M. Kasunic, The State of Software Measurement Practice: Results of 2006 Survey, Software
Engineering Institute, Carnegie Mellon University, Pittsburgh, December 2006.
[4] Project Management Institute, A Guide to the project management body of knowledge, PMBOK 2000.
[5] W. Goethert, W. Hayes, Experiences In Implementing Measurement Programs, Software Engineering
Measurement and Analysis Initiative, Technical Note CMU/SEI-2001-TN-026, November 2001.
[6] P. Morris, Case Study of a Successful Measurement Program, RPM-AEMES, Vol. 4, Nº Especial,
October 2007.
[7] CMMI Product Team, CMMI for Development, Version 1.2, Software Engineering Institute, Carnegie
Mellon University, Pittsburgh, August 2006.
[8] D. Goldenson, J. Jarzombek, T. Rout, Measurement and Analysis in Capability Maturity Model
Integration Models and Software Process Improvement , „CrossTalk. The Journal of Defence Software
Engineering", July 2003, pp. 20-24.
[9] N.E. Fenton, Zapewnienie jakości i metryki oprogramowania (Ensuring software quality and metrics),
in: Inżynieria oprogramowania w projekcie informatycznym (Software Engineering in IT Project), J.
Górski (ed.), broadened 2nd edition, Mikom, Warsaw, 2000.
[10] K. Richins, Measurement in CMMI , Proceedings of a Seminar On Metrics, International Council on
System Engineering (INCOSE), Hampton, Virginia, October 23-24, 2001.
[11] DoD Directive 5000.2-R, Mandatory Procedures for Major Defense Acquisition Programs (MDAPs)
and Major Automated Information System (MAIS) Acquisition Programs, Department of Defense,
March 15, 1996.
[12] ISO/IEC 90003:2004 Software Engineering – Guidelines for the application of ISO 9001:2000 to
computer software, ISO, Geneva, 2004.
[13] ISO/IEC 12207:2008 Systems and software engineering -- Software life cycle processes, ISO, Geneva,
2008.
[14] ISO/IEC 15504 Information Technology – Process Assessment - Parts 1-5, ISO, Geneva, 2003-2006.
[15] ISO/IEC 14598 Information Technology – Software Product Evaluation - Parts 1-6 , ISO, Geneva,
1998-2001.
[16] ISO/IEC 25000:2005 Software engineering – Software product Quality Requirements and Evaluation
(SQuaRE) – Guide to SQuaRE, ISO, Geneva, 2005.
[17] ISO/IEC 25001:2007 Software engineering – Software product Quality Requirements and Evaluation
(SQuaRE) – Planning and management, ISO, Geneva, 2007.
[18] ISO/IEC CD 25010 Software engineering – Software product Quality Requirements and Evaluation
(SQuaRE) Quality model (in preparation).
[19] ISO/IEC CD 25040 Software engineering – Software product Quality Requirements and Evaluation
(SQuaRE) – Evaluation reference model and guide (in preparation) .
[20] ISO/IEC 25030:2007 Software engineering - Software product Quality Requirements and Evaluation
(SQuaRE) – Quality requirements, ISO, Geneva, 2007.
[21] ISO/IEC 15939:2007 Systems and software engineering - Measurement process, ISO, Geneva, 2007.
[22] ISO/IEC 15288:2008 Systems and software engineering -- System life cycle processes, ISO, Geneva,
2008.
[23] L. Bégnoche, A. Abran, L. Buglione, A Measurement Approach Integrating ISO 15939, CMMI and
ISBSG, Proceedings of 4th Software Measurement European Forum (SMEF), Rome, 2007.
[24] The International Benchmarking Standards Group Release 10 Repository Demographics , International
Software Benchmarking Standards Group, Hawthorn VIC, Australia, January 2007.
[25] ISO/IEC 9126 Software Engineering – Product Quality – Parts 1-4, ISO, Geneva, 2001-2004.
[26] A. Kobyliński, T. Chodoła, Pomiary w praktyce wytwarzania oprogramowania (Measurements in the
practice of software production), in: Studies and Proceedings of Polish Association for Knowledge
Management No. 7 , W. Bojar, L. Drelichowski, G. Dzieża, A. Januszewski (eds), Bydgoszcz-
Ciechocinek, 2006.
[27] ISO/IEC 25020:2007 Software engineering – Software product Quality Requirements and Evaluation
(SQuaRE) – Measurement reference model and guide, ISO, Geneva, 2007.
[28] ISO/IEC TR 25021:2007 Software engineering – Software product Quality Requirements and
Evaluation (SQuaRE) – Quality measure elements, ISO, Geneva, 2007.
[29] ISO/IEC 14143 Information technology -- Software measurement -- Functional size measurement --
Parts 1-6, ISO, Geneva, 1998-2007.
[30] T.C. Jones, Software Assessments, Benchmarks, and Best Practices, Information Technology Series,
Addison-Wesley, 2000.
[31] ISO/IEC 20926:2003 Software engineering - IFPUG 4.1 Unadjusted functional size measurement method - Counting
practices manual, ISO, Geneva, 2003.
[32] ISO/IEC 20968:2002 Software engineering – Mk II Function Point Analysis - Counting practices manual, ISO,
Geneva, 2002.
[33] ISO/IEC 24570:2005 Software engineering – NESMA functional size measurement method version 2.1
- Definitions and counting guidelines for the application of Function Point Analysis, ISO, Geneva, 2005.
[34] ISO/IEC 19761:2003 Software engineering – COSMIC-FFP – A functional size measurement method, ISO,
Geneva, 2003.
[35] ISO/IEC 29881:2008 Information Technology – Software and systems engineering – FiSMA 1.1
functional size measurement method, ISO, Geneva, 2008.
[36] C.A. Dekkers, E. Emmons, How Function Points Suport the Capability Maturity Model Integration,
„CrossTalk. The Journal of Defence Software Engineering", February 2002, pp. 21-24.
[37] M. Brown, D. Goldenson, Measurement and Analysis: What Can and Does Go Wrong?, 10th IEEE
International Symposium on Software Metrics, September 2004, pp. 131-137.
[38] D.L. Gibson, D.R. Goldenson, K. Kost, Performance Results of CMMI-Based Process Improvement,
Software Engineering Institute, Carnegie Mellon University, Pittsburgh, August 2006, s. 3-30.
[39] D.F. Rico, ROI of Software Process Improvement: Metrics for Project Managers and Software
Engineers, J. Ross Publishing, February 2004.
[40] D. Longstreet, Function Point Analysis Training Course, Longstreet Consulting Inc., October 2004.
[41] The ISBSG Special Analysis Report: Tools & Techniques – No Silver Bullets! , International Software
Benchmarking Standards Group, Hawthorn VIC, Australia, September 2005.
[42] Standish Group, CHAOS Summary 2008, West Yarmouth, Massachusetts, 2008.
[43] J. Chabik, Jakość dla małych i średnich (Quality for small and medium-sized ones), „ComputerWorld"
2002 , no. 42 (Polish edition).
... 25) have been acknowledged by the ISO and IEC as conforming to the rules laid down in the ISO/IEC 14143 norm. They are the following (for more details see e.g. [3,4]): A. First generation methods: 1) International Function Point Users Group (IFPUG) method in its part limited to the so called unadjusted FP—normalised in the ISO/IEC 20926 standard [5]; in this method a measure unit is 1 IFPUG FP; 2) Netherlands Software Metrics Association (NESMA) function point method in its part taking into account functional size—normalised in the ISO/IEC 24570 Analysis of Software Development and Enhancement Projects Work Effort per Unit Based on the COSMIC Method with Regard to Technological Factors—Case Study 598 standard [6]; in this method a measure unit is 1 NESMA FP, which now is considered to be equivalent to 1 IFPUG FP; ...
... [19]). Both approaches, although differently, meet also the requirements that the ISO/IEC 14143 norm imposed on FSM methods therefore both were recognised as international standards for such measurement (the IFPUG method, however, not in the full version yet in its most important part) (for more details see [3]). However there are features these two methods differ with and which are of significance from the perspective of calculation of software development effort per unit (see e.g. ...
-
![Beata Czarnacka-Chrobot]()
This paper aims to present a case study that consists in the analysis of work effort per unit of software systems Development and Enhancement Projects (D&EP) depending on technological factors. That analysis was commissioned by one of the largest public institutions in Poland. This is the COSMIC (Common Software Measurement International Consortium) function points method that is chosen by this institution as a point of reference for size of software systems developed/enhanced for supporting its functions and therefore this method is the base for the analysis of D&EP work effort per unit with regard to technological factors.
... That's why over the last couple of years significant intensification of works could have been observed, which aimed to standardize the best practices, especially with regard to software products. Various ISO/IEC (International Organization for Standardization/ International Electrotechnical Commission) norms have been developed as a result of these works, filling an important gap in the software engineering [14]. One of the most important groups of ISO/IEC standards concerns software product size measurement. ...
... Some of the undertakings have only just gained recognition, which may be proved by the fact that the latest version of the CMMI-DEV model was strongly focused on measurement. Also various ISO/IEC norms have been developed as a result of these works, filling an important gap in the software engineering (for more details see [14]). One of the most important groups of ISO/IEC standards concerns the software product FSM. ...
-
![Beata Czarnacka-Chrobot]()
Execution of software Development and Enhancement Projects (D&EP), particularly those delivering Business Software Systems (BSS) as a product, encounters many problems, which still makes fulfilling of client requirements appear a big challenge for BSS providers. This may be proved by numerous analyses indicating exceptionally low effectiveness of BSS D&EP as compared to other types of IT projects, what-with their significant costs being considered-leads to the substantial financial losses. Author's analysis of fundamental BSS D&EP success factors indicates that one of the most important of them is objective and reliable measurement of such projects' product size, with particular consideration given to client's perspective. Further analyses led author to the conclusion that these conditions are only met by the software product size measure based on its functionality, what is confirmed by the acknowledgement of the so-called software Functional Size Measurement (FSM) concept along with several FSM methods by the ISO and IEC. The paper analyzes and evaluates the potential of effective usage of FSM with regard to BSS, with particular consideration given to the two most popular normalized FSM approaches, namely International Function Point Users Group (IFPUG) method and Common Software Measurement International Consortium (COSMIC) method. This issue is important not only for practical, but also for theoretical reasons, which are caused by the need to satisfy requirements of software engineering as a knowledge discipline having scientific grounds. Keywords-business software systems development and enhancement projects; functional size measurement; IFPUG method; COSMIC method; software engineering
... ISO/IEC 25000 Software Quality Requirements and Evaluation standard, attempts to harmonise, unify, and update the international ISO/IEC standards for evaluating software quality [27], derived from the SPICE project [28] and includes recommendations from some authors [29], [30]. Their suitable measurements can provide information that enables the customer or software purchaser to make rational business decisions, where the SQuaRE series includes a specific customer/purchaserfocused quality measurement application [31]. Other authors considered the standard to be widely applicable, both to evaluate the quality of commercial software product as well as custom-built and personalised software. ...
Information and Communications Technologies in healthcare has increased the need to consider quality criteria through standardised processes. The aim of this study was to analyse the software quality evaluation models applicable to healthcare from the perspective of ICT-purchasers. Through a systematic literature review with the keywords software, product, quality, evaluation and health, we selected and analysed 20 original research papers published from 2005-2016 in health science and technology databases. The results showed four main topics: non-ISO models, software quality evaluation models based on ISO/IEC standards, studies analysing software quality evaluation models, and studies analysing ISO standards for software quality evaluation. The models provide cost-efficiency criteria for specific software, and improve use outcomes. The ISO/IEC25000 standard is shown as the most suitable for evaluating the quality of ICTs for healthcare use from the perspective of institutional acquisition.
... 25) have been acknowledged by the ISO and IEC as conforming to the rules laid down in the ISO/IEC 14143 norm. They are the following (for more details see e.g., [5], [6]): ...
-
![Beata Czarnacka-Chrobot]()
In this paper we present a case study on tender competition concerning the enhancement of Web Information Portal (WIP) of one of the largest public institutions in Poland in which one of the three potential developers offered possibility to enhance such system at the cost of 300 US dollars per 1 Function Point (FP) of the Common Software Measurement International Consortium (COSMIC) method, whereas the other two attempted to prove that the enhancement of WIP at such unit cost is not possible to carry out. According to them, the unit cost was underestimated even several times. The goal of this paper is to demonstrate it is possible to carry out enhancement of the WIP at the above mentioned per-unit cost and consequently that the offer of a certain company does not feature the so-called abnormally low tender price as defined in the act " Public Procurement Law " , which makes it impossible to choose given tenderer due to the legal reasons. The analysis served as a main basis for settling legal dispute between a company offering values of attributes that are being analysed in the paper and the competing companies – in favour of a company having been selected by client as the company had proved that in the discussed area the selection of developer was made in accordance with the Polish law. Keywords—Web Information Portal (WIP); software development/enhancement projects; per-unit work effort; per-unit cost; functional size measurement; COSMIC method; IFPUG method
... @BULLET FSM method developed by the Finnish Software Measurement Association (FiSMA) [22]. The FSMM standardized by the ISO/IEC differ in terms of software measurement capabilities with regard to different software classes (functional domains), but all of them are adequate for business software systems (seeTable 2 and [23]). Functional size measurement of BSS supports first of all [15, Part 6]: @BULLET BSS D&EP management by enabling: to make early prognosis on resources necessary for project execution, to monitor progress in project execution, to manage the changes in the required BSS size, to determine degree to which the supplied product meets functional user requirements, as well as to make post-execution project analysis and compare its attributes with other projects. ...
-
![Beata Czarnacka-Chrobot]()
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.
... Specific weight is defined for every feature in each software groups which are the results of AHP model on experts. It can be mentioned that if the method of evaluation has been designed based on 25030 set [1][2][3][4], it would be accepted. Considering the standards mentioned above, this study attempts to extract a general model which is applicable for measuring the quality of software in ten steps. ...
-
![Bahram Sadeghi Bigham]()
- Hassan Alizadeh
- Hossein Afsari
In software rating area, it is necessary to apply a measurement reference model to evaluate the quality of software. The standard 25030 is an example of an evaluation system which is based on stakeholders' requirements. In this study, an attempt has been made to establish a model in which all implicit and explicit requirements of stakeholders, users and policy makers have been taken into account. In addition, AHP method has been followed to weigh the indicators used in the model. The results show applicability of the model to meet the requirements of Iranian users.
Systems quality requirements are defined by ISO/IEC 25000 series. In specifying these requirements, using Natural Language, it is possible that there are symptoms of low quality, Requirements Smells (RSs). The present work has the objective of confirming and analyzing the presence of Requirements Smells in specifications of quality requirements classified by ISO/IEC 25010. The specifications of 26 systems of a large public financial organization were analyzed. Content analysis and Nvivo software were used and 870 quality requirements were categorized and analyzed. As a result, it was verified that 44% of the analyzed requirements present Requirements Smells which signals the importance of the inspection of the requirements with this bias. It was also identified that the most representative RSs are related to Subjective Language (34.6%), Incomplete Reference (22%) and Non verifiable terms (16%). The RSs less found in the specifications are of the Superlative, Loopholes and Comparative categories.
The selection of appropriate Model-Driven Web Engineering (MDWE) methodology as a tool to develop web applications has become an important issue in terms of features that need to be included in the web site. Quality Evaluation Framework (QuEF) is used specifically to evaluate MDWE methodologies and other methodologies in general. It can be used to evaluate either a well-established methodology or a new methodology in early stages of development. In this paper, by using QuEF, NDT as a well-established MDWE methodology has been compared with WSDMDA as a new methodology. The comparison has been conducted based on only Functionality quality characteristic of QuEF and three features namely Model-Driven Engineering (MDE), Web Modeling and Tool Support. Results show that WSDMDA is obtained a higher value for Web Modeling feature, while a higher value for other two features has been obtained by NDT methodology.
This study examines the need to consider interactions between the measurements (metrics) of different quality factors in the development of software quality models. Though the correlation between metrics has been explored to a considerable depth in the development of these models, consideration of interactions between predictors is comparatively new in software engineering. This preliminary study is supported by statistically-proven results, differentiating interactions with correlation analysis. The issues raised here will assist analysts to improve empirical analyses by incorporating interactions in software quality model development, where amalgamating effects between different characteristics or subcharacteristics are observed.
- M. Brown
-
![Dennis Goldenson]()
By now, one can point to many instances where measurement has been used effectively to inform management and technical decisions in support of the development and maintenance of software and software intensive systems. Yet, measurement is not very well integrated into software or systems engineering education or practice, and measurement remains challenging for all too many organizations. For this paper, we have analyzed 1350 findings drawn from 663 Software CMM® appraisals that were conducted between 1987 and 2002 inclusive. The results are augmented by questions from a survey of CIO's from state and local governments and the private sector. Our analyses suggest several areas where both managers and engineers would benefit from better guidance about the proper use of measurement and analysis. Future work may include lexical analyses based on natural language processing as well as studies of appraiser understanding of the measurement content in CMMI® models.
- Pam Morris
The paper reviews the implementation of measurement using the ISO/IEC15939 (5) framework and examines how the measures have provided new (and some unexpected) insights into organisations' development and enhancement processes. The original objective of the measurement and benchmarking activity was to assist the IT Department demonstrate the cost efficiencies and benefits achieved by the gradual re- factoring of their large legacy application (~14,000 fps) over a period of 4 years. However, the process of baselining, collecting and analysing the measures has provided additional valuable insights into the Departments current development processes that have enabled significant productivity and quality improvements to be realised. These insights have changed the way that the Project managers plan and estimate their ongoing change requests, package quarterly Releases, and where they focus their development effort. Measurement results provide a major input into setting directions for their process improvement initiatives. The paper examines the key success factors of this measurement program that has been effective and evolving for over 2 years and how senior management responded to the measurement data and incorporated it in their decision making. 1. Background Howard Rubens (1) reported in 1995, that 4 out of 5 software measurement programs 'fail to succeed', where a successful program is one that lasts for more than 2 years and it impacts the organisation's management decisions. Total Metrics is a metrics consultancy that has assisted numerous clients to implement measurement programs over the past 13 years. Frustratingly we have experienced similar levels of failure to that reported by Rubens in 1995. This paper looks at a case study of one or our 'successful' programs and investigates why it has succeeded when so many fail. The paper is based on the experiences of a section within an Australian Government Department employing approximately 60 developers to enhance, maintain and support their large (~14,000 fps) legacy Asset Licensing and Registration (ALRS) system. The majority of the personnel within the IT area are long term, highly skilled contractors who have had significant experience in the competitive private sector. The ARLS system provides a significant revenue stream to the Department and is required by the business to remain profitable and competitive.
Zapewnienie jakosci i metryki oprogramowania (Ensuring software quality and metrics), in: Inzynieria oprogramowania w projekcie informatycznym (Software Engineering in IT Project
- N E Fenton
Software Engineering - Guidelines for the application of ISO 9001:2000 to computer software
- Iso Iec
Modele jakosci produktów i procesów programowych (The Programming Product and Processes Quality Models)
- A Kobylinski
Software engineering - NESMA functional size measurement method version 2.1 - Definitions and counting guidelines for the application of Function Point Analysis
- Iso Iec
Software engineering - IFPUG 4.1 Unadjusted functional size measurement method - Counting practices manual
- Iso Iec
Source: https://www.researchgate.net/publication/221026585_The_ISOIEC_Standards_for_the_Software_Processes_and_Products_Measurement
Posted by: forbeanbags.blogspot.com
