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

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

…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

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…

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?

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

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

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

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

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

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