IEEE WG 12 Software Meeting 09

August 9, 2001

Meeting Minutes - Approved

The ninth meeting of the working group was held on February 27 and 28, 2001 at the Safetran offices in Rancho Cucamonga, CA.

Participants

A listing of participants is attached. Ten members attended the meeting.

Agenda

The agenda was accepted as distributed. See attachment.

Minutes

The committee approved the minutes from meeting 08. The final meeting minutes will be posted on the website.

Assignment Reports

1. Draft Standard Concept Acceptance Paul Jamieson

A presentation was made to the RTVIS full committee on February 12, 2001. The full presentation can be found on the website. The committee accepted the working group direction.

2. J-STD-016 Usage Tom McGean

Paul Jamieson reported for Tom McGean that J-STD-016 could be either referenced or used in part in P1588. IEEE owns the standard copyright. The document will be available through Global Engineering. Tom McGean’s response was emailed on 02/20/01.

3. Adobe Acrobat Text Extraction John Corvin

John Corvin provided the extraction technique that can be used. Some issues exist when the document is only graphics there is no text to extract. The information was emailed on 01/23/01.

4. IEEE 12207 Coordination Tom McGean

Paul Jamieson reported for Tom McGean that coordination with IEEE/EIA 12207 is not required due to the operation change implemented by the Standards Governing Board. Tom McGean’s response was emailed on 12/08/00.

5. Reference Standards Paul Jamieson

The standard reference listing was updated and includes information on standard availability, current activities and usage within P1588. The listing was emailed on 02/06/01.

Paul Jamieson to revise the listing to show ATA 102 Computer Software Manual has been withdrawn and correct spelling errors.

John Corvin to provide a set of reference standards including J-Std-016 to the primary team members.

6. RTM Document Sample Tibor Simon

Tibor Simon forwarded a RTM sample document for the working group review. The document was emailed on 02/08/01. Direction for the RTM is described in section 7.

7. Standard Usage

Reports from the working group members are as follows:

SPMP/SDP/SCMP Shanti Morar

SPMP (Software Project Management Plan) will replace the SDP in the standard. IEEE 1058 will be utilized as a basis for the document. Review the PMBOK (Product Management Body of Knowlegde) for incorporation Shanti Morar to map the SDP requirements into SPMP.

SPMP needs to address the safety concerns throughout the process including coding standards.

SCMP still needs to be mapped for usage in the standard.

Shanti Morar to prepare an outline (straw man) for an SPMP to replace the SDP.

Paul Jamieson to update Process Flow Diagram to include SPMP, safety activities and maintenance document changes.

SQAP John Corvin

The document has not been revised from the last meeting. The author received no comments. Based on the SPMP effort, the SQAP will need to be reviewed and modified as required.

SPS, SVD, CPM, FSM/LCP, SUM, SIP Tom Tougas

SVD and SPS are combined and may be called SVD. The name will be reviewed against IEEE 12207.

SUM will include the information contained in the FSM. FSM includes the LCP in section 3.x.5. Therefore, a separate LCP is not required.

The SIP has been deleted as the topics deal with the system installation.

CPM will not be required as custom designed processors and compilers are not being utilized within the industry.

Tom Tougas shall create a graphic showing the relationship of the maintenance document.

STD, STR, STP Denise Edgecomb-Cope

STD and STR information was distributed. STR provides a summary of all test activities. These documents apply to the any testing level. The J-STD-016 STD combined several activities that were individually defined in IEEE 829. The STD designation will be changed to STPr (Software Test Procedures). Denise Edgecomb-Cope will map IEEE 829 requirements against the SVVP and SVVR. A recommendation for final document configuration will be made.

STP (Software Test Plan) was not available for this meeting.

SRS, IRS, SDD, IDD, DBDD Bill MacArthur

Comments to these documents are contained in the attached information prepared by Bill MacArthur and Linda Martinez.

SVVP, SVVR Byron Frank

SVVP and SVVR mapping appears in the attached document.

SVVP as defined in IEEE 1012 includes many references to the safety requirements that may not be applicable to IEEE P1588. IEEE 1012 includes the validation of tools utilized.

STR and SVVR need to be reviewed during final document preparation to assure that duplication does not occur.

SPMP will contain instructions when the SVVR will be updated such as at the completion of each phase.

RTM Lori Karr

The RTM sample was review by the group

RTM needs to address these topics:

Mapping back to the source

Define what is a requirement

What documents do you need to map forward such as SDD, SPS, STD, STR, etc. including the specific reference.

Codes for allocation

Source code traceability

Lori Karr to update the RTM for review based on the comments and present at the next meeting.

8. Document Format Paul Jamieson

Requirements for a document outline were distributed by email on 02/19/01.

9. Feasibility Implementation Tibor Simon

No report was made. The NYCT R160 project may be applicable due to timing of the standard completion and project award.

10. Safety Critical System Requirements Denise Edgecomb-Cope

Denise Edgecomb-Cope reported that there are no additional requirements for safety-critical systems. Denise’s response was emailed on 02/19/01.

IEEE 1483 starts with a safety assurance plan and addresses the verification and validation efforts.

Draft Standard Review Lori Karr

Introduction needs to address the gray blocks of the process flow diagram and training is essential for proper use, requirements are the most difficult to identify and clearly define

Paul Jamieson to revise the draft standard.

Action Item Review Paul Jamieson

Action items were assigned. (wg12ail10.doc)

Next Meeting

The next working group meeting will be on May 8 & 9, 2001 at LTK Offices – Ambler, PA.

Adjournment

The meeting was adjourned on February 28 at 3:00 PM

Attachments

The following information distributed at the meeting appears on the following pages:

Agenda – separate file

Roster – separate file

RTVIS P1588 Presentation – separate file

APTA Rail Transit Standards Presentation – separate file

Reference Standard matrix – separate file

Software Development Plan (SDP) Outline

Software Quality Assurance Plan (SQAP) Outline

Requirements Documents (SRS, IRS, SDD, IDD, DBDD) Outline

Test Documents (STP, STPr STR) Outline

Verification & Validation (SVVP, SVVR) Outline

User Manual (SVD,SUM) Outline

Document Format Outline

Action Item Listing – separate file

Software Quality Assurance Plan (SQAP) Outline

SQAP

Standards Investigation

Consider:

IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans
IEEE/EIA 12207.0-1996 IEEE/EIA Standard Industry Implementation of International Standard ISO/IEC 12207:1995 (ISO/IEC 12207) Standard for Information Technology—Software life cycle processes
IEEE/EIA 12207.1-1997 IEEE/EIA Guide Industry Implementation of International Standard ISO/IEC 12207 : 1995 (ISO/IEC 12207) Standard for Information Technology—Software life cycle processes—Life cycle data
J-STD-016-1995, 30 September 1995, Trial-Use Standard, Standard for Information Technology Software Life Cycle Processes Software Development Acquirer-Supplier Agreement

Since the J-STD-016-1995 was chosen as the “standard of choice” for the Software Development Plan, it seems a likely place to start. Per the standard,

“This EIA/IEEE Interim (Trial-Use) Standard is based upon the major technical content of ISO/IEC 12207 Information Technology Software Life Cycle Process, 22 February 1995, for the software development process.”

The intent of IEEE/EIA 12207.0 is to “… provide clarifications, additions, and changes accepted by the Institute of Electrical and Electronics Engineers (IEEE) and the Electronic Industries Association (EIA) …” to ISO/IEC 12207. Thus, we have a tight coupling here too.

Finally, Annex A of IEEE Std 730-1998 explores the correlation between the IEEE Std 730-1998 and IEEE/EIA 12207.0-1996. In general, it finds that IEEE Std 730 is more prescriptive with respect to process and format, but lists several areas where additional information is required.

Therefore, it seems appropriate to use a modification of IEEE Std 730 for our standards effort.

One warning, however. Per J-STD-016-1995, the “EIA/IEEE Interim (Trial-Use) Standards contain information deemed to be of technical value to the industry, and are published at the request of the originating Committee without necessarily following the rigorous public review and resolution of comments which is a procedural part of the development of an EIA/IEEE Standard.” The lack of the rigorous review probably means that our use of the J-STD-16 will be controversial in some circles.

Section	SQAP Content List	Applicable to Railway Software Standards	Amendments For Railway Software Standards
Cover	Date of issue and document status	Mandatory	12207
Inside Cover	SQAP Change History	Mandatory	12207
1.0	Purpose	Mandatory
1.1	SQAP Purpose	Mandatory
1.2	Scope	Mandatory
1.4	SQA Objectives	Mandatory	Documents motivating the SQAP shall be referenced - 12207
1.5	Software Items Covered	Mandatory
1.6	SQA Life Cycle	Recommended
1.7	SQAP Standards	Mandatory
1.8	SQAP Maintenance	Mandatory	12207
2.0	References	Mandatory
2.1	Document References	Mandatory
2.2	Acronyms	Mandatory	12207
2.3	Definitions	Mandatory	12207
3.0	Management	Mandatory
3.1	Organization	Mandatory	Identify issuing organization
3.1.1	Quality Element Description	Mandatory
3.1.2.1	SQA Project Estimates	Mandatory	(cost, effort, size, etc.) 12207
3.1.2.2	SQA Independence	Mandatory	12207
3.1.n	Organizational Element n	Recommended	List all elements that interact with or approve the SQAP
3.2	Tasks	Mandatory
3.2.1	SQA Task 1	Mandatory
3.2.1.1	Life Cycle Portion	Mandatory	12207
3.2.1.2	Task Milestones and Schedule	Mandatory	12207
3.2.2	SQA Task n	Mandatory
3.2.2.1	Life Cycle Portion	Mandatory	12207
3.2.2.2	Task Milestones and Schedule	Mandatory	12207
3.3	Responsibilities	Mandatory
3.3.1	Software Quality Assurance Engineer	Mandatory
3.3.2	Project Software Engineer	Mandatory
3.3.3	Project System Engineer	Recommended
3.3.4	Customer	Recommended
3.3.5	Organizational Element n	Recommended
4.0	Documentation	Mandatory
4.1	Purpose	Mandatory
4.1.1	Governing Documentation	Recommended
4.1.2	Document Validation	Mandatory
4.2	Minimum Documentation Requirements	Omit, Move to SDP
4.2.1	Software Requirements Specification (SRS)	Omit, Move to SDP
4.2.2	Software Design Description (SDD)	Omit, Move to SDP
4.2.3	Software Verification and Validation Plan (SVVP)	Omit, Move to SDP
4.2.4	Software Verification and Validation Report (SVVR)	Omit, Move to SDP
4.2.5	User Documentation	Omit, Move to SDP
4.2.6	Software Configuration Management Plan (SCMP)	Omit, Move to SDP
4.3	Other Documentation	Omit, Move to SDP
4.3.1	Software Development Plan (SDP)	Omit, Move to SDP
4.3.2	Software and Procedures Manual	Omit, Move to SDP
4.3.3	Software Project Management Plan (SPMP)	Omit, Move to SDP
4.3.4	Software Maintenance Manual (SMM)	Omit, Move to SDP
5.0	Standards, Practices, Conventions And Metrics	Mandatory	Omit S, P, & C (included in SDP)
5.1	Purpose	Mandatory
5.1.1	Application of S, P, C, & M	Mandatory
5.1.2	Compliance Verification of S, P, C, & M	Mandatory
5.2	Content	Mandatory
5.2.1	Documentation Standards	Omit, Move to SDP
5.2.2	Logic Structure Standards	Omit, Move to SDP
5.2.3	Coding Standards And Conventions	Omit, Move to SDP
5.2.4	Commentary Standards	Omit, Move to SDP
5.2.5	Testing Standards And Practices	Recommended
5.2.6	Software Quality Assurance Product Metrics	Mandatory
5.2.7	Software Quality Assurance Process Metrics	Mandatory
6.0	Reviews And Audits	Mandatory
6.1	Purpose	Mandatory
6.1.1	Technical Reviews and Audits	Recommended
6.1.2	Managerial Reviews and Audits	Recommended
6.1.3	Additional Reviews and Audits	Recommended
6.2.1	Software Requirements Review (SRR)	Limit discussion to SQA Involvement, move rest to SDP
6.2.2	Preliminary Design Review (PDR)	Limit discussion to SQA Involvement, move rest to SDP
6.2.3	Critical Design Review (CDR)	Limit discussion to SQA Involvement, move rest to SDP
6.2.4	Software Verification And Validation Plan (SVVP) Review (SVVPR)	Limit discussion to SQA Involvement, move rest to SDP
6.2.5	Functional Audit (FA)	Limit discussion to SQA Involvement, move rest to SDP
6.2.6	Physical Audit (PA)	Mandatory
6.2.7	In-Process Audits	Limit discussion to SQA Involvement, move rest to SDP
6.2.7.1	Code Verification Audit	Limit discussion to SQA Involvement, move rest to SDP
6.2.7.2	Interface Specification Audit	Limit discussion to SQA Involvement, move rest to SDP
6.2.7.3	Design Verification Audit	Limit discussion to SQA Involvement, move rest to SDP
6.2.7.4	Test Procedure Functional Audit	Limit discussion to SQA Involvement, move rest to SDP
6.2.8	Managerial Reviews	Limit discussion to SQA Involvement, move rest to SDP
6.2.9	Software Configuration Management Review (SCMPR)	Limit discussion to SQA Involvement, move rest to SDP
6.2.10	Post Mortem Review	Limit discussion to SQA Involvement, move rest to SDP
6.3	Other Reviews and Audits	Limit discussion to SQA Involvement, move rest to SDP
6.3.n	Other Review/Audit n	Limit discussion to SQA Involvement, move rest to SDP	SDP, SQAP, SCMP, SVVR, STP, SUM, SMM
6.4	Review and Audit Schedules	Mandatory	Added for 12207
7.0	Test	Omit, Include in SVVP
7.1.1	Test Omitted in SVVP n	Omit, Include in SVVP
8.0	Problem Reporting And Corrective Action	Limit discussion to SQA Involvement, move rest to SDP
8.1	Software Problem Reporting	Limit discussion to SQA Involvement, move rest to SDP
8.2	Software Problem Tracking	Limit discussion to SQA Involvement, move rest to SDP
8.3	Software Problem Resolution	Limit discussion to SQA Involvement, move rest to SDP
8.4	Software Problem Corrective Action	Limit discussion to SQA Involvement, move rest to SDP
9.0	SQA Tools, Techniques, And Methodologies	Mandatory
10.0	Code Control	Omit, Move to SCMP
11.0	Media Control	Omit, Move to SCMP
12.0	Supplier Control	Mandatory
12.1	Supplier SQA Provisions	Mandatory
12.2	Supplier Requirements Delivery Verification	Recommended
12.3	Software Reuse SQA Validation	Recommended
12.4	Supplier SQA Verification	Mandatory
13.0	Records Collection, Maintenance And Retention	Mandatory
13.1	Collection	Mandatory
13.2	Maintenance	Mandatory
13.3	Retention	Mandatory
14.0	Training	Mandatory
14.1	SQAP Training Requirements	Mandatory
15.0	Risk Management	Mandatory

Software Development Plan (SDP) Outline

Software Development Plan

The following table describes the content of the Software Development Plan (SDP) that is adopted from J-STD-016 –1995 for the Railway Software Development Standards. The table identifies sections that are needed for the Railway Software Development Standards and is complemented by additional information for sub-clauses and by introducing new subsections that are required for the Railway Software Standards.

Each of section defined in the J-STD 16 SDP has been assigned an attribute that identifies the requirements of each section as follows:

Mandatory: This means that the section is mandatory in the SDP document.

Highly Recommended: This means that the section is highly recommended and the rational for not including the section should be described Software Quality Plan or Project Management Plan.

Recommended: This means that the section is recommended.

Current J-STD 16	J-STD 16 SDP Content List	Applicable to Railway Software Development Standards	Amendments to J-STD 16 For Railway Software Development Standards
1.0	Scope	Mandatory
1.1	Identification	Mandatory
1.2	System Overview	Mandatory	Add following Subsections 1.2.1 Context Diagram 1.2.2 Functional Elements
1.3	Document Overview	Mandatory
1.4	Relationship to Other Plans	Mandatory
2.0	Reference Documents	Mandatory	Add following Subsections 2.1 Abbreviations 2.2 Definitions
3.0	Overview of Required Work	Mandatory	Add following Subsection 3.1 Software Artefacts 3.2 Deliverable Software Artefacts
4.0	Plans for Performing General Software Development Activities	Mandatory	Addition to sub-clause.
4.1	Software Development Process	Mandatory	Addition to sub-clause
4.2	General Plans for Software Development	Mandatory
4.2.1	Software Development Methods	Mandatory	Add following Subsections 4.2.1.1 New Software 4.2.1.2 Reusable Software 4.2.1.3 Prototype Software
4.2.2	Standards and Practice for Software Products	Mandatory
4.2.3	Traceability	Mandatory	Update to the sub-clause. Add following Subsections 4.2.3.1 New Software 4.2.3.2 Reusable Software
4.2.4	Reusable Software Product	Mandatory
4.2.5	Handling of Critical Requirements	Mandatory
4.2.6	Computer Hardware Resource Utilisation	Recommended
4.2.7	Recording Rationale	Highly Recommended
4.2.8	Access for Acquire Review	Highly Recommended
5.0	Plans for Performing Detailed Software Development Activities	Mandatory
5.1	Project Planning and Oversight	Mandatory
5.1.1	Software Development Planning	Mandatory
5.1.2	Software Item Test Planning	Mandatory	This is Software Qualification Testing
5.1.3	System Test Planning	Highly Recommended
5.1.4	Software Installation Planning	Highly Recommended
5.1.5	Software Transition Planning	Highly Recommended
5.1.6	Following and Updating Plans	Mandatory	Update to the sub-clause.
5.2	Establishing a Software Development Environment	Mandatory
5.2.1	Software Engineering Environment	Mandatory
5.2.2	Software Test Environment	Mandatory
5.2.3	Software Development Library	Recommended
5.2.4	Software Development Files	Recommended
5.2.5	Non-Deliverable Software	Recommended	Update to the sub-clause
5.3	System Requirements Definition	Highly Recommended
5.3.1	Analysis of User Inputs	Highly Recommended
5.3.2	Operational Concept	Highly Recommended
5.3.3	System Requirements	Highly Recommended
5.4	System Design	Highly Recommended
5.4.1	System-Wide Design Decisions	Highly Recommended
5.4.2	System Architectural Design	Highly Recommended
5.5	Software Requirements Definition	Mandatory	Add the following Subsections 5.5.1 New Software 5.5.2 Reusable Software
5.6	Software Design	Mandatory	Add the following Subsections 5.6.1 New Software 5.6.2 Reusable Software
5.6.1	Software Item-Wide Design Decisions	Recommended
5.6.2	Software Item Architectural Design	Mandatory
5.6.3	Software Item Detailed Design	Mandatory
5.7	Software Implementation and Unit Testing	Mandatory
5.7.1	Software Implementation	Mandatory
5.7.2	Preparing for Unit Testing	Mandatory
5.7.3	Performing Unit Testing	Mandatory
5.7.4	Revision and Re-testing	Mandatory
5.7.5	Analysing and Recording Unit test Results	Mandatory
5.8	Unit Integration and Testing	Mandatory
5.8.1	Preparing for Unit Integration and Testing	Mandatory
5.8.2	Performing Unit Integration and Testing	Mandatory
5.8.3	Revision and Re-testing	Mandatory
5.8.4	Analysing and Recording Unit Integration and Test Results	Mandatory
5.9	Software Item Qualification Testing	Highly Recommended
5.9.1	Independence in Software Item Qualification Testing	Recommended
5.9.2	Testing on Target Computer System	Highly Recommended
5.9.3	Preparing for Software Item Qualification Testing	Highly Recommended
5.9.4	Dry Run Software Item Qualification Testing	Highly Recommended
5.9.5	Performing Software Item Qualification Testing	Highly Recommended
5.9.6	Revision and Re-testing	Highly Recommended
5.9.7	Analysing and Recording Software Item Qualification Test Results	Highly Recommended
5.10	Software/Hardware Item Integration and Testing	Mandatory
5.10.1	Preparing for Software/Hardware Item Integration and Testing	Mandatory
5.10.2	Performing Software/Hardware Item Integration and Testing	Mandatory
5.10.3	Revision and Re-testing	Mandatory
5.10.4	Analysing and Recording Software/Hardware Item Integration and Test Results	Mandatory
5.11	System Qualification Testing	Mandatory
5.11.1	Independence in System Qualification Testing	Mandatory
5.11.2	Testing on the Target Computer System	Mandatory
5.11.3	Preparing for System Qualification Testing	Mandatory
5.11.4	Dry Run of System Qualification Testing	Mandatory
5.11.5	Performing System Qualification testing	Mandatory
5.11.6	Revision and Re-testing	Mandatory
5.11.7	Analysing and Recording System Qualification Test Results	Mandatory
5.12	Preparing for Software Use	Mandatory
5.12.1	Preparing the Executable Software	Mandatory
5.12.2	Preparing Version Descriptions for User Site	Mandatory
5.12.3	Preparing User Manuals	Mandatory
5.12.4	Installation at User Site	Mandatory
5.13	Preparing for Software Transition	Mandatory
5.13.1	Preparing the Executable Software	Mandatory
5.13.2	Preparing Source Files	Mandatory
5.13.3	Preparing Version Descriptions for the Maintenance Site	Highly Recommended
5.13.4	Preparing the “as built” Software Item Design and Other Software Maintenance Information	Mandatory
5.13.5	Updating the System Design Description	Highly Recommended
5.13.6	Updating the Software Requirements Specification	Mandatory
5.13.7	Updating the System/Subsystem Specification	Mandatory
5.13.8	Updating the Maintenance Manuals	Mandatory
5.13.9	Transition to Designated Maintenance Site	Highly Recommended
5.14	Software Configuration Management	Mandatory	Add the following subsection 5.14.6 Baseline Definitions
5.14.1	Configuration Identification	Mandatory
5.14.2	Configuration Control	Mandatory
5.14.3	Configuration Status Accounting	Highly Recommended
5.14.4	Configuration Audits	Highly Recommended
5.14.5	Packaging, Storage, Handling and Delivery	Highly Recommended
5.15	Software Product Evaluation	Highly Recommended
5.15.1	In-process and Final Software Product Evaluation	Highly Recommended
5.15.2	Software Evaluation Records	Highly Recommended
5.15.3	Independence in Software Product Evaluation	Highly Recommended
5.16	Software Quality Assurance	Mandatory
5.16.1	Software Quality Assurance Evaluation	Mandatory
5.16.2	Software Quality Assurance Records	Mandatory
5.16.3	Independence in Software Quality Assurance	Mandatory
5.17	Corrective Action	Mandatory
5.17.1	Problem/Change Reports	Mandatory
5.17.2	Corrective Action System	Mandatory
5.18	Joint Technical and Management Reviews	Recommended
5.18.1	Joint Technical Reviews	Recommended
5.18.2	Joint Management Reviews	Recommended
5.19	Risk Management	Mandatory
5.20	Software Management Indicators	Recommended	Updated of the sub-clause.
5.21	Administrative Security and Privacy Protection	Recommended
5.22	Managing Subcontractors	Mandatory
5.23	Interfacing with Software IV&V Agents	Highly Recommended
5.24	Co-ordinating with associated Developers	Highly Recommended
5.25	Project Process Improvement	Recommended
6.0	Schedule and Activity Network	Mandatory
7.0	Project Organisation and Resource	Mandatory
7.1	Project Organisation	Mandatory
7.2	Project Resource	Mandatory	Add the following subsection 7.2.1 Project Resource Training
8.0	Notes	Recommended	Note: Abbreviation and Definitions have been brought foreword into section 2.0 under subsection 2.1 and 2.2 respectively.
A	Annexes	Recommended

Sub-Clause Description

1.2.1 Context Diagram: This sub-clause shall depict the overall system and shall identify system and elements that are covered by this plan. A system context diagrams which shows the interface between the system to be provided and the rest of the world with which it interacts.

1.2.2 Functional Elements: This sub-clause shall describe each of the functional elements that will be developed using this plan.

2.0 Reference Documents: This sub-clause shall identify by reference number, title, revision and date of all documents that are applicable to the software development. This sub-clause shall also identify: The priority of documents if applicable, the methods to be applied to resolving conflicts identified between documents and the methods to be applied to issuing, updating and verifying the accuracy of the documents used by project staff.

2.1 Abbreviations: This sub-clause shall provide description of all the abbreviations that are used within the Software Development Plan.

2.2 Definitions: This sub-clause shall provide description of all the definitions that are used within the Software Development Plan.

3.1 Software Artefacts: This sub-clause shall state all the software artefacts that will be produced using this Software Development Plan. It shall summarise when each of the software artefacts will be produced, it will identify the verification method to be deployed.

3.2 Deliverable Software Artefacts: This sub-clause shall identify software work products to be delivered to the customer and any specific or special requirements for these documents (Format, Content, Schedule, Acquirer Approval, etc.)

4.0 Plans for Performing General Software Development Activities: This sub-clause shall identify all the software development actives and shall identify any special resource and expertise required during each phase of the software life cycle.

4.1 Software Development Process: This sub-clause shall also describe all the inputs that are required for each of the development life cycle and outputs that will be produced for each development phase. If iterative development life cycle is to be adpoted, than it will describe in which build the particular output is considered complete.

4.2.1.1 New Software: This sub-clause shall describe the software development method that is to be deployed for software that is to be developed from start.

4.2.1.2 Reusable Software: This sub-clause shall describe the software development method that is to be deployed for software that is to be modified from an existing baseline that has been previously qualified for similar application.

4.2.1.3 Prototype Software: This sub-clause shall describe the software development method that is to be deployed for software that is to be modified from an existing baseline that has been previously qualified for similar application.

4.2.3 Traceability: This sub-clause shall provide description of how the traceability for each software life cycle will be conducted. It shall describe all the inputs required to perform the traceability for each phase of the software life cycle. It will identify any untraceable item and will provide rational why this will not have any bearing upon the safety and integrity of the system.

4.2.3.1 New Software: This sub-clause shall describe the software traceability technique and approach for upward and downward traceability for a system that has all new software development.

4.2.3.2 Reusable Software: This sub-clause shall describe the software traceability approach for upward and downward traceability for a system where the reusable software is deployed. For legacy software, the untraceable items will be backed up by rational why the delivered system is considered complete.

5.1.6 Following and Updating Plans: This sub-clause shall describe the replanning actives that will be performed for the duration of the project. At minimum, the following replanning activities shall be covered: Change to the Scope of Work; Addressing of Corrective Actions.

5.2.5 Non-Deliverable Software: This sub-clause shall describe all the non-deliverable software that will be used in the development of deliverable software. It shall describe provisions that will be made to ensure that the same software can be obtained for future development and/or maintenance.

5.20 Software Management Indicators: This sub-clause shall describe the set of management indicators that might be used for the duration of the project. It will identify when the metric collection activity will start and when it will stop. It will describe what indicators will be used to trigger management action plan to mitigate potential risks projected by the metrics. As a guidance, the following management indicators may be used:

a) Requirements Volatility,

b) Software Size,

c) Problem/change report status,

d) Milestone performance.

7.2.1 Project Resource Training: This sub-clause shall describe the orientation training of new software personnel on the project. It will describe minimum sets of training courses that should be taken in order for the new personnel to be effective on the project.

Requirements Documents (SRS, SDD, IRS, SDD, IDD, DBDD) Outline

Bill MacArthur

1-26-1 10:00 am

2-13-1 1:10 pm

Version 1 (Draft)

General requirements for all software documents to be supplied

1 Configuration control. Each document shall be under configuration control. When and change is made the version identifier will be changed.

2 Title page. Each document shall have a title page. The format and content shall be consistent for all software documents provided from a supplier.

3 The title page shall preferably be consistent across suppliers on a given project.

4 The title page shall provide at lease the following information: Document Name, Document Identifier, Supplier name, project name, Version Identifier, Total number of pages in the document.

5 There shall be a change history table that shall list the changes by version. Each change shall give the section changed down to the paragraph and it shall give the reason for the change and the source of the change such as a design review.

6 All terms and abbreviations shall be consistent with other documentation for the project including the technical specifications and system design documentation.

SDP

1 The SDP must address schedule as well as tasks. The schedule should show the interrelationships between the tasks and the start and finish dates. This schedule should cover only the software related tasks and should be used as input to higher level scheduling.

SRS

1 Document must conform to IEEE 830 1998. Particular attention must be given to IEEE Standard 830-1998, section 4.3, Characteristics of a good SRS, which contains several critical characteristics.

2 Individual requirements must be labeled with a "project unique identifier". This is then used for tracing requirements. These specific requirements shall be at a sufficient level of detail so that when they are traced to other documents they shall trace to one specific section. That reference shall be sufficiently precise that it will not contain extraneous information.

3 Timings must be included for processing of inputs to outputs. Need to specify the timing of the functions and related operations such as the reading and filtering of inputs and the generation of outputs. Requirement may be for the software to read inputs, filter, process, and generate the outputs within a certain time. This may also involve requirements for scale or units conversion on input and output.

4 Initialization requirements and power loss requirements

5 For all combinations of inputs, including timing of inputs, the behavior requirements must be described. This must cover normal and unusual conditions.

6 Relationship to the Processing Hardware: Identify the processor and memory that will execute the SCI. Should specify the allowable range of processors and speeds. Requirements for detecting and processing processor exceptions should be included.

7 Relationship to the I/O Hardware: Units and scale conversions required, valid ranges, values indicating failed sensors, and indicators of valid data.

8 Parameters and the allowable ranges of parameters shall be specified in the requirements. Also the method of changing each parameter shall be specified. Rationale: Sometimes a value is given for a parameter, then later either due to changes based on measured performance or due to changes in requirements the parameter must be changed. If a range is stated for the parameter then the design must be verified as compliant with the allowed range and similarly the tests must show the range is valid, that is the functions perform correctly throughout the range specified.

SDD

1 Should be structured such that the requirements can be traced, that is there should be a convenient means to reference the specific lines that apply to a given requirement.

IRS

1 Use J-STD-016 as a reference

2 Document should be optional; the requirements can be in SRS documents.

3 Individual requirements must be labeled with a "project unique identifier" as for the SRS.

4 Requirements are required for time delay and error detection.

IDD

1 Also optional, design can be in the SDDs. There should not be an IDD if there was no IRS.

2 Use J-STD-016 as a guide.

DBDD

1 Standards

2 Standards for the storage and access, such as SQL and ODBC (Open Data Base Connectivity)

3 Access time requirements

4 Access control requirements for users

5 Capacity requirements for amount of data and throughput of data

SRTM

1 Include reference to Source Code

2 Reference to test plan and test procedure

3 There should be a table for each SCI

4 The document must be specific regarding the other documents references - document name and version.

Each matrix or table shall have:

1 A heading specifying the Software Configuration Item name and version

2 A row for each requirement in the SRS software requirement in the Software Requirements Specification.

3 The columns shall provide the following information. When all of the references in a column refer to a particular version of a document, then the specific document shall be identified in the column header.

The requirement identifier from the SRS.

A reference to the relevant section of the SRS

The reference to the system design description

The reference to the relevant section of the SDD.

The reference to the Source Program ( to the Function or equivalent level)

A reference to the software test plan or procedure

A reference to a system test plan.

4 Every requirement shall be traceable to one or more test procedures.

SCMP

Related issue

There must be a plan for controlling the documentation in relation to the software changes and what is actually treated as software items on the target systems. That is if a change is needed to the software some of the documentation should change and go through a revision cycle, then the software itself will be changed and a new version will have to be tested and then released to the target product units. If a document is related to more than one software load module, then when the document is changed and a new version assigned, one of the related load modules will change and have a new version number and the other(s) will not change or have a new version number. In this case something would have to keep track of this relationship.

In the example of an SRS for a system of software items and say, two SDDs and 4 load modules, if a problem is found and it is determined that the requirements are correct but there is an error in the design in one of the SDDs then the one SDD must be changed. It must then be determined if the change in the design will affect both load modules or just one. This may be determined from the implementation stage when the source code is changed and reviewed against the SDD.

CASE tools

Tools to help perform tasks for Software Engineering, in particular design and design documentation or alternately, requirements analysis and documentation. Some also assist with test plans, test case, or conducting tests. The SDP should describe the relationship between these tools and the required documentation.

It may be that the tools would produce documentation that would be part of the documents, say as an appendix.

CASE Tools can be used as a means to meet the requirements not as an alternative to meeting them.

COTS Items

It is necessary to define the Requirements and to compare them to an official document from the supplier stating the functions of the COTS item.

This is to assure that the requirements are known and that the software supplier is committing to providing those functions. Therefore an SRS is needed and a software requirements traceability matrix that links the requirements to specific sections of product information.

Rationale:

1 On one project a networks interface program to do FTP file transfers was claimed to be software provided by the networking company. It turned out the program was an example provided in a training class from the company. It was not complete. It did not handle error conditions and failed during car tests.

2 On another project a real time operating system is to be used. The power fail design is to close all files in 100 msec so the power supply can provide power for 100 msec after a loss of input power is detected. The operating system must be able to close all files within the 100 msec based on a signal from the power loss detection function. The real time operating system provider may not have this requirement as part of what they are committing to for future releases. The operatig system could be upgraded at some time without anyone knowing that the requirements existed unless it is documented as a requirement.

In another example

Legacy or Preexisting software

The requirements from the customer are the same regardless of whether the software has been used on previous projects. It should, however, be easier for the supplier to write the requirements specifications nd the other documentation because the design is understood.

Does the software item really meet the requirements for the particular project? This can only be answered if the requirements are known and the design is known.

To know if software has been previously used for the "same application" the requirements for the other application and for the current application must be known.

Section	STD Content List	Applicable to Railway Software Development Standards
1.0	Scope
1.1	Identification	Mandatory
1.2	System Overview	Not Required
1.3	Document Overview	Mandatory
2.0	Referenced documents	Mandatory
3.0	Test preparations	Mandatory
3.x	Project-unique identifier of a test	Mandatory
3.x.1	Hardware preparation	Mandatory
3.x.2	Software preparation	Mandatory
3.x.3	Other pre-test preparations	Mandatory
4.0	Test descriptions	Mandatory
4.x	Project-unique identifier of a test	Mandatory
4.x.y	Project-unique identifier of a test case	Mandatory
4.x.y.1	Requirements addressed	Mandatory
4.x.y.2	Prerequisite conditions	Mandatory
4.x.y.3	Test input	Mandatory
4.x.y.4	Expected test results	Mandatory
4.x.y.5	Criteria for evaluating results	Mandatory
4.x.y.6	Test procedure	Mandatory
4.x.y.7	Assumptions and constraints	Mandatory
5.0	Requirements traceability	Mandatory
6.0	Notes	Mandatory
A.0	Annexes	Mandatory

Section	STR Content List	Applicable to Railway Software Development Standards
1.0	Test report identifier	Mandatory
2.0	Summary	Mandatory
3.0	Variances	Mandatory
4.0	Comprehensive assessment	Mandatory
5.0	Summary of results	Mandatory
6.0	Evaluation	Mandatory
7.0	Summary of activities	Mandatory
8.0	Approvals	Mandatory

Verification & Validation (SVVP, SVVR) Outline

User Manual Outline

Document	Computer Programming Manual (CPM)
Reference	J-STD-016, Annex I.2.3
Purpose	Provide target computer instruction set
Guidance	Only develop this when a COTS data book does not exist. Otherwise, reference the data book in the Software Product Specification (SPS) and do not generate this document.

Section	Content	Guidance

Document	Software Users Manual (SUM)
Reference	J-STD-016, Annex J.2.1
Purpose	Describe how the User installs and runs the software
Guidance	This document may not apply to embedded systems if there is no specific user interaction that applies only to the software and not to the system. Otherwise, the users manuals and operating procedures for the system may make this document unnecessary.

Section	Content	Guidance
3.2	SW Inventory	Identify the files to install the software
3.3	SW Environment	Identify the HW, SW, manual installation resources. For an embedded system, reference the FSM for installation and checkout of the software.
3.4	SW Organization and Operation	Include how to initialize the software upon startup
3.7	Assistance and Problem Reporting	Who to contact if a problem is encountered and how to generate a problem report.
5.5	Data backup	Procedures for creating and backing up data
5.7	Messages	List or reference any error messages the user will encounter while performing the user’s functions.

Document	Software Version Description (SVD)
Reference	J-STD-016, Annex I.2.2
Purpose	Identifies the version of the released software
Guidance

Section	Content	Guidance
3.1	Identify the physical media the SW is released on
3.2	Inventory of SW contents	Identify the revisions of the software files using the version control repository identifier.
3.3	Changes installed	Identify the changes since the last release
3.4	Adaptation data	If site-adaptation is required, reference the SIP.
3.6	Installation instructions	For embedded software, reference the FSM
3.7	Known errors	List any known anomalies with the released software

Document	Firmware Support Manual
Reference	J-STD-016, Annex I.2.4
Purpose	Documents how the software is loaded on the target hardware
Guidance	This manual applies to software that is loaded into a target (non-native) computer’s memory. This memory may include PROM, EPROM, EEPROM, Flash RAM, etc. This manual addresses the requirements of the target memory, how the software is loaded in the memory, and how the software load is verified.

Section	Content	Guidance
3.x.1	Description of pre-programmed device	Describe the physical characteristics of the target memory device.
3.x.2	Software to be programmed in the device	Identify the software to loaded in the target memory device
3.x.3	Programming equipment	Document the equipment used to program the target memory device. If the device is programmed differently in the field than the factory, identify both sets of equipment.
3.x.4	Programming software	Document the software used to program the target memory device. If the device is programmed differently in the field than the factory, identify both sets of software.
3.x.5	Programming Procedures	Document the procedures used to program and reprogram the target memory device. Include the procedures to install the software, checkout the software, and protect the software against load failures.
3.x.6	Installation and Repair procedures

Document	Software Installation Plan
Reference	J-STD-016, Annex E.2.3
Purpose	Document the plans for installing software at specific sites
Guidance	This document only applies to software that is installed in the field. If software is not installed or reprogrammed in the field, this document does not apply.

Section	Content	Guidance
3.1	Description	List all the sites that will require the software to be installed at it.
3.5	Tasks	Describe the tasks involved in installing the software.
5	Site specific information for software users
5.x.2	Installation procedures	Either reference the FSM for software installed in a target memory device OR reference the SUM for software-only systems.

Document	Software Product Specification
Reference	J-STD-016, Annex I.2.1
Purpose	Document the delivered software product
Guidance	Use this document for all software delivered, either as a complete system or as part of another system

Section	Content	Guidance
3.1	Executable software	Identify the media the executable software is delivered on. If the software is not delivered as part of the contract, this section may not apply?
3.2	Source files	Reference the SVD for a list of all the source files needed to generate toe executable software
4	Qualification provisions	Identify the method to be used to ensure the executable software delivered is a valid copy. This may be done by verifying a Checksum or CRC, etc.
5.2	Compilation/Build Procedures	Identify all the tools, by version number, used to develop the software. Describe the compilation/build processes required to produce the executable software from the source file.
5.3	Modification procedures	Describe how modification to the software will be done. This may/should be done in a software maintenance plan.
5.4	Computer hardware resource utilization	Document the “as built” software resource utilization. Suggest a reference to the SDP so this document does not have to be maintained with each software release.
6	Requirements traceability	Reference the RTM for traceability to/from software source files to software units.

Revision level	Date	Description of changes

Participants

A listing of participants is attached. Ten members attended the meeting.

Agenda

Minutes

Assignment Reports

A presentation was made to the RTVIS full committee on February 12, 2001. The full presentation can be found on the website. The committee accepted the working group direction.

Draft Standard Review Lori Karr

Next Meeting

Adjournment

Attachments

Standards Investigation

Software Development Plan

Software Test Description

J-Std-016-1995

Software Test Report

Document

Document

Guidance

Document

Document

Document

Document

Section Name

Subsection Name

Subsection Name

Subsection Name

Subsection Name

Subsection Name

Subsection Name

Section Name

Subsection Name

Subsection Name

Subsection Name

Section Name

Subsection Name

Subsection Name

1 Section Name

Subsection Name

Subsection Name

Subsection Name

Subsection Name

Subsection Name

Subsection Name

Section Name