1 / 11

ALMA Integrated Computing Team Coordination & Planning Meeting #1 Santiago, 17-19 April 2013

ALMA Integrated Computing Team Coordination & Planning Meeting #1 Santiago, 17-19 April 2013. Acceptance Manager Transition Steve Scott. Overview. Current AM term through end of 2013 Propose changes in process and duties Start transition soon With next acceptance – May/June

griffith-hogan
Download Presentation

ALMA Integrated Computing Team Coordination & Planning Meeting #1 Santiago, 17-19 April 2013

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ALMA Integrated Computing TeamCoordination & Planning Meeting #1Santiago, 17-19 April 2013 Acceptance Manager Transition Steve Scott

  2. Overview • Current AM term through end of 2013 • Propose changes in process and duties • Start transition soon • With next acceptance – May/June • Basic Principles • General flow of acceptance is unchanged, but… • Trim acceptance process as much as possible • Use JIRA as much as possible • Cut out the middle-man • Direct interaction of stakeholders (ICT/SciOps) • More responsibility for stakeholders (but not work) • More input (and responsibilities) from QM • Less work (and responsibilities) for AM (<= 25% FTE)

  3. Communication • Twiki is focal point • ‘Everyone’ informed at start of acceptance process • Sign up for notifications if they want • Key stakeholders (‘committee’) are special • Meetings scheduled around their availability • But everyone welcome to attend! • Keep as small as possible (ease of scheduling) • AM • Computing (1 or 2?) • Science (1 or 2?) • ASG/AIV (1 rep only) for Online acceptances only

  4. Communication 2 • Masao is the coordinator of the Offline Phase V testing/testers • Single point of contact for the AM • This will significantly reduce AM work load • New change, just now going into effect

  5. Document Content • Feature list • Testing list and summary, links to reports • Documentation links • Links to acceptance tests • QM provides • Test failures • Bugs • Evaluation of quality • Conditions on previous acceptances • Maybe this is a separate doc, maybe not • Reduces AM work load

  6. Document Changes Overview • Acceptance Plan (for TRR) • Only signed by AM • EDM • Acceptance Report • Signed by AM, Computing, Science (as now) • EDM • No Acceptance Certificate • Signed Acceptance Report is sufficient • All other docs (test reports…) on twiki (as now) • EDM would be nice, but…

  7. AM as Broker • ICT • “I’ve got some great software, barely been used…” • “Look at all these fantastic test results!” • DSO • “I’ll test it by driving off a cliff, if it survives then I’ll take it” • QM • “The Odometer has been rolled back” • “The left rear tire is flat” • AM • “ICT, can you fix that tire and maybe the fender too?” • “DSO, maybe just drive it down to the beach?”

  8. Producer/Consumer • Cut out the middle man • Basic responsibilities fall on producer and consumer • ICT/DSO negotiate start of acceptance • TRR • ICT makes case for their software • DSO states what tests will validate the software • Acceptance Review • DSO decision on acceptance, based on test results • ICT agrees with decision or makes it own case • AM provides process, bookkeeping

  9. What to Keep • The basic acceptance process, with some minimal formalism, gives order and known expectations • Open process, everyone welcome • The principle that software should be accepted before it is deployed for official observatory use • Data schema changes should not force deployment of new software • SCCB provides stability

  10. Process Improvements • JIRA field in feature for acceptance version, e.g. ‘A9.1R4’ • Define acceptance tests early (before Phase I) • Developers will ensure that code passes • Acceptance testing is the integrated test • Phase V testing should be feature oriented • Pass/fail criteria clearly stated • For Online, a 1 or 2 night pre-TRR test to make sure we are ready for TRR (until regression tests are complete), with a week of acceptance testing after TRR

  11. Transition Schedule • Replace AM on SCCB with Science rep • Cut out the middle man • It’s not much work • Make change by the end of this meeting • Start with lean acceptance process in May/June • Bring on next AM in acceptance after the May/June • Will work with current AM through end of year, ramping up and sharing duties • New definition of AM duties may open up position to more candidates

More Related