Subject: Re: [Tzdist] making things easy

From: Rob Seaman <[email-masked]>
Date: Sat, 13 Dec 2014 07:59:15 -0700

For unrelated reasons I'm reviewing notes from systems engineering courses I took a few years back.  Our software group had been going through software process purgatory (waterfall to spiral to agile to extreme) and it was useful to investigate how engineers themselves handle process.

Short answer - use SysML rather than UML - the real world has state machines.  Slightly longer - there are dozens of process variations but they all come down to formalizing the separation between two stages: 1) define the problem (singular), and 2) evaluate trade-offs between candidate solutions (plural).  That is to say: 1) discover requirements, and 2) build something meeting the requirements.

This likely seems obvious (or alternately rubbish), but a failure to separate thinking about the problem from thinking about possible solutions is at the heart of pretty much every human debacle.  Half of Aesop and Ben Franklin is "look before you leap".

On Dec 13, 2014, at 2:20 AM, Lester Caine <[email-masked]> wrote:

> I think that this perhaps is a fundamental part of the problem? Since
> the charter is predicated on iCalendar in an attempt to 'make things
> easy for the first pass', all of the baggage of that is weighing down
> the discussion.

What you are describing is what the professor (an IEEE and INCOSE fellow, his slides are a bit old school) called "The Systems Engineering Started in the Middle Process":

	http://www.sie.arizona.edu/sysengr/slides/middle.ppt

Slide 9 summarizes the cost (and time spent) of carting around the baggage:

	"A complete SESitMP would cost 2 to 10 times as
	much as an SE project started at the beginning."

He's saying that the systems engineering management plan costs 10 times as much, not (necessarily) that the entire project does.  Which is to say that the cost of "making things easy" is to make them harder to understand and manage.

His last slide:

	- Is SESitM the norm, rather than the exception?
	- COTS components and legacy elements constrain design.
	- Political and marketing decisions constrain design.
	- Such constraints cannot be systems engineered. We are not able to question the purpose, the functions or the requirements.

Experience here is that every project does indeed start in the middle.  Carrying the baggage becomes the main activity unless you are exceptionally careful.

(Trying not to trip over the soap box getting down.)

Rob Seaman
National Optical Astronomy Observatory