Citation preview
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
Printed Document is Uncontrolled Page 15 of 31
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
Printed Document is Uncontrolled Page 18 of 31
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
Printed Document is Uncontrolled Page 21 of 31
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
Printed Document is Uncontrolled Page 26 of 31
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
Printed Document is Uncontrolled Page 27 of 31
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
Printed Document is Uncontrolled Page 28 of 31
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
Project Workbook during development
Project Workbook during development
Agile – PLM