Software Sizing and Estimation Body of Knowledge
Open (working) issues:
• Sponsorship
• Advisory panel
• Editors
• Reviewers
• Materials list
• Content
o Knowledge Areas (KA)
o
• Schedule/timelines
o Guide
o Sponsors
o Contributors
o Certification
o Courses
o Examinations
Certified Software Estimation Professional (CSEP)
The CSEP credential is intended for mid-career software development professionals that want to
confirm their proficiency of standard software sizing and estimation practices and advance in their
careers.
Who is eligible to take the CSDP?
If you are a Senior Member of IEEE or a Licensed Software Engineer, no further qualifications are
necessary. All other candidates are required to meet both Education and Experience requirements as
outlined below.
Education: (need at least one)
• You have a bachelor's degree
• You are a CSDA certificate holder
• You are an educator at the post-baccalaureate level
• You are a full member of the IEEE
Experience: (need at least one)
• You have an advanced degree in software engineering and at least two years (about 3,500
hours) of experience in software engineering/development
• You have at least four years (about 7,000 hrs) experience in software
engineering/development
Professionals
• Confirms your proficiency of established software sizing and estimation practices
• Demonstrates your commitment to expanding your knowledge and increasing responsibilities
• Differentiates you with a credential developed by, and for, software engineering professionals
Employers
• Standardize your software sizing and estimation practices
• Protect your investment in a competent and proficient workforce
• Gives you independent assurance that employees can perform on real-world projects
CSDP Assessment Course Outline
Module 1: Software Requirements
Requirements Process
Requirements Elicitation
Requirements Analysis
Requirements Specification
Practical Considerations
Module 2: Software Design
Design Fundamentals
Key Design Issues
Software Structure and Architecture
Design Quality Analysis and Evaluation
Design Notations, Strategies and Methods
Module 3: Software Construction and Methods
Construction Fundamentals
Managing Construction
Practical Considerations
Construction Technologies
Construction Tools Software Modeling
Types of Models
Analysis
Development Methods
Module 4: Software Testing
Software Testing Fundamentals
Test Levels
Test Techniques
Human-Computer Interface (HCI)
Test-Related Measures
Test Process
Module 5: Software Maintenance and Configuration Management
Software Maintenance Fundamentals
Key Issues in Software Maintenance
Maintenance Process
Techniques for Maintenance
Management of the Configuration Process
Software Configuration Identification
Software Configuration Control
Software Configuration Status Accounting
Software Release Management and Delivery
Software Configuration Management Tools
Module 6: Software Engineering Management, Professional Practices and Economics
Initiation and Scope Definition
Software Project Planning
Software Project Enactment
Review and Evaluation
Software Engineering Measurement
Software Management Tools
Professionalism
Code of Ethics
Group Dynamics and Psychology
Communication Skills
Economic Fundamentals
Not-for-Profit Decision-Making
Present Economy
Estimation, Risk and Uncertainty
Multiple Attribute Decisions
Module 7: Software Engineering Process and Quality
Process Implementation and Change
Process Definition
Process Assessment
Measurement
Software Process Tools
Software Quality Fundamentals
Software Quality Management Process
Software Quality Practical Considerations
Module 8: Foundations
Computing Foundations
Mathematical Foundations
Engineering Foundations
PREFACE
Software engineering is an emerging discipline and there are unmistakable trends indicating an increasing
level of maturity:
• Several universities throughout the world offer undergraduate degrees in software engineering. For
example, such degrees are offered at the University of New South Wales (Australia), McMaster University
(Canada), the Rochester Institute of Technology (US), the University of Sheffield (UK), and other
universities.
• In the US, the Engineering Accreditation Commission of the Accreditation Board for Engineering and
Technology (ABET) is responsible for the accreditation of undergraduate software engineering programs.
• The Canadian Information Processing Society has published criteria to accredit software engineering
undergraduate university programs.
• The Software Engineering Institute's Capability Maturity Model for Software (SW CMM) and the new
Capability Maturity Model Integration (CMMI) are used to assess organizational capability for software
engineering. The famous ISO 9000 quality management standards have been applied to software
engineering by the new ISO/IEC 90003.
• The Texas Board of Professional Engineers has begun to license professional software engineers.
• The Association of Professional Engineers and Geoscientists of British Columbia (APEGBC) has begun
registering software professional engineers, and the Professional Engineers of Ontario (PEO) has also
announced requirements for licensing.
• The Association for Computing Machinery (ACM) and the Computer Society of the Institute of Electrical
and Electronics Engineers (IEEE) have jointly developed and adopted a Code of Ethics and Professional
Practice for software engineering professionals.1
• The IEEE Computer Society offers the Certified Software Development Professional certification for
software engineering. The Institute for Certification of Computing Professionals (ICCP) has long offered a
certification for computing professionals.
All of these efforts are based upon the presumption that there is a Body of Knowledge that should be
mastered by practicing software engineers. The Body of Knowledge exists in the literature that has
accumulated over the past thirty years. This book provides a Guide to that Body of Knowledge.
PURPOSE
The purpose of the Guide to the Software Engineering Body of Knowledge is to provide a consensually
validated characterization of the bounds of the software engineering discipline and to provide a topical
access to the Body of Knowledge supporting that discipline. The Body of Knowledge is subdivided into ten
software engineering Knowledge Areas (KA) plus an additional chapter providing an overview of the KAs of
strongly related disciplines. The descriptions of the KAs are designed to discriminate among the various
important concepts, permitting readers to find their way quickly to subjects of interest. Upon finding a
subject, readers are referred to key papers or book chapters selected because they succinctly present the
knowledge.
In browsing the Guide, readers will note that the content is markedly different from computer science. Just
as electrical engineering is based upon the science of physics, software engineering should be based, among
other things, upon computer science. In these two cases, though, the emphasis is necessarily different.
Scientists extend our knowledge of the laws of nature while engineers apply those laws of nature to build
useful artifacts, under a number of constraints. Therefore, the emphasis of the Guide is placed on the
construction of useful software artifacts.
Readers will also notice that many important aspects of information technology that may constitute
important software engineering knowledge are not covered in the Guide, including specific programming
languages, relational databases, and networks. This is a consequence of an engineering-based approach. In
all fields - not only computing - the designers of engineering curricula have realized that specific
technologies are replaced much more rapidly than the engineering work force. An engineer must be
equipped with the essential knowledge that supports the selection of the appropriate technology at the
appropriate time in the appropriate circumstance. For example, software might be built in Fortran using
functional decomposition or in C++ using objectoriented techniques. The techniques for software configuring
instances of those systems would be quite different. But, the principles and objectives of configuration
management remain the same. The Guide therefore does not focus on the rapidly changing technologies,
although their general principles are described in relevant KAs.
These exclusions demonstrate that this Guide is necessarily incomplete. The Guide covers software
engineering knowledge that is necessary but not sufficient for a software engineer. Practicing software
engineers will need to know many things about computer science, project management, and systems
engineering - to name a few - that fall outside the Body of Knowledge characterized by this Guide. However,
stating that this information should be known by software engineers is not the same as stating that this
knowledge falls within the bounds of the software engineering discipline. Instead, it should be stated that
software engineers need to know some things taken from other disciplines - and that is the approach
adopted in this Guide. So, this Guide characterizes the Body of Knowledge falling within the scope of
software engineering and provides references to relevant information from other disciplines. A chapter of the
Guide provides a taxonomical overview of the related disciplines derived from authoritative sources.
The emphasis on engineering practice leads the Guide toward a strong relationship with the normative
literature. Most of the computer science, information technology, and software engineering literature
provides information useful to software engineers, but a relatively small portion is normative. A normative
document prescribes what an engineer should do in a specified situation rather than providing information
that might be helpful. The normative literature is validated by consensus formed among practitioners and is
concentrated in standards and related documents. From the beginning, the SWEBOK project was conceived
as having a strong relationship to the normative literature of software engineering. The two major standards
bodies for software engineering (IEEE Computer Society Software Engineering Standards Committee and
ISO/IEC JTC1/SC7) are represented in the project. Ultimately, we hope that software engineering practice
standards will contain principles directly traceable to the Guide.
INTENDED AUDIENCE
The Guide is oriented toward a variety of audiences, all over the world. It aims to serve public and private
organizations in need of a consistent view of software engineering for defining education and training
requirements, classifying jobs, developing performance evaluation policies, or specifying software
development tasks. It also addresses practicing, or managing, software engineers and the officials
responsible for making public policy regarding licensing and professional guidelines. In addition, professional
societies and educators defining the certification rules, accreditation policies for university curricula, and
guidelines for professional practice will benefit from SWEBOK, as well as the students learning the software
engineering profession and educators and trainers engaged in defining curricula and course content.
EVOLUTION OF THE GUIDE
From 1993 to 2000, the IEEE Computer Society and the Association for Computing Machinery (ACM)
cooperated in promoting the professionalization of software engineering through their joint Software
Engineering Coordinating Committee (SWECC). The Code of Ethics was completed under stewardship of the
SWECC primarily through volunteer efforts. The SWEBOK project was initiated by the SWECC in 1998.
The SWEBOK project's scope, the variety of communities involved, and the need for broad participation
suggested a need for full-time rather than volunteer management. For this purpose, the IEEE Computer
Society contracted the Software Engineering Management Research Laboratory at the Université du
Québec à Montréal (UQAM) to manage the effort. In recent years, UQAM has been joined by the �cole
de technologie supérieure, Montréal, Québec.
The project plan comprised three successive phases: Strawman, Stoneman, and Ironman. An early
prototype, Strawman, demonstrated how the project might be organized. The publication of the widely
circulated Trial Version of the Guide in 2001 marked the end of the Stoneman phase of the project and
initiated a period of trial usage. The current Guide marks the end of the Ironman period by providing a
Guide that has achieved consensus through broad review and trial application.
The project team developed two important principles for guiding the project: transparency and consensus.
By transparency, we mean that the development process is itself documented, published, and publicized so
that important decisions and status are visible to all concerned parties. By consensus, we mean that the
only practical method for legitimizing a statement of this kind is through broad participation and agreement
by all significant sectors of the relevant community. Literally hundreds of contributors, reviewers, and trial
users have played a part in producing the current document.
Like any software project, the SWEBOK project has many stakeholders - some of which are formally
represented. An Industrial Advisory Board, composed of representatives from industry (Boeing, Construx
Software, the MITRE Corporation, Rational Software, Raytheon Systems, and SAP Labs-Canada), research
agencies (National Institute of Standards and Technology, National Research Council of Canada), the
Canadian Council of Professional Engineers, and the IEEE Computer Society, has provided financial support
for the project. The IAB's generous support permits us to make the products of the SWEBOK project publicly
available without any charge (see http://www.swebok.org). IAB membership is supplemented with the
chairs of ISO/IEC JTC1/SC7 and the related Computing Curricula 2001 initiative. The IAB reviews and
approves the project plans, oversees consensus building and review processes, promotes the project, and
lends credibility to the effort. In general, it ensures the relevance of the effort to real-world needs.
The Trial Version of the Guide was the product of extensive review and comment. In three public review
cycles, a total of roughly 500 reviewers from 42 countries provided roughly 9,000 comments, all of which
are available at www.swebok.org. To produce the current version, we released the Trial Version for
extensive trial usage. Trial application in specialized studies resulted in 17 papers describing good aspects of
the Guide, as well as aspects needing improvement. A Web-based survey captured additional experience:
573 individuals from 55 countries registered for the survey; 124 reviewers from 21 countries actually
provided comments - 1,020 of them. Additional suggestions for improvement resulted from liaison with
related organizations and efforts: IEEE-CS/ACM Computing Curricula Software Engineering; the IEEE CS
Certified Software Development Professional project; ISO/IEC JTC1/SC7 (software and systems engineering
standards); the IEEE Software Engineering Standards Committee; the American Society for Quality,
Software Division; and an engineering professional society, the Canadian Council of Professional Engineers.
CHANGES SINCE THE TRIAL VERSION
The overall goal of the current revision was to improve the readability, consistency, and usability of the
Guide. This implied a general rewrite of the entire text to make the style consistent throughout the
document. In several cases, the topical breakdown of the KA was rearranged to make it more usable, but we
were careful to include the same information that was approved by the earlier consensus process. We
updated the reference list so that it would be easier to obtain the references.
Trial usage resulted in the recommendation that three KAs should be rewritten. Practitioners remarked that
the Construction KA was difficult to apply in a practical context. The Management KA was perceived as being
too close to general management and not sufficiently specific to software engineering concerns. The Quality
KA was viewed as an uncomfortable mix of process quality and product quality; it was revised to emphasize
the latter.
Finally, some KAs were revised to remove material duplicating that of other KAs.
LIMITATIONS
Even though the Guide has gone through an elaborate development and review process, the following
limitations of this process must be recognized and stated:
• Software engineering continues to be infused with new technology and new practices. Acceptance of new
techniques grows and older techniques are discarded. The topics listed as "generally accepted" in this
Guide are carefully selected at this time. Inevitably, though, the selection will need to evolve.
• The amount of literature that has been published on software engineering is considerable and the
reference material included in this Guide should not be seen as a definitive selection but rather as a
reasonable selection. Obviously, there are other excellent authors and excellent references than those
included in the Guide. In the case of the Guide, references were selected because they are written in
English, readily available, recent, and easily readable, and - taken as a group - they provide coverage of
the topics within the KA.
• Important and highly relevant reference material written in languages other than English have been
omitted from the selected reference material.
Additionally, one must consider that
• Software engineering is an emerging discipline. This is especially true if you compare it to certain more
established engineering disciplines. This means notably that the boundaries between the KAs of software
engineering and between software engineering and its related disciplines remain a matter for continued
evolution.
The contents of this Guide must therefore be viewed as an "informed and reasonable" characterization of the
software engineering Body of Knowledge and as baseline for future evolution. Additionally, please note that
the Guide is not attempting nor does it claim to replace or amend in any way laws, rules, and procedures
that have been defined by official public policy makers around the world regarding the practice and definition
of engineering and software engineering in particular.
