RE: [scrumdevelopment] IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.
As a reviewer of SWEBOK this is a problem in a larger context. SWEBOK is
an academic framework for the teaching of Software Engineering. The
first thought is that XP and agile method are transitory in the
engineering world. Meaning they are the "current" methods and describing
them in a "body of knowledge" is risky. Not because of their value to
the software world but because they are too far down in the food chain.
It would belike teaching GIS methods for waste water remediation in an
environmental engineering Body of Knowledge - critically important but
only so once you reach the field.
On the other hand agile methods have become recognizable in the broader
community and they need to be addressed somewhere besides the forums and
trade rags. I haven't received the review package yet (June is the plan)
so I'll make my meager effort to ask the power that be - "why not
mention agile methods."
BTW the SWEBOK is a normative standard and as such does not address the
participative and heuristic approaches to methodologies.
Glen B. Alleman
VP, Program Management Offfice
Rocky Flast Environmental Technology Site
From: Mike Cohn [mailto:mike@...]
Sent: Friday, May 30, 2003 1:33 PM
Subject: [scrumdevelopment] 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
additional reviewers. Since they don't even mention XP, Agile, Scrum,
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
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
of Knowledge (SWEBOK) scheduled for year-end. The three review cycles
leading to the publication of the Trial Version in May 2001 (version
were based on expert opinions. Now that the Trial Version of the Guide
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
by the Board of Governors of the IEEE Computer Society and is undergoing
the final steps for publication as a Technical Report by the
Organization for Standardization (ISO TR 19759). The Guide to the
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
Standards and Technology, the National Research Council of Canada,
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
comments. Each individual reviewer comment, the identity of the
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
the study material for a software engineering licensing examination that
graduates would take after gaining four years of work experience.
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
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
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
imprecise ones. All reviewers will be recognized by having their name
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
For further information, please contact Pierre
(1) Project Management Institute, A Guide to the Project Management Body
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>
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
Your use of Yahoo! Groups is subject to
- -----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