2. AWIPS Governance What are we Governing? –EDEX/CAVE plugins developed for an operational AWIPS system Out of Scope: GFE Smart inits and tools, µengine requests, textdb, subscriptions and scripts (shell, python) are covered by the Local Applications Policy Why are we Governing? –Preserve operational system integrity (performance) –Ensure software quality (functionality, science) –Ensure efficient use of the architecture (maintainability) –Avoid duplication of effort (resources) What are we Governing? –EDEX/CAVE plugins developed for an operational AWIPS system Out of Scope: GFE Smart inits and tools, µengine requests, textdb, subscriptions and scripts (shell, python) are covered by the Local Applications Policy Why are we Governing? –Preserve operational system integrity (performance) –Ensure software quality (functionality, science) –Ensure efficient use of the architecture (maintainability) –Avoid duplication of effort (resources)

3. AWIPS Governance How can Governance be achieved? –Establishing simple, flexible, software development and change management policies and procedures that provide value and empower development teams Defines chains of authority, responsibility and communication; Provides Templates and Samples –Providing a place for developers to develop and collaborate Virtual Lab Collaboration Services (communities) Virtual Lab Development Services (issue tracking, version control, integration and code review tools) How can Governance be achieved? –Establishing simple, flexible, software development and change management policies and procedures that provide value and empower development teams Defines chains of authority, responsibility and communication; Provides Templates and Samples –Providing a place for developers to develop and collaborate Virtual Lab Collaboration Services (communities) Virtual Lab Development Services (issue tracking, version control, integration and code review tools)

4. 4 AWIPS-II Development Community Integrator (Raytheon) AWIPS-II Program Developers CP/ASDT, MDL, GSD, Raytheon Satellite Proving Ground Members National Centers Regions & Forecast Offices External Partners AWIPS-II Program Management Virtual Lab Bottom-Up Top-Down National Water Center Process Orientation

5. Governance of AWIPS-II Community Developed Capabilities Focus is on the “Bottom-Up” Community – Key assumption is that work does not originate as part of a “Systems Engineering” process – Expects development via a mission-responsive Rapid Response or Experimental Prototyping Objectives – For Developers – Do not require documentation until it is clear that the content will be needed – Make the process clear, straightforward, affordable, and optimizable Objectives – For Program Office – Promote good practices that optimize the integration process – Promote community collaboration – Promote effective community resource utilization – Minimize incorporation cost and schedule – Minimize Operational Risk due to Feature Insertion

6. Governance of AWIPS-II Community Developed Capabilities VLab “makes the market” – All transactions and status will be conducted and stored using the Virtual Lab AWIPS Community – All integration artifacts are expected to be managed with VLab Redmine projects AWIPS Community on the Vlab – How to instructions https://vlab.ncep.noaa.gov/group/awips-community/home Two Governance Phases – Part 1 - Prototyping and Development – Part 2 - Baseline Integration

7. Governance, Part I Activity Developer VLab Transaction Developer VLab Artifacts Write Great Plugin NHDA Test Request ATAN Request ATAN SREC Request SREC Review NHDA Test Install Script Uninstall Script Code Test Data NHDA Test Plan Install Script Uninstall Script Code Test Data NHDA Test Plan NHDA Test Report CONOPS/Use Case Op. Requirements Data Descriptions/RC Justification

8. Governance, Part II Activity Developer Vlab Transaction Developer Vlab Artifacts > 10 days> 30 days SREC Approval DCS Application Final Artifact Delivery Design Review Integration & Testing Artifact Delivery Baseline Integration & Testing Baseline!DCS Submission CONOPS/Use Case Op. Requirements Data Descriptions/RC Justification Sample Data Prototype Code Install Script Uninstall Script Code Test Data NHDA Test Plan NHDA Test Report CONOPS/Use Case User Manual Ops Requirement Design Template (Updated) Install Script Uninstall Script Code Test Data NHDA Test Plan NHDA Test Report CONOPS/Use Case User Manual Ops Requirement Design Template Sets Target Release and Schedule Code Review Code

9. 9 AWIPS Development Technical Interchanges Technical Interchanges – Architecture Team (Raytheon included) available for technical interchange (1- 2 hours) meetings Schedule a technical interchange (pre-design review): Contact xxxxxxxxxx Instructions to schedule a design review: Virtual Lab  AWIPS Community  Governance  Request a Design Review ( https://vlab.ncep.noaa.gov/group/awips-community/governance) https://vlab.ncep.noaa.gov/group/awips-community/governance xxxxxxxxxx

10. AWIPS Development Training Goal: Diverse community with expertise – Creates options for out-year acquisitions – Enabled by Open-Source system basis – Range of required technologies is a challenge Use of VLab as a knowledge base for training materials Training effort must be organic – The EPDT is a great example! – How do we maintain momentum?

11. Questions