[SystemSafety] Putting Agile into a longer perspective

[Steve Tockey]

Responding to both Alvery Grazebrook and David Mentré at the same time:

Alvery wrote:

"I¹d like to think we¹re doing better than this locally. One particular
push is towards MBSE (Model Based Systems Engineering)."

Congratulations, this makes you and your team pretty exceptional.


Alvery also wrote:

""formalism set A" is much harder to pin down, because it needs to address
a wide variety of topics, not just the data & logic. It may also need to
represent geometry and loads, energy transfer, radio transmit/receive etc.
I'm not aware of anything that even comes close. (And before anyone else
mentions it, I don't think SysML comes close; neither in scope nor
formalism)"

This is where we differ. You are talking about Model Based *Systems*
Engineering. I am only talking about Model Based *Software* Engineering.
There are significant differences between the two. One issue is that I am
not enough of a systems engineer to even hope to address the much larger
Systems Engineering set of problems. The models I speak of are,
essentially (although not necessarily permanently), limited to software.

One very important difference (IMHO) between Systems Engineering and
Software Engineering is in the need for Formalism Set A in the first
place. How complex would the specification of a building be if a) all
building materials were free, and b) the strength of those materials was
infinite? No need to worry about load-bearing vs. non-load bearing walls,
etc. The challenges facing an engineer in the recognized engineering
disciplines are almost always solution-space challenges, not problem-space
challenges. This is where software tends to be very different. While
software can also have solution-space challenges, it also tends to have
massive problem-space challenges. In an order processing system:

Can one still be a Customer without ever having placed any Orders?
Can the .date opened on an Order be 21-January-1966?
Can the .selling price of a Catalog Item be zero? Is there a maximum
possible value? Can the value be negative?
Can the .stock on hand of an Inventory Item be zero? Is there a maximum
possible value? Can it be negative?
Can we source (order) the same Inventory Item from different Suppliers or
not?
What happens when no Suppliers supply an Inventory Item?
Do we allow shipment of partial Orders?
What are the policies and processes around a Customer returning (part of)
an Order?

While order processing might be considered trivial to some, it's not
nearly as trivial as many people think. And, I am not limiting
problem-space complexities to classic business information systems. We can
talk about problem space complexities in Automated Test Equipment (ATE)
for commercial airliners as non-trivial. We can talk about visualization
of the input to, and the output from, Computational Fluid Dynamics code as
non-trivial. And, we can talk about the Mission Systems on the Boeing P-8
Poseidon as a massively complex problem-space.

As I said in my earlier reply to Olwen, it's vitally important in the
software world to separate problem-space complexities from solution-space
complexities. I don't believe it's that big a deal in the recognized
engineering disciplines, which is why they haven't already addressed that
as a problem.


D. Mentré wrote:

"In an idealistic world, which formalism(s) would you use for "formalism
set A" and "formalism set B""

Formalism Set B is--at least on the surface, i.e., user-level--pretty much
classic software design ala OOD, Structured Design, or whatever with the
exception that Design by Contract is an absolute requirement. A solid
understanding of Assertions & Software Proofs of Correctness, and how to
use them both properly, is also critical. None of these, in my experience,
is in the repertoire of the average highly-paid software amateur.

Formalism Set A can be described at two different levels. The surface,
i.e., user, level appears mostly as logical class models and cooperating
state models with actions. The real key to understanding this set of
formalisms is that it explicitly excludes automation technology from the
model. When I mentioned Inventory Item earlier, its appearance in a
(policy- and process-) semantic model does NOT in any way imply memory
resident Java or C++ class, database table, linked list, records in a flat
file on a disk, etc. It represents nothing more and nothing less than a
business-critical concept that needs to be accurately represented in
whatever automation technology is chosen. So when we talk about the .stock
on hand for the Inventory Item, we do NOT say it is an int, or an unsigned
int, or anything like that. We talk about it's "range" in terms of policy
constraints on acceptable values, like "A whole number not less than zero,
and not more than 1234". It takes a little over 200 book pages to describe
how to use Formalism Set A from a modeler's perspective.

The underlying, true formal basis for Formalism Set A includes things like
Set Theory, Measurement Theory, Finite Automata Theory, etc. The linkage
between the surface level and the underlying formal level are
semi-formally defined in a "Semantic Model of Semantic Modeling". I can
make that available if someone is interested, just send me a direct
off-list request and I will send it back to you as a .pdf attachment.


Cheers,

-- steve








-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de>
on behalf of "Grazebrook, Alvery AN" <alvery.grazebrook at airbus.com>
Date: Friday, October 25, 2019 at 4:56 AM
To: "systemsafety at lists.techfak.uni-bielefeld.de"
<systemsafety at lists.techfak.uni-bielefeld.de>
Subject: Re: [SystemSafety] Putting Agile into a longer perspective


> D. Mentré: In an idealistic world, which formalism(s) would you use for
>"formalism set A" and "formalism set B"?
[Grazebrook, Alvery AN]
I think this discussion is missing a point - the real-world interfaces to
systems are not just across software boundaries. So for software as an
implementation technique, you probably can select a single "formalism set
B", maybe an extension from Lustre or Event B or SPARK or something more
data-oriented if you are implementing a database-oriented system.

"formalism set A" is much harder to pin down, because it needs to address
a wide variety of topics, not just the data & logic. It may also need to
represent geometry and loads, energy transfer, radio transmit/receive etc.
I'm not aware of anything that even comes close. (And before anyone else
mentions it, I don't think SysML comes close; neither in scope nor
formalism)

Cheers,
	Alvery

** These opinions are my own, not necessarily those of my employer.
This email and its attachments may contain confidential and/or privileged
information.  If you have received them in error you must not use, copy or
disclose their content to any person.  Please notify the sender
immediately and then delete this email from your system.  This e-mail has
been scanned for viruses, but it is the responsibility of the recipient to
conduct their own security measures. Airbus Operations Limited is not
liable for any loss or damage arising from the receipt or use of this
e-mail.

Airbus Operations Limited, a company registered in England and Wales,
registration number, 3468788.  Registered office:  Pegasus House,
Aerospace Avenue, Filton, Bristol, BS34 7PA, UK.
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE
Manage your subscription:
https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety