Obsprep Planning, 2017 Alan Bridger

Development for Cycle5 Phase1, Status Cycle5 Phase1 requests totalled 72 tickets (as of yeterday morning), 19 High, 37 Medium, 16 Low. (Evolving as deferal takes place) 6 New Features, 42 Improvements, 24 Bugs To date: 23 Closed/Resolved, 5 Implemented/Verifying, 44 others Tickets implemented across releases 2016.6 (3), OCT2016 (18), NOV2016 (4) and DEC2016 (TBC, >20). Option to use FEB2017, but that is too late for further features/improvements. Will be bug fixes, minor changes only. We will not complete all 72 tickets for Cycle5. Will be ~ 2/3 complete.

Development for Cycle5 Phase1, Timeline Complete DEC2016 verification: 20-Jan, validation 27 Jan User test currently 2-13 Feb We propose earlier, start immediately after validation period, so about 27 Jan to 6 Feb So that can fix issues in FEB2017 release And bring validation start forward a little to overlap with verification (in a coordinated manner) Include Phase 1 SB generation test? (next talk) Acceptance 16-20 March CfP due 21 March

Development for Cycle5 Phase1, Issues Cycle5 yet again a tough assignment for developers. Key functional challenges: Changes to angular resolution interface – different options including capturing a range Much more complex than appears, potentially costly in cpu Implementing use of 90 deg Walsh function switching at Science Goal Level Without confusing the users (and developers) Adding storage of expected and overlaid spectral lines Again this apparently simple request hides a large number of details to resolve and has uncovered a splatalog issue. Improving speed of validation – this is just hard. And required APDM support classes changes. Band 5, until overlap concerns disappeared

Development for Cycle5 Phase1, Issues and also: Replacement for Java-applet version of Sensitivity Calculator in the Science Portal (browsers ceasing support) Re-implementation in javascript on-going Late tickets (mid- and even late-November…) Late arrival of specifications (still): As of mid-November approx 5 features were “almost” complete, but could not go in to OBSPREP-NOV2016 because we were still refining details with science. and we are still debating several other tickets (<14 development days left)

Development for Cycle5 Phase1, Issues And getting used to new process: When/where do we branch from and to? Now roughly understood How to announce where software is? Now understood Where to fix bugs found? In verification? Validation? Can we fix bugs found? Especially in Validation. Our understanding is that features failing validation should be removed: This might result in end user not being offered an agreed capability This will often take more effort than simply fixing the issue This is usually more risky than simply fixing the issue Note that NOV2016 release had 5 tickets. DEC2016 is likely to have > 20. (2016.6 had 3, OCT2016 had 18). Smoothing out of feature release is not panning out so far

Development for Cycle5 Phase2 So far Cycle5 Phase2 has 25 tickets as of now, more are very likely. Key points: Extend to Phase 2 some of the Phase 1 changes, e.g. 90 deg walsh follow through, adding spectral lines etc. Many items – e.g. support for multiple configs as result of angular resolution changes – in place now for Phase 1 SB generation More support for contact scientists Not sure yet how that is to be implemented – if it can be. User Testing? May/June 2017? Acceptance? TBD July 2017 Deployment 27 July 2017 To be delivered across MAR2017, APR2017, (MAY2017?)

Cycle6 As of yesterday morning Cycle6 Phase1 had 3 tickets, 1 of which will not be implemented (integrating OSS into OT), 2 of which may not be needed (reciever band overlap)? Situation is evolving as we start deferring Cycle5 tickets to Cycle6. So what are we doing? Expected potential requests: Remove 10 deg restriction on SB sources; High sensitivity array; OTFI; Science Goal dependencies; single dish continuum (fast scanning); “special” calibration modes/user intents (is this what “more options, more flexibility” means?) – there are 5 of these outlined so far; polarization; extentions to Solar/VLBI; daytime observing; usual changes to numbers;… This is more than enough for us.

TP Spectrometer TP Spectrometer expected to enter commissioning April 2019 Needs to be added to OT, Schedulng Block setup to facilitate commissioning. Of order 2 fte-months work. Requires APDM changes. Need to fit both into 2018 schedule -> Fewer Cycle7 tickets.

Agile Development – my personal view I am in favour of agile development… Must be matched to reality of client/stakeholder needs: The OT end-user expects 2 releases per year – monthly releases are of no interest to them The OT ALMA stakeholders (JAO, iSOPT, ...) expect certain feature to be present at time of deployment. Full stop. Must get developer buy-in: Developers must see this is helping them and their end-users Must not add to developer work-load for no obvious benefit I’m not convinced the new process is fulfilling those requirements. In particular I will examine very carefully what we can agree to achieve for Cycle6 – I expect to accept fewer “must do” features. This may improve quality. Is that an acceptable trade?

The Atacama Large Millimeter/submillimeter Array (ALMA), an international astronomy facility, is a partnership of Europe, North America and East Asia in cooperation with the Republic of Chile. ALMA is funded in Europe by the European Organization for Astronomical Research in the Southern Hemisphere (ESO), in North America by the U.S. National Science Foundation (NSF) in cooperation with the National Research Council of Canada (NRC) and the National Science Council of Taiwan (NSC) and in East Asia by the National Institutes of Natural Sciences (NINS) of Japan in cooperation with the Academia Sinica (AS) in Taiwan. ALMA construction and operations are led on behalf of Europe by ESO, on behalf of North America by the National Radio Astronomy Observatory (NRAO), which is managed by Associated Universities, Inc. (AUI) and on behalf of East Asia by the National Astronomical Observatory of Japan (NAOJ). The Joint ALMA Observatory (JAO) provides the unified leadership and management of the construction, commissioning and operation of ALMA.