1. Operations Perspective
SAFe Construction Planning Workshop
Gary Davis
2nd October 2017

2. The objective of this project is not to build two telescopes
Introduction
The objective of this project is not to build two telescopes
It is to do transformational science with the two telescopes we will build
over a 50-year lifetime
design & construction is only the first step

3. …We need software that works
For This To Happen…
…We need software that works
that does what it is supposed to do
that is reliable
that is (mostly) free of bugs
that is easily maintained, modified and scaled
that is well documented
Extensive software re-work or de-bugging in early operations would be a serious problem

4. Reliability in Hardware
Standard techniques:
FMECA = Failure Modes, Effects and Criticality Analysis
RAM = Reliability, Availability and Maintainability
If done properly, hardware design should be reliable to within system-level requirements
Reliability in the field then depends on fabrication and installation
We need something equivalent for software…

5. Software projects are notorious for failing to deliver
Case Study
Software projects are notorious for failing to deliver
including, but not limited to, astronomy
“Project A”
data reduction software for new correlator
software was delivered to the observatory as part of the correlator development project
it was discarded by the observatory and re-written from scratch, at significant cost
why did this happen?

6. Case Study Pace of technology Solution
project ran late – computing capacity increased in the meantime
enabled a completely different (and superior) design by the time it was delivered
developer was not sufficiently flexible to accommodate this – driven by initial requirements
Solution
aim for best solution at point of delivery, not at point of tender
difficult to define in advance – flexibility

7. Case Study
Lack of effective collaboration between the developer and the observatory
poor & difficult communications
“them and us” mentality
developer did not understand software environment at observatory
Solution
getting this relationship right is critical
the delivered software must be what the customer wants, not what the developer thinks we want

8. Lack of high-level commitment to the project
Case Study
Lack of high-level commitment to the project
developer didn’t really want to do it anyway
affected commitment of resource – both quality and quantity
resistance to changing direction, lack of interest in solving problems
Solution
need ability to change developer if it’s not working

9. Case Study Poor quality software Solution
delivered software was full of bugs and had to be cleaned up by observatory
painful process, took time and resource
Solution
need ability to replace programmers if they are not producing software to the required standard

10. Case Study Other factors
ineffective project management – no control over cost, schedule, performance
dependence on developments elsewhere

11. Summary
I just want software that works
It’s up to the software engineering part of the project to determine how best to deliver this