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

REVIEW: "Achieving Software Quality Through Teamwork", Isabel Evans

Expand Messages
  • Rob, grandpa of Ryan, Trevor, Devon & Ha
    BKASWQTT.RVW 20040622 Achieving Software Quality Through Teamwork , Isabel Evans, 2004, 1-58053-662-X, U$79.00/C$114.95 %A Isabel Evans %C 685 Canton
    Message 1 of 1 , Jul 15, 2004
    • 0 Attachment
      BKASWQTT.RVW 20040622

      "Achieving Software Quality Through Teamwork", Isabel Evans, 2004,
      1-58053-662-X, U$79.00/C$114.95
      %A Isabel Evans
      %C 685 Canton St., Norwood, MA 02062
      %D 2004
      %G 1-58053-662-X
      %I Artech House/Horizon
      %O U$79.00 617-769-9750 fax: 617-769-6334 artech@...
      %O http://www.amazon.com/exec/obidos/ASIN/158053662X/robsladesinterne
      %O http://www.amazon.ca/exec/obidos/ASIN/158053662X/robsladesin03-20
      %P 294 p.
      %T "Achieving Software Quality Through Teamwork"

      The preface notes that software is produced by people, and usually
      teams of people. The author proposes that understanding people, and
      teams, should help make better software.

      Chapter one attempts to point out that quality depends upon
      perception, but doesn't do a really clear job of it. Four definitions
      of quality are presented: product (specifications), manufacturing
      (development process), user (fitness for use: the most subjective),
      and value (related to return on investment). The European Foundation
      for Quality Management (EFQM) model is introduced as the basis for the
      book (which appears to concentrate on the user and value definitions).
      Different groups of people, and the different ways of viewing quality,
      are outlined in chapter two, but the interactions and implications are
      not apparent. One set of divisions; between customers, managers,
      builders, measurers, and supporters; is used to structure the next
      five chapters.

      Chapter three looks at various types, factors, and needs of customers,
      but gives little that would be of help in the development process.
      Managers fare slightly better in chapter four: one specific
      communications tool or exercise is listed. Builders are defined, in
      chapter five, by a litany of complaints that programmers have about
      others. Oddly, responsibility for communications is laid at the feet
      of the coders, but no means of improvement is provided for them. The
      role of measurers, in chapter six, is again described primarily in
      terms of problems, with few solutions discussed. Chapter seven uses
      lots of words in dealing with supporters, but says little of

      Chapter eight describes the life cycle of systems, collapsing
      requirements, design, and implementation into a small development
      block, and emphasizing delivery and post-delivery. Start-up has some
      brief ideas on concepts and initiation, and then gets into contracts.
      The software development life cycle (which, since it is only referred
      to as SDLC, is hard to keep separate from the "system" cycle) provides
      a terse outline of some project management methods. A few aspects of
      delivery and acceptance are reviewed in chapter eleven. The post-
      delivery material, in chapter twelve, is confused and confusing, but
      eventually talks about maintenance.

      Overall, the book has numerous points worth considering in the
      development process. Some may help when dealing with requirements and
      design, which may assist with the user and value definitions of
      quality. Very little of the content is applicable to the product or
      manufacturing aspects noted at the beginning. In addition, the
      particulars are buried in a great deal of superfluous verbiage, and
      little is of direct and practical use. For example, communications is
      frequently noted as a problem, and appendix A lists a variety of
      communications techniques, but there is very little discussion as to
      how to use these methods.

      It is very difficult to identify an audience that would benefit from
      this work.

      copyright Robert M. Slade, 2004 BKASWQTT.RVW 20040622

      ====================== (quote inserted randomly by Pegasus Mailer)
      rslade@... slade@... rslade@...
      Absurdiveness Training: Don't get even, get odd.
      http://victoria.tc.ca/techrev or http://sun.soci.niu.edu/~rslade
    Your message has been successfully submitted and would be delivered to recipients shortly.