IEEE WG 12 Software Meeting 10

August 10, 2001

Meeting Minutes - Approved

The tenth meeting of the working group was held on May 16 and 17, 2001 at the LTK offices in Ambler, PA.

Participants

A listing of participants is attached (WG12 Roster.xls). Eight members attended the meeting.

Agenda

The agenda was discussed and agreement reached. (wg12agn10.doc)

Minutes

No action was taken to approve the meeting minutes from meeting 09 as the minutes were not distributed in time for a through review.

Assignment Reports

1. Software Requirements Traceability Matrix Lori Karr

A document (attached) was distributed and reviewed by the group. The following comments and direction were established.

Every requirement in the SRS shall appear in the SRTM.

Each requirement shall have a unique identifier.

The project management plan shall how requirements are managed and controlled including the identifier structure.

The matrix shall include the technical requirements

SRTM column changes are as follows:

Column 1 &2 are combined Source Document Reference. Specific reference within the source document shall be provided.

Column 3 heading shall be changed to Source Requirement Description. This description

Column 4 change heading shall be “SRS/IRS Identifier”.

Column 5 change heading shall be “SDD/IDD/DB/DD Identifier”.

Column 6 change heading shall be “Code Identifier”.

Column 4, 5 and 6 shall be a unique identifier.

A sample SRTM was presented by Bombardier and provided as a separate document.

Show different views of the SRTM and make a recommendation of the position to be used in the within the standard. Participants are L. Karr, F. Ouellette and P. Jamieson. Tentative date: June 26th

Updated SRTM to be prepared for next meeting. - L. Karr

2. Software Configuration Management Plan John Corvin

A document (attached) was distributed and reviewed by the group. The following comments and direction were established.

IEEE 12207.1 specifies section 5.7 SCM Cost shall be included. Consideration needs to be given to replacing cost with resource allocation.

Review 12207 and update the SCMP requirements for the next meeting. - J. Corvin

3. Software Project Management Plan Shanti Morar

A document (attached) was distributed and reviewed by the group. The following comments and direction were established.

Content diagram and functional elements shall appear in section 1.1.1 purpose, scope and objectives.

Project Deliverables (section 1.1.3) shall include all work products. Work products that are deliverable to the acquirer shall be clearly identified. The title shall be changed to “Project Work Products”.

Reference documents shall be identified but the revision level is not required. A change control process shall be addressed in the SCMP.

Review 12207 and update the SPMP requirements for the next meeting. – S. Morar

4. General Comments

Each section straw man including revision level to be posted on the website for review and comment. - P. Jamieson

The question arose of having our standard specify that the planning documents should be separate (vs integrated in one document or combined in some way). The documents under consideration are

the SQAP, SCMP, SPMP, and SVVP. Some reasons for keeping them separate were discussed. These are as follows:

a) Audiences - the audiences of each plan may be slightly different.

b) Opportunities for reuse. In practice, once one of these documents is created, it is likely that, from project to project, the basic information will remain the same, with only project specific information changing.

c) Consistency - one of the aims of creating this standard is to encourage consistency in documentation from different suppliers, and consistency in the expectations of the customer.

d) Two principles from software design - when designing a code module, the preference is for high cohesion and well defined coupling. For documents, cohesion carries the idea that the document should focus on one specific area (e.g. SQA or SCM), and be internally cohesive and consistent. Coupling between documents should be limited to pointers from one document to the other, and not necessarily repeating the same information in two documents.

Action Item Review Paul Jamieson

Action items were assigned and reviewed. (wg12ail10.doc)

Next Meeting

The next working group meeting will be on August 14 & 15, 2001 at location to be determined (East Coast).

Adjournment

The meeting was adjourned on May 17 at 2:30 PM

Attachments

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

Software Requirements Traceability Matrix (SRTM) Outline

Software Configuration Management Plan (SCMP) Outline

Software Project Management Plan (SPDP) Outline

DEFINITION OF EACH COLUMN:

Software Requirement Number:

Each software requirement shall be uniquely numbered. The numbering system shall consist of a prefix that that denotes the source document from which this requirement was derived (e.g. SOW, ORD, RFP), followed by a ‘-‘ and a suffix which denotes the section within the source document from which this requirement was derived (e.g. 1.01, 4.2). If there are multiple requirements identified within a section, then each requirement number shall be uniquely identified with an additional suffix of ‘-‘ followed by a sequential number starting at 1. The sequential number will restart at 1, within each section. The following are examples:

SOW-1.01-1

SOW-1.01-2

SOW-1.01-3

SOW-1.02-1

SOW-1.02-2

SSS Section or Contract Document section

This column shall contain a backward reference to appropriate system level documentation and the section from which this requirement was derived. It is assumed that the supplier has created an SSS and that the software requirements have been allocated via the RTM.

In the instance that the supplier has not created an SSS or equivalent system level documentation, then this column shall map back to the Contract Document (SOW, ORD, RFP) from which this requirement was derived.

The reference to the SSS section number shall correspond to the lowest level of detail defined within the source document Table of Contents. (can this or should this be defined further???)

Software Requirement Text:

This column shall contain the software requirement text, which has been extracted from the source document. During the Software Requirements Analysis activity the software analyst shall enter each software requirement into the RTM. Each software requirement shall possess the qualities identified in the “Definition of a Requirement” section within this document. When deciding whether to break a statement into individual requirements, the analyst should consider how the requirement would be tested. If the requirement will be tested by a single test procedure, then the requirement probably does not need to be broken down further. If the requirement will be tested by multiple test procedures, then the requirement should be broken down into multiple requirements. It is important to follow a consistent and documented methodology for breaking down requirements.

SRS/IRS Ref.

This column shall contain a forward reference to the document name (SRS/IRS) and section within the document in which this software requirement is addressed.

All software requirements must be mapped to one or more section(s). The reference to the SRS/IRS section number shall correspond to the lowest level of detail defined within the SRS/IRS Table of Contents. (can this or should this be defined further??? Also, will the SRS contain references to the requirement number within the SRS text?)

SDD/IDD/DBDD Ref.

The software supplier may elect to create an IDD and/or DBDD in addition to the SDD. According to IEEE Std 1016, “In a complete SDD, each requirement must be traceable to one or more design entities... Entities can exist as a system, subsystems, data stores, modules, programs and processes.” This column shall contain a forward reference to the document name (SDD/IDD/DBDD) and one or more design entity(ies). The reference should denote the section number of the design entity in which the software requirement is addressed.

The Visio Diagram shows that we are to provide mapping to the Software Architectural Design and the Software Detailed Design. I am assuming that the mapping will not change between these 2 design documents, if we continue to map to the design entity level. The information described for each design entity will change among the two documents, but the mapping will not.

Code Ref.

This column shall contain a forward reference to the module name or object name that implements this software requirement. (Verify with the team whether we want to map to code).

Software Test Procedure

(Need to verify with the team to what level we want to what level we want to map the tests. Unit, Integration, Validation, Qualification).

This column will provide a forward reference to the Software Validation Test Procedure identification number in which this software requirement will be tested.

Other Ref/Comments

This column will provide references to other documents or free-form comments as necessary.

REPORTS

This section will address reports that are required to be generated as output from the SRTM.

Software Configuration Management Plan

Standards Investigation

Consider:

IEEE Std 828-1998, IEEE Standard for Software Configuration Management Plans
IEEE Std 1042-1987, (Reaff 1993) IEEE Guide to Software Configuration Management
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

IEEE 828 specifies the following:

SCM planning information may be presented in any format, sequence, or location that is meaningful to the intended users of the Plan with the following restrictions:

a) A document with the title “Software Configuration Management Plan” shall exist either in stand-alone form or embedded in another project document. Suggest Rail Transit require a separate SCMP.

b) This document shall contain all SCM planning information either by inclusion or by reference to other locations, such as other documents or automated systems.

c) A format for this document shall be defined.

The writer of the Plan shall use the sequence of sections specified in 828 Table 1 unless a different format has been defined in the Introduction of the Plan. Suggest we require sections as defined in Table 1.

As such, the following sections are proposed:

Section	SCMP Content List	Applicable to Railway Software Standards	Amendments For Railway Software Standards
Cover	Date of issue and document status	Mandatory	12207.1-1997
Inside Cover	SCMP Change History	Mandatory	12207.1-1997
1.0	INTRODUCTION	Mandatory
1.1	Purpose	Mandatory
1.2	Scope	Mandatory
1.2.1	Software items covered	Mandatory
1.2.1.1	Lowest Entity Covered	Recommended
1.2.1.2	Other Entities Covered (e.g. Test or Support S/W)	Recommended
1.2.2	SCM Relationships to Other CM	Mandatory
1.2.3	Life Cycle	Mandatory
1.2.4	Specific Limitations and Constraints	Recommended
1.3	Assumptions	Mandatory
1.3.1	Internal	Recommended
1.3.2	Tools	Recommended
1.3.3	Customer Participation	Recommended
1.4	Acronyms and definitions	Mandatory
1.4.1	Acronyms	Mandatory
1.4.2	Definitions	Mandatory
1.5	References	Mandatory
2.0	SCM MANAGEMENT	Mandatory
2.1	Organization	Mandatory
2.2	SCM Responsibilities	Mandatory
2.2.1	SCM Roles	Mandatory
2.2.1.1	Group 1 (e.g., SCCB)	Mandatory
2.2.1.1.1	Purpose and objectives	Mandatory
2.2.1.1.2	Membership and affiliations	Mandatory
2.2.1.1.3	Period of effectivity	Mandatory
2.2.1.1.4	Scope of authority	Mandatory
2.2.1.1.5	Operational procedures.	Mandatory
2.2.1.2	Group 2 (e.g., Quality Assurance)	Recommended
2.2.1.2.x	As above
2.2.1.3	Role n (e.g. Customer)	Recommended
2.3	Applicable External Plan Policies, Directives, and Procedures	Mandatory
2.4	SCM Risk and Abatement	Mandatory
2.4.1	Risk Identification	Mandatory	12207.1-1997
2.4.2	Risk Management	Mandatory	12207.1-1997
3.0	SCM ACTIVITIES	Mandatory
3.1	Configuration Identification	Mandatory
3.1.1	Configuration Item Identification	Mandatory
3.1.1.1	Configuration Items	Mandatory
3.1.1.2	Baseline Definition	Mandatory
3.1.2	Configuration Item Naming	Mandatory
3.1.2.1	Documentation	Mandatory
3.1.2.2	Source Code	Mandatory
3.1.2.3	Executable Code	Mandatory
3.1.2.4	Media (e.g. EPROM, Flash, Diskette, PCMCIA,…	Mandatory
3.1.2.5	Subcontracted or Commercial Software Identification	Mandatory
3.1.2.6	Other Configuration Item Identification	Recommended
3.1.3	Configuration Item Acquisition	Mandatory
3.1.3.1	Documentation Acquisition	Mandatory
3.1.3.2	Source Code Acquisition	Mandatory
3.1.3.3	Library and Component Code Acquisition	Mandatory
3.1.3.4	Physical Storage	Mandatory
3.1.3.5	Configuration Item Retention and Recovery	Mandatory
3.1.3.6	Configuration Item Distribution	Mandatory
3.2	Configuration Control	Mandatory
3.2.1	Requesting Changes	Mandatory
3.2.2	Evaluating Changes	Mandatory
3.2.2.1	Change Requests (CR)	Mandatory
3.2.2.2	Requirements Changes	Recommended
3.2.2.3	Change n	Recommended
3.2.3	Approving Changes	Mandatory
3.2.3.1	Change Approval	Mandatory
3.2.3.1.1	Software Configuration Control Board	Mandatory
3.2.3.1.2	Product Configuration Control Board	Recommended
3.2.3.1.3	Document Configuration Control Board	Mandatory
3.2.3.1.4	Other Configuration Control Board	Recommended
3.2.4	Implementing Changes	Mandatory
3.2.4.1	Change Process	Mandatory
3.2.4.2	Release Process	Recommended
3.3	Configuration Status Accounting	Mandatory
3.3.1	SCI Status Accounting	Mandatory
3.3.2	SCI Baseline Accounting	Mandatory
3.4	Configuration Audits and Reviews	Mandatory
3.4.1	Formal SCM Audits	Mandatory
3.4.2	In-process SCM Audits	Mandatory
3.5	Interface Control	Mandatory
3.5.1	Dependencies	Mandatory
3.5.1.1	System	Recommended
3.5.1.2	Hardware	Recommended
3.5.1.3	Support Software	Recommended
3.5.1.4	Other	Recommended
3.5.2	Interface Configuration Control	Mandatory
3.6	Subcontractor and Vendor Control	Mandatory
3.6.1	Third-Party Software	Mandatory
3.6.2	Subcontracted Software Design	Mandatory
3.6.3	Engineering Subcontractors	Recommended
4.0	SCM SCHEDULES	Mandatory
4.1	SCM Sequence and Dependencies	Mandatory
4.2	SCM Milestones and Schedule	Mandatory
5.0	SCM RESOURCES	Mandatory
5.1	Tools	Mandatory
5.1.1	Configuration Management of Tools	Mandatory
5.2	Techniques	Mandatory
5.3	Methodologies	Mandatory
5.4	Personnel	Mandatory
5.5	Training	Mandatory
5.6	Environment and Infrastructure	Mandatory	12207.1-1997
5.7	SCM Cost Management	Recommended	12207.1-1997
6.0	SCMP MAINTENANCE	Mandatory
6.1	SCMP Monitoring	Mandatory
6.2	SCMP Revision and Approval	Mandatory
6.3	SCMP Change Distribution and Training	Mandatory

Mandatory

Recommended

Omit, Move to xxx

Limit discussion to SCM Involvement, move rest to SDP

Software Project Management Plan

The following table describes the content of the Software Project Management Plan (SPMP) that is adopted from the IEEE Std 1058-1998 for the Railway Software Development Standards. The table identifies new subsections needed for the Railway Software Development Standards and complemented by additional information for sub-clauses.

[Need to review and include some of the sub-clauses/information from IEEE 12207.2]

	IEEE 1058 SPMP Content List	Applicable to Railway Software Development Standards	Amendments to IEEE 1058 Standards for Railway Software Development Standards	Comments/Sub-clause update
1	Overview	Mandatory	Addition to sub-clause.	Overview: The overview of the scope shall describe the general nature of the system and software; summarize the history of system development, operation and maintenance.
1.1	Project summary
1.1.1	Purpose, scope, and objectives	Mandatory	Add following Subsections 1.1.1.1 Context Diagram 1.1.1.2 Functional Elements	Context Diagram: This sub-clause shall depict the overall system and shall identify system and elements covered by this plan. A system context diagrams shows the interface between the system provided and the rest of the world with which it interacts. Functional Elements: This sub-clause shall describe each of the functional elements developed using this plan.
1.1.2	Assumptions and constraints	Mandatory
1.1.3	Project ~~deliverables~~ Work Product	Mandatory	Add following Subsection 1.1.3.1 Work products 1.1.3.2 Deliverable Work products 1.1.3.3 Non Deliverable Work products	Work products: This sub-clause shall state all the work products produced using this Plan. It shall summarise when each of the work products is produced. Deliverable Work Product: This sub-clause shall identify software products delivered to the customer and any specific or special requirements for these documents (Format, Content, Schedule, Acquirer Approval, etc.) Non Deliverable Work products: This sub-clause shall identify all the non-deliverable work product used in the development of deliverable work product. For example, development and test tools used for developing and testing deliverable software.
1.1.4	Schedule and budget summary	Highly Recommended		These plans may be incorporated directly or by reference to other plans. Reference to Level 2 Project Schedule, where high level schedule activity is defined.
1.2	Evolution of the SPMP	Recommended		These plans may be incorporated directly or by reference to other plans. Reference to Level 3 Project Schedule, where documents update schedule is detailed.
2	References	Mandatory		The IEEE1058 Section 4.2 is replaced by the following: ‘This clause of the SPMP shall provide a complete list of all documents and other sources of information referenced in the SPMP. Each document should be identified by title, report number, date, author, path/name for electronic access, and publishing organization. Other sources of information, such as electronic files, shall be identified using unique identifiers such as date and version number.’
3	Definitions	Mandatory
4	Project organization
4.1	External interfaces	Recommended		These plans may be incorporated directly or by reference to other plans. Reference to Project management Plan
4.2	Internal structure	Highly Recommended
4.3	Roles and responsibilities	Highly Recommended
5	Managerial process plans	Mandatory		These plans may be incorporated directly or by reference to other plans. Reference to Project Management Plan
5.1	Project start-up plan
5.1.1	Estimation plan	Recommended		These plans may be incorporated directly or by reference to other plans. Reference to Project Management Plan and/or Company ISO Process/Work Instructions.
5.1.2	Staffing plan	Recommended		These plans may be incorporated directly or by reference to other plans. Reference to Project M anagement Plan.
5.1.3	Resource acquisition plan	Not required
5.1.4	Project staff training plan	Not required
5.2	Work plan			These plans may be incorporated directly or by reference to other plans.
5.2.1	Work activities	Recommended Appears that this is repeated below in Section 6.1 Process Model!		These plans may be incorporated directly or by reference to other plans. Reference to Level 3 Schedule.
5.2.2	Schedule allocation	Recommended		These plans may be incorporated directly or by reference to other plans. Reference to Level 3 Schedule.
5.2.3	Resource allocation	Recommended		These plans may be incorporated directly or by reference to other plans. Reference to Level 3 Schedule.
5.2.4	Budget allocation	Recommended		These plans may be incorporated directly or by reference to other plans. Reference to Level 3 Schedule.
5.3	Control plan	Recommended		These plans may be incorporated directly or by reference to other plans. Reference to Project management Plan and/or Company ISO Process/Work Instructions
5.3.1	Requirements control plan	Mandatory
5.3.2	Schedule control plan	Recommended – I would propose that this is included as part of section 5.2.2 Schedule Allocation		These plans may be incorporated directly or by reference to other plans.
5.3.3	Budget control plan	Recommended– I would propose that this is included as part of section 5.2.4 Budget Allocation		These plans may be incorporated directly or by reference to other plans.
5.3.4	Quality control plan	Mandatory		These plans may be incorporated directly or by reference to other plans. Reference Project Management Plan and/or Project Quality Plan.
5.3.5	Reporting plan	Highly Recommended		These plans may be incorporated directly or by reference to other plans.
5.3.6	Metrics collection plan	Highly Recommended		Metrics Collection Plan: This sub-clause shall describe the set of management indicators required for the duration of the project. It will identify when the metric collection activity will start and when it will stop. It will describe the indicators that 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 e) Test Procedures Ran vs Tests Failed.
5.4	Risk management plan	Mandatory		These plans may be incorporated directly or by reference to other plans. Reference in Project Management Plan.
5.5	Project closeout plan	Not Required. The information stated in 1058 is partly covered by CM.		These plans may be incorporated directly or by reference to other plans. Reference Project Management Plan and/or Company ISO Process.
6	Technical process plans
6.1	Process model	Mandatory	Add following Subsection 6.1.1Software Development Process	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 adopted, than it will describe in which build the particular output is considered complete.
6.2	Methods, tools, and techniques	Mandatory	Add following Subsections 6.2.1. Software Requirements Definition 6.2.2 Software Architecture Design 6.2.3 Software Detailed Design 6.2.4 Software Implementation 6.2.5 Traceability 6.2.6 Software Test Methods	These subsections shall address all aspect of software development for a) New Software b) Reuse Software c) Prototype Software d) Test Tool Software The Software Test Method shall address different phases testing, namely Unit Testing, Integration Testing and Target Hardware Integration Testing. Reusable Software: This sub-clause shall describe of how the traceability for each software life cycle is 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. For legacy software, the untraceable items shall be backed up by rational why the delivered system is considered complete and safe.
6.3	Infrastructure plan	Highly Recommended – only for the software development environment.		These plans may be incorporated directly or by reference to other plans. Reference Project Management Plan
6.4	Product acceptance plan	Mandatory		These plans may be incorporated directly or by reference to other plans.
7	Supporting process plans
7.1	Configuration management plan	Mandatory		These plans may be incorporated directly or by reference to other plans. Reference Configuration Management Plan.
7.2	Verification and validation plan	Mandatory It is unlikely at project start how the Validation will be done, therefore this section cannot be finalized until the end of requirements phase.		These plans may be incorporated directly or by reference to other plans. Reference Verification & Validation Plan.
7.3	Documentation plan	Not required – Repeated! See section 1.1.3 Project Work Product		These plans may be incorporated directly or by reference to other plans.
7.4	Quality assurance plan	Mandatory		These plans may be incorporated directly or by reference to other plans. Reference Project Quality Plan.
7.5	Reviews and audits plan	Not Required I propose this section be included in above section - Quality Assurance Plan		These plans may be incorporated directly or by reference to other plans. Reference Project Quality Plan.
7.6	Problem resolution and corrective action plan	Mandatory		This sub-clause shall describe the Problem Resolution and Corrective Action process for analyzing and resolving the problems (including non-conformances), whatever their nature or source, that are discovered during the execution of development, operation, maintenance, or other processes. The objective is to provide a timely, responsible, and documented means to ensure that all discovered problems are analyzed and resolved and trends are recognized for the development process corrective action.
7.7	Subcontractor management plans	Mandatory		These plans may be incorporated directly or by reference to other plans. Reference to Project Management Plan or Subcontract Management Plan.
7.8	Process improvement plan	Not required – included in 7.6 above.
8	Annexes~~Additional plans~~	Recommended