Configuration Management, Software, Honeywell

PL-1458-11202 SOFTWARE CONFIGURATION MANAGEMENT PLAN A3DCW0000001 Rev:
Project Plan
For
Number Brief Description Tech Writer Date
A 14-0363 Project Plan to initialize Software Testing for PRODUCT Modules
James Brown 11/29/18
DCW0000001 Rev:
TABLE OF CONTENTS
1. INTRODUCTION ............................................................................................ 4
1.1 SCOPE ............................................................................................................. 4
1.4 DEFINITIONS ................................................................................................... 6
2. DOCUMENTS ................................................................................................ 7
2.3 EXTERNAL STANDARD DOCUMENTS ........................................................... 7
3. ENVIRONMENT OVERVIEW ......................................................................... 8
3.1.2 Revision Control – Agile ....................................................................... 12
3.1.3 Software Freeze ................................................................................... 12
3.1.4 Release Criteria ................................................................................... 12
4.1.2 Relationship of identification ................................................................. 22
XYZ Company
DCW0000001 Rev:
4.2 BASELINES AND TRACEABILITY ................................................................. 23
4.3 PROBLEM REPORTING ................................................................................ 23
4.3.2 Sample 2: “Create Issue” ..................................................................... 24
4.4 SOURCE FILE CONTROL.............................................................................. 25
4.6 CONFIGURATION STATUS ACCOUNTING .................................................. 29
4.7 ARCHIVE, RETRIEVAL, AND RELEASE ....................................................... 29
4.8 SOFTWARE LOAD CONTROL ...................................................................... 30
5. SCM DATA ................................................................................................... 31
DCW0000001 Rev: C
1. INTRODUCTION
1.1 SCOPE
This Software Configuration Management Plan (SCMP) establishes the methods to be used to achieve the objectives of the Software Configuration Management (SCM) process throughout the software life cycle of the Product Radio Frequency Unit (PRODUCT) Module, part numbers:
• ABT-KAG025-MT10 (CON)
• ABT-KAG025-MT11 (AIR)
• ABT-KAG025-MT12 (FAN)
This SCMP adheres to XYZ Company’s Standard Operating Procedures defined in SOP-ENG-0007 – Software Development Life Cycle.
This SCM addresses specific disciplines applied to insure effective version identification, control of the software components, identification of responsible parties for configuration management, and defined processes involved in making and implementing modifications.
1.2 DOCUMENT STRUCTURE
Section 1 Introduction: Provides the document scope and structure as well as a listing of acronyms and abbreviations.
Section 2 Documents: Provides a listing of applicable and/or reference documents.
Section 3 Environment: Provides a description of the SCM environment to be used, including procedures, tools, methods, standards, organizational responsibilities, and interfaces.
Section 4 Activities: Provides a description of the SCM process activities in the software life cycle.
Section Error! Reference source not found. Error! Reference source not found.: Provides a description of the transition criteria for entering the SCM process.
Section 5 SCM Data: Provides a definition of the software life cycle data produced by the SCM process.
XYZ Company
DCW0000001 Rev: C
1.3 ACRONYMS AND ABBREVIATIONS
SOP Standard Operating Procedure
SRD Software Requirements Document
SDP Software Development Plan
SAS Software Accomplishment Summary
DCW0000001 Rev: C
1.4 DEFINITIONS
Blue Label Unit: Blue Label Units are preliminary design units that are under new
product development control. Both hardware and software components are formally
released. The Blue Label build standard is representative of preliminary design and
product definition. Software of Blue Label Units is tested for functionality and
compliance with Software Requirement Specification (SRS).
Red Label Unit: Red Label Units are developmental units that are under engineering
design control. Both hardware and software components are formally released. The
Red Label build standard is representative of the final critical design units. However,
minor software modifications required by Software Verification Plan (SVP) and software
testing will be incorporated in the final PRODUCT design.
Black Label Unit: Black Label Units are LRUs that are under full production control for
customer delivery. The Black Label Units have full functionality as defined by the
PRODUCT SCD and is Airborne certified. All software developed for Black Label Units
will be tracked, controlled and released as baseline software components and will be
documented in the Software Assessment Summary (SAS).
• ISO / IEC 12207 Software Lifecycle
• ISO / IEC TR 19759 Guide to Software Engineering Body of Knowledge
• ISO 9126 – Characteristics of Software Product Quality
XYZ Company
DCW0000001 Rev: C
2. DOCUMENTS
The documents identified below were either used as guidelines for the preparation of the SCM plan or reflect standard operating procedures applicable to the procedures to be followed for this development effort.
2.1 REFERENCE DOCUMENTS
Document ID Description
2.2 APPLICABLE XYZ COMPANY DOCUMENTS
Document ID Description
SOP-ENG-0007 Software Lifecycle
SOP-QAL-0001 Quality Manual
SOP-QAL-0012 Quality Management System (QMS)
SOP-QAL-0015 Product Labeling Requirements, Tracking Revisions & Modifications, Airborne, Commercial
2.3 EXTERNAL STANDARD DOCUMENTS
RTCA DO 178 Software Considerations in Airborne Systems & Equipment Certification
ISO 9001:2008 Quality Systems – Model for Quality Assurance in Design, Production, Installation and Servicing
RTCA/DO-254 Design Assurance Guidance for Airborne Electronic Hardware, 19 April 2000
IEEE 12207.1/2 Standard for Information Technology-software life cycle
ISO 9126-1 Software Quality- Characteristics of Software Product Quality
ISO / IEC TR 19759 Guide to Software Engineering Body of Knowledge
ANSI/EIA-649-A 2004 National Consensus Standard for Configuration Management
XYZ Company
DCW0000001 Rev: C
3. ENVIRONMENT OVERVIEW
XYZ Company adheres to structured software development processes. The chart on the
subsequent page illustrates the standard Software Development Life Cycle (SDLC) used for
program developments associated with a Customer Requirements Specifications document;
wherein customers have defined the performance and interface requirements for the product.
The chart illustrates the primary inputs and outputs to each phase of development including
Operation and Maintenance.
All product artifacts are maintained under document control within our secured network.
Document management is provided by Agile wherein each document is issued a part number.
Prior to release each document must go through a formal release process. Agile is used to
manage the Bill of Materials for each product. Inclusive within Agile are both hardware and
software part numbers. For software part numbers, there are corresponding software version
identifiers called out within the part number description.
The SDLC consists of 7 Phases:
• Planning Phase:
The primary output from this phase is the Software Requirements Document with links
back to customer requirement specifications. The initial project plan is developed.
• Preliminary Design Phase:
The primary outputs from this phase are the Software Design (SDD) and SICD.
• Critical Design Phase:
Primary outputs from this phase include test plans, updated SDD, initial code
development, and bench test results.
• BETA Build and Test
During this phase HPTs will be assembled and tested including Design Verification Test
and Environmental tests.
• Release to Manufacturing
• Mature Operation
This phase reflects the ongoing production needs; FAT; assembly procedure updates;
enhancements and changes; updated software components; and defect fixes.
• Support
The Support phase reflects the end of Sales Life wherein no further modifications are
made to hardware or software.
XYZ Company
DCW0000001 Rev: B
Figure 1
XYZ Company
DCW0000001 Rev: C
Configuration management is facilitated through Agile Project Lifecycle Management system and adherence to change management procedures addressed in SOP-ENG-0003 and SOP-ENG-0009; Engineering Change Order (ECO) Process and Software Release Procedure respectively.
The project manager has overall responsibility for the configuration of the system under development. The Project Workbook identifies designated responsibilities for Change Control included authorized personnel to sign-off on changes through the Agile PLM. SOP- ENG-0003, Engineering Change Order (ECO) Process, defines the sign-off process required for all modifications. All software related modifications are originated by a firmware engineer from the Electrical Engineering group. Typically the following work groups are included in the approval of all ECOs.
Originator
o Mechanical
o RF
Material Management
Quality Control
Configuration Manager/Document Control Release
The sign-off or rejection of the change is performed online. If rejected, the individual must enter password and update the Reason for Failure field. Similarly, if approved, the individual will need to enter his/her password.
The configuration manager is responsible for the administrative handling of the changes through Agile PLM. The CM reviews the initial change request and provides final oversight and release. CM assigns privileges and approval work flows for the Agile PLM.
XYZ Company
DCW0000001 Rev: C
3.1 OVERVIEW OF SOFTWARE CONTROL PROCEDURES
All firmware and GUIs are controlled via Agile and adhere to XYZ Company internal standard operating procedures; SOP-ENG-0007, Software Life Cycle; and SOP-ENG- 0009, software Release Procedure. All software must be released prior to being shipped in a product to a customer. Changes to firmware or GUI require an ECO. XYZ Company Test software is available via a shared directory. For customer approval, Test Software is available through secure FTP Web site.
SOP-ENG-0009 provides the specific control and code management procedures and
forms to be used. During the project development effort, the code versioning is
managed through Perforce. Code Checking and Check out processes are managed
through Perforce maintaining a full audit trail and chain of custody for deployed
artifacts. Once the programmer is satisfied with the correctness of the code, the formal
test forms specified in SOP-ENG-0009 are followed and independent testing completed
in preparation of releasing software in Agile. After approval the source and executable
are retained in Agile. These are identified as the currently released versions in Perforce.
Once firmware or a GUI has been released, it will be uploaded by Document Control to the Software folder on Foghorn for access by authorized personnel through Agile. Access to this folder must be requested from Document Control.
• See Form-0042 for folder location
Software is managed by version and revision. A decimal number is used to manage the software version and revision. Revisions are controlled by Agile. Versions are incremental through the development and testing process and are represented by the number to the right of the decimal.
x.yy
X (digit left of decimal) is considered a major change and will affect the customer (i.e. it is a ‘front end’ change)
o Customer Notification is required
o In some instances, customer approval may be required prior to making a software change. Marketing and/or Engineering must define the customers affected by the change.
o Document Control will get approvals as needed.
o A Software Change Notice form shall be completed by Document Control.
YY (digits right of decimal) is considered a minor change and may not affect the customer (i.e. it is a ‘back end’ change)
o Customer will be notified of the changes
XYZ Company
DCW0000001 Rev: C
• Version - Examples Only
Type of Change
Version [for example]
Status Customer notification
Minor V1.24 Released through Agile Yes
Major V2.10 Released through Agile Yes
3.1.1 VERSION CONTROL – (SUBVERSION OR EQUIVALENT)
Versions are sequential iterations of software that are primarily used during development. Perforce is used to control versions, intelligently organize modules, support debugging, and maintain an audit trail of all change activity. Test versioning follows a version sequencing in accord with SOP-ENG-0009, Section 6.2 – Managing Firmware Test Versions (e.g., unreleased-001, unreleased-002, etc.). Typically versions are not released to customers until a version is proven to be satisfactory, then that version will be released for product shipment. The numbering sequence traces the software evolution.
Iterations shall change the digits to the right of the decimal
Updates – checkout the most current iteration of the software Testing – functionality testing should follow the appropriate test plan Storage – iterations of the software will be stored in the appropriate folder
Bug Tracking and defect mitigation should be tracked via Excel problem log.
3.1.2 REVISION CONTROL – AGILE
Revisions are released software item records, whenever a front end change occurs the revision must be incremented and the software item is either released or updated in Agile. Software is tested during the Beta Build and Test Phase then Released to Manufacturing for the Operation stage. Source code and executable are stored in Agile (Foghorn library accessed for update only through Agile).
Updates – released software requires an ECO and approval before being rolled out Testing – regression testing should be performed for each revision Storage – released software is stored in Agile Release – software must be reviewed and released via Agile
3.1.3 SOFTWARE FREEZE
During new product development, the software components are frozen during the Beta phase to allow evaluation, testing, and bugs to be identified, tracked, and incorporated prior to final release of the software components.
3.1.4 RELEASE CRITERIA
Before routing a software revision through Agile for release, the Test Plan should be executed to verify the design and as needed regression testing.
XYZ Company
DCW0000001 Rev: C
3.1.5 NOTIFICATIONS
When Document Control releases the software these functional areas have the following responsibilities.
• Document Control:
Automatic notification is sent by Agile to XYZ Company users
Update software network folder with the latest version
• Marketing:
• Production:
XYZ Company
DCW0000001 Rev: C
Printed Document is Uncontrolled Page 14 of 31
The chart below provides a high level view of the software develop process for this
development program. The customer PRODUCT_SCD will be the basis for establishing
software requirements – stated and derived. These requirements will direct the completion of
the internal Software Requirements Document that will provide traceability to the
PRODUCT_SCD. The WS SRD for this project will provide: a) WS ID & control number; b)
Description of the Requirement, c) Related PRODUCT_SCD ID, and Test Case ID. Test Case
ID will be completed during the Test Planning Phase.
Figure 2
XYZ Company
DCW0000001 Rev: C
The requirements provide the basis for the software design. Perforce is used to maintain source
libraries; physically manage and track code modifications. The firmware facilitates PRODUCT
management and the Monitoring and Control interface to the PRODUCT. The GUI software
supports our external access to the PRODUCT supporting initial tuning and testing of the unit.
3.2 TOOLS
Several tools are used throughout the Software Development Life Cycle. These tools are used to insure effective and meaningful controls and support to the development effort.
Compilers/IDEs
Firmware:
• Perforce
• Agile
Bug Tracking
• Microsoft Excel
Perforce is the tool used to manage source code; facilitate hand-off from development to production; and facilitate effective team collaboration. The file management structure within Perforce enables effective identification and tracking of both test software and locked down production versions. Perforce provides adaptable workflow for teams and promotes efficiencies such as code re-use, automated merging, fast context switching, efficient workspace updates, and inherited workspace and branch views.
Agile provides for product lifecycle management. The development libraries are managed within Perforce. Approval and release of source and executable files are managed within Agile and locked down and stored in the Foghorn directory. The BoM includes the software part number and identifies the source and executable within Documents tab.
All bugs that occur during development are tracked on an Excel spreadsheet.
XYZ Company
DCW0000001 Rev: C
3.3 METHODS
Documents and other artifacts developed during the software development process
include:
• Manufacturing Test Procedure
• Source Code/Executable
Review processes are integral to each stage of development and document control is maintained under Agile. All support documentation facilitates traceability to requirements. Source Code is developed under Perforce to manage code development, versioning, and testing. Figure 2 provides a high level overview.
Software development adheres to practices and procedures defined in SOP-ENG-0007; code release procedures are addressed in SOP-ENG-0009; modifications follow procedures defined in SOP-ENG-0002
3.4 STANDARDS
The primary guiding standard for configuration management within this program is RTCA
DO 178 level D.
The Configuration Manager manages all configuration items into Agile insuring proper document and part number identification. The CM coordinates introduction of new part numbers for artifacts included in the development process. CM coordinates review and sign-off of artifacts for release. CM coordinates customer notification for artifacts requirement customer notification or approval. CM assigns privileges and approval work flows for the Agile PLM.
Software Engineering manages the code libraries and adheres to Perforce check-in and check-out processes. Final source and executable are locked down in Perforce and retained in the Foghorn director for Agile PLM.
Project Manager reviews and approves all artifacts. Project/program manager also directs the Change Control Board after implementation prioritizing potential changes. The
XYZ Company
DCW0000001 Rev: C
following chart is extracted from SOP-ENG-0009 that outlines firmware development responsibilities.
Title Responsibilities
Software Engineer
Apply Form-0074 to unit.
Manage Software Version updates while under evaluation/testing.
Submit necessary Software files (see SOP-ENG-0002) in Agile for approval.
Fill out Form-0112 (for checking purposes, needs to be done by the SE reviewing, not the SE that wrote the code).
Test Engineer Provide feedback for software upgrades needed or to fix a problem.
Perform Regression Testing as needed
Acknowledge software is working.
Configuration Management
Verify Software Version has been released in Agile.
Verify all requirements are in place before authorizing the removal of the Warning Label.
3.6 INTERFACES
Configuration Management interfaces with nearly all facets of the organization.
• Materials Management
The BoM for all products are maintained in Agile PLM. Material Managers utilize this information to support their planning activities.
• Purchasing
All parts are managed and tracked in Agile PLM and utilize the system for part information; drawings and specifications to obtain bids, and research. Technical files access for third part builds.
• Engineering
DCW0000001 Rev: C
Engineering relies on Agile PLM for parts management and control of all mechanical and PCB assembly drawings, schematics, and technical files. ECOs are processed through Agile.
• Manufacturing
Assembly procedures, test procedures, assembly drawings are stored in Agile and available to the manufacturing personnel.
• Customer Service
Customer service accesses the PLM for access to part information in support of customers.
• Accounting
Agile PLM interfaces with the SAP accounting system supporting product cost analysis, parts availability, and in identifying potential shortages.
XYZ Company
DCW0000001 Rev: C
4. ACTIVITIES
The different artifacts that are created throughout the development process adhere to
the following naming conventions:
99-006-xxxx Test Report
EXE-70-001-xxxx Executable associated with SW part number
SRC-70-002-0002 Source code associated with SW part number
70-001-0002 GUI Software Part Number
SWF0000004 GUI Executable associated with SW Part number
SRC-70-004-0004 GUI Source associated with SW Part number
70-001-0002 Manufacturing Test Code
DCW0000001 Rev: C
Identification Scheme (Part
Number within BoM)
SRC-70-003-0003 Source associated with Mfg. Test Code
70-001-0003 Manufacturing Test Procedure
Below is an example of top level software part number illustrating “Title Block” view in Agile. The Rev ID along with the most current engineering change causing this rev level is identified just below the part number designation in left corner of the center frame.
The source code, executable and test report files are in identified in the BoM in the “Attachment
tab”.
DCW0000001 Rev: C
By selecting the “Where Used” Tab Agile will display the associated top level product. The
software also appears as a part number in the top level BoM.
XYZ Company
DCW0000001 Rev: C
4.1.2 RELATIONSHIP OF IDENTIFICATION
The main software is identified as a level 1 part number in the product BoM. Firmware associated with specific components is included as child items under their related PCBA. The Block Downconverter’s firmware, for example, is a child item under its part number. In the sample display below, 01-019-0001 is the part number for the BDC, hardware. The BDC has two firmware components – one for the Low band and one for the high band; 70-001-0070 and 70-001-0074 respectively.
If either part number is selected, the source and executable files are displayed in their Attachments tab in Agile as shown below.
XYZ Company
DCW0000001 Rev: C
4.2 BASELINES AND TRACEABILITY
The release of the Software Requirements Document into Agile marks the initial baseline for the software to be delivered with the associated mainline product. Any modifications to these requirements will be performed under change control. Baselines are maintained in Agile and Perforce. All development controls prior to submission to Agile are maintained within Perforce. All released versions are maintained as baselines in Perforce. The baseline source code is established at the end of the Beta Test and Build Phase after the formal Design Verification Test and Acceptance Tests have been successfully completed. Code changes during the testing phase are managed through Perforce and tracked using the Program Update Log. With the completion of the Acceptance test the baseline code versions are placed under change management control. The software/firmware part numbers are released in Agile and are frozen. Any modifications moving forward will adhere to Engineer Change Control (ECO) process.
4.3 PROBLEM REPORTING
XYZ Company Jira is the new platform for capturing, tracking, and resolving bugs and issues throughout the development process. It replaces Excel and is used for reporting problems and issues that may occur during testing. Once logged into the “Dashboard” select “Create Issue” from the sidebar to see a selection of user customizable fields available for problem reporting. (See samples 1, 2 and table below).
Sample 1: Jira “System Dashboard”
XYZ Company
DCW0000001 Rev: C
Sample 2: Create Issue
Table 1: Sample of user customizable fields for problem tracking, resolution, and reporting.
Field Name Description
Project Software/Hardware Tests
Summary A short description of the request.
Priority The importance of the request’s resolution, usually in regards to your business needs and goals. Sometimes, priority is calculated by impact and urgency.
Security Level
Determined by High, Medium, or Low security.
Unit Tested Determined by the product being tested (software, hardware, etc)
XYZ Company
DCW0000001 Rev: C
Description A detailed description of the request.
Estimated Completion Date
Component/s
Segments of your equipment or tests that relate to the request. These are used for labelling, categorization, and reporting.
Reporter
Assignee
Attachment
Final Approval
Field for inputting names of key personnel(s) for final approval
Closed Officially closing the issue
4.4 SOURCE FILE CONTROL
4.4.1 SOURCE CODE
Perforce facilitates source file version control during the development process. Once the code baseline has been established and is frozen – released for production in Agile, ECO is required in order to make any modifications.
4.4.2 MEDIA
Providing source and executable files to the customer are performed through XYZ Company’s secure FTP site.
4.5 CHANGE CONTROL
4.5.1 ENGINEERING
All software related configuration items are controlled through Agile. Once each applicable artifact is approved and released through Agile, an ECO is required in order to initiate any changes. Approvals are required by engineering and project/program manager. Any modification to released source code requires customer approval. Artifacts are stored in a secured directory on the internal server. Password authorization to these files are controlled by the configuration manager.
ECO is defined and tracked within Agile. Once approved by the CM, (Doc Control Review) a notification is present to the next stage of approval. In the scenario below, this is the Product Manager.
XYZ Company
DCW0000001 Rev: C
The subsequent display presents the ECO to the Program Manager for approval.
This same approval page is available to each subsequent signer in the Work Flow associated with the approval process for this ECO.
XYZ Company
DCW0000001 Rev: C
The Workflow screen provides a visual of the process of approval from the Originator to Implementation. The screen includes current status of approval.
Any comments made by the approver are indicated in the Signoff Comments dialog box. The Notice will not go out to subsequent signers until the approval has been completed by the Program Manager.
History is available on the same screen.
XYZ Company
DCW0000001 Rev: C
To approve the ECO, entry of the signer’s password is required. The signer can enter information pertaining to the ECO in the Comments section.
If the signer opts to reject the ECO, Reject is selected from the prior screen. The same information is presented enabling comments. Password entry is also required.
Depending upon the nature of the change, technical walkthroughs are conducted prior to submitting the ECO for sign-off.
XYZ Company
DCW0000001 Rev: C
4.5.2 CHANGE CONTROL BOARD (CCB)
Members of the Configuration Control Board are selected by the Program Manager. The CCB is made up by:
• Configuration Manager
• Program Manager
• Materials Manager
4.6 CONFIGURATION STATUS ACCOUNTING
Agile Product Lifecycle Manager provides the Configuration Status Accounting (CSA) facilitating timely information base concerning the product and its associated product configuration information throughout the product life cycle. Agile captures and maintains product configuration information to ensure that current and historical configurations of the product and product configuration information can be accurately determined throughout the product life cycle. Source and executable are maintained within Agile for all releases. Agile is updated through ECO which delineates the updates to firmware/ software that are included in each release. Perforce provides baseline and incremental detail status accounting for all firmware/software developed.
4.7 ARCHIVE, RETRIEVAL, AND RELEASE
During the development process, Perforce is used to manage code versions. Programmers perform bench testing and debug initial constructs prior to the establishment of the initial code baseline. After Acceptance testing has been completed, a test version of the code is provided to the customer through the XYZ Company FTP site. The software is frozen at this point in time. After customer approval the software artifacts are released in Agile. Any changes to the product forward are controlled by the ECO. The description within the ECO describes the nature of the change and the reason for the change.
Prior versions of code and other configuration items are maintained from the top level to the individual component level. If a prior rev level of the product is selected within Agile, all corresponding parts for that rev are displayed under the BoM. If a prior rev of a
XYZ Company
DCW0000001 Rev: C
subcomponent is selected, Agile will provide part numbers and their corresponding rev level at that time.
Release of each software version will include a Software Version Description document that will provide an overview of the changes included in the release and act as a cover document to the ECO’s included in the release. The combination of the cover document and the ECO support documentation will detail the software release id, changes incorporated, outstanding changes, any 3rd party software supplied, and any other pertinent information regarding the release. The base firmware facilitates program update of shipped units with new firmware releases. During project mode, if there are restrictions with respect to backward compatibility, these will be included in the ECO document and in the Software Version Description. Newly shipped units will have the most current released firmware included at the time the hardware is shipped.
4.8 SOFTWARE LOAD CONTROL
Software is developed and controlled within Perforce. Once released in Agile, the code is frozen. A copy of the code is placed in a password protected Manufacturing directory for loading to the end product prior to Factory Acceptance Testing.
Manufacturing is included in the sign-off for any changes to the software.
Any work orders for new building to new product includes identification of the most current software release. The software release ID is included on the Test Data Sheet and Traveler to insure the correct version of code is used in the production build.
XYZ Company
DCW0000001 Rev: C
5. SCM DATA
All SCM data is stored and managed electronically within Agile.
DATA CATEGORY CM TOOL FORMS
Assignment logs for all configured items Excel –Project Workbook
Engineering Change Request
Project Workbook during development
Agile – PLM