Slide1: UPGRADING LEGACY APPLICATIONS Lt(N) Howard Morris DGMEPM/DMSS Project Manager HALIFAX Software Support Facility (HSSF) Global Command and Control System Maritime Afloat (GCCS-M Afloat)


Upgrading means “Changing”: Upgrading means “Changing” Upgrading is simply “Changing” to something presumably better At the System Level: first examine the impact of a proposed change to people, processes, safety and equipment next, obtain a cost estimate for the change, and finally, implement the change according to the estimate Two primary System Level processes for controlling and measuring the cost of the change within the Navy DGMEPM Business Planning process Engineering Change process (EC process)


Slide3: Upgrading the Dilbert Way


Engineering Change (EC) Process Business Planning Process: Engineering Change (EC) Process Business Planning Process EC Process Two Forms - EC Part I form identifies the requirement for the change and EC Part II form is an impact analysis ECs are reviewed by Systems Engineering and Requirements ECs are tracked using a database tool - CMIS DGMEPM Business Planning Process Business Planning Process subsumes EC process Projects are the elements of Business Planning Project Directive authorizes expenditure of funds and entry into the Business Management/Project Management Tool - WorkMan Business Planning Process EC Process Change(s) Requested Change(s) Installed


Software Change Process MARCORD 4-30: Software Change Process MARCORD 4-30 Software Change is controlled by the EC process The MARCORD Describes the method for processing change: When there is a reason to change software from the user’s perspective, a DND Unsatisfactory Condition Report (UCR) form is raised Operational Analysts perform initial vetting of the UCR Technical analysts from system engineering facilities (second and third line) ensure the change requested can be performed via software User group meetings are held to prioritize a list of changes User list combined with NDHQ sponsored (third line) changes to create a version plan Version planning meeting held to review and authorize the plan EC is raised against the version plan 1 N


Slide6: Software Test and Evaluation MARCORD 4-30 Subsystem testing is first performed within the subsystem Three More Levels of Test mandated in MARCORD 4-30 Integration Test System Test Fleet Test Integration Testing tests the subsystem interface and associated system level software components System Testing is a full-up test system test and attempts to simulate reality as much as possible Fleet Testing is performed in the operational environment Also included in the MARCORD is a requirement for Weapons Certification Testing Upon completion of all tests, and once training issues are assessed, the software is released to the Fleet Subsystem Integration System Fleet Weapon Release


Software Integrated Logistic Support MARCORD 4-30: Software Integrated Logistic Support MARCORD 4-30 All ships within a class are meant to be configured identically thus facilitating software configuration management at the system level In practice, there are unique aspects to each ship Media Libraries exist in Halifax and Esquimalt in order to assist with system level software configuration management Subsystem OPIs deliver changed media + copies to media libraries New Media is released once it is approved by operational, technical, and, if necessary, weapon certification authorities On release of new media, retention of previous media is not authorized Media Libraries track delivered software to each ship and provide a depot for the return of superceded software from each ship Media Library To From Ships


Example of Managed Change Mk 49 INS Replacement: Example of Managed Change Mk 49 INS Replacement Mk 49 Inertial Navigation System (INS) Replacement Adaptive Change to the HALIFAX class CCS Requirement for Change existing INS (Mk 29) not reliable and increasingly unsupportable INS is a critical system - it provides attitude data to all weapons and sensors Change Philosophy of minimizing impact accomplished by: preserving CCS - Navigation software interface preventing “requirements creep” ECs and Project Directives were created and the change to software was entered against the Version Plan for HALIFAX class CCS CCS Software Change (Version 6.0) will be released through the Media Libraries to each ship once the Mk 49 is installed


Software Change Contracting: Software Change Contracting There are no directives within DGMEPM, nor MARCORDs that specifically deal with how to contract out software work However, all Navy software work is contracted out General contracting practices: DND personnel perform requirements analysis, track contractors progress, and accept finished work Contractor designs and implements software products against DND’s stated requirements Software contracting observations: People, not products, are the true contractual item Good software people are expensive Contracting Risks: Intellectual Property of entire product may not belong to DND Software Process Improvement dependant upon contractor Change of business processes and more importantly, people


Slide10: Software Contracting at the Halifax Software Support Facility (HSSF) Some successful practices to date: Complete Test Environment on-site Establishment of an NDHQ project manager NDHQ PM is a virtual member of the on-site team Open Communication from on-site contractor through to NDHQ Navy personnel on-site with the contractor On-site personnel members of NDHQ Delegated Responsibility to the on-site Navy personnel NDHQ support of facility level Software Process Improvement initiatives resulting in well-defined process documentation Defined processes implemented electronically using a customized work flow tool Independent assessments - S:Prime, CMM, and MITRE


Upcoming ChangeNavy’s C4I Way Ahead: Upcoming Change Navy’s C4I Way Ahead Requirement for Change based on need for “information management” New System Architecture currently based on C4I Way Ahead Brief DMSS 8-2 - Mr. Udo Seltitz Guiding Principles: Flexibility Expandability Build on existing management procedures and systems Constraints: Cost Implied use of “COTS”


Example Change Current HALIFAX Combat Data System: Example Change Current HALIFAX Combat Data System COMMUNICATIONS TORPEDOES SEA SPARROW VERTICAL LAUNCH 57MM CIWS HARPOON 13 TACTICAL COLOUR DISPLAYS SHINPADS DATA BUS FAULT TOLERANT USING 4 CABLES CROSS CONNECTED STIRS EW SYSTEM


Example Change Future HALIFAX Combat and Control System: Example Change Future HALIFAX Combat and Control System


Halifax Software Support Facility Upgrades Program Generation Center Upgrade: Halifax Software Support Facility Upgrades Program Generation Center Upgrade Before - Jul 95


Halifax Software Support Facility Upgrades Program Generation Center Upgrade: Halifax Software Support Facility Upgrades Program Generation Center Upgrade Now


Slide16: Halifax Software Support Facility Software Process Improvement Products of Process Improvement Include the following documentation: Revised Software Engineering Management Plan Technical Investigation Process Software Change Process Software Quality Project Plan Work Instruction for Software Estimation Version Test Release Process establishes the minimum acceptable test framework for CCS Testing which amplifies MARCORD 4-30 Annex A Release Weapons Certification Fleet Test Stress (Beta Test) System Delta Functional Survivability Integration Subsystem


Slide17: COTS : Global Command and Control System - Maritime Afloat (GCCS-M Afloat)


Slide18: COTS : NAVAL CONFERENCE DISPLAY


Slide19: COTS : NAVAL CONFERENCE DISPLAY


Slide20: The Navy is successfully upgrading systems via: Established Processes Best Practices Project Management focus Remaining constantly vigilant of risks Primarily Contract and Personnel Change The Navy will successfully manage the upgrade path to COTS through application of current practices and processes Summary Upgrading Legacy Applications