J. Software Engi neeri n g & Applications, 2010, 3, 972-982
doi:10.4236/jsea.2010.310114 Published Online October 2010 (http://www.SciRP.org/journal/jsea)
Software Engineering Principles: Do They Meet
Engineering Criteria?
Kenza Meridji, Alain Abran
École de Technologie Supérieure (ÉTS)—University of Québec, Montréal, Québec, Canada.
Received July 31st, 2010; revised August 25th, 2010; accepted August 31st, 2010.
ABSTRACT
As a discipline, software engineering is not as mature as other engineering disciplines, and it still lacks consensus on a
well-recognized set of fundamental principles. A 2006 analysis surveyed and analyzed 308 separate proposals for prin-
ciples of software engineering, of which only thirty-four met the criteria to be recognized as such. This paper reports on
a further analysis of these thirty-four candidate principles using two sets of engineering criteria derived from: A) the
engineering categories of knowledge defined by Vincenti in his analysis of engineering foundations; and B) the joint
IEEE and ACM software engineering curriculum. The outcome of this analysis is a proposed set of nine software engi-
neering principles that conform to engineering criteria.
Keywords: Engineering Criteria, Software Engineering Principles, Vincenti, Engineering Verification Criteria
1. Introduction
Software engineering is defined by the IEEE as:
“1) The application of a systematic, disciplined, quan-
tifiable approach to the development, operation and
maintenance of software, i.e. the application of engi-
neering to software.
2) The study of approaches as in 1” [1].
The intended goals of software engineering are differ-
ent from those of computer science. In software engi-
neering, artifacts are designed, produced and put into
operation, while in computer science the theoretical
foundations of information and computation are the ob-
ject of study. Computer science deals with the investiga-
tion and analysis of algorithms and their related problems,
in order to enable th e computer perform the task [2].
Computer science is the discipline that underlies soft-
ware engineering, and it is to be expected that the princi-
ples for computer science will be different fro m the prin-
ciples of software engineering. For example, a principle
proposed in computer science, “Use coupling and cohe-
sion” [3], deals with the underlying science, while soft-
ware engineering principles are more general, like “Ap-
ply and use quantitative measurements in decision mak-
ing” [3].
Of course, software engineering is still an emerging
engineering discipline and is not yet as mature as other
traditional engineering disciplines such as mechanical
and electrical engineering. Much of the research con-
ducted to date in software engineering has focused on
developing methods, techniques, and tools, and consid-
erably less on exploring the engineering foundations of
software engineering, including identifying the software
engineering fundamental principles, or how to apply
them in research and practice.
A significant amount of the work carried out to date on
software engineering principles has been based on expert
opinion, with a few exceptions in which defined research
methodologies have been used, such as in [4] and [5],
where Delphi rounds are applied to develop an initial
consensus among a group of 12 experts on a set of can-
didate principles for software engineering.
In a 2006, literature survey on this topic, covering the
previous 20 years [3], 308 separate proposals for candi-
date software engineering principles was identified.
These were then analyzed against a set of criteria related
to the specific concept of a ‘principle’, following which
only 34 were recognized as bona fide ‘candidate’ funda-
mental principles (FPs) [3]. However, the research scope
of that study did not, include within its research scope an
analysis of these candidates from an engineering per-
spective.
In this paper, we perform that analysis. One of the
challenges, of course, is to figure out what criteria should

Software Engineering Principles: Do They Meet Engineering Criteria?973
be verified from an engineering perspective, since, in the
traditional engineering literature, such criteria are not
explicitly described. This paper documents the method-
ology to make that determination, as well as what we
found when we applied them to the set of 34 candidate
FPs.
The paper is organized as follows: Section 2 presents
related work on software engineering principles. Section
3 presents the analysis methodology selected. Section 4
identifies the software engineering verification criteria.
Section 5 describes the application of these criteria. Sec-
tion 6 presents the analysis results. Section 7 points out
the limitations of that work. Section 8 presents our con-
clusion.
2. Related Work on Software Engineering
Principles
The expression “fundamental principle” is composed of
two terms. According to the Cambridge University Dic-
tionary, the term “fundamental” means “forming the base,
from which everything else originates; more important
than anything else”, and “principle” means “a basic idea
or rule that explains or controls how something happens
or works”.
From the literature on software engineering principles,
the authors of [3] inventoried 308 principles that had
been proposed by individuals (for instance [6-8]) or as
part of a collaborative effort [9-12]. With the exception
of [11] and [3], the authors involved proposed only
nominative principles, without including either formal
definitions or procedures for implementing them. To
verify whether or not each of these was indeed a candi-
date ‘fundamental’ principle, in our sense of the terms, a
two-step verifi cat i on pr ocess was used in [3-11,13,1 4] :
1) Identification of seven verification criteria
Five criteria applicable to each proposed principle were
derived from [4]:
 A principle is a proposal formulated in a prescrip-
tive way;
 A principle should not be directly associated with,
or arise from, a technology, a method, or a tech-
nique, or itself be an activity of software engineer-
ing;
 The principle shou ld not dictate a compromise (or a
proportioning) between two actions or concepts;
 A principle of software engineering should include
concepts connected to the engineering discipline;
 It must be possible to test the formulation of a
principle in practice, or to check its consequences.
Two additional criteria were identified as applicable
across the full set of proposed principles:
 The principles should be independent, e.g. not de-
duced [6];
 A principle should not contradict another known
principle [4].
2) Verification of each of the proposed 308 principles
surveyed against these criteria
In [3] it is reported that only 34 of the 308 proposals
met the full set of criteria to be recognized as candidate
FPs. Table 1 lists them, in alphabetical order [3].
In their paper “Fundamental Principles of Software
Engineering–A Journey” [4], the authors identified a set
of fundamental principles through a well documented
research methodology. They defined the relationships
between principles, standards and implemented best
practices as illustrated in Figure 1.
Prin ciples of
Engineering
and other
Disciplines
Principles of
Software
Engineering
Practices
Standards
Implemented
“Best
Practices”
SWE principles
are specific cases of
general
engineering
principles
SWE principles
organize, explain and
validate practices
standards.
Practices are
deployed based on
practice standards.
Some SW E pri nciples
may be generalized
to prin ci pl es for the
engineering of
complexe systems.
SWE principles
should be
“abstractions”
of practice s tand a rd s .
Practice standards
should be recordings
of observe d best
practices.
Figure 1. Relationships between principles, standards an d practices [4].

Software Engineering Principles: Do They Meet Engineering Criteria? 974
This figure illustrates the relationships sought among
principles standards and practices. It is believed that a
body of fundamental principles has been recorded for
some branches of engineering, e.g. [15]. Most of the en-
gineering branches have a history far longer than that of
software engineering and software engineering principles
(SWE principles in Figure 1) would, in general, be re-
garded as specializations of these principles. The soft-
ware engineering principles would play the role of orga-
nizing, motivating, explaining, validating the practice
standards and implemented practices should be based on
those practice standards [4].
Working from the specific toward the general, practice
standards would be recordings and idealizations of ob-
served and validated “best practices”. The software en-
gineering principles would be abstractions of the practice
standards. Furthermore, software engineering principles
might be candidates for generalization to the status of
general engineering principles, particularly when com-
plexity is a concern [4].
3. Analysis Methodology
The scope of the criteria used in [3] was limited to the
concept of ‘principles’, and did not include the specific
features of the engineering concepts themselves. This is
the focus of the work reported here: the list of 34 candi-
date principles in Table 1 constitutes the input to the
analysis process required to verify whether or not they
conform to engineering criteria. This will make it possi-
ble to narrow the number of principles. More specifically,
the research issue addressed in this paper is, which of
these 34 candidate FPs conform to engineering criteria?
Of course, engineering criteria are required for this
verification and must be available, but no related work
could be identified. So, the first challenge was to deter-
mine verification criteria from an engineering perspec-
tive.
To tackle this issue, it w as necessary to study the epis-
temology of engineering. For that purpose, two sources,
Vincenti, the author of the book, What Engineers Know
and How They Know It [15], and the joint IEEE-ACM
software engineering curriculum [16] were selected:
 Vincenti has identified a number of engineering
knowledge types as key to the engineering disci-
plines and from which engineering criteria can be
derived;
 The IEEE and the ACM have documented a set of
topics within their joint software engineering cur-
riculum from which engineering criteria can be de-
rived.
The approach designed for identifying relevant criteria
and applying them to the set of 34 candidate FPs consists
of three phases—see Figure 2.
Phase 1: Identification of two sets of verification cri-
teria
This phase consists of the identification of criteria
which would be relevant to any engineering discipline.
Such criteria could have been taken either as is, when
expressly identified and defined, or derived, when docu-
mented only implicitly. The inputs to this phase are the
two sources of information identified from the related
work. The outputs of this phase are the two sets of crite-
ria derived from Vincenti and from the IEEE-ACM joint
software engineering curriculum. The criteria identifica-
tion phase based on Vincenti is summarized in Figure 3,
which shows its inputs and outputs.
The criteria id entifi cation phase b ased on the IEEE-ACM
criteria is summarized in Figure 4, which shows its in-
puts and outputs. This phase is presen ted in greater detail
in Section 4.
Phase 2: Verification execution:
The 34 candidate FPs will be taken as inputs in the
second phase and analyzed next with respect to the two
sets of engineering criteria identified in Phase 1.
The output will be the FPs that have at least one direct
mapping, and those that have only an indirect mapping to
either Vincenti or to the IEEE-ACM eng ineering criteria.
This phase is illustrated in Figure 5 and is presented in
greater detail in Section 5.
Phase 3: Analy si s and selection:
In Phase 3, the analysis across each set of engineering
criteria is performed. This phase identifies the candidate
FPs that meet engineering criteria from both sets of crite-
ria and those that do not. For instance, the candidate FPs
that meet only the Vincenti criteria [15] and the candi-
date FPs that only meet the IEEE-ACM criteria [14] are
then be analyzed to check whether or not they can be
identified from the FP th at are recogniz ed as engineer ing
FPs. This phase is described in greater detail in Section
6.
4. Phase 1: Identification of Engineering
Criteria
4.1. Vincenti
Vincenti [17] studied the epistemology of engineering
based on the historical analysis of five case studies in
aeronautical engineering covering a roughly fifty-year
period and proposed a taxonomy of engineering knowl-
edge. He identified different types of engineering
knowledge and classified them into six categories:
1) Fundamental design concepts,
2) Criteria and specifications,
3) Theoretical tools,
4) Quantitative data,
5
) Practical considerations, and

Software Engineering Principles: Do They Meet Engineering Criteria?975
Table 1. Inventory of Candidate FPs [3].
No Proposals–in alphabetical order
1 Align incentives for developer and customer
2 Apply and use quantitative measurements in decision making
3 Build software so that it needs a short user m anual
4 Build with and for reuse
5 Define software artifacts ri go rously
6 Design for maintenance
7 Determine requirements now
8 Don’t overstrain your hardwar e
9 Don’t try to retrofit quality
10 Don’t write your own test plans
11 Establish a software process that provides flexibility
12 Fix requirement s pe c if ic at i on e rrors now
13 Give product to customers ear ly
14 Grow systems incrementally
3 Implement a disciplined approach and i mprove it continuously
16 Invest in understa nding the problem
17 Involve the customer
18 Keep design under intellectual control
19 Maintain clear accountability for results
20 Produce software in a stepwise fashion
21 Quality is the top priority; long-term productivity is a natural consequence of high quality
22 Rotate (top perform ing) people through product assuran ce
23 Since change is inherent to software, plan for it an d manage it
24 Since tradeoffs are inherent to software engineering, make them explicit and document them
25 Strive to have a peer find a defect, rather than a customer
26 Tailor cost estimation method s
27 To improve de si gn , study previous solutions to similar problems
28 Use better and fewer people
29 Use documentation standards
30 Write program s for people first
31 Know software engineering techn iq ues before using development tools
32 Select tests based on the likelihood that they will find faults
33 Choose a programming language t o ensure maintai nability
34 F aced with unstructured code, rethink the module and rede s ig n it fr om scratch

Software Engineering Principles: Do They Meet Engineering Criteria? 976
Figure 2. The three-phase verification process.
Figure 3. Identification of Vincenti engineering criteria.
Figure 4. Identification of the IEEE-ACM engineering criteria.
Figure 5. Phase 2: Process of verification against sets of engineering criteria.
6) Design instrumentalities.
According to Vincenti, this classification is not spe-
cific to aeronautical engineering, but can be transferred
to other engineering domains. For instance, a detailed
analysis of engineering know ledge types was used in [18]
to analyze the content of the Software Quality Knowl-
edge Area of the Guide to the Software Engineering
Body of Knowledge–SWEBOK [15].
Vincenti has distinguished seven elements for engi-
neering, which he refers to as “interactive elements”, and
which he selected prior to categories of engineering
knowledge types. These elements show the epistemo-
logical structure of the engineering learning process
based on the analysis of the five aeronautical case studies.
These seven elements represent, in Vincenti’s opinion, a
necessary set of different elements that interact with each
other for the completion of an engineering activity. These
seven interactive elements are referred to here as the
Vincenti engineering criteria, and are listed in Table 2.
The abbreviations we have selected to represent each of
these criteria are listed in the right-hand column of Table
2.
4.2. IEEE and ACM Joint Curriculum
The IEEE Computer Society (IEEE-CS) and the Asso-
ciation for Computing Machinery joined forces to de-
velop a joint set of computer curricula, including one on
software engineering. More specifically, chapter 2 of the
joint software engineering curriculum lists the character-
istics of an engineering discpline (see Table 3). These i

Software Engineering Principles: Do They Meet Engineering Criteria?977
Table 2. Engineering criteria identified in Vincenti.
ID. Vincenti Engineering Criteria Abbreviation
1 Recognition of a prob l e m Problem
2 Identification of concepts and criteria Criteria
3 Development of instruments an d te c hniques Techniques
4 Growth and refinement of opinions regarding desirable qualities Quality
5 Combination of partial results from 2, 3 and 4 into practical schema for research Testing
6 Measurement of characteristics Measurement
7 Assessment of results and data Assessment
Table 3. Identification of IEEE & ACM engineering criteria.
ID. Engineering Criteria Identified Abbreviation
1 Engineers proceed by making a series of decisions, carefully evaluating options, and choosing an ap- proach at each decision point that is appropriate for the current task in the current context. Appropriate-
ness can be judged by tradeoff analy si s, which balances costs against benefits. Decision making
2 Engineers measure things, and, when appropriate, work quantitatively; they calibrate and validate their
measurements; and they use approximations based on experience and empirical data. Measurements
3 Engineers emphasize the use of a disciplined process when creating a design and can operate eff ectively
as part of a team in doing so. Disciplined process
4 Engineers can have multiple roles: research, development, design, production, testing, construction,
operations, management, and others, such as sales, consulting, an d t ea ch in g. Engineer’s roles
5 Engineers use tools to apply processes systematically. Therefore, the choice and use of appropriate tools
is key to engineering. Use of Tools
6 Engineers, via their professional societies, advance by the development and validation of principles,
standards, and best practices. Development and validation
7 Engineers reuse designs and desi gn artifacts. Reuse design
characteristics are adopted here as engineering verifica-
tion criteria. The abbreviations we have selected to rep-
resent each of these criteria are listed in the right-hand
column of Table 3.
5. Phase 2: Verification against the Two Sets
of Criteria
The set of 34 candidate FPs is next mapped to the two
sets of engineering criteria: each candidate FP is taken as
input and analyzed using each of Vincenti’s seven crite-
ria and, again, each of the seven IEEE-ACM software
engineering criteria.
The output of the mapping to Vincenti’s engineering
criteria is presented in Appendix A-1, where the letter D
represents a direct mapping, and the letter I an indirect
one. For instance:
 Candidate FP #2 (Apply and use quantitative
measurements in decision making) maps directly to
Vincenti’s criterion #6 and indirectly to Vincenti’s
criterion #4.
 Candidate FP #31 (Know software engineering
techniques before using development tools) has
only an indirect mapping to criterion #3 and to cri-
terion #7 (Assessment).
 Finally, there are candidate FPs with no mapping to
any engineering criteria: for instance, candidate FP
#13 (Give product to customers early).
This first verification against the Vincenti criteria
leads to the following results (see Appendix A-1):
 12 candidate FPs have at least one direct mapping
to a Vincenti engineering criterion;
 21 candidate FPs have only indirect mappings to
Vincenti engineering criteria;
 1 candidate FP has no direct or indirect mapping to
any Vincenti engineering criteria.
The second verification against the seven IEEE &
ACM engineering criteria is presented in Appendix A-2.

Software Engineering Principles: Do They Meet Engineering Criteria? 978
For instance:
 Candidate FP #2 (Apply and use quantitative
measurements…) has a direct mapping to criteria
#1 (Decision making) and #2 (Measurements).
Candidate FP #16 (Invest in the understanding of
the problem) is mapped indirectly to criteria #1
(Decision making) and #3 (Disciplined process).
 Candidate FP #4 (Build with and for reuse) is
mapped directly and indirectly to criteria #7 (Reuse)
and #3 (Disciplined process).
 Finally, candidate FP #13 (Give products to cus-
tomers early) is not related to any engineering cri-
teria.
This second verification against the IEEE and ACM
criteria leads to the following results (see Appendix
A-2):
 15 candidate FPs have at least one direct mapping
to an IEEE-ACM engineering criterion;
 16 candidate FPs have only indirect mappings to an
IEEE-ACM engineering criterion;
 3 candidate FPs have neither direct nor indirect
mappings to any IEEE-ACM engineering criteria.
6. Phase 3: Analysis and Consolidation Using
Both Sets of Criteria
6.1. Analysis across Each Set of Engineering
Criteria
The candidate FPs with a direct mapping to either the
Vincenti or IEEE-ACM criteria are listed in Table 4.
From a comparison of the two columns in this table, the
candidate FPs with direct mappings can be grouped into
three sets:
1) Candidate FPs with a Vincenti mapping similar to
the IEEE-ACM mapping;
2) Candidate FPs with a Vincenti mapping with no
equivalen t IE EE-ACM m a pping;
3) Candidate FPs with an IEEE-ACM mapping with
no equivalent Vincenti mapping.
Table 4. Candidate FPs that directly meet criteria from either set.
# Vincenti Mapping # IEEE-ACM Mapping
2 Apply and use quantitative measurements in decision making 2 Apply and use quantitative measurements in decision making
4 Build with and for reuse 4 Build with and for reuse
5 Define software artifact rigorously
6 Design for maintenance
7 Determine requirements now
9 Don’t try to retrofit quality
10 Don’t write your own test plans
11 Establish a software process that provides flexibility 12 Fix requirements specification error now
14 Grow systems incrementally
15 Implement a disciplined approach and improve it continuously 15 Implement a di sciplined approac h a nd improve it continuously
16 Invest in underst anding the problem
18 Keep design under intellectual control
21 Quality is the top priority; long term productivity is a natural con-
sequence of high quality 21 Quality is the top priority; long term productivity is a natural con- sequence of high quality
22 Rotate (high performi ng) people through product assurance
23 Since change is inherent to software, plan for it and manage it
24 Since tradeoffs are inherent to software engineering, make them
explicit and document them 24 Since tradeoffs are inherent to software engineering, make them explicit and document them
25 Strive to have a peer, find a defect rather than a c u s t omer
26 Tailor cost estimation methods
27 To impro v e d e s i gn , study previous solut ions to sim il ar problems 27 To improve design, study pr e vious solutions to similar problems
31
Know software engineering techniques before using developmen
t
tools

Software Engineering Principles: Do They Meet Engineering Criteria?979
Set A:
From Table 4, we can see that six candidate FPs (#2,
#4, #15, #21, #24, #27) are present in both columns (the
highlighted ones) and therefore satisfy at least one engi-
neering criterion in each set of criteria (Vincenti and
IEEE-ACM): these six could reasonably be considered as
FPs that conform to engineering criteria.
Set B:
From Table 4, we note that there are 6 other candidate
FPs that meet the Vincenti criteria, but no IEEE-ACM
criteria, and 9 candidate FPs that meet the IEEE-ACM
criteria, but no Vincenti criteria. Can these still be con-
sidered as FPs, or are they merely instances of more
fundamental principles?
To answer this question, we could reasonably argue
from the Vincenti subset that:
 Candidate FP #7 (Determine requirements now)
can be deduced from candidate FP #16 (Invest in
understan ding the problem );
 Candidate FP #9 (Don’t try to retrofit quality) can
be deduced from candidate FP #21 (Quality is the
top priority; long-term productivity is a natural
consequence of high quality);
 Candidate FP #11 (Establish a software process
that provides flexibility) can be deduced from FP
#9 (Don’t try to retrofit quality).
This would eliminate candidates FPs #7, #9, and #11
from the list of FPs, since they represent specific instan-
tiations of more general FPs, while principles #16, #14,
and #23 would be retained on the list of FPs.
Set C:
From Ta ble 4, there remain 9 candidate FPs withou t a
corresponding direct mapping to the Vincenti criteria.
We could reasonably argue that these 9 can be deduced
from those with direct Vincenti mappings: for instance,
FP #18 (Keep design under intellectual control) and FP
#31 (Know software engineering techniques before using
development tools) can be deduced from FP #15 (Im-
plement a disciplined approach and improve it continu-
ously).
This would eliminate candidate FPs #5, #6, #10, #12,
#18, #22, #25, #26, and #31 from the list of FPs, since
they represent specific instan tiations of more general FPs,
while retaining principle #15.
In summary, this analysis has allowed us to refine the
list of 34 candidate principles to 9 software engineering
principles based on engineering criteria. This analysis
has also eliminated the overlap between the various prin-
ciples; as a consequence, a subset of only 9 (see Table 5)
from the list of 34 candidates identified in Seguin 2006
are recognized as principles that conform to engineering
criteria, the remaining 25 being specific instantiations of
those 9. In Table 5, these software engineering FPs are
sequenced from 1 to 9, along with their or iginal sequen ce
number (right-hand column) assigned when the initial list
of 34 candidates was compiled.
6.2. Identification of a Hierarchy
Table 6 presents next the outcome of our analysis of the
25 remaining candidate FPs as instantiations of the 9
principles in Table 5 that conform to engineering crite-
ria.
7. Work Limitations
The initial list of 34 candidates taken as input for this
research is not necessarily exhaustive: to summarize,
these 34 candidates have been refined from 304 proposed
principles identified in the literature over a period of 20
years, up to 2006 [19]. The methodology used engineering
Table 5. List of 9 software engineering principles.
# Vincenti, IEEE-ACM mapping
1 Apply and use quantitative measurements in decision making 2
2 Build with and for reuse 4
3 Grow systems incrementally 14
4 Implement a disciplined approach and improve it continuously 15
5 Invest in the understanding of the problem 16
6 Quality is the top priority; long term productivity is a natural consequence of high q uality 21
7 Since change is inherent to software, plan for it and manage it 23
8 Since tradeoffs are inherent to software engineer in g, make them explicit and document it 24
9 To improve de si gn , study previous solutions to similar problems 27

Software Engineering Principles: Do They Meet Engineering Criteria? 980
Table 6. Hierarchy of candidate principles for software engineering.
# Direct mapping to Vincenti criteria Derived instantiation (= Indirect mapping)
26Tailor cost estimation me thods
2 Apply and use quantitative measurements in decision mak-
ing 8 Don’t overstrain your hardware
4 Build with and for reuse
5 Define software artifacts rigorously
14 Grow systems incrementally 20Produce software in a stepwise fashion
1 Align incentives for developer and customer
10Don’t write your own test plans
17Involve the customer
18Keep design under intellectual control
20Produce software in a stepwise fashion
31 Know software engineering’s techniques before using development
tools
19Maintain clear accountability for results
29Use documentation standards
15 Implement a disciplined approach and improve it continu-
ously
10Don’t write your own test plans
7 Determine requirements now
12Fix requirement s specific a ti o n e rror now
16 Invest in understanding the problem
17Involve the customer
9 Don’t try to retrofit quality
22Rotate (high performing peop le t hrough product assurance
25Strive to have a peer find a defect rather than a customer,
30Write programs for people first
3 Build software so that it needs a short user manual
11Establish a software process that provides flexibility
21 Quality is the top priority; long term productivity is a natu-
ral consequence of high quality
28Use better and fewer people
6 Design for maintenance
33Choose a programming language to ensure maintainab i lity
32Select tests based on the likelihood that they wil l find faults
23 Since change is inherent to software, plan for it and manage
it
34 In the face of unstructured code, rethink the module and redesign it
from scratch.
24 Since tradeoffs are inherent to software engineering, make
them explicit and document them
27 To improve design, study previous solutions to similar
problems

Software Engineering Principles: Do They Meet Engineering Criteria? 981
criteria from Vincenti and the joint IEEE & ACM soft-
ware engineering curriculum to identify the 9 candidate
principles that conform to these engineering criteria;
however, this list of criteria is not necessarily exhaustive,
and more criteria could eventually be added.
Furthermore, most of the authors who proposed these
principles did not provide operational descriptions of
their proposals, and did not provide research experimen-
tation for each principle identified.
8. Conclusions
Software engineering, as a discipline, is certainly not yet
as mature as other engineering disciplines, and, while a
number of autho rs ha v e proposed over 300 distinct FPs, a
consensus on a set of well-recognized FPs has been
lacking. This research report has taken as input, or as its
object of study, the set of 34 statements identified in [19]
as candidate FPs of software engineering. This set has
been analyzed from an engineering perspective using the
engineering criteria identified by either Vincenti or the
IEEE-ACM joint effort on developing a software engi-
neering curriculum.
The 34 candidate FPs were divided into three catego-
ries: A) candidate FPs that are directly linked to engi-
neering, B) candidate FPs that are indirectly linked to
engineering, and C) candidate FPs with no specific link
to engineering.
In the next step, the candidate FPs that were generic
were distinguished from the more specific ones: this dis-
tinction was based on the type of mapping (direct or in-
direct). In the final step, candidate FPs from both lists
were analyzed and compared. Our proposed reduced list
of 9 software engineering principles now needs to be
further discussed by the software engineering commu-
nity.
Of course, this list depends on the methodology used,
and is being proposed to the engineering community for
discussion and scrutiny with the aim of improving it and
developing a consensus over time.
There is no claim that this list is exhaustive or that it
covers the whole software engineering discipline. Even
though the inputs to this analysis were derived from an
extensive literature survey, this does not guarantee that
those authors have indeed provided full coverage of the
software engineering discipline.
Similarly, the hierarchy propo sed in Ta ble 6 is derived
from the engineering criteria in our analytical approach.
Further research should be carried out to verify the com-
pleteness of the criteria used.
REFERENCES
[1] IEEE Std 610.12, IEEE Standard Glossary of Software
Engineering Terminology. Corrected Edition, February
1991.
[2] K. E. Wiegers, “Creating a Software Engineering Cul-
ture,” Dorset House Publishing, New York, USA, 1996.
[3] N. Séguin, “Inventaire, Analyse et Consolidation des
Principes Fondamentaux du Génie Logiciel,” École de
technologie supérieure, Université du Québec, Québec,
Canada, 2006.
[4] P. Bourque, R. Dupuis, A. Abran, J. W. Moore, L. Tripp
and S. Wolff, “Fundamental Principles of Software Engi-
neering–A Journey,” Journal of Systems and Software,
Vol. 62, No. 1, 2002, pp. 59-70.
[5] Jabir and J. W. Moore, “A Search For Fundamental Prin-
ciples of Software Engineering,” Report of a Workshop
Conducted at the Forum on Software Engineering Stan-
dards Issues, Computer Standards & Interfaces–In- terna-
tional Journal on the Development and Application of
Standards for Computers, Data Communications and In-
terfaces, Elsevier, Amsterdam, North Holland (the par-
ticipants at this workshop names their group “Jabir”), Vol.
19, No. 2, 1998, pp. 155-160.
[6] B. W Boehm, “Seven Basic Principles of Software Engi-
neering,” Journal of Systems and Software, Vol. 3, No. 1,
1983, pp. 3-24.
[7] A. M. Davis, “201 Principles of Software Development,”
McGraw-Hill, New York, USA, 1995.
[8] K. E. Wiegers, “Creating a Software Engineering Cul-
ture,” Dorset House Publishing, New York, 1996.
[9] P. Bourque and R. Dupuis, “Fundamental Principles of
Software Engineering,” Third International Symposium
and Forum on Software Engineering Standards, Walnut
Creek, CA, USA, 1997.
[10] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad,
and M. Stal, “Pattern Oriented Software Architecture,”
John Wiley & Sons, England, 1996.
[11] C. Ghezzi, M. Jazayeri and D. Mandrioli, “Fundamentals
of Software Engineering,” Prentice Hall, New Jersey,
2003.
[12] P. Bourque and R. Dupuis, “Fundamental Principles of
Software Engineering,” 3rd International Symposium and
Forum on Software Engineering Standards, Walnut
Creek, CA, 1997.
[13] A. Abran, N. Seguin, P. Bourque and R. Dupuis, “The
Search for Software Engineering Principles: An Overview
of Results,” Conference on the Principles of Software
Engineering, Buenos Aires, Argentina, 2004.
[14] N. Séguin and A. Abran, “Inventaire des principes du
génie logiciel,” Revue Génie Logiciel, Numéro 80, Paris,
France, 2007, pp. 45-51.
[15] W. G. Vincenti, “What Engineers Know and How They
Know It—Analytical Studies from Aeronautical History,”
Johns Hopkins University, Baltimore, MD, USA, and
London, UK, 1990.
[16] IEEE and ACM, “IEEE Computer Society and Associa-
tion for Computing Machinery,” Curriculum Guidelines
for Undergraduate Degree Programs in Software Engi-

Software Engineering Principles: Do They Meet Engineering Criteria? 982
neering, A Volume of the Computing Curricula Series,
2004.
[17] A. Abran, J. W. Moore, P. Bourque and R. Dupuis,
“Guide to the Software Engineering Body of Knowl-
edge,” 4th Edition, In: P. Bourque and R. Dupuis, Eds.,
IEEE Computer Society, Los Alamitos, CA, USA, 2005.
[18] A. Abran and K. Meridji, “Analysis of Software Engi-
neering from an Engineering Perspective,” European
Journal for the Informatics Professional, Vol. 7, No. 1,
February 2006, pp. 46-52.
[19] SO-TR-19759, “Software Engineering—Guide to the
Software Engineering Body of Knowledge (SWEBOK),”
International Organization for Standardization, Switzer-
land, 2005.