RE: [plcs-dex] Template: assigning_realized_resource was referencing_resource_as_realized

["Barker, Sean (UK)" <Sean.Barker@baesystems.com>]

Attached a note on maturity rating.

Sean Barker
0117 302 8184
 

> -----Original Message-----
> From: Rob Bodington [mailto:rob.bodington@eurostep.com] 
> Sent: 22 October 2007 11:06
> To: Per-Åke Ling; Leif Gyllström
> Cc: Steve Yates; plcs-dex@lists.oasis-open.org
> Subject: RE: [plcs-dex] Template: assigning_realized_resource 
> was referencing_resource_as_realized
> 
> 
>                *** WARNING ***
> 
> This mail has originated outside your organization, either 
> from an external partner or the Global Internet. 
>      Keep this in mind if you answer this message. 
> 
> We have developed a configuration management tool for dexlib.
> It is undergoing testing.
> It will be used to manage the release of the templates etc. 
> before they are submitted to OASIS
> 
> Regards
> Rob
> -------------------------------------------
> Rob Bodington
> Eurostep Limited
> Web Page: http://www.eurostep.com http://www.share-a-space.com
> Email: Rob.Bodington@eurostep.com
> Phone: +44 (0)1452 810 960
> Mobile: +44 (0)7796 176 401
> Skype: rbodington
> Eurostep Limited. Registered in England and Wales No.03049099 
> Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ.
> 
> -----Original Message-----
> From: Per-Åke Ling [mailto:per-ake.ling@eurostep.com]
> Sent: 22 October 2007 10:56
> To: Leif Gyllström
> Cc: Steve Yates; Rob Bodington; plcs-dex@lists.oasis-open.org
> Subject: Re: [plcs-dex] Template: assigning_realized_resource 
> was referencing_resource_as_realized
> 
> I believe Steves idea of a "maturity level" on the 
> capabilities (or templates if finer granularity is needed) is 
> not only a good idea, it is actually necessary.
> 
> I also think we are getting to a point where we have to 
> reopen the discussion on version management (or, in a larger 
> scope, CM) for DEXLIB.
> One of the problems for DNV in Norway was the fact that 
> DEXLIB was a moving target, and there were no baselines or 
> organized releases with unambiguous identification.
> 
> To address Steves concern with implementation: with proper 
> version management in combination with "maturity level" or 
> some other review process, it would be possible as an 
> implementor to asses the risks with regard to coding. I.e. a 
> reasonably mature template would imply that only minor 
> changes will happen, so that coding would be relatively 
> risk-free, and only adjustments would be expected.
> 
> I know that there has been discussions on version management 
> et al with respect to RDL, but to my knowledge not with 
> respect to DEXLIB as a whole (at least not to the same degree).
> 
> I firmly believe this needs to addressed sooner, not later. 
> It is very hard to tack on CM after the fact.
> 
> Regards,
> Per-Åke
> 
> Leif Gyllström wrote:
> > Steve
> >  
> > If don't want to take any risks, then yes ! (at least this is my 
> > opinion)
> >  
> > Regards
> >  
> > Leif
> > 
> > ________________________________
> > 
> > From: Steve Yates [mailto:steve.yates@eurostep.com]
> > Sent: den 22 oktober 2007 10:46
> > To: Leif Gyllström; Rob Bodington; plcs-dex@lists.oasis-open.org
> > Subject: RE: [plcs-dex] Template: assigning_realized_resource was 
> > referencing_resource_as_realized
> > 
> > 
> > 
> > OK,
> > 
> >  
> > 
> > So we should wait for the review process to be complete 
> before coding any of the templates?
> > 
> >  
> > 
> > Steve
> > 
> >  
> > 
> > 
> ----------------------------------------------------------------------
> > --------------
> > 
> > Steve Yates
> > 
> > Senior Consultant
> > 
> > Tel: +44 1745 582008
> > 
> > Fax: +44 1745 585556
> > 
> > Mobile: +44 7795 563102
> > 
> > E-Mail: Steve.Yates@Eurostep.com <mailto:Steve.Yates@Eurostep.com>
> > 
> > Web: www.eurostep.com <http://www.eurostep.com/>
> > 
> >  
> > 
> > Eurostep Limited. Registered in England and Wales No.03049099
> > 
> > Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ.
> > 
> > 
> ----------------------------------------------------------------------
> > --------------
> > 
> > ________________________________
> > 
> > From: Leif Gyllström [mailto:Leif.Gyllstrom@sat.saabgroup.com]
> > Sent: 22 October 2007 09:45
> > To: Steve Yates; Rob Bodington; plcs-dex@lists.oasis-open.org
> > Subject: RE: [plcs-dex] Template: assigning_realized_resource was 
> > referencing_resource_as_realized
> > 
> >  
> > 
> > All
> > 
> >  
> > 
> > In my mind the review process solves this problem (at least 
> to certain 
> > extent)
> > 
> >  
> > 
> > Regards
> > 
> >  
> > 
> > Leif
> > 
> >  
> > 
> > ________________________________
> > 
> > From: Steve Yates [mailto:steve.yates@eurostep.com]
> > Sent: den 22 oktober 2007 10:34
> > To: Leif Gyllström; Rob Bodington; plcs-dex@lists.oasis-open.org
> > Subject: RE: [plcs-dex] Template: assigning_realized_resource was 
> > referencing_resource_as_realized
> > 
> > Hi Rob,
> > 
> >  
> > 
> > I have no objection to this one, but in principle I do have 
> a concern.  In this particular case, no effort has gone into 
> implementing this Template in real code.  If it had, then 
> that some rework would have been required, which would have 
> needed funding.
> > 
> > In the AP203/AP214 arena, there was particular dismay 
> amongst the software vendors when changes of this form came 
> up, leading in the end to them refusing to implement anything 
> that had not reached ISO IS status, i.e. would not change.  
> This may be something to bear in mind as more implementations 
> of AP239, especially those using the templates, come into being.
> > 
> >  
> > 
> > One way of mitigating this may be to have a maturity 
> indicator on the Template, to give a feeling of how likely it 
> is to change, and thus how "safe" it is to put into code.
> > 
> >  
> > 
> > Cheers
> > 
> >  
> > 
> > Steve
> > 
> >  
> > 
> > 
> ----------------------------------------------------------------------
> > --------------
> > 
> > Steve Yates
> > 
> > Senior Consultant
> > 
> > Tel: +44 1745 582008
> > 
> > Fax: +44 1745 585556
> > 
> > Mobile: +44 7795 563102
> > 
> > E-Mail: Steve.Yates@Eurostep.com <mailto:Steve.Yates@Eurostep.com>
> > 
> > Web: www.eurostep.com <http://www.eurostep.com/>
> > 
> >  
> > 
> > Eurostep Limited. Registered in England and Wales No.03049099
> > 
> > Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ.
> > 
> > 
> ----------------------------------------------------------------------
> > --------------
> > 
> > ________________________________
> > 
> > From: Leif Gyllström [mailto:Leif.Gyllstrom@sat.saabgroup.com]
> > Sent: 22 October 2007 09:23
> > To: Rob Bodington; plcs-dex@lists.oasis-open.org
> > Subject: RE: [plcs-dex] Template: assigning_realized_resource was 
> > referencing_resource_as_realized
> > 
> >  
> > 
> > Fine with me
> > 
> >  
> > 
> > Regards
> > 
> >  
> > 
> > Leif
> > 
> >  
> > 
> > ________________________________
> > 
> > From: Rob Bodington [mailto:rob.bodington@eurostep.com]
> > Sent: den 22 oktober 2007 10:15
> > To: plcs-dex@lists.oasis-open.org
> > Subject: [plcs-dex] Template: assigning_realized_resource was 
> > referencing_resource_as_realized
> > 
> > Hi
> > 
> > The template referencing_resource_as_realized has been renamed 
> > assigning_realized_resource
> > 
> > This is in response to an issue raised against it and to 
> align it with the template assigning_required_resource.
> > 
> >  
> > 
> > At this stage, the template 
> referencing_resource_as_realized has been deprecated rather 
> than deleted.
> > 
> >  
> > 
> > Unless there are any objections, I propose to go ahead with the 
> > renaming and delete referencing_resource_as_realized
> > 
> > Regards
> > Rob
> > 
> > -------------------------------------------   
> > Rob Bodington
> > Eurostep Limited
> > Web Page: http://www.eurostep.com <http://www.eurostep.com/>  
> > http://www.share-a-space.com <http://www.share-a-space.com/>
> > Email: Rob.Bodington@eurostep.com
> > Phone: +44 (0)1452 810 960
> > Mobile: +44 (0)7796 176 401
> > Skype: rbodington
> > 
> > Eurostep Limited. Registered in England and Wales No.03049099
> > 
> > Registered Office: Cwttir Lane, St. Asaph, Denbighshire LL17 0LQ.
> > 
> >  
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS 
> TC that generates this mail.  You may a link to this group 
> and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
oups.php 
> 
> 
> 


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

Title: Building Design Maturity

Showing how Design Maturity is Achieved

Introduction

    Design maturity can be viewed of the converse of the risk of change - where there is a high risk of major change a design is immature, while if there is only a slight risk of minor change then it will be regarded as mature. Change is most likely when the design fails to meet the design requirements, though in practice the design involves trade offs mean that not all criteria are met. 

Completeness and Maturity

    Completeness measure the set of design and analysis elements that have to be filled in by a certain stage of a design process. A completeness check would be done by reading down a checklist of elements that must have been done.

    Maturity is the converse of the risk of change for those design elements, where risk is defined by

        Probability_of_change*Impact_of_change

Here Impact_of_change is measured primarily against the containing system of the item being assessed. That is, there is a local impact of change which means work already done must be revisited, however the primary impact must be assessed against the part of the product where it is being used. E.g. in designing a fuel pump, the effects of a design change will be locally limited to reworking existing fuel pump data, however if it changes the performance of the fuel system, then that redesign is likely to be much more costly.

 

This might be measured by:

Impact 4	No knock on effects 1	Minor knock-on effects 2	Significant redesign/reanalysis 3	Major redesign or reanalysis 4	Complete Redesign 5
Probability 6
Slight chance   1	1   Fully Mature	2    Mature	3   Mature	4    Maturing	5    Maturing
Small chance   2	2   Mature	4    Mature	6   Maturing	8    Maturing	10   Immature
Significant chance   3	3   Mature	6    Maturing	9    Maturing	12   Immature	15   Immature
High chance   4	4   Maturing	8  Maturing	12   Immature	16  Immature	20 Ideas Stage
Nearly Certain    5	5    Maturing	10   Immature	15   Immature	20   Ideas Stage	25 Ideas Stage

In a complex product, maturity assessments might be made on a component basis and built into an overall score by a weighted sum of components.

    In passing a process gate, both a completeness check and a maturity check are required. The completeness check must be passed before the maturity check, since data cannot be mature unless it is complete, that is, it cannot be mature until all the required data have been produced. (It is a common mistake to use a checklist as a maturity assessment.) Maturity is an engineering judgement about how confident the engineers are of a design. Failure of a maturity check starts a new design iteration, aimed at raising the design to the required level of maturity.

    The overall design process can be seen as a series of sub-processes, each aimed at raising the overall level of product maturity. Perhaps the most atypical process has but a single iteration - this is possible for only the simplest of products. Perhaps more typical is a three stage process of initial idea (immature), prototype (maturing), finished product (fully mature).

    Maturity assessments can be made at various level of formality, the most formal being those at configuration boundaries, where designs passing the maturity test are formally issued. Processes, such as the IPT process, may record in an informal or semi-formal way progress against maturity criteria. Most maturity assessments however are made informally by engineers as they do the work.

 

<