IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.
- The IEEE SWEBOK is currently under public review and they are looking for
additional reviewers. Since they don't even mention XP, Agile, Scrum, etc.,
it would seem that they could use our help as reviewers. See the message
below or go to www.swebok.org to register as a reviewer or just read the
From: seworld-owner@... [mailto:seworld-owner@...]
On Behalf Of Pierre Bourque
Sent: Thursday, May 29, 2003 11:35 AM
Subject: (SEWORLD) SWEBOK Guide Call for Reviewers
Call for Reviewers
Guide to the Software Engineering Body of Knowledge (Trial Version)
Review Period: June 2, 2003 to June 30, 2003
To sign up: Please fill in the electronic form found at www.swebok.org
The purpose of this review cycle is to gather proposed changes to be
incorporated in the 2003 version of the Guide to Software Engineering Body
of Knowledge (SWEBOK) scheduled for year-end. The three review cycles
leading to the publication of the Trial Version in May 2001 (version 0.95)
were based on expert opinions. Now that the Trial Version of the Guide has
been available for two years and has been used in varying contexts for
different purposes, strong preference will be given to changes based on
The purpose of the Guide is to characterize the contents of the software
engineering discipline, to promote a consistent view of software
engineering worldwide, to clarify the place of, and set the boundary of,
software engineering with respect to other disciplines, and to provide a
foundation for curriculum development and individual licensing material.
All deliverables are available without any charge at www.swebok.org .
The Trial Version of the SWEBOK Guide was endorsed in 2001 for trial usage
by the Board of Governors of the IEEE Computer Society and is undergoing
the final steps for publication as a Technical Report by the International
Organization for Standardization (ISO TR 19759). The Guide to the Software
Engineering Body of Knowledge (SWEBOK) is a project of the IEEE Computer
Society with corporate support from Boeing, the Canadian Council of
Professional Engineers, Construx Software, MITRE, the National Institute of
Standards and Technology, the National Research Council of Canada, Rational
Software, Raytheon, and SAP Labs (Canada).
Close to 500 reviewers from over 40 countries participated in the three
review cycles leading to the Trial Version providing roughly eight thousand
comments. Each individual reviewer comment, the identity of the reviewer
who provided the comment and its resolution are publicly available on
www.swebok.org. The next review cycle will be conducted with a similar
The SWEBOK Guide seeks to identify and describe the subset of software
engineering knowledge that is generally accepted. Generally accepted
knowledge applies to most projects most of the time, and widespread
consensus validates its value and effectiveness (1). A complementary
definition states that generally accepted knowledge should be included in
the study material for a software engineering licensing examination that
graduates would take after gaining four years of work experience. Although
this criterion is specific to the U.S. style of education and does not
necessarily apply to other countries, it was deemed useful. Research
topics and specialized topics are therefore out of scope.
The Trial Version is organized into 10 chapters dealing with the following
Knowledge Areas: software requirements, software design, software
construction, software testing, software maintenance, software
configuration management, software engineering management, software
engineering process, software engineering tools and methods, and software
quality. The SWEBOK Guide also includes by reference a list of related
disciplines that are important to software engineers.
Please note that adequate information to implement a recommended change
must be provided by the reviewer for it to be considered. Well described
recommended actions will be given more attention and credence than vague or
imprecise ones. All reviewers will be recognized by having their name on
the list of contributors. Reviewers will send in their proposed changes
via a Web interface. Detailed review instructions will be sent to all
signed-up reviewers on June 2.
To sign up as a reviewer, please fill in the electronic form available at
For further information, please contact Pierre
(1) Project Management Institute, A Guide to the Project Management Body of
Knowledge, see www.pmi.org
Ecole de technologie superieure
Departement de genie electrique
1100, rue Notre-Dame Ouest
Montreal (Quebec), Canada H3C 1K3
Telephone: (1) 514-396-8623
Fax : (1) 514-396-8684
Home page available via / Page Personnelle disponible via
Guide to the Software Engineering
Body of Knowledge
To contribute to SEWORLD, send your submission to
http://www.cs.colorado.edu/serl/seworld provides more
information on SEWORLD as well as a complete archive of
messages posted to the list.
To subscribe to SEWORLD, send the following (as the body of
a message) to <seworld-subscribe@...>:
subscribe seworld <desired e-mail address>
To unsubscribe from SEWORLD, send the following (as the body
of a message) to <seworld-unsubscribe@...>:
unsubscribe seworld <registered e-mail address>
- -----Original Message-----
From: Fabian Ritzmann [mailto:usefri@...]
> Need to bring this back on topic for this list. :-)Oh, I don't know -- we are still sort of on topic.
> --- Fabian Ritzmann <usefri@...> wrote:We call tests by the user "acceptance tests" or ATs.
> XP as I understand it uses unit tests and system
> tests, unit tests for unit testing and system tests for
> whatever the users want to test, including quality
> aspects like performance, reliability, etc.
I think this is a valid definition across XP and
Scrum but I don't know if other agile methods call
them the same way.
> The combination is very powerful:Fabian wrote:
> * test as _specification_ from Test-First, and
> * program as executable _specification_ from
> functional programming
> Both strategies drive development more into the
> quantifiable _what_ space, much more than worthless
> "exhaustive requirements documents" or "models".
> Perhaps, this is what we need to concentrate in
> software architecture -- in patterns that tell us
> _what_ to program and that are executable,
>The principle problem is that provable (and executable)True. In our view, the need for acceptance tests
>specifications don't help if the specification is wrong.
>And we all know that specifications always change,
>that's why we do Scrum or another Agile development
>method. Of course that shouldn't keep anybody from
>improving the way we are programming these days.
conducted through people-2-people interaction
never goes away for the exact reasons you list
(and regardless the programming styles used):
- making sure that the specification is not wrong
- making sure that we keep up with changes
for the specification
- making sure that the user experience is
comfortable i.e. timely, convenient, beautiful, etc.
It is just easier, faster and even more economical
in some paradigms of programming to do the above