| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1765.1 | | MRKTNG::VULLO | You can breathe through that? | Thu Feb 13 1992 10:30 | 43 |
| I agree COMPLETELY with the views of the anonymous author in the base note.
Standards are necessary and can definitely help in programming efficiency,
but the way DEC STD 095 and 065 are being enforced is crazy.
A few months ago I worked for a different group. During my time there,
particularly in my last year there, I tried making a huge stink about
standards. I talked to anyone who would listen. I went as far up the
management chain as I dared. I wrote memos, used ODP, and tried to get people
to act. In the end, nothing happened.
I ended up personally rewriting an entire application TWICE, just to conform
to DEC STD 065 naming conventions. We're talking about more than month's worth
of my time, and NO NEW FUNCTIONALITY was added to the application. The entire
effort was just changing field names in the programs and databases.
On another project for the same group we held up development for weeks (approx.
4 programmers X several weeks) just to conform to DEC STD 095 conventions. And
in the end, it turned out that some of the DEC STD 095 standards did not even
work due to the layered products involved. This was a complete waste of time,
and no additional value was added for the users/customers.
In trying to get management to do something, this was the analogy I used:
You are one of 18 people who work at a golf course mowing the lawns. Each of
the 18 people are responsible for one green.
The owner says: "From now on, all mowers will mow their greens in a
North/South pattern"
(I say this is a good standard, because it makes the place look good)
Then the owner says: "When you mow the grass near a tree, do it in a
circular pattern around the tree"
(I say this is another ok standard)
Now they owner says: "When you start your mowers you must place your left
hand on your head."
"When you put gas in the mower you must first place a
clothes pin on your nose"
"When you drive in to work you must drive a blue car"
I say these are analogous to DEC STD 065 and 095. Standards carried
too far. So far in fact, that you never get a chance to mow the lawn.
Vin
|
| 1765.2 | | SQM::MACDONALD | | Thu Feb 13 1992 10:31 | 11 |
|
Re: .0
There is not enough information given about the standard to be able to
answer your question about cost. For example, are details of this
standard things we should have been doing all along? Will not doing
it cost us even more in the long run? Can you shed some more light
on this.
Steve
|
| 1765.3 | | CHRCHL::GERMAIN | Improvise! Adapt! Overcome! | Thu Feb 13 1992 10:50 | 7 |
| What these standards/methods represent is the framework around which
you build quality and consistencey. They are not an end unto
themselves.
The necessary catalyst is the willingness to do it.
Gregg
|
| 1765.4 | some thoughts and feelings on the matter. | MAJORS::ALFORD | | Thu Feb 13 1992 10:50 | 79 |
|
With reference to the anonymous submission, and in addition to that submission:
European engineering subsidiaries were asked for feedback regarding DEC-Std-095.
We submitted a large amount of feedback. Much of it relating to major concerns
around the incompatibility of this standard to our existing applications and
the way the Business in Europe handles it's software.
All of this feedback was apparently ignored. The version of DEC-Std-095 that
was released was identical to the version that was submitted for feedback.
With people in the process of being "rightsized" and groups vanishing in the
cuts, it is proving very difficult to have our concerns heard. NOONE seems
to "OWN" this standard. All our contacts seem to have left or now have other
jobs, and DEC-Std-095 seems to have been one of the casualties.
DEC-Std-095 was apparently based on the USIM&T US Application Environment
Standard. Many of the requirements can be traced directly back to that
standard and echo it word for word. This standard was developed for the
US Engineering market, and may be perfect for the US way of implementing
their applications. I will say, it's not all bad and that many of the
requirements of this standard are useful and sensible, but for an European
market, not *ALL* of them
As an example. The European business prefers to install the new version of
appliction software in advance of the change over date, and migrating from the
old to the new when they are satisfied with the new version. This is often
a period of weeks, especially if the release is relatively new.
Under the European Application Environment, this is possible to do on a
single machine/cluster. Under the requirements of DEC-Std-095 this is not
possible.
Due to the requirements that under DEC-Std-095 the top directory of an
application and the logical name table may *NOT* contain the version number
[fac] and fac$LOGICAL_NAMES means that only one version of an application
may be installed on a system environment at any one time.
This has expensive consequences. Either the subsidiaries have to invest in
more hardware (in these days of cost-cutting), or they have to install and
migrate to new software in a *VERY* short window, both solutions are costly.
We have asked for approval for two very small changes to the standard to make
life for our Customers bearable - [fac999] and fac999$LOGICAL_NAMES not
much to ask for (everything else we can live with), you may think.
...BUT WHO DO YOU ASK ? who is authorized to give approval ? we can provide
$n00,000 worth of justification for the change.
It may be that the US software engineering groups have the luxury of being able
to Field Test their products for long periods of time to prove their software,
but in the field of business software where there are very short developing
windows and even shorter release windows, the best we can hope for is a couple
of weeks of "hand-holding" pilot.
We are very concerned with quality, and do our best to achieve this; but we
are also aware that with time squeezed from all angles, it is a next to
impossible job to produce truely quality, problem free, software under todays
engineering conditions; thus it makes sense to enable the field to choose to
go for parallel running of concurrent released of software, if they feel that
this will reduce the business risk; and there is a risk entailed in every
release.
I share the concerns of the anonymous noter about a standard being imposed
on existing software. I totally agree that all new software, including new
additions to existing software be affected by a current standard, but
retrograde fitting ? is this really sensible ? is it cost-effective ?
|
| 1765.5 | | SQM::MACDONALD | | Thu Feb 13 1992 10:58 | 14 |
|
I recall over a year ago seeing a proposal for standard that was being
pushed by (I've forgotten the name of the group) the internal
information systems group. It sounds like this might be one and the
same standard that I saw. I don't remember the details but remember
having concerns with some of them. My understanding was that this
standard was to refer to software that was intended to be installed on
DEC internal systems and was not intended as a development standard
for software we were building for sale.
Can anyone shed more light?
Steve
|
| 1765.6 | | MAJORS::ALFORD | | Thu Feb 13 1992 10:59 | 4 |
| Re: .5
Yes, that's the one.
|
| 1765.7 | opinion | SGOUTL::BELDIN_R | Pull us together, not apart | Thu Feb 13 1992 13:13 | 26 |
| re .4
>With people in the process of being "rightsized" and groups vanishing in the
>cuts, it is proving very difficult to have our concerns heard. NOONE seems
>to "OWN" this standard. All our contacts seem to have left or now have other
>jobs, and DEC-Std-095 seems to have been one of the casualties.
If no one is in charge, then a frontal challenge is all that will be
effective. Those who know there is a serious business problem should
prepare a white paper declaring their concerns and expressing their
conscientious decision to violate the standard in lieu of finding a
responsible manager. Then forward it up though the command chain until
someone gives back an official answer. If that answer is unacceptable, jump
that position and keep on escalating. It's a long and lonely road, but I
can't think of anything else to do.
Good luck,
Dick
pd
For the enlightenment of the originators of DEC-Std-095, consistency is
not the be-all-end-all of quality. Satisfying customer requirements is.
|
| 1765.8 | | VANGA::KERRELL | Dave Kerrell @REO 830-2279 | Fri Feb 14 1992 04:07 | 27 |
| Reading this story this morning made me very angry. After all the pain of cost
cutting and watching people lose their jobs there are still people out there
doing things without cost justification. It does not suprise me that it is going
on in the area of European internal applications. I worked in that area for my
first 6� years in Digital and saw many times work being invented to keep the
ever growing army of developers busy. I remember one particular argument when
a so called "standard" was imposed on an application that actually contridicted
the user requirement but the developers still included it without comment! It
took weeks of fighting on my part to get them to back it out.
On the positive side the European Application Environment may not be perfect
but it is has proved a more than adequate tool for the purpose of building
business applications. Well done to the developers of that! It would be absolute
madness to abandon it after many years for another environment just for the sake
of standards alone! It is an even greater madness to migrate existing
applications to a new standard at a time of cost cutting and when the business
is suffering because our internal systems can not keep up with the changing
business!
I hope the people responsible for this are fired!
I can think of a few internal customers who will be very angry about this to,
one at least reads this conference - expect fireworks!
Flame off.
/Dave.
|
| 1765.9 | I am the Responsible Individual for DEC Std 095 | AKOALA::NEWMAN | John C. Newman Corporate Finance IM&T AKO1-3/M4 DTN 244-6174 | Sat Feb 15 1992 22:55 | 586 |
| <<< HUMANE::HUMANE$DUA1:[NOTES$LIBRARY]DIGITAL.NOTE;1 >>>
-< The DEC way of working >-
================================================================================
Note 1765.0 Quality within Digital.... 8 replies
SBPUS4::MARK "Mark Watkins @MCO" 92 lines 13-FEB-1992 09:59
--------------------------------------------------------------------------------
I AM RESPONDING TO THIS NOTE AS THE RESPONSIBLE INDIVIDUAL FOR DS095 (THE
DOCUMENT AND ITS CONTENT). I HAVE NO RESPONSIBILITY FOR POLICY DECISIONS
IN ORGANIZATIONS BEYOND MY OWN AS TO HOW SWIFTLY, HOW BROADLY, HOW FULLY
AND WITH WHAT FUNDING DS095 IS IMPLEMENTED IN APPLICATION PORTFOLIOS. I
TRY TO RESPOND TO QUESTIONS REGARDING THE STANDARD, BUT SOMETIMES LEAVE
PEOPLE WAITING FOR A FEW WEEKS WHILE BUSY WITH MY OWN PROJECTS AND, IN
AT LEAST ONE CASE (JANE ALFORD) I HAD COMPLETELY FORGOTTEN HER QUESTIONS
(TWICE). MY RESPONSE TO THIS NOTE AND ITS RESPONSES WILL BE IN BARBARIC
UPPER-CASE ONLY TO ALLOW ME TO INTERSPERSE MY ANSWERS WITH THE ORIGINAL
COMMENTS.
With this in mind I am posting a note for someone who wishes to remain
anonymous. Before anyone tries to guess; this is not someone I work with, is not
someone known as a friend of mine and in fact contains views which are not
necessarily in line with mine....
Now, leaving the fact that some of us here in Europe who are expected to
implement this standard have very serious reservations about parts of
it, I am puzzled about the following:
This standard is not only applicable to newly designed and written
software, but is to be retrospectively applied to existing applications.
We, in this site, have many products, and estimates for bringing these
products into line with this standard vary between 30 and 140 man-days.
Bear in mind, that this is simply the work involved to do it, and makes
no allowance for testing, integration testing, installation, and support
for the bugs such work will undoubtedly produce.
Given that a man-day is about $1000, I question whether it is reasonable
to spend over $140,000 on a product, plus additional implementation
costs, whilst offering no increased functionality at all. Taking this on
a global level, I find it hard to understand what kind of cost/benefit
analysis was done on this to justify the expense. Someone, somewhere at
a high level in the Corporation must have approved this, surely in the
knowledge that it would cost millions of dollars to implement, for no
increased functionality. Personally, I cannot see what business need
this *restrospective* application of this standard addresses. It
certainly won't improve the quality of the software itself, that's quite
another issue.
AGAIN, FROM A NOTE I SENT TO JOS LEEMANS IN BELGIUM LAST WEEK...
"EXCEPTIONS FOR UPDATES OF OLD (e.g. PDP-11 BASED) PRODUCTS ARE A LOCAL
MANAGEMENT POLICY DECISION BASED ON FACTORS SUCH AS LIMITED REMAINING LIFETIME,
EXCESSIVE COST AND YOUR ORGANIZATION'S WILLINGNESS TO DEBATE SPIRIT OF THE LAW
VS. LETTER OF THE ISSUES WITH INTERNAL AUDIT."
At a time when the company is trying to pull itself together, can we
*really* afford this? It seems to me, that logic and common sense has
been sacrificed at the alter of bureaucracy, and committee-based
thinking.
As I mentioned earlier, we have reservations about this standard anyway,
some of which are so great that we believe parts of this standard to be
invalid. Worse still, it is too rigid to allow compliance by some of our
products, in any way, shape, or form. I welcome standards, we need them,
but, this seems to have been imposed with little or no input from "the
field", and despite months of attempting to get things in it changed,
we're still stuck with the original. Some concessions have been allowed
in the areas of logical names and directory structures, but they still
leave the bulk of standard to be implemented.
A. PLEASE FORWARD SPECIFICS OF ANY LAYERED PRODUCT INCOMPATIBILITIES TO
ME SO THAT I CAN PASS THEM ON TO OTHER DEVELOPERS. I KNOW OF ONE ISSUE
WITH DMU AND THE TP-TOOLKIT HAS A DIFFERENT SUGGESTED DIRECTORY STRUCTURE.
B. LITTLE OR NO INPUT FROM THE FIELD IS SIMPLY NOT CORRECT. EUROPEAN
RELEASE MANAGEMENT CIRCULATED EVERY DRAFT (6) TO THEIR CLIENT CONTACT
LIST OVER THE 1 1/2 YEARS THE STANDARD WAS BEING DEVELOPED. I KNOW -
I INCLUDED THE CHANGES AND CORRECTIONS. HOW SERIOUSLY (PARTS OF) THE
FIELD TOOK THE EFFORT WAS BEYOND OUR CONTROL. HOWEVER, ON THE THE LAST
DRAFT PRIOR TO BEGINNING THE OFFICAL DEC STD GENERAL REVIEW PROCESS WE
RECEIVED 28 PAGES OF FEEDBACK FROM EUROPE ALONE. THE PARTCIPATION IN
THE OFFICIAL DEC STD GENERAL REVIEW PROCESS SPEAKS FOR ITSELF WITH OVER
90 PARTICPATING INDIVIDUALS FROM ALL 3 GEOGRAPHIES AND 34 WRITTEN
RESPONSES. IN ADDITION, THE EFFORT WAS PRESENTED TO THE DIS TMC, THE
IM&T MC (TWICE) AND THE IM&T MC.
C. I DON'T KNOW WHAT MONTHS OF ATTEMPTING TO GET THINGS IN IT CHANGED MEANS. NO
ONE HAS EVER INDICATED THAT THE STANDARD AS PUBLISHED IS SUBJECT TO CHANGE ON
ANYTHING LESS THAN AN ANNUAL (OR EVEN 18 MOS) BASIS. WE OBVIOUSLY HAVE TO
BALANCE DESIRES TO CHANGE (OR MORE COMMONLY ADD ADDITIONAL) ITEMS WITH *THE
COSTS* OF MAKING THE ENTIRE AUDIENCE GO THROUGH AN UPDATE CYCLE OF THEIR ENTIRE
PORTFOLIO. WE TOOK OUR LEAD HERE FROM THE EXISTING GEOGRAPHY STANDARDS. THE
EUROPEAN I.S. ACCEPTANCE CRITERIA V1.1 WAS PUBLISHED IN JULY 1988 AND V2 WAS
PUBLISHED IN DECEMBER 1989 AND THE USDIS APPLICATION SYSTEM STANDARDS V1 WAS
PUBLISHED IN JULY 1986 AND FINAL DRAFT OF V2 WAS PUBLISHED IN SEPT 1990.
D. RE: THE CONCESSIONS MENIONED ABOVE. THERE HAS BEEN NO CHANGE MADE TO THE
STANDARD, BUT A POLICY CLARIFICATION HAS BEEN MADE (THIS IS SIMILAR TO THE
CURRENT COMPANYWIDE DISCUSSION OF POLICY 5.12, WHICH "GOVERNS" HOW QUICKLY
AND BROADLY DS065 WILL BE IMPLEMENTED). I WAS RECENTLY FORWARDED TO THE
FOLLOWING (PARTIALLY EDITED AND *NOT* IN UPPER CASE) MAIL MESSAGE...
From: NAME: ANDREW TWEEDIE @AYO
FUNC: EUR SYSTEMS COMPLIANCE
TEL: (7) 823 3540 <TWEEDIE.ANDREW AT A1_AYOV26 AT AYOMTS AT AYO>
Date: 06-Feb-1992
Subject: I:European Position on Dec-Std 95
From: NAME: John HARRISON @FYO
FUNC: Information Management
TEL: (885)-6818 <HARRISON AT FNYA1 @EHQMTS @FYO>
Date: 05-Feb-1992
*********************************************************
PLEASE ENSURE THAT THIS MESSAGE IS PASSED TO ALL RELEVENT
PEOPLE WITHIN YOUR ORGANISATIONS - many thanks.
*********************************************************
After considerable feedback from development and portfolio groups, the
European IM&T Policay Board Meeting in December, discussed the compliance
to DEC-std 095 and the following agreement was reached -
the elements which refer to naming conventions and directory structures
(i.e. requiring significant design changes) can be excluded from
compliance for existing applications.
However, a documented justification for such non-compliance MUST be
provided in the event of subsequent Application Audit.
It is expected that existing applications will be compliant with ALL
other elements of the standard .
All new applications (those which have NOT passed the design phase before
the end of February 1992) must be compliant with ALL elements of the
standard - this is based on the fact that the original announcement for
the standard was made in June of 1991.
Where major re-engineering is scheduled to take place on existing
applications, it is expected that an attempt to achieve full compliance
be made, and that any reasons for non-compliance are justified in writing
for possible future reference by audit.
It is on the basis of this agreement that internal audit will carry out
applications audits after the 1st. March 1992.
Many thanks and best regards - John.
To Distribution List:
christiane quarterman @geo,
NAME: Brad LENTZ @FYO <LENTZ AT FNYA1 @EHQMTS @FYO>,
steve fuller @geo,
ALLEN ATWELL @VBO,
NAME: Daniel COETSIER @FYO <COETSIER AT FNYA1 @EHQMTS @FYO>,
MICHEL CRUBEZY @EVO,
FREDERIC GODET @NEU,
BARBARA HUCKLE @UCG,
franz peter @rto,
BERND STEPHAN @RTO,
MARCO VACCARO @MIO,
GHISLAIN DE VINCK @BRO,
CHARLES WHITEHEAD @SBP
CC Distribution List:
andrew tweedie @ayo,
rob watts @geo,
martin kelmanson @reo,
NAME: Dave TOUGH @FYO <TOUGH AT FNYA1 @EHQMTS @FYO>,
NAME: Alfonso DIIANNI @FYO <DIIANNI.ALFONSO AT FNYA1 @EHQMTS @FYO>
From the memos that have appeared since the standard went "live", it
appears to me that the views and comments from the people at the sharp
end are not being heard, or considered. From management reaction to the
retrospective imposition, I'm sure the true impact is not being made
clear to them.
Does the company need this (not the standard, but the retrospective
imposition), and can it afford it? What can we do about getting this
"committee" to change the areas of the standard we have very real
problems with? How indeed, can we be heard?
A. THANK YOU FOR SEPARATING THE STANDARD FROM THE POLICY DECISION!
B. RETROSPECTIVE APPLICATION (IMPOSITION DOES SOUND A BIT NEGATIVE) OF THE
STANDARD MAY MAKE SENSE IN MANY CASES (GEARS IS 10+ YEARS OLD), IT IS LUDICROUS
IN OTHERS (GEARS IS BEING REPLACED BY ROSS G/L) AND IT MAY BE A JUDGEMENT CALL
IN OTHERS (ROSS G/L HAS ONLY BEEN COMMITTED TO FOR UK AND HOLLAND PRIOR TO
FY94)...
C. ALL OF THE ITEMS SUBMITTED AT THE TAIL END OF DRAFT DEVELOPMENT, ALL
ITEMS WE COULDN'T REACH AGREEMENT ON DURING THE YEAR AND A HALF OF NEGOTIATION,
ALL *NEW* ITEMS RECEIVED (AND DEFERRED) DURING THE DEC STD GENERAL REVIEW, AND
ITEMS COLLECTED BY MYSELF AND THE AREA RELEASE MANAGEMENT FUNCTIONS WILL BE
ON THE TABLE FOR THE NEXT VERSION OF THE STANDARD. I BELIEVE THERE IS CONSENSUS
THAT A NEW VERSION BE RELEASED (AT MOST) EVERY 12-18 MONTHS. THIS, OF COURSE,
DOES NOT PROHIBIT GROUP FROM HAVING ADDITIONAL AREA OR LOCAL STANDARDS.
================================================================================
Note 1765.1 Quality within Digital.... 1 of 8
MRKTNG::VULLO "You can breathe through that?" 43 lines 13-FEB-1992 10:30
--------------------------------------------------------------------------------
I agree COMPLETELY with the views of the anonymous author in the base note.
Standards are necessary and can definitely help in programming efficiency,
but the way DEC STD 095 and 065 are being enforced is crazy.
A few months ago I worked for a different group. During my time there,
particularly in my last year there, I tried making a huge stink about
standards. I talked to anyone who would listen. I went as far up the
management chain as I dared. I wrote memos, used ODP, and tried to get people
to act. In the end, nothing happened.
I ended up personally rewriting an entire application TWICE, just to conform
to DEC STD 065 naming conventions. We're talking about more than month's worth
of my time, and NO NEW FUNCTIONALITY was added to the application. The entire
effort was just changing field names in the programs and databases.
A. IF THE DATA MODELING AND DATA STANDARDIZATION (INCLUDING APPLICATION OF THE
NAMING GUIDELINES, HOWEVER BIZARRE THEY MAY BE) WERE PERFORMED PRIOR TO CODING,
REWRITING ONCE, LET ALONE TWICE, SHOULD NOT HAVE BEEN REQUIRED.
B. AND WHILE NO NEW FUNCTIONALITY WAS ADDED TO *YOUR* SYSTEM, APPLICATION OF
NAMING STANDARDS MAY HAVE MADE IT POSSIBLE FOR SOMEONE DOWNSTREAM IN THE
MANAGEMENT REPORTING WORLD TO USE YOUR DATA (OR USE IT CORRECTLY FOR THE
FIRST TIME). CLEARLY, THAT'S THE (BROAD) INTENT BEHIND DS065 AND DATA
MANAGEMENT IN GENERAL.
On another project for the same group we held up development for weeks (approx.
4 programmers X several weeks) just to conform to DEC STD 095 conventions. And
in the end, it turned out that some of the DEC STD 095 standards did not even
work due to the layered products involved. This was a complete waste of time,
and no additional value was added for the users/customers.
A. PLEASE FORWARD ME SPECIFICS OF THE LAYERED PRODUCT INTERACTIONS TO WHICH
YOU REFER - A "BUG" IN THE STANDARD WILL NOT WAIT 18 MOS FOR CORRECTION!
B. DON'T BE SO SURE THAT NO VALUE TO THE CUSTOMERWAS ADDED. MANY GROUPS DIDN'T
EVEN USE TO PROVIDE FORMAL INSTALL KITS, LET ALONE VMSINSTAL KITS, IN YEARS
PAST. DATA CENTER GROUPS AND RECEIVING IS ORGANIZATIONS STRUGGLED TO GET
SYSTEMS INSTALLED (DELAYING CUSTOMER AVAILABILITY LONGER THAN A KIT WOULD TAKE
TO WRITE!); THE APPLICATION GOT OFF ON THE WRONG FOOT, AND IN SOME CASES WAS
DELAYED, REJECTED AND EVENTUALLY EVENTUALLY REWRITTEN OR PURCHASED (ALL FOR WANT
OF A HORSE).
SOMETHING AS TRIVIAL AS KIT NAMING AND/OR THE IDENTIFICATION OF THE VERSION
WITHIN THE EXECUTABLES (/IDENT) CAN CAUSE DAYS OF SPURIOUS PHONE CALLS OR
DEBUGGING IF NOT DONE. THESE DELAYS TRANSLATE TO LOST USAGE DAYS FOR THE USER/
CUSTOMER.
In trying to get management to do something, this was the analogy I used:
You are one of 18 people who work at a golf course mowing the lawns. Each of
the 18 people are responsible for one green.
The owner says: "From now on, all mowers will mow their greens in a
North/South pattern"
(I say this is a good standard, because it makes the place look good)
Then the owner says: "When you mow the grass near a tree, do it in a
circular pattern around the tree"
(I say this is another ok standard)
Now they owner says: "When you start your mowers you must place your left
hand on your head."
"When you put gas in the mower you must first place a
clothes pin on your nose"
"When you drive in to work you must drive a blue car"
I say these are analogous to DEC STD 065 and 095. Standards carried
too far. So far in fact, that you never get a chance to mow the lawn.
Vin
================================================================================
Note 1765.2 Quality within Digital.... 2 of 8
SQM::MACDONALD 11 lines 13-FEB-1992 10:31
--------------------------------------------------------------------------------
Re: .0
There is not enough information given about the standard to be able to
answer your question about cost. For example, are details of this
standard things we should have been doing all along? Will not doing
it cost us even more in the long run? Can you shed some more light
on this.
Steve
TWO EXCELLENT QUESTIONS!
================================================================================
Note 1765.3 Quality within Digital.... 3 of 8
CHRCHL::GERMAIN "Improvise! Adapt! Overcome!" 7 lines 13-FEB-1992 10:50
--------------------------------------------------------------------------------
What these standards/methods represent is the framework around which
you build quality and consistencey. They are not an end unto
themselves.
The necessary catalyst is the willingness to do it.
Gregg
BRAVO!
================================================================================
Note 1765.4 Quality within Digital.... 4 of 8
MAJORS::ALFORD 79 lines 13-FEB-1992 10:50
-< some thoughts and feelings on the matter. >-
--------------------------------------------------------------------------------
With reference to the anonymous submission, and in addition to that submission:
European engineering subsidiaries were asked for feedback regarding DEC-Std-095.
We submitted a large amount of feedback. Much of it relating to major concerns
around the incompatibility of this standard to our existing applications and
the way the Business in Europe handles it's software.
All of this feedback was apparently ignored. The version of DEC-Std-095 that
was released was identical to the version that was submitted for feedback.
THE AUTHOR OF THIS REPLY WAS NOT A PARTICIPANT IN THE DEC STD GENERAL REVIEW,
WHICH WAS OPEN TO ALL OF DIGITAL AND WELL PUBLICIZED BY SQM AND THE IM&T MC.
WHILE SOMEONE ELSE IN HER GROUP MAY HAVE SUBMITTED FEEDBACK, JANE FIRST SENT IN
A SET OF QUESTIONS IN OCTOBER OF 1991, THREE MONTHS AFTER THE STANDARD WAS
PUBLISHED (AND WITH ONLY TWO+ MONTHS LEFT TO GO PRIOR TO THE EFFECTIVE DATE)
WHILE I APOLOGISE FOR NEVER RESPONDING IN FULL TO HER QUESTIONS, I DID REFER HER
TO EUROPEAN RELEASE MANAGEMENT AND FORWARD HER THE EXISTING SET OF ALREADY
ANSWERED QUESTIONS.
MOREOVER, THE VERSION PUBLISHED WAS *NOT* IDENTICAL TO THE VERSION SENT OUT
FOR GENERAL REVIEW. THE SQM TECH WRITER DID A FINE JOB
INCORPORATING CHANGES AND CORRECTIONS FROM OVER 30 PEOPLE WHO PROVIDED
WRITTEN FEEDBACK. NOR HAVE YOU MENTIONED THE TWELVE PAGE (POSTSCRIPT WITH
MICROSCOPIC VAX DOCUMENT TABLE FONT) MEMO WHICH RESPONDED TO EACH AND
EVERY PIECE OF FEEDBACK. WHAT WAS DEFERRED (IN WRITING = *NOT* IGNORED)
WERE ANY *NEW* ITEMS, BECAUSE I WOULD HAVE FELT OBLIGATED TO GO THROUGH
GENERAL REVIEW AGAIN IF SUBSTANTATIVE CHANGES WE MADE AS A RESULT OF THE
GENERAL REVIEW AND THE STANDARD HAD TAKEN TWO YEARS OF NEGOTIATION ALREADY.
WHAT WERE ALSO LEFT OUT WERE ITEMS WHICH HAD ALREADY BEEN DISCUSSED OVER AND
OVER AND FOR WHICH NO COMPROMISE COULD BE NEGOTIATED.
With people in the process of being "rightsized" and groups vanishing in the
cuts, it is proving very difficult to have our concerns heard. NOONE seems
to "OWN" this standard. All our contacts seem to have left or now have other
jobs, and DEC-Std-095 seems to have been one of the casualties.
AS DOCUMENTED ON PAGE ii, I OWN THE STANDARD. AS DISCUSSED ABOVE AND IN
MY MAIL MESSAGE TO YOU OF 04-NOV-1991, I DO *NOT* OWN IMPLEMENTATION OF
IT IN ANY ORGANIZATION EXCEPT CORPORATE FINANCE IM&T. THERE IS NO COMPANY-WIDE
BODY TO "POLICE" RELEASE MANAGEMENT, BUT THERE ARE AREA RELEASE MANAGEMENT
FUNCTIONS. NOW, IT IS POSSIBLE THAT RIGHTSIZING/WORK FRANCHISING HAS LEFT
THE EUROPEAN RELEASE MANAGEMENT ORGANIZATION LESS WELL STAFFED THAN WE ALL
WOULD LIKE, BUT IT'S EUROPEAN IM&T MANAGEMENT WHO NEEDS TO HEAR THIS MESSAGE.
DEC-Std-095 was apparently based on the USIM&T US Application Environment
Standard. Many of the requirements can be traced directly back to that
standard and echo it word for word. This standard was developed for the
US Engineering market, and may be perfect for the US way of implementing
their applications. I will say, it's not all bad and that many of the
requirements of this standard are useful and sensible, but for an European
market, not *ALL* of them
A LITTLE HISTORY. MY ORGANIZATION RELEASES INTERNALLY WRITTEN AND VENDOR
SUPPLIED FINANCIAL SOFTWARE WORLDWIDE. FOR INSTANCE, WE SUPPLY ROSS SYSTEMS
SOFTWARE (FOR WHICH WE WRITE THE KITS, INTERFACE WITH AREA RLS MGT
ORGANIZATIONS AND SERVE AS VENDOR POINT OF CONTACT) TO "ALL" OF GIA AND,
MORE RECENTLY, TO EUROPE (ROSS G/L IS LIVE IN HUNGARY). WE ALSO SUPPLY
ALL OF THE SOFTWARE USED IN THE US FMC'S. WE OBVIOUSLY HAD A DESIRE TO
FIND THE COMMON DENOMINATOR IN THE RELEASE MANAGEMENT CRITERIA OF THESE
3 AREAS AND TO "NORMALIZE IT OUT" SO THAT IT NEED ONLY BE PERFORMED ONCE.
THIS WAS THE STATED GOAL OF THIS EFFORT AS IT WAS PRESENTED TO THE TMC IN
JUNE, 1989 (LONG BEFORE THERE WAS ANY TALK OF A DEC STD).
DEC STD 095 IS BASED ON THE USIS APPLICATION SYSTEMS STANDARD V1 (LATER
RENAMED) AND THE EUROPEAN (ADG) IS ACCEPTANCE CRITERIA STANDARD V1.1. WE
ACTUALLY HAD A SIDE-BY-SIDE COMPARISON TABLE, KEYED IF YOU WILL, BY THE
ORGANIZATION OF THE EUROPEAN DOCUMENT. THE EUROPEAN DOCUMENT HAD MANY
MORE SPECIFIC ITEMS, THE US DOCUMENT WENT INTO GREATER EXPLANATION AND,
IN SOME CASES (SUCH AS THE EVER-POPULAR SUBDIRECTORY STRUCTURES) GREATER
SPECIFICS.
WHILE SOME OF THE REQUIRMENTS CAN BE TRACED TO (EVEN QUOTED FROM) THE US
DOCUMENT, THE OVERALL STRUCTURE WAS TAKEN FAIRLY DIRECTLY FROM THE EUROPEAN
STANDARD. MANY ITEMS CAN ALSO BE TRACED DIRECTLY TO THE EUROPEAN ADG DOCUMENT.
A COUNT OF ITEMS SHOULD COME UP AS A DRAW, SINCE ONLY THOSE ITEMS WHICH WERE IN
BOTH (AND AGREEABLE TO GIA), WERE BY DEFINITION, APPROPRIATE FOR THE LOWEST
COMMON DENOMINATOR STANDARD. NOW, WHEN THE LCD WAS DISCOVERED TO ALMOST
IDENTICAL TO (BOTH OF) THE WHOLE(S) - WE DID PRESS FORWARD AND INJECT A SMALL
AMOUNT OF NON-COMMON MATERIAL (E.G. THE DIRECTORY STDS). IN OTHER CASES (RIGHTS
ID'S) MATERIAL THAT WAS ADDED TO THE LCD WAS MANDATED (ALREADY) BY OTHER
STANDARDS (e.g. 11.1) OR JUST SEEMED APPROPRIATE FOR 1990. IN ANY CASE,
EACH OF THE SIX MAJOR DRAFTS WAS FORWARDED OUT BY BOTH US AND EUROPEAN RLS MGT
TO THEIR RESPECTIVE CLIENT LISTS.
P.S. THE US DOC WAS NOT DEVELOPED FOR THE US ENGINEERING MARKET, IT WAS
DEVELOPED FOR INTERNAL APPLICATIONS (ORDER PROCESSING, FIELD SERVICE, ETC). I
THINK THE NEXT TWO NOTES REPLYS ARE RE: THIS POINT.
As an example. The European business prefers to install the new version of
appliction software in advance of the change over date, and migrating from the
old to the new when they are satisfied with the new version. This is often
a period of weeks, especially if the release is relatively new.
Under the European Application Environment, this is possible to do on a
single machine/cluster. Under the requirements of DEC-Std-095 this is not
possible.
Due to the requirements that under DEC-Std-095 the top directory of an
application and the logical name table may *NOT* contain the version number
[fac] and fac$LOGICAL_NAMES means that only one version of an application
may be installed on a system environment at any one time.
This has expensive consequences. Either the subsidiaries have to invest in
more hardware (in these days of cost-cutting), or they have to install and
migrate to new software in a *VERY* short window, both solutions are costly.
We have asked for approval for two very small changes to the standard to make
life for our Customers bearable - [fac999] and fac999$LOGICAL_NAMES not
much to ask for (everything else we can live with), you may think.
FACVVV IS A GREAT IDEA, BUT IT CAME IN DURING THE GENERAL REVIEW, IS CLEARLY
A NEW IDEA AND A MAJOR CHANGE, WAS NOT IN EITHER STANDARD AND THEREFORE NOT
IN THE LCD AND WOULD NOT HAVE BEEN ACCEPTED BY THE US. A SIMILAR IDEA IS
THE SUFFIXING OF THE FAC CODE WITH A TWO NATURAL CHAR LANGUAGE IDENTIFER, BUT
THIS WAS ALSO THOUGHT TO BE TOO GREAT A CHANGE TO AVOID A COMPLETE REPEAT
OF GENERAL REVIEW.
NOW, FOR HOW TO SOLVE YOUR PROBLEM. THE INTENT OF THE US ROOTED DIRECTORY
STRUCTURE WAS TO SOLVE EXACTLY WHAT YOU WISH TO SOLVE. THE PRODUCTION
VERSION WOULD BE HAPPILY RUNNING AWAY IN DISK$SOMETHING:[FAC...], WHILE
A TEST VERSION (THE STANDARD APPLIES TO PRODUCTION ENVIRONMENTS, ONLY) COULD
BE SET UP IN DISK$SOMETHING:[FAC_TEST...]. ONLY THE LOGICAL FOR FAC_ROOT
NEED BE MANIPULATED, ALL OTHER LOGICALS ARE BASED UPON IT. WHEN TESTING IS
COMPLETE YOU CAN BACK [FAC_TEST...] AND RESTORE IT INTO [FAC...] AND YOU'RE
DONE.
NOW, THE LOGICAL NAME TABLE CONFLICT IS A BIT TRICKIER, BUT YOU COULD USE
PROCESS LOGICALS FOR YOUR _TEST USERS - THE TEST SETUP DOESN'T HAVE TO
MEET THE STANDARD. YOU COULD, PRESUMABLY USE A PROCESS LOGICAL TO
OVERRIDE ONLY FAC_ROOT. OR YOU COULD USE YOUR FACvvv SYNTAX ON THE TEST SIDE.
ACTUALLY YOU COULD PROBABLY EVEN USE SEPARATE RIGHTS ID'S (NO NAMING
CONVENTIONS AT ALL, YET) TO CAUSE ONE BATCH OF USERS TO SEE ONE LOGICAL
NAME TABLE, WHILE THE OTHERS SEE ONLY THE OTHER.
...BUT WHO DO YOU ASK ? who is authorized to give approval ? we can provide
$n00,000 worth of justification for the change.
WELL, IF THE ABOVE TECHNIQUES DON'T WORK, TRY CALLING THE AUTHOR OF THE
US DOCUMENT (GLEN DOTTEN @DDD) - HIS EXPLANATION WILL BE BETTER THAN MINE.
AND IF THAT DOESN'T WORK, IN THE WORDS OF THE NIKE AD CAMPAIGN "JUST DO IT"
(FACvvv), AND PLEASE LET ME KNOW THE RESULT.
It may be that the US software engineering groups have the luxury of being able
to Field Test their products for long periods of time to prove their software,
but in the field of business software where there are very short developing
windows and even shorter release windows, the best we can hope for is a couple
of weeks of "hand-holding" pilot.
We are very concerned with quality, and do our best to achieve this; but we
are also aware that with time squeezed from all angles, it is a next to
impossible job to produce truely quality, problem free, software under todays
engineering conditions; thus it makes sense to enable the field to choose to
go for parallel running of concurrent released of software, if they feel that
this will reduce the business risk; and there is a risk entailed in every
release.
I share the concerns of the anonymous noter about a standard being imposed
on existing software. I totally agree that all new software, including new
additions to existing software be affected by a current standard, but
retrograde fitting ? is this really sensible ? is it cost-effective ?
================================================================================
Note 1765.5 Quality within Digital.... 5 of 8
SQM::MACDONALD 14 lines 13-FEB-1992 10:58
--------------------------------------------------------------------------------
I recall over a year ago seeing a proposal for standard that was being
pushed by (I've forgotten the name of the group) the internal
information systems group. It sounds like this might be one and the
same standard that I saw. I don't remember the details but remember
having concerns with some of them. My understanding was that this
standard was to refer to software that was intended to be installed on
DEC internal systems and was not intended as a development standard
for software we were building for sale.
Can anyone shed more light?
Steve
================================================================================
Note 1765.6 Quality within Digital.... 6 of 8
MAJORS::ALFORD 4 lines 13-FEB-1992 10:59
--------------------------------------------------------------------------------
Re: .5
Yes, that's the one.
================================================================================
Note 1765.7 Quality within Digital.... 7 of 8
SGOUTL::BELDIN_R "Pull us together, not apart" 26 lines 13-FEB-1992 13:13
-< opinion >-
--------------------------------------------------------------------------------
re .4
>With people in the process of being "rightsized" and groups vanishing in the
>cuts, it is proving very difficult to have our concerns heard. NOONE seems
>to "OWN" this standard. All our contacts seem to have left or now have other
>jobs, and DEC-Std-095 seems to have been one of the casualties.
AGAIN, I OWN THE STANDARD, BUT AREAS OR EVEN ORGANIZATIONS WITHIN THEM OWN
SETTING A POLICY AND MARCHING TO IT. I DON'T KNOW THIS REPLY'ER, BUT FROM
ELF I SEE HE'S IN PUERTO RICO. CONTACT PAUL FARRELL@AKO OR JIM HOGAN DIRECTLY
IF YOU FEEL THAT "RIGHTSIZING" HAS PUT THIS STANDARD, OR WHAT IT COULD BE,
AND/OR ITS GOALS, AT RISK. JIM HOGAN CHAIRED TO DIS MC SUBCOMMITTEE WHICH
DEVELOPED THE INITIAL SET OF RELEASE MANAGEMENT PRINCIPLES SUPPORTED BY
THE AREA RELEASE MANAGEMENT GROUPS AND (HOPEFULLY) THIS STANDARD.
If no one is in charge, then a frontal challenge is all that will be
effective. Those who know there is a serious business problem should
prepare a white paper declaring their concerns and expressing their
conscientious decision to violate the standard in lieu of finding a
responsible manager. Then forward it up though the command chain until
someone gives back an official answer. If that answer is unacceptable, jump
that position and keep on escalating. It's a long and lonely road, but I
can't think of anything else to do.
Good luck,
Dick
pd
For the enlightenment of the originators of DEC-Std-095, consistency is
not the be-all-end-all of quality. Satisfying customer requirements is.
================================================================================
Note 1765.8 Quality within Digital.... 8 of 8
VANGA::KERRELL "Dave Kerrell @REO 830-2279" 27 lines 14-FEB-1992 04:07
--------------------------------------------------------------------------------
Reading this story this morning made me very angry. After all the pain of cost
cutting and watching people lose their jobs there are still people out there
doing things without cost justification. It does not suprise me that it is going
on in the area of European internal applications. I worked in that area for my
first 6� years in Digital and saw many times work being invented to keep the
ever growing army of developers busy. I remember one particular argument when
a so called "standard" was imposed on an application that actually contridicted
the user requirement but the developers still included it without comment! It
took weeks of fighting on my part to get them to back it out.
On the positive side the European Application Environment may not be perfect
but it is has proved a more than adequate tool for the purpose of building
business applications. Well done to the developers of that! It would be absolute
madness to abandon it after many years for another environment just for the sake
of standards alone! It is an even greater madness to migrate existing
applications to a new standard at a time of cost cutting and when the business
is suffering because our internal systems can not keep up with the changing
business!
AGAIN, THE INTENT WAS NOT ABANDON THE EUROPEAN APPLICATION ENVIRONMENT NOR
EVEN TO EXPAND IT NOR EVEN TO COMBINE IT WITH THE US STANDARD, BUT MERELY TO
IDENTIFY THE COMMON REQUIREMENTS IN ORDER TO SERVE THE GOAL OF ALLOWING
SOFTWARE TO BE SHARED ACROSS GEOGRAPHIES MORE READILY. PERHAPS THE EUROPEAN
REPRESENTATIVE WAS TOO GIVING, PERHAPS THE EUROPEAN REVIEWERS DIDN'T TAKE
ANY OF THE FIRST SIX DRAFTS SERIOUSLY AND ONLY THE OFFICIAL DEC STD IMPRIMATUR
AWAKENED THEIR EYES, BUT I CAN'T WONDERING IF THE SAME SET OF REQUIREMENTS
IF MERELY INCLUDED IN THE EUROPEAN STANDARD V2 WOULD HAVE AROUSED SUCH
LANGUAGE AS "ABANDON", "NEW STANDARD", "ANOTHER ENVIRONMENT" AND "ABSOLUTE
MADNESS".
I hope the people responsible for this are fired!
I can think of a few internal customers who will be very angry about this to,
one at least reads this conference - expect fireworks!
Flame off.
/Dave.
|
| 1765.10 | A few comments | PLAYER::WINPENNY | | Mon Feb 17 1992 05:27 | 38 |
|
Re: .9
You give as a reason for not incorporating some of the feedback you
recieved:
BECAUSE I WOULD HAVE FELT OBLIGATED TO GO THROUGH THE GENERAL
REVIEW AGAIN.
What kind of a reason is this? What is the point of having a review if
you do not take notice of feedback because it would mean having to go
through the review procedure again.
If I as a developer recieve feedback about problems in my code would
the sender feel satisfied if I said "I am not going to take any action
because it would mean the application would have to go through QA
acceptance again"? *NO*
THE AUTHOR OF THIS REPLY WAS NOT A PARTICIPANT IN THE DEC STD
GENERAL REVIEW, WHICH WAS OPEN TO ALL OF DIGITAL AND WELL
PUBLICIZED BY SQM AND THE IM&T MC.
Well publicized??? The first I heard about it was ~October 1991. Which
is apparently after all decisions had been made. How was it *WELL*
publicized.? I feel that if Jane Alford had heard about the Genral
Review she would have participated. It was also very convenient to
forget her questions twice. Maybe because the questions were a little
too searching or maybe I'm being too cynnical.
THE PARTICIPATION IN THE OFFICIAL DEC STD GENERAL REVIEW PROCESS
SPEAKS FOR ITSELF WITH OVER 90 PARTICIPATING INDIVIDUALS FROM ALL
3 GEOGRAPHIES AND 34 WRITTEN RESPONSES.
I don't believe it does. For an organization the size of DIGITAL the
numbers mentioned are infinitesimal. Even if you take into account only
those employees of Project Leader status and above.
Chris.
|
| 1765.11 | While we're on the subject of standards... | BIGJOE::DMCLURE | Just say Notification Services | Mon Feb 17 1992 12:45 | 15 |
| re: .9,
> MY RESPONSE TO THIS NOTE AND ITS RESPONSES WILL BE IN BARBARIC
> UPPER-CASE ONLY TO ALLOW ME TO INTERSPERSE MY ANSWERS WITH THE ORIGINAL
> COMMENTS.
Speaking of standards, the standard means of replying to notes
is to highlight the note text being responded to with greater than
signs (as above). Anyone here will tell you that upper case is used
primarily for yelling and screaming.
-davo
p.s. On the other hand, I won't force you to reenter a standardized
version of your note. ;^)
|
| 1765.12 | | MRKTNG::VULLO | You can breathe through that? | Mon Feb 17 1992 13:15 | 4 |
| davo - that perfectly sums up the entire issue, except you'd have to
make re-entering the note mandatory.
Vin
|
| 1765.13 | | MAJORS::ALFORD | | Mon Feb 17 1992 13:20 | 39 |
|
Re: .9
Thankyou for that reply John, and the time you obviously took to enter it.
It has given me, and I hope many others, much needed answers.
> THE AUTHOR OF THIS REPLY WAS NOT A PARTICIPANT IN THE DEC STD
> GENERAL REVIEW, WHICH WAS OPEN TO ALL OF DIGITAL AND WELL
> PUBLICIZED BY SQM AND THE IM&T MC.
No, I wasn't an individual participant because it was decided to select a
representative from our site who would attend that review and put forward our
collective concerns. The person selected was Ian Preece, who did attend.
My involvement in starting to try to obtain clarification on some points was
because I was working on the task of updating the European Application
Environment (APPENV) to conform to DEC Std 095, and thus had a very real
interest in obtaining an in-depth understanding of the Standard and trying to
do the job properly, as it is this Environment that dictates the shape and
Standard conformance of all our applications released around all the
subsidiaries of Europe.
Your point on the FACvvv not being documented in the IS Acceptance Standard is
noted. Maybe you should have had access to the supporting document the
Application Standard User Guide, in which the directory structure and
conformation is well documented...but then it's too late now.
Re: .10
> I don't believe it does. For an organization the size of DIGITAL the
> numbers mentioned are infinitesimal. Even if you take into account only
> those employees of Project Leader status and above.
It would have been impracticable to send all interested parties to this review.
(Indeed there were many hundreds of us). Representatives from each engineering
site, at least from here in the UK, were sent to the review with a long list.
|
| 1765.14 | | VANGA::KERRELL | Dave Kerrell @REO 830-2279 | Tue Feb 18 1992 04:15 | 8 |
| I apologise for my earlier outburst of anger, it may have clouded my point,
which was that to migrate applications, in the current economic climate, from
one standard to another without justification (cost or otherwise) does not make
sense. Maybe they did justify it? Perhaps this is a restructuring excercise with
pay back over the next 'n' years? Who can tell us?
/Dave.
|
| 1765.15 | Food for thought? | PLAYER::BROWNL | On a whinge and a prayer | Wed Feb 19 1992 06:53 | 444 |
| Disclaimer: The following is my personal opinion, and is not to be considered
as the opinion of my group, my subsidiary, my management (all of
it), or my colleagues. I have no brief from management to become
involved in this debate, my motives are purely that I feel I have
a responsibility to contribute in an area where I believe an
expensive mistake could be being made. I am acting completely
independently, in my own time, not Digital's.
John, thanks for taking the time to reply. I've been following this note since
it was brought to my attention by a colleague. I'm working in the QA group in
Brussels, and we're dealing with these issues right now.
Parts of my response here address issues and areas that are not yours to deal
with. In the case of these, I hope those who do deal with these areas will
chip in, and explain what's going on. For those that are yours, I'd appreciate
your comments.
There are a couple of impressions that come over whilst reading your note. One
of which is that you are distancing yourself from the policy that followed the
release of this standard. This, I think, is naive, and the policy, is the
standard, and vice-versa. By releasing the standard, you have effectively
forced the policy that follows it.
Another thing I notice, is that you seem to feel that there is a different
policy in Europe to that in the US, and that there is room for a variance from
the standard from a European perspective. I have seen no evidence of this, or
of any other "local management policy". The standard is there, and we are
supposed to comply with it.
The base-noter raised to point of retro-fitting, and the costs involved.
Really, I suppose the thrust of this topic should stick to that. However,
inevitably, the standard itself will come into it. For this reason, I have
referred directly to the standard, as well as to the policy that is enforcing
it. However, even having read your note, I fail to see a case for
retro-fitting this standard in place of the one we already follow in Europe,
which has, until now, served us and the business well. The issue of the
future, is I believe, quite another matter.
On to the specifics, if I may:
� "EXCEPTIONS FOR UPDATES OF OLD (e.g. PDP-11 BASED) PRODUCTS ARE A LOCAL
� MANAGEMENT POLICY DECISION BASED ON FACTORS SUCH AS LIMITED REMAINING LIFETIME,
� EXCESSIVE COST AND YOUR ORGANIZATION'S WILLINGNESS TO DEBATE SPIRIT OF THE LAW
� VS. LETTER OF THE ISSUES WITH INTERNAL AUDIT."
This statement, whilst undoubtedly true, fails to take account of the
willingness or otherwise, of people to debate the issue. It is also evident,
that people are not aware that the policy regarding this standard is debatable
in the first place. Debates with internal audit will happen when it's too
late, we need to know now, what are the standards they expect.
� A. PLEASE FORWARD SPECIFICS OF ANY LAYERED PRODUCT INCOMPATIBILITIES TO
� ME SO THAT I CAN PASS THEM ON TO OTHER DEVELOPERS. I KNOW OF ONE ISSUE
� WITH DMU AND THE TP-TOOLKIT HAS A DIFFERENT SUGGESTED DIRECTORY STRUCTURE.
I suspect that the base-noter was talking about internal products here, rather
than layered ones. Here in Belgium, we are in the advanced stages of producing
a product that is highly distributed in nature. so much so, that the
implementation on each node will be different. It is actually not possible to
fit the standards (in many ways) to this product.
� B. LITTLE OR NO INPUT FROM THE FIELD IS SIMPLY NOT CORRECT. EUROPEAN
� RELEASE MANAGEMENT CIRCULATED EVERY DRAFT (6) TO THEIR CLIENT CONTACT
� LIST OVER THE 1 1/2 YEARS THE STANDARD WAS BEING DEVELOPED. I KNOW -
� I INCLUDED THE CHANGES AND CORRECTIONS. HOW SERIOUSLY (PARTS OF) THE
� FIELD TOOK THE EFFORT WAS BEYOND OUR CONTROL. HOWEVER, ON THE THE LAST
� DRAFT PRIOR TO BEGINNING THE OFFICAL DEC STD GENERAL REVIEW PROCESS WE
� RECEIVED 28 PAGES OF FEEDBACK FROM EUROPE ALONE. THE PARTCIPATION IN
� THE OFFICIAL DEC STD GENERAL REVIEW PROCESS SPEAKS FOR ITSELF WITH OVER
� 90 PARTICPATING INDIVIDUALS FROM ALL 3 GEOGRAPHIES AND 34 WRITTEN
� RESPONSES. IN ADDITION, THE EFFORT WAS PRESENTED TO THE DIS TMC, THE
� IM&T MC (TWICE) AND THE IM&T MC.
Well, for something this important, I should have thought that it should have
been available for debate, just as we are now. I don't think anyone from our
site was involved. I may be wrong, or indeed, someone may have been invited
but didn't go, I don't know. However, we are concerned about some areas of
this standard, and we wish we had the means to change some of them before too
much damage is done.
� C. I DON'T KNOW WHAT MONTHS OF ATTEMPTING TO GET THINGS IN IT CHANGED MEANS. NO
� ONE HAS EVER INDICATED THAT THE STANDARD AS PUBLISHED IS SUBJECT TO CHANGE ON
� ANYTHING LESS THAN AN ANNUAL (OR EVEN 18 MOS) BASIS. WE OBVIOUSLY HAVE TO
� BALANCE DESIRES TO CHANGE (OR MORE COMMONLY ADD ADDITIONAL) ITEMS WITH *THE
� COSTS* OF MAKING THE ENTIRE AUDIENCE GO THROUGH AN UPDATE CYCLE OF THEIR ENTIRE
� PORTFOLIO. WE TOOK OUR LEAD HERE FROM THE EXISTING GEOGRAPHY STANDARDS. THE
� EUROPEAN I.S. ACCEPTANCE CRITERIA V1.1 WAS PUBLISHED IN JULY 1988 AND V2 WAS
� PUBLISHED IN DECEMBER 1989 AND THE USDIS APPLICATION SYSTEM STANDARDS V1 WAS
� PUBLISHED IN JULY 1986 AND FINAL DRAFT OF V2 WAS PUBLISHED IN SEPT 1990.
I can see the influence of the European standards there, but many valuable
parts have been dropped or diluted. There are instances where these new
standards are too inflexible, whereas the original ones weren't. One area this
applies is in the directory structure. I will expand later.
� D. RE: THE CONCESSIONS MENIONED ABOVE. THERE HAS BEEN NO CHANGE MADE TO THE
� STANDARD, BUT A POLICY CLARIFICATION HAS BEEN MADE (THIS IS SIMILAR TO THE
� CURRENT COMPANYWIDE DISCUSSION OF POLICY 5.12, WHICH "GOVERNS" HOW QUICKLY
� AND BROADLY DS065 WILL BE IMPLEMENTED). I WAS RECENTLY FORWARDED TO THE
� FOLLOWING (PARTIALLY EDITED AND *NOT* IN UPPER CASE) MAIL MESSAGE...
I have read this mail, and written a report to my management. In my personal
view, not necessarily shared by my managers and colleagues, this mail makes
the matter worse. Prior to this, we had a directive that we must comply
henceforth, but not retrospectively. Then, we receive this mail, which is
clearly intended to make a clear directive on the path to follow. However,
there are three key phrases or terms around which the mail hinges.
1) "existing applications"
2) "requiring significant design changes"
3) "major re-engineering"
For me, "existing applications" must mean everything that is out there,
released and in use. The other two, must, of course, be subsets of this. There
is a case for allowing some overlap between these two subsets, but which
applications fall into which subset, and why, must be clear before an
interpretation of this "directive" can be attempted. Having accepted the
premise that there are two subsets, the ambiguity and contradiction of the
memo will become clear. The point being, how do we decide which application is
in which subset?
It is apparant from the first paragraph "After considerable feedback etc."
that more dissenting voices have been raised since the issue, than before, and
that the issues raised have created a need for a response. I just wish it had
been much, much more explicit, and not nearly so open to mis-interpretation. I
accept that he has probably tried to give the development groups some freedom
to enable them to comply with the spirit of the standard, as opposed to the
letter, but there is too much left half-said, and it's internal adit that will
judge. I can foresee widely differing interpretations of his mail, by internal
audit, and development groups.
� B. RETROSPECTIVE APPLICATION (IMPOSITION DOES SOUND A BIT NEGATIVE) OF THE
� STANDARD MAY MAKE SENSE IN MANY CASES (GEARS IS 10+ YEARS OLD), IT IS LUDICROUS
� IN OTHERS (GEARS IS BEING REPLACED BY ROSS G/L) AND IT MAY BE A JUDGEMENT CALL
� IN OTHERS (ROSS G/L HAS ONLY BEEN COMMITTED TO FOR UK AND HOLLAND PRIOR TO
� FY94)...
Well, whatever word you choose, the reality is the same. There are people out
there still very unhappy with the standard.
� C. ALL OF THE ITEMS SUBMITTED AT THE TAIL END OF DRAFT DEVELOPMENT, ALL
� ITEMS WE COULDN'T REACH AGREEMENT ON DURING THE YEAR AND A HALF OF NEGOTIATION,
� ALL *NEW* ITEMS RECEIVED (AND DEFERRED) DURING THE DEC STD GENERAL REVIEW, AND
� ITEMS COLLECTED BY MYSELF AND THE AREA RELEASE MANAGEMENT FUNCTIONS WILL BE
� ON THE TABLE FOR THE NEXT VERSION OF THE STANDARD. I BELIEVE THERE IS CONSENSUS
� THAT A NEW VERSION BE RELEASED (AT MOST) EVERY 12-18 MONTHS. THIS, OF COURSE,
� DOES NOT PROHIBIT GROUP FROM HAVING ADDITIONAL AREA OR LOCAL STANDARDS.
This last sentence is the most telling here. How can we? We have been told at
a European level to comply. Hitherto, there has never been any mention of the
fact that there was any possibility of local variance. Indeed, if there is,
just what is this standard trying to achieve? Are you saying that effectively
we can carry on as we have, and that DEC STD 095 applies to the US only? I
don't believe that you are for one second, but, it does rather give the
impression that more people believe that the standard may be inappropriate
than I first thought.
With respect to the "next version", if we're restrospectively applying these
standards to existing products, what use is it if these changes are reversed
in the next version? If we're to apply these standards, or rather, those
portions of the standard that cause us difficulties, to new products, what
help is it to us if we go back to the way things are now in a year's time?
Surely, now is the time to make addenda to the standard? Now is the time to
deal with these queries, because it's now that they're causing difficulties..
If there were outstanding matters on which "we couldn't reach agreement", why
was the standard released? Clearly, for someone, there were areas of
difficulty, areas that someone felt very strongly about. Surely, that's no
basis for a standard. I accept that there comes a point when there has to be a
decision reached, but a compromise can often be a disaster. Two clear options
can sometimes be the better choice.
� B. AND WHILE NO NEW FUNCTIONALITY WAS ADDED TO *YOUR* SYSTEM, APPLICATION OF
� NAMING STANDARDS MAY HAVE MADE IT POSSIBLE FOR SOMEONE DOWNSTREAM IN THE
� MANAGEMENT REPORTING WORLD TO USE YOUR DATA (OR USE IT CORRECTLY FOR THE
� FIRST TIME). CLEARLY, THAT'S THE (BROAD) INTENT BEHIND DS065 AND DATA
� MANAGEMENT IN GENERAL.
This is one area where the European standards have not been deficient.
� B. DON'T BE SO SURE THAT NO VALUE TO THE CUSTOMERWAS ADDED. MANY GROUPS DIDN'T
� EVEN USE TO PROVIDE FORMAL INSTALL KITS, LET ALONE VMSINSTAL KITS, IN YEARS
� PAST. DATA CENTER GROUPS AND RECEIVING IS ORGANIZATIONS STRUGGLED TO GET
� SYSTEMS INSTALLED (DELAYING CUSTOMER AVAILABILITY LONGER THAN A KIT WOULD TAKE
� TO WRITE!); THE APPLICATION GOT OFF ON THE WRONG FOOT, AND IN SOME CASES WAS
� DELAYED, REJECTED AND EVENTUALLY EVENTUALLY REWRITTEN OR PURCHASED (ALL FOR WANT
� OF A HORSE).
"Years past" doesn't reflect the present. We in Europe have done all this, and
more for some years. This scenario is not an issue here in Europe.
� SOMETHING AS TRIVIAL AS KIT NAMING AND/OR THE IDENTIFICATION OF THE VERSION
� WITHIN THE EXECUTABLES (/IDENT) CAN CAUSE DAYS OF SPURIOUS PHONE CALLS OR
� DEBUGGING IF NOT DONE. THESE DELAYS TRANSLATE TO LOST USAGE DAYS FOR THE USER/
� CUSTOMER.
Again, this scenario is not an issue here in Europe.
� Note 1765.2 Quality within Digital.... 2 of 8
� SQM::MACDONALD 11 lines 13-FEB-1992 10:31
� --------------------------------------------------------------------------------
�
� Re: .0
�
� There is not enough information given about the standard to be able to
� answer your question about cost. For example, are details of this
� standard things we should have been doing all along? Will not doing
� it cost us even more in the long run? Can you shed some more light
� on this.
�
� Steve
�
� TWO EXCELLENT QUESTIONS!
Again, this scenario is not an issue here in Europe.
� Note 1765.3 Quality within Digital.... 3 of 8
� CHRCHL::GERMAIN "Improvise! Adapt! Overcome!" 7 lines 13-FEB-1992 10:50
� --------------------------------------------------------------------------------
� What these standards/methods represent is the framework around which
� you build quality and consistencey. They are not an end unto
� themselves.
�
� The necessary catalyst is the willingness to do it.
�
� Gregg
�
� BRAVO!
Agreed, but once again, this scenario is not an issue here in Europe. Further,
there is no such air of compromise here as regards this standard. It is not
seen as a framework, it is seen as an absolute. There is no case for
retro-fitting a framework.
� Note 1765.4 Quality within Digital.... 4 of 8
� MAJORS::ALFORD 79 lines 13-FEB-1992 10:50
� -< some thoughts and feelings on the matter. >-
� --------------------------------------------------------------------------------
� WRITTEN FEEDBACK. NOR HAVE YOU MENTIONED THE TWELVE PAGE (POSTSCRIPT WITH
� MICROSCOPIC VAX DOCUMENT TABLE FONT) MEMO WHICH RESPONDED TO EACH AND
� EVERY PIECE OF FEEDBACK.
I have neither seen, nor heard of this document.
� WHAT WAS DEFERRED (IN WRITING = *NOT* IGNORED)
� WERE ANY *NEW* ITEMS, BECAUSE I WOULD HAVE FELT OBLIGATED TO GO THROUGH
� GENERAL REVIEW AGAIN IF SUBSTANTATIVE CHANGES WE MADE AS A RESULT OF THE
� GENERAL REVIEW AND THE STANDARD HAD TAKEN TWO YEARS OF NEGOTIATION ALREADY.
� WHAT WERE ALSO LEFT OUT WERE ITEMS WHICH HAD ALREADY BEEN DISCUSSED OVER AND
� OVER AND FOR WHICH NO COMPROMISE COULD BE NEGOTIATED.
I'm afraid I have to take issue with this. It is apparent that the standard is
flawed. I say this partly because of the fact that this topic exists, and
partly because of the opinion I have been privy to during the course of my
work. I shall spell out the flaws, from a European perspective, as I see them,
later. It is clear that the items on which compromise was not reached were
important. Further, the issues causing that lack of compromise have not gone
away. As I said, this standard is not seen as a framework, it is an absolute,
and in some areas, it is inappropriate. It does rather seem that you've
decided to make this standard, in the knowledge that there are problems,
rather than try to get it right. I realise that's easy to say from this
position, but then, it's us that's trying to deal with the anomolies.
� AS DOCUMENTED ON PAGE ii, I OWN THE STANDARD. AS DISCUSSED ABOVE AND IN
� MY MAIL MESSAGE TO YOU OF 04-NOV-1991, I DO *NOT* OWN IMPLEMENTATION OF
� IT IN ANY ORGANIZATION EXCEPT CORPORATE FINANCE IM&T. THERE IS NO COMPANY-WIDE
� BODY TO "POLICE" RELEASE MANAGEMENT, BUT THERE ARE AREA RELEASE MANAGEMENT
� FUNCTIONS. NOW, IT IS POSSIBLE THAT RIGHTSIZING/WORK FRANCHISING HAS LEFT
� THE EUROPEAN RELEASE MANAGEMENT ORGANIZATION LESS WELL STAFFED THAN WE ALL
� WOULD LIKE, BUT IT'S EUROPEAN IM&T MANAGEMENT WHO NEEDS TO HEAR THIS MESSAGE.
I hear what you say, but, there seems to be little willingness to buck the
trend, and to decide not to adopt the standard here in Europe. This, I
believe, is because they don't realise either the quality of standards we
have, or the effects that the retro-fitting this new one will have. Nor, I
believe, do they realise how inappropriate this standard is to some of our new
products. As the source and owner of this standard, you can't simply pass
responsibility for policy off like that. It is a Corporate standard, and as
such, it will be enforced by the bean-counters. The people who really know
what's what, get no say. In other words, you issued this as a standard, it
will be enforced, the standard will make the policy.
� FACVVV IS A GREAT IDEA, BUT IT CAME IN DURING THE GENERAL REVIEW, IS CLEARLY
� A NEW IDEA AND A MAJOR CHANGE, WAS NOT IN EITHER STANDARD AND THEREFORE NOT
� IN THE LCD AND WOULD NOT HAVE BEEN ACCEPTED BY THE US. A SIMILAR IDEA IS
� THE SUFFIXING OF THE FAC CODE WITH A TWO NATURAL CHAR LANGUAGE IDENTIFER, BUT
� THIS WAS ALSO THOUGHT TO BE TOO GREAT A CHANGE TO AVOID A COMPLETE REPEAT
� OF GENERAL REVIEW.
This is not a new idea by any means. We have been using it in Europe for
years. Again, the benefits are so obvious, I can't see how you can justify not
including it. It is hardly, as you assert, a major change. The structure as
the standard has decreed, is not always appropriate to an application. The
choice of directory structure should be driven by the needs of the
application, not a standard. Where a standard does have a place, is in the
naming conventions used in that structure, and the logicals that point to it.
Again, please bear in mind that this structure is an absolute, and leaves no
room for manoeuvre. any standard applying to directory structure should allow
sufficient flexibility to fit any application.
� NOW, FOR HOW TO SOLVE YOUR PROBLEM. THE INTENT OF THE US ROOTED DIRECTORY
� STRUCTURE WAS TO SOLVE EXACTLY WHAT YOU WISH TO SOLVE. THE PRODUCTION
� VERSION WOULD BE HAPPILY RUNNING AWAY IN DISK$SOMETHING:[FAC...], WHILE
� A TEST VERSION (THE STANDARD APPLIES TO PRODUCTION ENVIRONMENTS, ONLY) COULD
� BE SET UP IN DISK$SOMETHING:[FAC_TEST...]. ONLY THE LOGICAL FOR FAC_ROOT
� NEED BE MANIPULATED, ALL OTHER LOGICALS ARE BASED UPON IT. WHEN TESTING IS
� COMPLETE YOU CAN BACK [FAC_TEST...] AND RESTORE IT INTO [FAC...] AND YOU'RE
� DONE.
�
� NOW, THE LOGICAL NAME TABLE CONFLICT IS A BIT TRICKIER, BUT YOU COULD USE
� PROCESS LOGICALS FOR YOUR _TEST USERS - THE TEST SETUP DOESN'T HAVE TO
� MEET THE STANDARD. YOU COULD, PRESUMABLY USE A PROCESS LOGICAL TO
� OVERRIDE ONLY FAC_ROOT. OR YOU COULD USE YOUR FACvvv SYNTAX ON THE TEST SIDE.
� ACTUALLY YOU COULD PROBABLY EVEN USE SEPARATE RIGHTS ID'S (NO NAMING
� CONVENTIONS AT ALL, YET) TO CAUSE ONE BATCH OF USERS TO SEE ONE LOGICAL
� NAME TABLE, WHILE THE OTHERS SEE ONLY THE OTHER.
I don't accept any of this. As soon as you start having to jump through hoops
to meet a simple business requirement, it brings the cause of
the jumping into question. The test setup has to mirror the live one as
closely as possible or it is of diminished value. We had the means to do that,
and this standard takes it away.
� WELL, IF THE ABOVE TECHNIQUES DON'T WORK, TRY CALLING THE AUTHOR OF THE
� US DOCUMENT (GLEN DOTTEN @DDD) - HIS EXPLANATION WILL BE BETTER THAN MINE.
� AND IF THAT DOESN'T WORK, IN THE WORDS OF THE NIKE AD CAMPAIGN "JUST DO IT"
� (FACvvv), AND PLEASE LET ME KNOW THE RESULT.
An interesting comment, however, it misses the point. We are not permitted the
luxury of "just doing it", the standard is going to be applied, as is, to new
products. Worse, it is going to be applied retrospectively. This area, amongst
others, is one of high concern with respect to retro-fitting. Calling the
author, and having the rationale explained will change nothing.
� AGAIN, I OWN THE STANDARD, BUT AREAS OR EVEN ORGANIZATIONS WITHIN THEM OWN
� SETTING A POLICY AND MARCHING TO IT. I DON'T KNOW THIS REPLY'ER, BUT FROM
� ELF I SEE HE'S IN PUERTO RICO. CONTACT PAUL FARRELL@AKO OR JIM HOGAN DIRECTLY
� IF YOU FEEL THAT "RIGHTSIZING" HAS PUT THIS STANDARD, OR WHAT IT COULD BE,
� AND/OR ITS GOALS, AT RISK. JIM HOGAN CHAIRED TO DIS MC SUBCOMMITTEE WHICH
� DEVELOPED THE INITIAL SET OF RELEASE MANAGEMENT PRINCIPLES SUPPORTED BY
� THE AREA RELEASE MANAGEMENT GROUPS AND (HOPEFULLY) THIS STANDARD.
Once more, I must point out the difficulties in this. A corporate standard is
just that, a corporate standard. Deviation is not a trivial matter. As has
been pointed out, we already have very good standards in Europe, These
standards have evolved over the years, and match the business needs well, if
not exactly. They were by no means perfect, and they certainly weren't adhered
to by every subsidiary. However, they have now been scrapped. The definite
message I'm getting here, from the above paragraph, and the tone of your
reply, is that you accept that there will be deviations from this standard. I
should like to point out, that this throws the validity of the whole standard
into question. More importantly, it makes the entire concept of retro-fitting
a nonsense.
Most importantly, I suppose, there has to be a willingness by the senior
management in Europe to consider deviation. Politics being what they are, I
doubt such a willingness exists, any more than the knowledge to believe in or
back said deviation. If one senior manager has decided it's the way to go, how
many of those below, assuming they understand the problem, are going to argue
the contrary view? In fact, it's my opinion that, once the dissent and
counter-argument has filtered its way through the levels, it's so diluted as
to be pointless. This is one of the reason I believe in NOTES so strongly,
nothing is diluted. This standard, had it been debated in a public forum such
as this (as it should have been), would, I suspect, be a very different animal.
I wonder if the full impact of this standard on the corporation is understood.
In view of the impact, I don't think it was argued sufficiently, and I don't
believe the imput was broad enough, or from a low enough level, ie from the
sharp end.
� AGAIN, THE INTENT WAS NOT ABANDON THE EUROPEAN APPLICATION ENVIRONMENT NOR
� EVEN TO EXPAND IT NOR EVEN TO COMBINE IT WITH THE US STANDARD, BUT MERELY TO
� IDENTIFY THE COMMON REQUIREMENTS IN ORDER TO SERVE THE GOAL OF ALLOWING
� SOFTWARE TO BE SHARED ACROSS GEOGRAPHIES MORE READILY. PERHAPS THE EUROPEAN
� REPRESENTATIVE WAS TOO GIVING, PERHAPS THE EUROPEAN REVIEWERS DIDN'T TAKE
� ANY OF THE FIRST SIX DRAFTS SERIOUSLY AND ONLY THE OFFICIAL DEC STD IMPRIMATUR
� AWAKENED THEIR EYES, BUT I CAN'T WONDERING IF THE SAME SET OF REQUIREMENTS
� IF MERELY INCLUDED IN THE EUROPEAN STANDARD V2 WOULD HAVE AROUSED SUCH
� LANGUAGE AS "ABANDON", "NEW STANDARD", "ANOTHER ENVIRONMENT" AND "ABSOLUTE
� MADNESS".
This, again, is a very interesting, and illuminating comment. I wonder how
many of the senior managers in Europe, who are insisting on compliance, and
the throwing out of the European standard, are aware of this. Very, very few,
if any, I suspect. Your comments about the European reviewers are possibly
correct, I can't really comment on that. However, it is clear that many of the
people now dealing with this standard, were not involved in the review process
at all. The same set of requirements would not have been included in the
European standards, since they would invalidate them. They are, after all,
incompatible. In the event that they were, I believe your presumption is
correct.
Most importantly, in view of the above paragraph, just what case is there for
retro-fitting this standard to existing applications?
Ok, here are some specific reasons I believe the standard is flawed. These
areas, I believe, will have a negative impact on the business, and will cause
us trouble in the future:
1) By enforcing dollars in logicals it wipes out future compatability
with ULTRIX. Rumour has it that VMS will replace $ with _ soon. Some
layered products are already following this route.
2) It fails to provide for multiple physical discs, for either
perfomance or security reasons.
3) Its reference to SYS$MANAGER instead of SYS$STARTUP is wrong.
4) It does not allow for Migration kits (as in VMS versions), nor does
it allow for BOY/EOY kits.
5) It demands ACL's and then specifies no names for them, this
conflicts with other rigid naming conventions
6) It does not specify names for product-specific queues
7) It makes no provision for multiple installations of a product on one
cluster ie. Area/Subsidiary versions of the same product.
8) It makes no provision for distributed applications, where different
subsets of a product are distributed area wide. We have one such
application, under design at the moment.
9) There is a requirement for product version numbers, but no standard.
Assuming the standard is here to stay, as is, how, specifically, are we
supposed to deal with those areas that directly impact the business, and under
what circumstances can we not comply with the standard, both retrospectively,
and for new products?
I still agree with the base noter, in that I cannot see what benefit there is
in retro-fitting this standard, especially since, by your own admission, it
isn't binding, and the issues we have to fix, might well be included in the
next release of it.
All of these issues (and it appears, all of the standard) are open to local
interpretation. This is fine, just so long as those doing the internal audit
agree with the interpretation of those making the changes. Any one care to
start a book on that?
Not only that, all this really addresses is environment, not an area we in
Europe have major problems in at the moment. We *do* (all of us) have a
problem with software quality, quite another issue, and this standard won't
make any major impact on that, at all. At least, that is, from a European
perspective.
Regards, Laurie Brown.
QA Group, Brussels.
PS. Please don't forget the disclaimer at the start of this reply.
|
| 1765.16 | | SBPUS4::MARK | | Wed Feb 19 1992 07:45 | 64 |
| ********* My opinion, not my Manager's, my group's or anyone else's *********
>Not only that, all this really addresses is environment, not an area we in
>Europe have major problems in at the moment. We *do* (all of us) have a
>problem with software quality, quite another issue, and this standard won't
>make any major impact on that, at all. At least, that is, from a European
>perspective.
Without wishing to take anything away from the rest of Laurie's note, the above
paragraph is the most important in my opinion.
A standard should be a means, not an end. ensuring that a product conforms with
a standard only proves that it conforms with that standard, it has no bearing on
the quality or appropriateness(sp?) of that software.
Any quality system should take into account the needs of the business, and the
restrictions of the customer requirements/budget. The result of the rigidity and
occasionaly inappropriateness of this standard, is that many decisions not to
retro-fit it to existing products will be taken. This is a pity, since many of
those products could have done with some improvment. Had the standard been
closer to current practices and more compatiable with other similar documents,
then perhaps it would have been applied to all our products.
We need to spend our money, our time and our people on getting the finished
product right, not on a standard which adds nothing to this finished product. At
a time when money is short, it seems strange that we are investing this much
resource into something that in many areas is deficient.
The issue, in my opinion, is much wider than DEC Std 095, which at least had the
right intentions behind it, and in a lot of cases has some good ideas. I believe
that we (Digital) have a tendency to pay lip service to quality. We are
concerned with showing all the quality standards and procedures and whatever
else we are writing and installing and with talking about how much we believe in
quality. We should be concerned with actually achieving quality, not documenting
it for the sake of it.
It is basically a very simple ideal and a very simple thing to achieve. It seems
to be giving us a lot of trouble even working out how to achieve it never mind
starting to.
UK DSE is now working on what we believe will be a system which will help us to
achieve that end. To do so, we are talking to and working with people who
actually do that work, not their manager or supervisor or person responsible for
quality, but actually to the sharp end. But it will apply to us, because it fits
what we are doing and the way we do it. It should not conflict with what we
already do, it should add to it. I have high hopes that it will have a marked
effect on the quality of the work done by this group and it's various centres.
It would be inappropriate, however, to assume that it can be applied to all
other organisations blindly, it may form a basis for other similar systems
within such organisations, it may not, but it can't just be applied.
Unless a quality standard or procedure makes sense to the person using it, is
easy to understand and follow, then it will eventually fall by the wayside
having had virtually no effect. All standards and procedures should be easily
understood, simply followed, workable and appropriate. They should be maintained
in this state always. Problems should be fixed immediately otherwise money is
wasted following the wrong route and then coming back. They MUST be popular at
the sharp end. If people believe in your standards, then you just solved 75% of
your problem.
End of sermon.
M.
|
| 1765.17 | Substantiate this with facts please | GENIE::MORRIS | | Wed Feb 19 1992 09:29 | 24 |
| Will someone send me the official communication that states that
DEC Standard 095 should be implemented retrospectively in Europe.
I find this suprising, as I was present at the European IM&T Policy
board that specifically decided that NO RETOSPECTIVE action should
be taken for Legacy applications within Europe on the basis of cost.
That is to say the board correctly identified the exact concerns you
are now raising and took the correct and appropriate action.
Only new applications and those under revision would be considered.
If there is any communication to the contrary it is incorrect and I
will personally clarify the situation.
If there is no formal basis for this discussion then I need to
understand why we are wasting our time debating it.
Chris.
IM&T
European Systems
Compliance Consultant
|
| 1765.18 | | SBPUS4::MARK | | Wed Feb 19 1992 09:36 | 21 |
| > Only new applications and those under revision would be considered.
Does "under revision" include those applications for which any alteration to
functionality is to take place ? To explain, If I have an application which has
not been altered to DEC Std 095 level, and then the users request some
additional functionality, do I then have to apply the whole of DEC Std 095
before I may revise the product in accordance with the user's wishes ?
What does "considered" mean in this context ?
> If there is no formal basis for this discussion then I need to
> understand why we are wasting our time debating it.
We are not wasting our time. You have already stated one piece of information of
which I was not aware, more may become apparant. If nothing else, listening to
other people's feelings about quality and DEC Std 095 adds to my understanding
of the issues involved.
M.
|
| 1765.19 | "considered" | SGOUTL::BELDIN_R | Pull us together, not apart | Wed Feb 19 1992 09:46 | 24 |
| re .18
>> Only new applications and those under revision would be considered.
>Does "under revision" include those applications for which any alteration to
>functionality is to take place ? To explain, If I have an application which has
>not been altered to DEC Std 095 level, and then the users request some
>additional functionality, do I then have to apply the whole of DEC Std 095
>before I may revise the product in accordance with the user's wishes ?
>What does "considered" mean in this context ?
I read "considered" as a requirement for an application by application
decision process which may or may not result in a given existing
application being brought into conformance with STD095 when it is
revised. This is obviously not an official interpretation, just one
man's opinion of what seems like common sense.
Let's keep our minds clear as we continue to examine the facts and the
issues.
fwiw,
Dick
|
| 1765.20 | Clarification | GENIE::MORRIS | | Wed Feb 19 1992 10:24 | 46 |
| Now lets calm down a bit please. I am trying to help here in three ways
1. If you have a different view of what the DEC standard 095
implementation is from what I know to be reality I need to help
correct that.
2. If 1) is true I need to know how that came about so I can
investigate why this is, so I can improve the communication process
so it doesn't happen again. Mis/non communication is one of the
largest time wasters in DEC.
3. If there are communications which state anything different I need to
have sight of them also so I can again correct any
misunderstandings.
As to the discusion on the word considered, let me try and clarify
that:-
Consider the different status applications could be in:-
1. New and not implemented -- DEC Standard 95 applies
2. Old and to be retired (legacy) -- DEC Standard 95 does not apply
3. In developement or functional rev -- Business justification as
why DEC 095 is not
appropriate ( cost,etc)
Otherwise it applies.
Standards are not absolutes. They are reference points from which
discussions about justifiable deviations can begin.
Chris...
PS. By the way I don't own Dec Standard 095, If you wish to take up
discussions on its content,history and relevance you should contact
John Harrison @FYO of Release management.. He is you European Rep
and as such owns this on behalf of Europe.
|
| 1765.21 | | SBPUS4::MARK | | Wed Feb 19 1992 10:43 | 37 |
| > Now lets calm down a bit please. I am trying to help here in three ways
Ummm, I am calm. Are you reading something into what I said ? If I wasn't clear,
then I apologise. I am not upset, I am merely trying to get a handle on what is
being said.
> 1. New and not implemented -- DEC Standard 95 applies
Ok.
> 2. Old and to be retired (legacy) -- DEC Standard 95 does not apply
Ok
> 3. In developement or functional rev -- Business justification as
> why DEC 095 is not
> appropriate ( cost,etc)
>
> Otherwise it applies.
To whom ? And is the business justification solely cost driven ? In which case,
what are perceived as the benefits that 095 will give us that we would not have
otehrwise enjoyed ?
> Standards are not absolutes. They are reference points from which
> discussions about justifiable deviations can begin.
Surely 095 is put forward as an absolute if 1. is true ?
In which case, Laurie's specific concerns raise their head again.
If the Std is not an absolute, should it not be called a guideline and treated
as such ?
But, as I said, I feel the issue is bigger than just 095.
M. - Solent, England, Not upset.
|
| 1765.22 | | WUMBCK::FOX | | Wed Feb 19 1992 11:08 | 14 |
| > Consider the different status applications could be in:-
> 1. New and not implemented -- DEC Standard 95 applies
> 2. Old and to be retired (legacy) -- DEC Standard 95 does not apply
> 3. In developement or functional rev -- Business justification as
> why DEC 095 is not
> appropriate ( cost,etc)
What about not new, but not about to be retired, and not being
drastically changed? In other words, applications already in place
for which there are not plans of retirement. I have to believe
a great many (most?) fall into that category. What is the
justification *for* 095? Where is the gain/payback?
John
|
| 1765.23 | Before I confuse things further - official memo | GENIE::MORRIS | | Wed Feb 19 1992 11:20 | 64 |
|
I N T E R O F F I C E M E M O R A N D U M
Date: 05-Feb-1992 04:28pm CET
From: John HARRISON @FYO
HARRISON AT FNYA1 @EHQMTS @FYO
Dept: Information Management
Tel No: (885)-6818
TO: See Below
Subject: U:I: DEC-std 095 - Implementation and Compliance.
*********************************************************
PLEASE ENSURE THAT THIS MESSAGE IS PASSED TO ALL RELEVENT
PEOPLE WITHIN YOUR ORGANISATIONS - many thanks.
*********************************************************
After considerable feedback from development and portfolio groups, the
European IM&T Policay Board Meeting in December, discussed the compliance
to DEC-std 095 and the following agreement was reached -
the elements which refer to naming conventions and directory structures
(i.e. requiring significant design changes) can be excluded from
compliance for existing applications.
However, a documented justification for such non-compliance MUST be
provided in the event of subsequent Application Audit.
It is expected that existing applications will be compliant with ALL
other elements of the standard .
All new applications (those which have NOT passed the design phase before
the end of February 1992) must be compliant with ALL elements of the
standard - this is based on the fact that the original announcement for
the standard was made in June of 1991.
Where major re-engineering is scheduled to take place on existing
applications, it is expected that an attempt to achieve full compliance
be made, and that any reasons for non-compliance are justified in writing
for possible future reference by audit.
It is on the basis of this agreement that internal audit will carry out
applications audits after the 1st. March 1992.
Many thanks and best regards - John.
Distribution:
TO:
ALLEN ATWELL @VBO Daniel COETSIER @FY MICHEL CRUBEZY @EVO steve fuller @geo
FREDERIC GODET @NEU BARBARA HUCKLE @UCG Brad LENTZ @FYO franz peter @rto
christiane quarterm BERND STEPHAN @RTO MARCO VACCARO @MIO GHISLAIN DE VINCK @
CHARLES WHITEHEAD @
CC:
Alfonso DIIANNI @FY martin kelmanson @r Dave TOUGH @FYO andrew tweedie @ayo
rob watts @geo
|
| 1765.24 | | PLAYER::BROWNL | On a whinge and a prayer | Wed Feb 19 1992 11:56 | 9 |
| I have already commented on that memo in my reply to John Newman, who
copied it in the body of the text in his earlier reply. In my opinion,
it confuses the matter further. Please see my earlier reply for
details.
I shall comment more fully on your earlier notes later, I've run out of
time.
Laurie.
|
| 1765.25 | An offer | GENIE::MORRIS | | Wed Feb 19 1992 12:33 | 23 |
| Right, I have read through all the replies here carefully this time
and see that we indeed have a lot of confusion (which I seemed
to add to - apologies).
Now I will make the following offer. If the European contingent will
get together (logically that is) and put a well reasoned,objective,
constructive proposal as to how we should move forward on this issue I
will ensure it gets reviewed at the next IM&T policy board meeting.
I am not saying that this will change anything, or that I agree with
all thats said, just that I will ensure that it has visibility and
a response. This is probably a better course of action than trying
resolve it here.
Given the level I would be taking this to, I wouldn't expect to see any
disclaimers like my "my manager doesn't necesserily agree to this"
Its up to you if you wish me facilitate this. I await you response.
Regards,
Chris
|
| 1765.26 | | PLAYER::BROWNL | On a whinge and a prayer | Thu Feb 20 1992 05:37 | 66 |
| RE: <<< Note 1765.25 by GENIE::MORRIS >>>
� Right, I have read through all the replies here carefully this time
� and see that we indeed have a lot of confusion (which I seemed
� to add to - apologies).
There is indeed! However, I think it's fairly clear where the specific
areas of confusion lie.
1) There are concerns with the standard itself, that a body of people
feel need to be addressed before the standard should be implemented.
2) There is confusion as to when and where this standard must be
retro-fitted to existing applications.
3) There is a body of opinion in Europe that says that it is a waste of
time and money to apply the standard to *any* existing products.
� Now I will make the following offer. If the European contingent will
� get together (logically that is) and put a well reasoned,objective,
� constructive proposal as to how we should move forward on this issue I
� will ensure it gets reviewed at the next IM&T policy board meeting.
�...
� Given the level I would be taking this to, I wouldn't expect to see any
� disclaimers like my "my manager doesn't necesserily agree to this"
Thanks for this. However, with the best will(s) in the world, I can't
see this happening. The reason for this, and the disclaimers you've
seen, are rooted in the structure of the business, and the nature of
mankind.
The scenario is this, a Corporate standard is issued, and the word goes
out to comply with it. Managers of the level of the people on the
distribution list on John Harrison's mail quoted here, will pass the
word down the line. Project leaders tell the drones. Now, ideally, if a
drone has a problem, he tells the PL, the PL, tells the manager, and so
on up the line. Unfortunately, it doesn't always happen like that. For
a variety of reasons, perhaps the problem isn't fully understood, the
implications aren't appreciated, time is tight, there are other more
pressing matters, the message gets diluted, whatever. The feedback
isn't being escalated to those that issued the edict in the first
place.
I make no judgements here, and I'm not singling any part of Digital
out, but this is facet of things that's everywhere. the result is,the
drones, when commenting in a forum such as this, have to put a
disclaimer in, because they definitely aren't talking for their
managers or Project Leaders.
In the end, it comes to this. It is apparent that you can see we have a
problem, and it's apparent that you, like the rest of us, want to see
it resolved for the good of Digital. However, I believe that only the
implementing managers can deal with this, and that they must speak for
themselves. It is they that decide what happens in their areas, and
what response is sent back up the tree. I believe in the ODP, and "do
the right thing", but I won't go behind my manager's back and put words
in his mouth.
I believe a statement from you or John Harrison is called for, to the
original distribution list, and your request for feedback and proposals
should be in there. I think that that's the only way there will be a
(logical) meeting of minds, and that any proposals will result. Nobody
else has the authority to make the necessary decisions.
Regards, Laurie Brown
QA Group, Brussels (acting independantly again).
|
| 1765.27 | who is it who has the problem ? | GENIE::MORRIS | | Thu Feb 20 1992 06:47 | 29 |
| Laurie,
Nice reply, and I very much agree and support you view that
that the most appropriate channel to drive this issue is back through
your management chain. The only question I could ask, is if you believe
that why aren't you?
The reason I made the comment about disclaimers is excactly the point
you make. It may be there are very valid reasons why you management
have chosen to accept this Standard and support it. If that is the
case then the only appropriate course of action would be for you and
your colleagues to express your concerns and help them understand
the issues and suggest the actions they could take.
As for not wanting to "go round" you manager I am afraid in a way you
already are by expressing your views in a public notes file. Thats not
a criticism, merely a statement of reality. I have read it, I am one of
those people up there with the other people on the dist list, and its my
job to try resolve this type of issue. Therefore the wheels are already
in motion.
Again I will help in anway I can to ensure resolution of this
conflict. But I am not sure yet where in reality it lies.
Chris
|
| 1765.28 | What's the scope of this standard? | FROCKY::ROBERTS | Eur.-Ing. | Thu Feb 20 1992 10:58 | 31 |
| Without meaning to interrupt the flow of debate, may I just ask for
some clarification . . .
Where _exactly_ does this standard apply? From previous notes, I got
the distinct impression that this "DEC STD 095" applies to all
programming effort _anywhere_ in the corporation.
Does this now mean:
that Engineering will use the standard in development
of layered products? (and retrofit it to existing,
non-retired layered products, as well?)
and SWAS will use it in developing software projects for
customers?
and Internal applications groups will use it?
Or does it only apply to a sub-set of the above?
If this question has already been answered in the preceding replies,
then please point me to the relevant reply; I'm afraid that I have
found the discussion so far to be somewhat confusing.
Regards,
n.
|
| 1765.29 | Dan Infante Reply | IAMOK::ABROWN | | Fri Feb 21 1992 16:35 | 25 |
|
THIS NOTE HAS BEEN POSTED AT THE REQUEST OF DAN INFANTE, VP IM&T
As the responsible manager for Digital's Internal Systems development,
I have read your Notes correspondence regarding DEC STD 065 and 095.
You can be assured many hours of heated debate from across the World
went into discussing both the technical feasibility and the
implementation of these policies.
My staff will respond to specific concerns raised and Peter Cook, IM&T
Manager for Europe, should receive feedback and communications
regarding concerns relating to local interpretation.
If you would like to communicate directly to me my address is:
Dan Infante @MSO or my VAX mail account is CORMTS.
Regards,
Dan Infante
DIGITAL INTERNAL USE ONLY Document
|
| 1765.30 | So why can't Infante post his own reply? | EDINA::SCOTT | | Sat Feb 22 1992 22:21 | 1 |
|
|
| 1765.31 | You got Dan's address, ask him | FASDER::AHERB | Al is the *first* name | Sat Feb 22 1992 23:20 | 8 |
| >So why can't Infante post his own reply?
1. Where did it say that this (part of a memo?) was a direct
reply to this conference?
2. Whether it was meant as a reply in this conference or not is
not as important as the fact that Dan has stated his position
and offered those who differ to discuss with him their opposition.
|
| 1765.32 | An update... | PLAYER::BROWNL | Wriggle, wriggle, wriggle. | Tue Apr 07 1992 12:37 | 18 |
| A quick update here.
I just left a meeting attended by other people from our group in
Belgium, and by John Newman, John Harrison, and Dave Tough. Yesterday
they were at the Solent in the UK, and tomorrow they will be at
Ferney-Voltaire in France.
There will be an announcement on the official status of DECSTD 095 at
some time in the near future. I won't pre-empt that any more than to
say the retro-fitting is seen as inappropriate, and that the standard
is in the review phase.
I am very pleased with what was a positive, constructive and
informative meeting. I would also like to say that I appreciate the
efforts to improve the standard, on the part of those responsible for
it, John Newman having flown over from the States especially.
Laurie.
|