Loading ...
Sorry, an error occurred while loading the content.

IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.

Expand Messages
  • Mike Cohn
    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
    Message 1 of 37 , May 30, 2003
      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


      -----Original Message-----
      From: seworld-owner@... [mailto:seworld-owner@...]
      On Behalf Of Pierre Bourque
      Sent: Thursday, May 29, 2003 11:35 AM
      To: SEWORLD@...
      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
      trial usage.

      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
      Bourque (pbourque@...)

      (1) Project Management Institute, A Guide to the Project Management Body of
      Knowledge, see www.pmi.org

      Pierre Bourque
      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>
    • Mike Beedle
      ... From: Fabian Ritzmann [mailto:usefri@gmx.net] ... Oh, I don t know -- we are still sort of on topic. ... We call tests by the user acceptance tests or
      Message 37 of 37 , Jun 6 9:29 AM
        -----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:
        > 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.

        We call tests by the user "acceptance tests" or ATs.

        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.

        self wrote:
        > The combination is very powerful:
        > * 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,

        Fabian wrote:
        >The principle problem is that provable (and executable)
        >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.

        True. In our view, the need for acceptance tests
        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
        3 things,

        - Mike
      Your message has been successfully submitted and would be delivered to recipients shortly.