NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/software/5061

Text File | 1992-12-20 | 7.1 KB | 144 lines

Newsgroups: comp.software-eng
Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!spool.mu.edu!umn.edu!csus.edu!netcom.com!mcgregor
From: [e-mail] (Scott Mcgregor)
Subject: Re: SWIFT/FURPS
Message-ID: <[e-mail]>
Keywords: SWIFT FURPS
Organization: Netcom - Online Communication Services (408 241-9760 guest)
References: <david.724561188@hawk>
Date: Fri, 18 Dec 1992 08:31:34 GMT
Lines: 132

In article <david.724561188@hawk> [e-mail] (David Hatley) writes:
>While reading the discussion on the SEI model I have noticed several
>references to SWIFT and FURPS. As I am currently looking at having an
>SEI assessment done on our company I would like some information on these
>and how they relate to the SEI model.

FURPS modelling, to the best of my knowledge evolved at
Hewlett-Packard Co. though I can't find anywhere in my record who the
principal developer of this model was.  The earliest usage that I can
find comes from groups headed by Bob Grady (still at HP)  and Chuck
House (now at Informix).  They might be able to provide more complete
history. FURPS stands for Functionality, Usability, Reliability,
Performance, and Supportability.  The first principle of the FURPS
model is that the requirements specs should describe the minimal
acceptance criteria on ALL of these dimensions (later other dimensions
were added and the model got different names: FLURPS, FLURPSL,
FURPS+... but I won't go into that here).  The point is that you don't
just want to specify the functionality and meet that requirement but
the product fails because the functionality is unusable, or unreliable
or too slow, etc.   So you need to be specific about what is required
in those dimensions as well.

The second principle of the FURPS model (as it was practiced when I
was at HP which was up to 1990) is that you should take those
requirements and turn them from a binary characteristic to a
continuum, with various intermediate points.  This continuum is then
mapped to some sort of ad hoc metric so that you can assign a number,
say from 1-5 to performance vs. the specification.  Then you set
target numbers for each dimension and manage the project by comparing
the actual metric evaluations on each dimension with the goal.  This
is often done with the use of "Radar" charts, multi-dimensional planar
polar graphs with the 5 (or more) dimensions of FURPS measures
radiating out from a central origin.

FURPS is therefore a technique for improving requirements definitions,
and for measuring them. Its relation to the SEI CMM is that you need
to have a standard means to requirements definitions to be a
defined process. The first principle addresses this issue, though it
is not the only way , and the SEI CMM doesn't specify a particular
method.  Also, you need to be able to measure performance
against targets to have a managed process, and the second principle
addresses this issue.

The origin of SWIFT, I can talk with a bit more certainty, as I
personally developed it.  This was also developed originally at HP,
though I have done substantial refinements to it over the last three
years since I left HP. SWIFT is a method for

a) developing requirements specifications, designs, implementations,
    and tests to ensure product desirability, usability and
    profitability. And,
b) for managing development from requirements capture through product
    ship and ongoing support and maintenance, taking into
    consideration not only technical/engineering success criteria,
    but also business success factors across functional areas,
    such as impact of product design on sales cycle, project cost,
    sales channel requirements, etc.

I must apologize that remarkably little is written about it. There
have been some comments about it's use in particular projects in some
HP internal magazines (e.g. the now defunct COMMENT) at various
workshops (such as the Groupware '88 Workshop associated wiht the
World Computer Congress) and most recently some an overview in Marc
Rettig's Practical Programmer column in the May 1992 Communications of
the ACM. This is because I have been primarily using this method for
many years to produce products rather than expend effort teaching it
to others.  In the past three years, due to an increase interest by
others, and some opportunities to share it with others, I have begun
to work on getting more information out to the public on this method.

The most notable aspect of SWIFT is its focus on getting concrete
product specifications in  terms of actual PROBLEM ORIENTED TASK
SCENARIOS. Typically we use "screenplays" as part of the requirements
specification and "storyboards" as part of the design specifications.
These scenarios also become the basis for both acceptance and
usability testing. (Given the sample problem can a novice users
correctly proceed through the screenplay even though they have never
read it?)

The most notable product to have been developed using SWIFT in the
recent past is Merge Ahead, which received a cover notice in the May
1992 Sun World.

The primary method spreading the SWIFT method at this time is via
consulting and contract training or seminars I offer. I also expect to
offer some courses through University of California at Berkeley later
this year to introduce people to SWIFT as part of an extension
certificate in software engineering program. I'm working on the class
design right now; comments are welcome. I am also working on a book on this
topic for O'Reilley & Associates. We are working on the contents of
this book right now, and welcome suggestions (send comments to:
[e-mail], [e-mail], [e-mail]).

The relationship between SWIFT and SEI CMM is complementary.  As I
have tried to explain elsewhere in this news group, SEI CMM is
primarily focussed on ensuring that "given a good requirements
specification, produce that as predictably and reliably as possible).
In short hand, SEI CMM is a focus on DOING THINGS RIGHT. SWIFT
focusses on ensuring the antecedent, namely that what you build will
be desirable to the marketplace. In other words, SWIFT focusses on
ensuring that you are DOING THE RIGHT THINGS.

Companies benefit from doing both, though the former (addressed by SEI
CMM) is often more crucial in contract software firms, while the
latter  is often the critical success factor for "shrink-wrap" or
"product" software firms.  Contract firms were much more prevalent in the
50s-70s (and still are in Government and Military markets as well as
in Japan).  But since the mid 80s, due largely to the PC, Unix and
open systems the product oriented companies have become a greater
and greater proportion of the U.S. software market. Internal software
projects are also moving from more of a contract model to more of a
product model.  This is part of what I think is leading to the growth
of a greater interest in methods like FURPS, SWIFT, and the increased
interest in design for usability noted by Rob Kling and others.





--

Scott L. McGregor        [e-mail]
President            tel: [phone]
Prescient Software, Inc.    fax: [phone]
3494 Yuba Avenue
San Jose, CA 95117-2967

Prescient Software sells Merge Ahead, the tool for Merging Text or Code and
offers consulting  & training in project management and design for usability.