Presentation Tomorrow -- 11/11/2016 -- AT SeaGL

0 vue
Accéder directement au premier message non lu

joseph simpson

non lue,
11 nov. 2016, 00:34:5111/11/2016
à gmo...@u.washington.edu,Aleksandar Malečić,Andrew Borota,Gabriel AWAD,George Mobus,Hogan, Michael,Jack Ring,Janet Singer,Janet Singer,Joe Simpson,Kevin Dye,Kevin Dye,Lenard Troncale,Mary Keeler (mkeeler@u.washington.edu),Michael Singer,mjs...@eskimo.com,mjs...@gmail.com,Narayana Mandaleeka,Peter D Tuddenham,Richard Martin,SpaceKatt PoiSpin,Steve Krane,Steven Engle,Sys Sci,Yiannis Laouris,Yiannis Laouris
Looking forward to speaking at SeaGL! Check out the schedule here, https://osem.seagl.org/conference/seagl2016/schedule

I'm presenting on Nov. 11/12 at the Seattle GNU/Linux Conference, a community-run tech conference on Capitol Hill. http://seagl.org/

Copies of the presentation slides are available at:


Take care, be good to yourself and have fun,

Joe

--
Joe Simpson

“Reasonable people adapt themselves to the world. 

Unreasonable people attempt to adapt the world to themselves. 

All progress, therefore, depends on unreasonable people.”

George Bernard Shaw

Jack Ring

non lue,
11 nov. 2016, 10:01:1011/11/2016
à joseph simpson,gmo...@u.washington.edu,Aleksandar Malečić,Andrew Borota,Gabriel AWAD,George Mobus,Hogan, Michael,Janet Singer,Janet Singer,Kevin Dye,Kevin Dye,Len Troncale,Mary Keeler (mkeeler@u.washington.edu),Michael Singer,mjs...@eskimo.com,mjs...@gmail.com,Narayana Mandaleeka,Peter D Tuddenham,Richard Martin,SpaceKatt PoiSpin,Steve Krane,Steven Engle,Sys Sci,Yiannis Laouris,Yiannis Laouris
Joe,
Good work.
Regarding your claim, "There is a strong need for a common test and evaluation approach…” I suggest you be aware of Dijkstra’s caution, “Testing shows the presence, not the absence of bugs” and think about more complete ways of assessing a) the integrity of a model and b)  the system dynamic limits of a chosen realization of the model. 
I am hoping to get more time to understand your work. It appears to be very important for discovering viable systems.
Jack

Ferris, Tim

non lue,
11 nov. 2016, 10:19:3611/11/2016
à syss...@googlegroups.com,joseph simpson,gmo...@u.washington.edu,Aleksandar Malečić,Andrew Borota,Gabriel AWAD,George Mobus,Hogan, Michael,Janet Singer,Janet Singer,Kevin Dye,Kevin Dye,Len Troncale,Mary Keeler (mkeeler@u.washington.edu),Michael Singer,mjs...@eskimo.com,mjs...@gmail.com,Narayana Mandaleeka,Peter D Tuddenham,Richard Martin,SpaceKatt PoiSpin,Steve Krane,Steven Engle,Yiannis Laouris,Yiannis Laouris

If there were a common T&E approach, anyone putting forward something for test would know how the T&E would be conducted, and with creativity may be able to work out ways to game the system – in the same way people in other aspects of life work out how to game systems (such as where they can get away with certain driving offences or what things they can probably get away with in their tax returns because they know what kinds of claims trigger investigations or where the police monitor driving).

 

Similarly, any test of a system which is not actually measuring the system doing what it is meant to do under operational conditions risks being gamed – a la Volkswagen.

 

Tim Ferris

--
The SysSciWG wiki is at https://sites.google.com/site/syssciwg/.
 
Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
---
You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+u...@googlegroups.com.
Visit this group at https://groups.google.com/group/syssciwg.
For more options, visit https://groups.google.com/d/optout.

Jack Ring

non lue,
11 nov. 2016, 11:07:0911/11/2016
à Sys Sci,joseph simpson,gmo...@u.washington.edu,Aleksandar Malečić,Andrew Borota,Gabriel AWAD,George Mobus,Hogan, Michael,Janet Singer,Janet Singer,Kevin Dye,Kevin Dye,Len Troncale,Mary Keeler (mkeeler@u.washington.edu),Michael Singer,mjs...@eskimo.com,mjs...@gmail.com,Narayana Mandaleeka,Peter D Tuddenham,Richard Martin,SpaceKatt PoiSpin,Steve Krane,Steven Engle,Yiannis Laouris,Yiannis Laouris
We may be stalking different prey. I am concerned with anticipating the dynamic and integrity limits of a system and doing so with zero probable error. I am concerned with doing this when the system is expressed as a model as well as doing so later when it is expressed as an operational entity.

Consider the desire to remove all faults from a manuscript. One way is to have a well informed editor proof read the manuscript. Another is to test it by having one or more intended audience read it and confirm whether it conveyed what the author intended (even including sentences such as ‘Throw the horse over the fence some hay.’)  

Somehow after Logicon formulated the idea of V&V in the 1960’s the notion of testing an artifact rather than proofreading it first got lost. 

While it may be near-impossible to proofread poetry with zero probable error it is now possible to proofread artifacts that are intended to be algorithms, no matter how extensive and complex. A system has progress properties and safety properties. Most test cases deal only with progress properties. A proof reader can identify all the relevant safety properties.

Are we dealing with the same elephant?
Jack

ps., In every one of the several Interpretive Structural Modeling sessions I have experienced a review of the resulting model ALWAYS prompted a ‘wait a minute, this item should not have been excluded’ followed by an agreement to edit it into the ISM structure in a specific place. This is an example of proofreading the model.

joseph simpson

non lue,
11 nov. 2016, 22:43:2611/11/2016
à Sys Sci,gmo...@u.washington.edu,Aleksandar Malečić,Andrew Borota,Gabriel AWAD,George Mobus,Hogan, Michael,Janet Singer,Janet Singer,Kevin Dye,Kevin Dye,Len Troncale,Mary Keeler (mkeeler@u.washington.edu),Michael Singer,mjs...@eskimo.com,mjs...@gmail.com,Narayana Mandaleeka,Peter D Tuddenham,Richard Martin,SpaceKatt PoiSpin,Steve Krane,Steven Engle,Yiannis Laouris,Yiannis Laouris
Jack:

Good points...

My view of the testing needed for structural modeling is multifaceted. 

There is the facet of structural modeling associated with the testing of the total, functional application.  Does the system support the production of valuable artifacts and outcomes.

There is a testing facet associated with each of the three main areas of structural modeling:
  - Basic structural modeling (BSM),
  - Interpretive structural modeling (ISM), and 
  - Structural integration modeling (SIM).

A key question that must be answered before the content of a specific facet can be completely described is:
  "Where does the computing component reside?"

We have placed the mandatory structural modeling computer component in the SIM area of structural modeling.  The computer algorithm tests are located in the SIM area.

There are tests for the BSM area generated and applied by the mathematics community.

There are some structured evaluation techniques that are used in the ISM area, but no common operational tests.

The SIM area has no common operational tests at this time.  We are in the process of creating these types of tests.

The computing component, in the SIM area, needs a wide range of software unit, functional, integration and operational tests.  As we move from the formal language component, in the BSM area, to the informal language area, in the ISM area, types of tests and the purpose of these tests will change.

A step forward would be the development of a common set of testing values and goals for structural modeling.

Please let me know if you need further information to support your exploration of this set of structural modeling material. 

Take care, be good to yourself and have fun,

Joe

--
The SysSciWG wiki is at https://sites.google.com/site/syssciwg/.
 
Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
---
You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

joseph simpson

non lue,
11 nov. 2016, 23:05:2211/11/2016
à Ferris, Tim,syss...@googlegroups.com,gmo...@u.washington.edu,Aleksandar Malečić,Andrew Borota,Gabriel AWAD,George Mobus,Hogan, Michael,Janet Singer,Janet Singer,Kevin Dye,Kevin Dye,Len Troncale,Mary Keeler (mkeeler@u.washington.edu),Michael Singer,mjs...@eskimo.com,mjs...@gmail.com,Narayana Mandaleeka,Peter D Tuddenham,Richard Martin,SpaceKatt PoiSpin,Steve Krane,Steven Engle,Yiannis Laouris,Yiannis Laouris
Tim:

Good points...

At this time we are just working with the very basics of structure and computing algorithms.  Most of the current systems do not detail the algorithms used or the software implementation of these algorithms.

Our current work, based on the GMU ISM software instructions in Appendix 2 of "A Handbook of Interactive Management," addresses a range of algorithms and software functions.  A copy of the handbook is available here: 

At the foundation of these processes are functions that search, sort, cluster and order objects.  There are a wide range of algorithms that could be used to implement search, sort, cluster and ordering functions.  

In these cases each different approach could reach an answer, but a specific approach may be a much more expensive and/or limiting than the other implementations.

Lets take the structural modeling approach used in India, as an example.  They do not use a software inference component.  Much, if not all, of the work is done by hand using structured graphics operations.  

These people are not "gaming the system," they are just using a very expensive (resource wise) approach because they can not take advantage of the inference elements.  These approaches also limit the size of any given problem.

Another area to consider is the existence of a wide range of viable approaches.  Each approach will have advantages and disadvantages.  Tests will be used to identify, evaluate and qualify each approach.

Just establishing a clear description of the structural modeling area will be a step forward.

Take care, be good to yourself and have fun,

Joe

To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.

joseph simpson

non lue,
11 nov. 2016, 23:16:2811/11/2016
à Jack Ring,Sys Sci,gmo...@u.washington.edu,Aleksandar Malečić,Andrew Borota,Gabriel AWAD,George Mobus,Hogan, Michael,Janet Singer,Janet Singer,Kevin Dye,Kevin Dye,Len Troncale,Mary Keeler (mkeeler@u.washington.edu),Michael Singer,mjs...@eskimo.com,mjs...@gmail.com,Narayana Mandaleeka,Peter D Tuddenham,Richard Martin,SpaceKatt PoiSpin,Steve Krane,Steven Engle,Yiannis Laouris,Yiannis Laouris
Jack:

Our goal is to include the "operational tests" and "communication tests" of the type that you describe above.

One area that needs much more attention is the evaluation of the individual perception bias associated with each of the group participants.  

This type of individual evaluation is an area where psychology and sociology can make strong contributions. 

The goal is an effective, operational balance of the formal language of mathematics and the informal constructs of natural language.  Once achieved, this balance is viewed as the primary factor in generating a common, shared context that humans can use to increase communication precision.

The party has started and we are on the way..

Take care, be good to yourself and have fun,

Joe
To unsubscribe from this group and stop receiving emails from it, send an email tosyssciwg+unsubscribe@googlegroups.com.

-- 
The SysSciWG wiki is at https://sites.google.com/site/syssciwg/.  
 
Contributions to the discussion are licensed by authors under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
--- 
You received this message because you are subscribed to the Google Groups "Sys Sci Discussion List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+unsubscribe@googlegroups.com.




--

joseph simpson

non lue,
11 nov. 2016, 23:19:3811/11/2016
à Yiannis Laouris,Jack Ring,gmo...@u.washington.edu,Aleksandar Malečić,Andrew Borota,Gabriel AWAD,George Mobus,Hogan, Michael,Janet Singer,Janet Singer,Kevin Dye,Kevin Dye,Len Troncale,Mary Keeler (mkeeler@u.washington.edu),Michael Singer,mjs...@eskimo.com,mjs...@gmail.com,Narayana Mandaleeka,Peter D Tuddenham,Richard Martin,SpaceKatt PoiSpin,Steve Krane,Steven Engle,Sys Sci,Yiannis Laouris
Yiannis:

The team did a great job today..

As you know, with Kevin on your team things go very well..

Thomas and Kevin did a great job...

Take care, be good to yourself and have fun,

Joe

On Fri, Nov 11, 2016 at 8:32 AM, <lao...@cnti.org.cy> wrote:
Good luck Joseph

Sent from my iPhone
_________________________
Yiannis Laouris MD, PhD (Neurophysiology), MS (systems Engineering)
Senior Scientist
Cyprus  Neuroscience & Technology Institute
Future Worlds Center


Jack Ring

non lue,
12 nov. 2016, 10:09:3512/11/2016
à Sys Sci
Joe,
My point is that testing will never reveal whether the system dynamic and integrity limits are known with Zero error. The integrity aspect must be discovered by assessment. It is now possible to assess actual code and the way to assess viability of a system design model is next. See www.ontopilot.com. Not suggesting we try to meld ideas at this point, only encouraging you to be aware of the limitations of testing (actually, the near-impossibility of high acuity test cases — Firesmith, SEI, notwithstanding)
Jack
To unsubscribe from this group and stop receiving emails from it, send an email to syssciwg+u...@googlegroups.com.

joseph simpson

non lue,
12 nov. 2016, 11:17:2712/11/2016
à Sys Sci
Jack:

Thanks for the clarification.

Take care, be good to yourself and have fun,

Joe

Jack Ring

non lue,
12 nov. 2016, 12:46:1312/11/2016
à Sys Sci
On Nov 11, 2016, at 8:19 AM, Ferris, Tim <Timothy...@cranfield.ac.uk> wrote:
“...actually measuring the system doing what it is meant to do under operational conditions…"
This can be done only after deployment and even then 'operational conditions’ are probably not verifiable. Further, most T&E recipes do not call estimating probable error in the conclusions.
Now it is possible to determine system integrity limits by proofreading the system model/code then devise exercises to discover the dynamic limits.
Jack
> To unsubscribe from this group and stop receiving emails from it, send an email tosyssciwg+...@googlegroups.com.
Répondre à tous
Répondre à l'auteur
Transférer
0 nouveau message