I
believe that this e-mail demonstrates a serious problem that the TC must address
before committing further effort to final reviews of the Capabilities and
DEXs. It arises from the impossible co-ordination task that Trine Hansen was
given trying to regulate DEX development work under the OASIS
structure over the last 18 months.
Capabilities were intended to provide an
intermediate stage between the AP 239 modules and the business orientated
DEXs. The aspiration was to develop reusable components to
provide consistent modelling solutions for business requirements that
repeated across the DEXs. Because we never achieved an even
distribution of modelling skills across the DEX teams, we have never been able
to conduct co-ordinated reviews of individual Capabilities to ensure that
they are fit-for-purpose across multiple DEXs. Worse, we have allowed a
proliferation of Capabilities without defining the requirement for each in terms
of the functionality expected of the Capability across its DEX
customer base. Thus, for example, we have Capabilities 59 and 64, both
good pieces of work in themselves but offering completely different solutions
for what should clearly have been developed as a single common resource. There
are many other such examples in the Capability list. This is not a criticism of
the modellers who created the individual Capabilities but of our organisation
that has let precious modelling resource be wasted in this fashion. It has left
me, as DEX Team 4 Leader trying to define DEX 9, with conflicting options for
how I should model reporting the outcome of an
activity.
We
should not be undertaking formal reviews of individual Capabilities simply
because they are there on DEXLIB. Similarly, we cannot finalise any DEX until
all the Capabilities from which it is built are stable. I believe we
need to do a check to confirm that there is a genuine requirement for each
one. I would expect this check to result in the recommendation for some to
be merged (as with these two) and others to be dropped completely. Only
when each Capability has been confirmed as a useful common resource should
it go forward for review to confirm completeness and good Express. I will
then be confident that I can proceed with the final build of my DEXs from
components I know to be stable.
Nigel
Hi
Tim
Are we agreed that we
change the product_as_realized capabilities to
product-as_individual?
I do not want to make
the changes and then undo them.
Also, I am confused as
to the difference between
Capability
(C059):- representing_work_output
Capability
(C064):- representing_work_done
They seem to have
significant overlap
-----Original
Message----- From:
Tim Turner (E-mail)
[mailto:timturner11@bellsouth.net] Sent: 03 September 2004 07:41 To: 'Gordon
Robb'; 'Tim Turner (Offsite)'; 'Tom Hendrix
E-mail' Cc: 'Robert M Mcbride
E-mail'; 'Plcs E-mail' Subject: [plcs] RE: Comments on DEX 8 -
Overview - V3
Just managed to get
mail to send(!)
I made some comments
inside..
-----Original
Message----- From: Gordon
Robb [mailto:gor@lsc.co.uk] Sent: 02 September 2004
07:33 To: Tim Turner
(Offsite); 'Tom Hendrix E-mail' Cc: 'Robert M Mcbride E-mail'; 'Plcs
E-mail' Subject: Comments
on DEX 8 - Overview - V3
Just had a look at
V3 of your overview.
In the Product
Configuration block - why is their a requirement to utilise C068 as well as
C067 [Tim
Turner:] Good point gordon, given all of C068 will be present in C067,
and that the latter is surely a requirement, I agree we do not need the
former to be specified also.
On the original
diagram, both representing and referencing versions of these & other
capabilities were present and I was trying to build in some consistency.
In the Information
Management block - C074 should be replaced with C016 (Representing instead
of referencing person_org) [Tim
Turner:] Ok
The Manufacturing,
test & inspection records block should be changed to Documentation
of Product (common generic approach as per DEX 1) - also C011 and C075 are
not required. [Tim
Turner:] Ok - title now consistent. I was assuming that
C011 was also being used for in-service inspection/testing as well as
design - but the capability only refers to the design (part) not to
individual. Deleted.
The Identification
of Design block would benefit from being retitled View of Prod
Structure (this is in alignment with DEX 1) [Tim
Turner:] Well I would rather keep "Identification" or
"Referencing" the Design, as this is the functionality that the capabilties
are providing here rather than the representation of a
view.
The use of C008
Referencing Part or Slot - is this still valid as you have split the
'representing' equivalent C002 into 2 caps (parts retaining the 002 id
and currently slots is 0XX) [Tim
Turner:] This is fine. However, we I need to raise an issue on C008 to
use C087 (Slots) - only Parts is related at present.
The Product
Structure block would benefit from being retitled Product
Individual. [Tim
Turner:] Can I suggest we name it View of Product
Individual?
The scope
statement for the Dex states that breakdown of individuals are
required, so I assume that we need to add C004,
right?
The 'Environment'
block is not required. [Tim
Turner:] Ok - removed.
Should
the requirement to record non-feedback usage (observed states) &
location of the realized product also be removed from the scope statement
since these are handled elsewhere?
he
'Transmission of the product data' block requires retitling to 'Transmission
of the Product' (as per DEX 1) [Tim
Turner:] Ok - done
I am, obviously,
trying to get the nomenclature used within DEX 1 and 8 common as
near as possible. [Tim
Turner:] Yes - I also had that in mind, those sections for Dex 1
were derived from the need to bring order to the capability usage within the
Dex based upon their functionality.
-----Original
Message----- From: Tim
turner [mailto:timturner11@bellsouth.net] Sent: 01 September 2004
04:57 To:
timturner11@bellsouth.net; 'Tom Hendrix E-mail' Cc: 'Robert M Mcbride E-mail'; 'Plcs
E-mail' Subject: [plcs] New
DEX 8 - Overview - V3
Attached is the
latest Dex8 overview offering.
Dex 8 has a
requirement to be able to represent usage and maintenance
history.
At present I
have interpreted maintenance history to be a set of
representing_work_done. This is obviously done with respect to the scheme
that has been devised for the product, though this is not necessarily the
same thing (i.e. scheme is not providing a record of what *has* been
done). The Introduction of this capability
(representing_work_done) states "The purpose of the
"Representing work done" capability is to describe how a record of work
that has been done can be represented. Examples of work done are:
- a maintenance task performed on some equipment;
- change made to some equipment in accordance with
a technical bulletin.
Thus, I believe
that this and it's dependant capabilities should suffice. Note this
subsumes several other dependant capabilities.
With respect
to the recording of usage, what are the other items (other than
covered in feedback) that are required for this? Les, Gordon - any
thoughts? I noted from Mike's earlier diagram that 2 capabilities are now
no longer available (C025-Assigning
Observation &
C033-Representing Product Usage ) - have
they been overtaken by others?
New items
(dependant) on the overview have been circled - I had missed analysis
result.
Again any
feedback appreciated!
-----Original
Message----- From: Tim
Turner [mailto:timturner11@bellsouth.net] Sent: 31 August 2004
09:30 To:
timturner11@bellsouth.net; john.dunford@eurostep.com; 'Tom Hendrix
E-mail' Cc: 'Robert M
Mcbride E-mail'; 'Plcs E-mail' Subject: [plcs] New DEX 8 -
Overview
attached is a
re-work of the Dex 8 overview for comment.
I think it
still needs a little more work, but I'd value further comments on this.
Note, I have
generated this from the Introduction where thee functional heading have
come from (except for the generic parts).
DISCLAIMER:
***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this
message is confidential and may be legally privileged. It is intended solely
for the addressee. Access to this message by anyone else is unauthorised. If
you are not the intended recipient, any disclosure, copying, or distribution
of the message, or any action or omission taken by you in reliance on it, is
prohibited and may be unlawful. Please immediately contact the sender if you
have received this message in error. This e-mail originates from LSC Group.
Registered in England & Wales No 2275471 Registered Office: Devonport
Royal Dockyard, Devonport, Plymouth, PL1 4SG
DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG
|