Software Development & Maintenance Process

1. Software Development & Maintenance Process RADAR OPERATIONS CENTER SOFTWARE ENGINEERING NEXT

2. Software Development& Maintenance Process External Committees & Boards START Process CCRs Problem Analysis Process RTIs Design Security Patches Development External User Problem Reports Testing Documentation Release END

3. Software Process Start • Project Initiation • The ROC/SE maintenance process can be initiated in numerous ways: user requests via various boards and committees associated with the WSR-88D, Hotline support calls & Requests for Technical Information (RTIs), test reports, etc. • Notification • The ROC/SE maintenance process can be initiated in numerous ways: user requests via various boards and committees associated with the WSR-88D, Hotline support calls & Requests for Technical Information (RTIs), test reports, etc. • Configuration Change Requests • Any change to software baselines maintained by the ROC must be preceded by an approved Configuration Change Request (CCR). CCRs are used to track requested changes through the software maintenance process. • Committees & Review Boards • Software CCRs must pass through various committees, boards, and working groups to ensure that changes meet the requirements set for the WSR-88D. • NEXRAD Program Management Committee (NPMC) • Technical Advisory Committee (TAC) • Technical Review Committee (TRC) • Software Requirements & Evaluation Committee (SREC) • Test Review Board (TRB) • Build Review Board (BRB) • Configuration Control Board (CCB) • Adaptable Parameters Working Group (APWG) • Computer Networks Working Group (CNWG) • Test Bed Working Group (TBWG) • Operations & Services Improvement Process (OSIP) NEXT

4. Problem Analysis • Investigation • The SWE will attempt to recreate any problem reported and analyze the results until a cause is determined. The SWE may be required to perform some problem analysis prior to creating the SW CCR in order to accurately describe the problem and propose possible solutions. In general, the Problem and Solution sections of the CCR form should be as descriptive as possible in order for external reviewers to fully understand the problem and how the problem will be addressed by the software solution. • Cost Estimates • Once the SWE has determined the cause of a problem, he will estimate the level of effort required to correct the problem. This estimate will include software lines of code (SLOC) and man-hours required to implement and test changes. The cost information will be used to assign a level of risk associated with implementation of the CCR. • Resource Metrics • The SWE will decide what resources will be required to execute the change. This will include manpower, hardware or software requirements, test bed assets required, etc. • Requirements And Specifications • Once the analysis is complete, the SWE shall define requirements and specifications for any proposed software change. These requirements and specifications may include a proposed solution, an impact statement, a list of impacted shared code, a list of impacted CPCIs, a list of impacted documentation, and any security impacts. These requirements and specifications shall be documented in a CCR in accordance with WPI0002SW, SW CCR Originator Instructions. NEXT PREVIOUS

5. Design • Preliminary Design • The SWE will design a solution based on the requirements and specifications documented in the CCR. • Design Approach Review • The Design Approach Review (DAR) is a joint review with the customer, developer, implementer, ROC, and external users in order to reach an agreement on the proposed design. The DAR is to be held as early as possible in the design phase. Not all changes require a DAR. A DAR is required for changes that affect the external user of the system or the system operator. WPI00XX, Transfer Of RPG Science To The ROC contains guidance on DAR requirements and content. NEXT PREVIOUS

6. Development • The SWE will implement the software changes according to the approved design. • Development Systems - Hardware • PC Compatible Computers • RDA and RPG software is developed on a PC compatible computer system under RedHat Enterprise Linux. PUP software is developed on a Sun Microsystems computer system under Sun Solaris. • Software Test Bed • ROC/SE operates and maintains a Software Test Bed (SWTB). The SWTB contains fully functional and reconfigurable representations of fielded systems. The SWTB is used to investigate reported problems from the field and test software under development. • Development Systems - Software • RAZOR • RAZOR is used as a repository for all software source code developed by ROC/SE. Razor has the capability to maintain several baselines concurrently and is maintained by ROC/CM. Razor Versions is a software version control tool used to control software changes. Razor Issues tracks software change proposals. Every Razor Issue is associated with at least one software CCR. Software modifications can only be introduced into Razor Versions with an “active” Issue. Issues can only be placed in an “active” state with an approved CCR and only by ROC/CM. NEXT PREVIOUS

7. Development (cont’d) • Coding Standards • Coding standards define a set of standards and common practices related to developing software for inclusion into software under development. If coding standards are defined for a software area, the SWE is expected to follow the standard for all software changes introduced into the software baseline. • RDA • The RDA Software Coding Standards for Java and ‘C’ Language programming are currently part of the RDA Software Development Plan (SDP), OSTPLN-ORDA-002. • RPG • The RPG C Coding Standard (CCS) establishes a set of standards and common practices related to developing software for inclusion into the RPG software baseline using the C programming language. The RPG CCS closely follows the ANSI C and POSIX standard and is available as WPI0051, RPG C Coding Standard. • PUP • The PUP does not currently have an established software coding standard. NEXT PREVIOUS

8. Development (cont’d) • Meteorological Algorithm Development • Meteorological algorithms are developed to analyze products generated by the RPG. Algorithms are included as part of the RPG baseline, however most algorithms are developed by WSR-88D Implementing Organizations (IOs) sponsored by any of the three supporting agencies. All algorithms submitted to the TAC for consideration. The TAC will review the proposed algorithm if they approve will recommend it be included in the WSR-88D operational baseline. The SREC will make a recommendation for targeting the algorithm to a specific build. The NEXRAD PMC has final approval authority. • Implementing Organizations • New algorithms may be submitted to the ROC by any of the IOs sponsored by any of the three supporting agencies. • Common Operations Development Environment • The Common Operations Development Environment (CODE) is an algorithm development environment for the WSR-88D. CODE contains the software and guidance required to create the algorithm development on an Intel PC running RedHat Enterprise Workstation Linux. CODE provides a “clone” of a WSR-88D RPG on a workstation which can run existing and user-created algorithms by ingesting WSR-88D Archive Level 2 data. CODE can also be used to study past weather events by ingesting Level 2 data obtained from the National Climatic Data Center (NCDC) web site and creating products for analysis. CODE is maintained by the Office Of Science And Technology (OS&T). For more information visit the WSR-88D CODE web site (www.Weather.gov/code88d/). • Transfer Of RPG Science To The ROC • The process for including new algorithms into the WSR-88D baseline is described in WPI00XX, Transfer Of RPG Science To The ROC. NEXT PREVIOUS

9. Testing • ROC/SE is responsible for conducting a series of tests on all newly developed and updated software prior to handing off to the Radar Systems Test section (RST) for formal IV&V testing. The various tests performed by ROC/SE are described below. • Test Procedures • SWEs will develop test procedures on all newly developed and updated software. These procedures will be documented in applicable RAZOR Issues. • Testing Phases • Unit Testing • SWEs perform Unit Testing on all newly developed and updated software prior to introducing into RAZOR for inclusion in the WSR-88D baseline. The methodology and results of unit testing is documented in applicable RAZOR Issues and may be used during Integration and IV&V Testing. After checking changes into RAZOR, the SWE will test the software build to verify all source code relating to the change was successfully introduced into the software baseline. NEXT PREVIOUS

10. Testing (cont’d) • Testing Phases (cont’d) • Integration Testing • Integration and Regression Testing is a ROC/SE function. Any critical or minimal major defects identified during Integration and Regression Testing will be resolved by ROC/SE before the start of IV&V. Other defects or problems identified will be resolved and corrected on a case by case basis. • Integration Test Readiness Review • The Integration Test Readiness Review (ITRR) is an informal discussion between test personnel and software developers of all changes to the software baseline. The purpose of the ITRR is to review the implemented (as built) software enhancements, Unit Test methodologies and results, and associated documentation. • Integration Testing • ROC/SE performs Integration Tests in accordance with the developed test procedures. Integration tests are performed to ensure new functionality behaves as designed and software defect corrections actually correct the defect they were designed to correct. NEXT PREVIOUS

11. Testing (cont’d) • Testing Phases (cont’d) • Regression Testing • ROC/SE will perform Regression Tests in accordance with applicable Regression Test Plans. Regression Test Plans are updated as required for each software baseline and stored in Agile. Regression tests are performed to verify existing functionality performs as expected and no defects were introduced during the Development phase. For more information, refer to 2660042 RDA Regression Test Plan and 2660043 OPUP Regression Test Plan. • Product Regression Testing • Product Regression Testing (PRT) is performed to verify that products which should not have been affected by changes made during the development phase were indeed unaffected. PRTs will cover all products defined by 2620001M, ICD For The RPG To Class 1 User. NEXT PREVIOUS

12. Documentation • Comment Source Code • User Instructions, Manuals & Training Material • System Maintenance Manuals, Instructions, & Training Material • System Documentation • System Specification • System/Subsystem Design Description • Interface Control Documents • Software Documentation • Software Requirements Specification • Software Design Description • Software Product Specification • Software Test Description • Software Test Report • Software Version Description NEXT PREVIOUS

13. Release • Upload Source Code To RAZOR. • Update Status • Issues In Razor • CCRs In Agile • ECPs In Agile • Software baseline released for IV&V. NEXT PREVIOUS

14. Reference • For more information, refer to the Software Development & Maintenance Guide, http://www.ROC.NOAA.gov/[InsertRealLinkHere] PREVIOUS