IEEE WG 12 Software Meeting
08
December 5 & 6, 2000
Draft Meeting Minutes
The
eighth meeting of the working group was held on December 5th and 6th,
2000 at the Safetran offices in Rancho Cucamonga, CA.
The
agenda was accepted as distributed.
Document: sw agenda 08.
The
committee approved the minutes from meetings six and seven. Both sets of minutes will be posted on the
website.
The
next working group meeting will be on February 27th and 28th.
D.
Edgecomb-Cope will confirm availability of the Safetran facility.
T.
McGean stated that there are seven published standards and the committee is
working with APTA and transit research board to get these standards published
to transit community. The eighth standard “Environmental Conditions for Transit
Rail Car Electronic Equipment, should be approved in the near term by
IEEE. NJT is using the communications
protocol standard (standard 1473) and the data elements standard (standard
1544) for their car procurement. The committee is very eager to observe the
standards in action on this procurement and is looking for other transit
agencies to do the same.
B.
MacArthur questioned how our initiatives relate to ITS initiatives. T. McGean stated that the ITS initiatives
basically cover surface transportation.
There are clear crossovers with rail, for example, in the highway
crossings area. L. Denney suggested that the committee view ITS as an
inter-modal control system that handles all facets of transportation within a
corridor.
P.
Jamieson stated that the next full committee meeting is in Miami on February 12th
and 13th. P. Jamieson stated that the goal of meeting 8 is to discuss
modification to the draft standard such that it can be presented to the full
committee in February. The completed
draft standard must be submitted to the full committee for their review by Mid
January 2001 in preparation for the February 2001 meeting. A revision to the
draft standard would be required for the 2nd full committee meeting
of 2001. The completed standard would be required by the end of this year.
J-STD-016
will no longer be supported, therefore P1588 should not reference this
standard. The IEEE direction is to use 12207. The working group discussed
absorbing the text from J-STD-016 into standard P1588 as needed. T. McGean
stated that we need to verify whether we can extract verbiage from the
J-Std-016. To do so, we would need to contact the IEEE/EIA working group since
the standard is copyrighted. T. McGean
suggested that it may be easier to attach J-STD-016 in an annex to our
standard. T. McGean will contact the EIA to
determine what we are allowed to do with respect to this standard.
The
working group has access to a number of standards in PDF format. J. Corvin will inform the team on how to
extract text from Adobe Acrobat for insertion into P1588.
The working group walked through the draft standard and
modified language such that it can be presented to the full committee in
February 2001. The draft standard was updated during the course of meeting 8
with track changes turned on. A copy of
the updated draft is attached. Please note that this version will be
further updated for the February 2001 working group meeting.
Additional Modifications to the Standard (not yet made
during meeting 8) are as follows:
·
T.
McGean stated that bullets are not allowed within the body of the standard.
·
Remove
all text that states “in conformance with P1588”
·
Remove
the sentences that state “… shall comply with standard…”. The standard
compliance will be provided in table format and attached to the draft standard
for the February 2001 full committee meeting.
·
W.
MacArthur stated that P1588 should include a section that addresses consistency
among software documents. The working group agreed.
·
Remove
the documents that correspond to the gray boxes on the diagram (i.e. OCD,
SSS). The standard will no longer refer
to these documents; it will only refer to the system level activities that are
identified on the diagram.
·
Ensure
that “shall” language is used within the body of the standard instead of
“will”.
J.
Corvin stated that we need to discuss how CASE tools will effect the format and
content of the required deliverables.
We need to strike a balance by allowing the supplier to use his/her CASE
tool, and still meet the intent of our standard. It was suggested that the
intent to use the CASE tool documentation be defined within the SDP/SPMP or be
addressed within the tailoring guidelines within P1588.
The
diagram that will be inserted into P1588 shall be entitled “Software
development activities and associated documentation”. It should not be referred
to as a lifecycle diagram.
Modifications to the Software development activities and Associated Documentation diagram are as follows:
·
Remove
the documents associated with the gray boxes on the diagram. The standard will no longer refer to these
documents
·
A note
must be added on the diagram stating that the terminology used is drawn from
12207.
· The diagram will be modified to change Software Item 2 to Software Item n.
L.
Karr will update standard based on the review conducted during the meeting.
P.
Jamieson to update diagram to use within the standard.
P.
Jamieson to draft a document template to be used for all documents.
T. Simon will discuss with J. McDermott the use of P1588 on an NYCT software project.
T. McGean will check with IEEE on how to add IEEE/EIA 12207 to our coordination effort and whether a PAR change is needed.
D. Edgecomb-Cope and S. Morar will review whether there are additional requirements and/or standards to be followed for Safety Critical Systems. For example, are there special V&V standards to be followed for safety critical systems? Refer to IEEE 1228 and 1483. This action item must be resolved before the February 2001 committee meeting.
B. MacArthur highly recommends that the working group
purchase and read a copy of the following: "Software Engineering
Standards, A User's Road Map" by James W. More. This book provides a good
introduction to the 4-volume set of IEEE standards. The book is available at “www.amazom.com”. It also describes how the various standards
relate to each other. It was suggested
to add this document to our list of references within our standard.
Day Two:
It was decided that if we are referencing sections within existing standards, then we should reference the date associated with the standard.
Document Reviews
S. Morar presented the template for development of the
SDP. S. Morar and his group need to evaluate
whether we can use IEEE 1058 SPMP as a basis for the description of the SDP.
J. Corvin presented the SQAP. It was decided that IEEE
730.1 (the guide) provides additional clarification to IEEE 730 (the standard)
and that our standard should not be solely dependent upon IEEE 730. J. Corvin
stated that there are a number of differences between IEEE 730 and IEEE 730.1. P. Jamieson will ask IEEE if an update to
730 is being worked on and if so, when it will be released, in hopes that the
guide will match the standard more closely. P. Jamieson also stated that he
will follow up on all standards that we are referencing from within our
standard to determine if there are outstanding PARs.
Other Actions
P. Jamieson will generate an agenda for the
February 2001 meeting, ASAP such that the transit authorities can get approval
60 days prior to this trip.
P. Jamieson to take the draft standard from
meeting 8 and update the reference standard listing to incorporate all
standards from the draft.
P. Jamieson to speak with T. Tougas on
whether he can lead the effort on the four maintenance documents.
P. Jamieson to remind L. Martinez of action
item 06.09.
T. Simon will provide a sample RTM from the
NYCT 63rd Street project for use in the RTM section of P1588.
W. MacArthur identified the following major issues that the working group must address in the near term:
· Legacy issues
· Software development tools
· COTS
· RTM
Presentations on SDP and SQAP are included.
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 |