[trustable-software] Trustable Software Workflow

Paul Sherwood paul.sherwood at codethink.co.uk
Wed Jan 11 13:42:29 UTC 2017


John, Andrew,
thanks very much for your comments on this thread so far (and please 
keep them coming)

I think the best we can aim for in the short term is to expose the 
issues and 'map the territory', so please consider that the work Chris, 
Jim and others are exploring to be 'straw man' until such time as we 
identify or originate better open alternatives.

One of the key reasons for starting our discussion in the first place 
was a realisation that there's not enough open/public community 
understanding of these issues, so it's great to see expert comment and 
critique here.

br
Paul

On 2017-01-08 10:49, Andrew Banks wrote:
> Without delving into the details of this proposal, I am concerned
> HUGELY that it seems to imply that Software Engineering is just about
> writing code...
> 
> It misses the obvious steps of:
> * Requirement Capture
> * Design (at differing levels)
> * Treats testing as an afterthought...
> Etc


On 2017-01-11 13:29, John Lewis wrote:
> Whilst “commit early and often” is good practice for many types of
> software development, for safety critical (especially) and security
> critical development it isn’t always possible and one either has to
> use “long transactions” - where other users are locked-out (for
> possibly several days) or a separate branch has to be taken. The user
> stories seem to be very simplistic.
> 
> Many “requirements” are implicit - so obvious that they should not
> really need to be stated - and frequently are not!. They should be
> discovered before or at the latest during development e.g. the
> requirement for the Type45 destroyers to be able to operate in warm
> water (currently the subject of a dispute between the Royal Navy and
> Rolls-Royce).
> 
> As Andrew points out Software Engineering is more than writing code
> (inc. CI and Test code) and an “industry standard” will not cater
> for stupidity or missing/changing requirements so “Compliance” to
> an industry standard is pretty meaningless. Similarly, checking that
> the requirements are traced through to code does not help if the
> requirements are not explicitely stated. You may be interested in
> http://www.objektum-modernization.com/case_study_4.php - long projects
> have their own problems.



More information about the trustable-software mailing list