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

RE: [scrumdevelopment] IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.

Expand Messages
  • Alleman, Glen B.
    Mike, 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
    Message 1 of 37 , Jun 3, 2003
    • 0 Attachment
      Mike,

      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
      CH2M HILL
      Rocky Flast Environmental Technology Site
      303.966.5865 Office
      303.994.0874 Cell
      glen.alleman@...
      glen.alleman@...

      -----Original Message-----
      From: Mike Cohn [mailto:mike@...]
      Sent: Friday, May 30, 2003 1:33 PM
      To: extremeprogramming@yahoogroups.com;
      scrumdevelopment@yahoogroups.com; xpdenver@yahoogroups.com
      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
      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
      SWEBOK.

      --Mike


      -----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
      approach.

      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
      www.swebok.org.

      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
      Professeur/Professor
      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
      pbourque@...
      Home page available via / Page Personnelle disponible via
      http://www.lrgl.uqam.ca/team/membres.html

      Co-editor
      Guide to the Software Engineering
      Body of Knowledge
      http://www.swebok.org


      ============================================================
      To contribute to SEWORLD, send your submission to
      <seworld@...>.

      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>
      end

      To unsubscribe from SEWORLD, send the following (as the body
      of a message) to <seworld-unsubscribe@...>:

      unsubscribe seworld <registered e-mail address>
      end
      ============================================================




      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...

      Your use of Yahoo! Groups is subject to
      http://docs.yahoo.com/info/terms/
    • 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, 2003
      • 0 Attachment
        -----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.