1 / 19

SWSI Bulk Scheduling Enhancement (BSE) Release 04.2 Transition Readiness Review

SWSI Bulk Scheduling Enhancement (BSE) Release 04.2 Transition Readiness Review. Merri Benjamin David Warren. Agenda. Introduction/Background BSE Requirements Software Changes Acceptance Testing Customer Evaluation SWSI User’s Guide Training Status Current SWSI Software Status

chi
Download Presentation

SWSI Bulk Scheduling Enhancement (BSE) Release 04.2 Transition Readiness Review

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. SWSI Bulk SchedulingEnhancement (BSE) Release 04.2Transition Readiness Review Merri Benjamin David Warren

  2. Agenda • Introduction/Background • BSE Requirements • Software Changes • Acceptance Testing • Customer Evaluation • SWSI User’s Guide • Training Status • Current SWSI Software Status • Delivery Plan • Summary-Checklist • Recommendation • Wrap up

  3. Introduction/Background • The purpose of the meeting is the SWSI Bulk Scheduling Enhancement (BSE) Transition Readiness Review (TRR). • The objective of this TRR is to obtain SN Operations and Customer agreement that the SWSI BSE can transition from development to operations as SWSI Release 04.2. • RFA forms are provided and will be accepted until December 9. • With the current SWSI baseline, Release 04.1, SWSI customers must submit their schedules or changes to their schedules, one at a time through their SWSI Client. • SWSI Release 04.2 contains the BSE which enables submission of multiple schedule requests [SARs, SDRs, and RRs] from files.

  4. BSE Requirements • At the start of this software development task, several meetings were held to discuss the functional requirements and desires of the SWSI for the BSE functionality. Bulk schedule input file formats were defined. • On July 7, 2004 a Requirements/Design Concept Review (R/DCR) was held. • 10 RFAs were submitted and all dispositioned. • Action: Verify save function in “submit” path is identical to save function in “save” path • Response: Data flow diagram was modified to better clarify save function • Action: Confirm unknown fields in input file are indeed “don’t cares” • Response: A table was provided which listed the fields that are ignored by the parser.

  5. BSE Requirements (cont) • Action: Eliminate “Filter For …” button if its functionality remains strictly associated with the save function. • Response: button was renamed to “Filter” and will serve as the real filter for the requests in the window. • Action: Consider changing labels to “Start Creation Time” and “Stop Creation Time” • Response: The labels remain as “Minimum Creation Time” and Maximum Creation Time” to maintain uniformity of the SN systems (e.g. SPSR). • Action: Add name of parsed file to tabular display of validation results. • Response: File name added to display • Action: Change the format of the date and time in the “Start Time” field. • Response: Date and time fields are displayed as DOY/HH:MM:SS. • Action: Re-address the minimum requirement for Client, specifically, amount of RAM and hard disk required. • Response: BSE performance testing results indicate no changes to client requirements are necessary as a result of the client modifications.

  6. BSE Requirements (cont) • Action: Modify Tabular Display of Validation window to include the name of the parsed file and provide number of valid/invalid requests. • Response: Window was updated to include file name and provides number of valid/invalid requests. • Action: Add additional filter criteria to filter functions. • Response: Additional filter criteria added (e.g., SIC, TDRS, Status). • Action: Monitor performance problems recently reported in the baseline SWSI and characterize impacts to BSE and develop workarounds • Response: The SWSI development team aggressively investigated the performance problems being reported in Operations and determined a database purge script was not in the baseline. An automated purge script was delivered and subsequently, no performance problems have been reported. Additionally, a system performance and loading test was executed against the BSE delivery and no performance problems were noted.

  7. BSE Requirements (cont) • DCN to SWSI System Requirements Document (SRD) completed and changes approved by the SN CCB. The SWSI SRD has since transitioned to NENS responsibility. • High-level System Requirements • Allow SWSI customer to submit NCCDS bulk schedule add requests (SAR), bulk schedule delete requests (SDR), and bulk schedule replace requests (RR). • Upon successful addition/deletion/replacement, SWSI will provide a request ID for each request listed in the bulk request.

  8. BSE Requirements (cont) • Design derived functional requirements • Bulk Schedule File Input Characteristics • An input bulk schedule file shall be able to contain a mixture of SARs, SDRs, and RRs. • Each SAR, SDR, or RR embedded in the input file will be separated by a new line character. • Comments lines shall be able to be inserted by starting the line with the special delimiter %%%. • The input file shall be limited to 300Kbytes and shall be supplied by the client. • File Processing • Users shall be able to select the input bulk data file via a standard file chooser. • File validation shall be performed on the Client and validation results shall be available for user review and or saved for editing. • User shall have the option to submit to Server the SARs, SDR, or RR which successfully passed Client validation or user shall have the option to abort bulk schedule request. • Summary Filtering • User shall be able to filter Schedule Request Summary window by creation time. • User shall be able to save filtered Schedule Request Summary to a file.

  9. Software Changes • Application Server • No modifications to Server applications or database schema • Baseline system PR 4045  fix is implemented with the BSE.  This fix adjusts the data value of the display length of some service parameters from 4 to 3 and is needed to accommodate the validation checks that are implemented in the BSE Client enhancement.  The fix has no impact to any user. • Client Displays • New Bulk Schedule Requests option on menu under NCC Scheduling • New displays under NCC • Select Bulk Schedule Request Data File pop-up • Summary of Bulk Schedule Request File window • Schedule Add Summary Request Detail for Entry # xx window • Schedule Delete Summary Request Detail for Entry # xx window • Replace Summary Request Detail for Entry # xx window • Service Detail window • New Schedule Request Filter window for Schedule Request Summary • New Active Schedule Filter window for Active Schedule Summary • Client Software • Bulk [SAR / SDR / RR] file parsing and validation routines • Peer Code Walkthroughs were performed.

  10. Acceptance Testing • Since the system is hosted at WSC, client-side environment is defined as desktop PCs (Windows and Unix) with internet access. • Client tested on platforms with • Windows 98, NT, 2000, XP • Solaris 7, 8 • Linux (Red Hat 7.3) • The Open IONet client-side test environment for the system located at GSFC, Building 13 and WSC. • The Closed IONet client-side test environment for the system located only at WSC.

  11. Acceptance Testing (cont) • Acceptance Test Plan generated and contained two test suites • BSE specific functionality and performance testing. • SWSI Regression Test (SWSI – Regression Test 001) • BSE specific tests contained 4 groups of testing with several test cases within each group. Each test case designed to verify the high-level and derived functional requirements. A Verification Case Requirements Matrix (VCRM) is provided in the Acceptance Test Plan. • Group 1 – Verify Client download and installation • Group 2 – Verify new GUI screens and Bulk Schedule Submission and Request ID extraction function. • Group 3 – Verify validation functions for Bulk Schedule SARs, SDR, and SRR . • Group 4 – Performance and Loading tests • All “run for the record” test cases were executed with Beta04. • All tests cases executed against Beta04 passed. A final Test Report was completed on 11/19/04.

  12. Customer Evaluation • Early versions (Beta02 and Beta03) provided to SWSI customers for evaluation. • Operations • Made suggestion to improve validation corrections by asking for an “edit-on-the-fly” capability • Suggested “Deselect All” button for filter screens • GP-B Scheduler and NOM • SWIFT NOM • SP&M "Overall, the SWSI terminal has done an excellent job of verifying the content of our requests and has given very useful error messages which helped us fix our data.  After adjusting the values to meet the expected values, the message parsed successfully and has been transmitted."

  13. SWSI User’s Guide • The User’s Guide was updated and reviewed, and used by the Test Team during Acceptance Testing. • DCN 002 to the User’s Guide is complete and submitted to SN CCB for review and approval. CCB review is scheduled for December 7, 2004.

  14. Training Status • Some SN Operations staff provided initial Beta evaluations and supported BSE Acceptance Testing. • Test Team will initiate training with appropriate Operations Support Personnel • Initial instructions and sample test files provided to interested SWSI customers during testing phase. Test support and Operations support personnel will provide technical assistance to all SWSI customers, as needed. • Updated SWSI User’s Guide provides detailed instructions with screen snaps of the operation of the BSE function. BSE scheduling is provided in Section 8.

  15. Current SWSI Software Status • All problems noted in earlier Beta versions were fixed and there are no open BSE PRs against Beta04. • If accepted for transition to Operations, Beta04 will be delivered as SWSI Release 04.2 and replace Release 04.1.

  16. Delivery Plan • BSE Release Delivery • Highlights • Issue Network Advisory Message (NAM) • Upon transition approval, the Release 04.2 client will be made available for download from the website • Customers will upgrade client at own downtime but expect all users to download and use new client by 1/31/05. • Zero SWSI server downtime but Operations will restart SNIF and Isolator to activate PR change • 04.1 client is compatible for users not urgently needing BSE functionality • WSC OPS will provide support • No Failover testing necessary since no server changes • No back out of delivery has to happen as 04.1 and 04.2 SW can co-exist on client • Sustaining Engineering • Status Quo • SWSI I&T environment will remain at GSFC. • SWSI falls under the purview of the SERB. • CDS used as the discrepancy management system. • Next release (05.1) to correct 04.1 PR’s prioritized by SERB

  17. Summary - Checklist • All requirements verified in testing- No software rework required. • System Requirements Document and User’s Guide updated. • Some training has taken place and SN Operator training will be provided by the SWSI Development and Test Team. • SWSI Development and Test Team will provide Customer assistance, as needed. • A delivery plan is provided. CM processes developed during Release 04.1 will be used.

  18. Recommendation We recommend that the 04.2 SWSI Bulk Scheduling Enhancements be accepted and transitioned into SN Operations.

  19. Wrap up • Review and assignment of Action Items • RFA Form available on Documentation page at http://swsi.gsfc.nasa.gov/ • Submit RFAs to the TRR Chairperson only. • RFAs due by December 9th • Closing remarks

More Related