| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 7.1 | Perhaps it's instinctual | ULTRA::KINDEL | Bill Kindel | Mon Apr 27 1987 14:54 | 14 |
| The fatal flaw in the Honeywell application of the Quality process
("conformance to requirements") was that there was not an assurance
that the requirements were subject to the same standard. Instead,
a VP would indicate that the requirement was a "perfect" product
by an arbitrary date.
My experience here at Digital is that (a) the ultimate goal of the
product (at least the one on which I'm working) is better-defined, and
(b) development is done as a series of smallish steps headed toward
that goal rather than one giant leap from nothing to code freeze. I've
had to learn a few new disciplines in making estimates for the small
steps, but there's little debate about the requirements with such an
approach. Without referring to Deming, the important most part of the
quality process is already in place.
|
| 7.2 | some background | EXODUS::KRISHNASWAMY | | Mon Apr 27 1987 17:12 | 31 |
| I do not know enough about the "Quality Process" in Digital to comment
or compare. But I was involved with the Honeywell process enough
to understand its strenghts and weaknesses.
Just a note on where it came from...
A gentleman named Crosby once (in the 70s) ran a QA department in
a major DoD outfit (Lockheed, I believe) and instituted a "Zero
Defect Program". He later left the company and went on to fame and
fortune running a Quality College in Florida which sells and teaches
his 14-step Quality Process. Some noteworthy Fortune 500 companies
are its clients, like Dupont, IBM, etc., I believe even DEC people
have shown up at some of the classes. It is difficult to tell because
I do not think DEC made the committment at the *Corporate* level.
Whatever reservations one had about the definition, one had to see
it applied by *believers* to realize how well it can work. It can
be applied at every level of the organization,in fact that is one
of the messages we did try to get across in ASD in Middlesex Turnpike.
In other words, to corrupt what Bill Kindel said, it could be applied
in little steps.
The greatest values to me in the process were the identification
of customer-vendor relationships and measurable goals that could
be used to improve "quality". The problem with the "quality" of
the product requirements themselves was recognized, and was being
slowly worked on at least in ASD.
Too bad it died of apathy.
|
| 7.3 | "Schedule" as a Requirement | DELNI::JONG | Steve Jong/NaC Pubs | Tue Apr 28 1987 10:45 | 9 |
| On the last major project I worked on, "meeting FCS" was one of
the requirements. We screamed at that every chance we got, but it
was never changed. Of course, as time went on and schedules got
tight, it turned out (surprise!) that schedule was the first
requirement among equals, and functions were dropped to meet the
schedule.
They didn't take the time to do it right the first time -- or they
didn't feel they HAD the time. Very sad.
|
| 7.4 | -<Schedule>- | TIGGER::AMUISE | | Tue Apr 28 1987 11:03 | 6 |
| -<"Schedule" as the prime requirement>-
I really must agree about the schedule business. I saw it in my
relations with my last project.
Al Muise
|
| 7.5 | schedule vs. functionality | EXODUS::KRISHNASWAMY | | Tue Apr 28 1987 11:14 | 13 |
| Re .3 and .4
"Meeting Schedule" was always a problem. We approached it where
I worked by saying that schedule or to put it another way "time
to market"WAS also an important requirement and must be negotiated
with care up front. Then if schedule slips, the either the "vendors"
did not do a "quality job" OR there might be new circumstances that
warrented either a new schedule or dropped functionality. But I
agree it was never easy.
Oh, by the way "do it right the first time" was a lot harder than
it sounds due to built-in "bad habits" so we started using the phrase
"do it better every time"
|