IEEE WG 12 Software Meeting 05

April 5 & 6, 2000

Meeting Minutes - Approved

The fifth meeting of the working group was held on March 5 and 6, 2000 at the New Jersey Transit Offices in Newark, NJ.

Participants

A listing of participants is attached. Sixteen members attended the meeting. Document: sw names 05.

Agenda

The agenda was accepted as distributed. Document: sw agenda 05

Meeting Minutes 04 Approval

The meeting 04 minutes from January 12 and 13, 2000 were distributed and no corrections were made. The minutes were approved by voice vote.

PAR Status / Scope and Purpose Review

Paul Jamieson recommended that the voting would remain at the full committee level, in order to give our standard a better balance of voters (more members across the industry). Tom McGean stated that we might want to be our own balloting group; if so, we would need to decide within 5-6 months.

The next meeting is scheduled for May 31st and June 1st, 2000 at WABCO Transit Division located in Spartanburg, SC.

Paul Jamieson stated that we should plan to submit our standard at the full committee meeting in January 2001. We should prepare a draft of the standard and provide it to the full committee, prior to the January 2001 meeting. The target date for standard completion is mid 2001. The draft standard can be posted on the TSD website earlier for use by industry.

Assignment Reports

Each team member that had a Task Assignment from the January 2000 meeting, reported on his or her assignment. Paul J. distributed the Process & Documentation Table compiled at the January 2000 meeting.

1. PMP and SDP Implementation – Dave Falkenberg

Dave was not present at the meeting; therefore there was no presentation of related material

2. Management & Planning – Byron Frank.

Byron distributed a 3 page Management & Planning document, with attached SCMP and SQAP sample templates.

It was noted that there is overlap between the SQAP and the PMP/SDP documentation.

3. Integrated SQAP – Martin Cloutier

Martin distributed a 14-page presentation on the Integrated SQAP and a 3-page presentation on the SRVTM.

During the presentation, the team agreed that there was a need for a document that would provide the “roadmap” to all documentation required by our standard. The team did not come to agreement on whether the “roadmap” document would be our standard, or a top-level document required by our standard. It was suggested that the SDP is the top-level document. Team must resolve in the near future.

The team discussed the benefits and downfalls of having an Integrated SQAP. It was stated that there is a lot of value in having separate Quality Assurance documents due to the nature and intent of the individual documents. Martin clarified that the initial intent was to create an SDP standard in accordance with J-STD-016. He suggested that the team review this standard, and will provide team members with a copy of this standard.

The team raised the following issues with the ISQAP:

Who within the vendor organization will have ownership of the integrated document, since we are now combining responsibilities from different departments? The ISQAP may be easier to implement in a small organization, than a larger organization.

How will the ISQAP document address-varying levels of criticality in subsystems?

The team raised a fundamental question with respect to our standard. “Is our driving factor, compliance to a standard, or ensuring the appropriate information is documented?” The answer to this question, may help us find an answer to whether the ISQAP should be specified.

4. Design SFD, SRS, SDD - Leroy Denney and Bill MacArthur

Leroy and Bill distributed a 3-page white-paper entitled “General Requirements for Rail Vehicle SRS and SDD Documents” and a copy of the ”IEEE Recommended Practice for Software Requirements Specifications”.

SFD – The purpose of the SFD is to partition the system into hardware, software, etc. The team once again revisited whether the SFD was within the scope of our standard. The team agreed that the SFD is a critical engineering component however is out of the scope of our standard. The technical portion of our standard begins with the SRS. Input to the SRS is a defined set of software requirements resulting from the system partitioning that occurred via the SFD.

The team agreed that the introduction to our standard should describe the Engineering Processes that should have been performed prior to the start of our Software Life Cycle.

Refer to the Diagram entitled “Documentation Flow” that appears at the end of the minutes. This information was drawn on the flipchart within the meeting room.

SRS – The team discussed whether an Interface Requirements Document (IRD) should be required by our standard. It was decided that our standard should allow the flexibility to reference Interface Requirements Documents for interface requirements, but should not be mandated.

The team came to consensus that defining processes (such as requirement management) is not within the scope of our standard.

The SRS should include validation of user input. The SRS should include error conditions and/or abnormal conditions, for example, when the field is not acting properly or an unexpected condition occurs. This could be documented in the Assumptions section of the SRS.

The team did not have a clear definition of Software Reliability. We will need to do more homework with respect to Reliability.

SDD – No information was presented on the SDD. It was noted that CASE Tools would effect the content of the SDD.

5. Testing – Martin Cloutier and Shantilal Morar

Martin and Shantilal presented a 2-page white paper on testing

Tom McGean stated that the team should be aware of IEEE 1483 – Software Verification for Vital Functions, just approved by the IEEE board, such that effort is not duplicated.

It was stated that the standard should be written such that we are not advocating testing as the mechanism to build a quality product. A quality product should be a result of a quality process.

The team discussed the concern of where to draw the line between defining standard documentation and defining a process. We agreed that it is not within our scope to define a process, however in the future, our working group may want to recommend that a process that complements our documentation set be created.

It was stated that we need to ensure we are focusing on the content of the documentation and not just the document itself.

The software integration tests may not be able to ignore hardware interface tests. It is expected the hardware/software integration requirements be specified in the SRS. For example, the SRS should reflect a requirement that the software operates on a target platform.

A software test plan is required.

6. User Documentation - George Hacken

George stated that Standard 1063 is applicable to our standard.

It was stated that the User Documentation to be supplied is frequently dependent upon the contract requirements. If the owner is taking responsibility for maintenance of the product, then a Software Maintenance Manual will be required. If a maintenance contract is established, then the Software Maintenance Manual will not be required.

When software is burned onto a PROM, is it now hardware or software and does it require a Users’ Manual? Needs further review by the team.

7. Traceability Matrix – Martin Cloutier

Martin distributed a 3-page white paper, attached to the ISQAP presentation.

It was stated that the entry criteria to the SRS (our starting point) should include an SRVTM that maps back to the Technical Specification.

Need to evaluate whether there are standards for creation of an RTM. George believes that 2167 has an example of an RTM.

8. Commercial Off the Shelf – Lori Karr

Lori distributed a 5-page white paper entitled Commercial Off-the-Shelf (COTS) Products

It was noted that the portion of the paper that describes the SVVP, must be updated to include a section that describes how the COTS product would be verified and validated, throughout the lifecycle.

COTS should be defined as a black box item, meaning it is a non-developmental item as defined by Standard 2167.

It was noted that the portion of the paper that describes the Software Maintenance Manual should describe how the COTS product would be maintained within the scope of the system.

9. Standard Framework – Paul Jamieson

No presentation was made at this time.

Addition Meeting Notes

What Acquirer wants (acquirer as part of the design team?):

· See that the plans:

- Are reasonable

- Are being followed

- Contain reasonable schedules

· Totality of software delivery:

- All documents

- Confidence

- Quality product

- Does it meet the requirements

· Maintainability by supplier or user

· Have adequate documentation to :

- Ensure the provider understands the requirements

- Verify the system design

- Use the system

- Maintain/modify the system

The audience for our standard is the:

· Users (acquirer)

· Suppliers (prime/subs)

Informative Annex (for Software) – the working group may want to consider the use of an Informative Annex for the following:

· Definition of the types of documents to be delivered

· When are documents to be delivered? For example, After Award, ADR, PDR, CDR, FAI

The Software Development Plan should describe what’s to be delivered, including:

· What’s certain

· Resources required

· Tools

· Gantt Chart

· Interface Control Document resolution

The team discussed whether one standard would be capable of meeting varying types of projects. The team discussed the use of instituting tailoring guidelines, which would allow the end user to tailor the standard according to the type of project that the standard would be applied on.

It was stated that documentation should be produced such that it can be audited. This requirement should be stated in the Introduction of our standard.

Next Steps:

The following are required in preparation for the May 2000 meeting:

· Develop the straw-man document via the Software Development Plan.

· Create an outline of the Standard, with the Table of Contents

· Produce a list of documents included in the standard and why

· Review of the IEEE 1483

· Review of applicability of J-STD-016

Action Item List

Action Item	Name	Due Date
Review the J-STD-016 for May 2000 meeting	All
George (STD-498) and Martin (J-STD-016) will send the Standards files to Paul for distribution with the minutes.	George Hacken, Martin Cloutier	ASAP
Review of Standard IEEE 1483 from www.tsd.org	All	May 2000 meeting
Brief working group members on Standard IEEE 1483	George Hacken	May 2000 meeting
Compile a list of all standards and provide team member access to them	Paul Jamieson	May 2000 meeting
Create Outline/Introduction	Lori Karr, Paul Jamieson	May 2000 meeting
Bill and Martin to produce the list of documents and their mapping to the standards and reason for the standard. This will be incorporated into the outline. This will be based on J-STD-016 & others. For May 2000 meeting.	Bill MacArthur, Martin Cloutier	May 2000 meeting
Martin, Shantilal & Dave: Develop the straw-man document via the Software Development Plan for May 2000 meeting.	Martin Cloutier, Shantilal Morar, Dave Falkenberg	May 2000 meeting
Create an action item database in Excel	Byron Frank	ASAP
Evaluate whether there are standards for creation of an RTM.	Martin Cloutier
Research the various types of User Documentation that will be required by our standard		Future
Address impact of CASE Tools on our standard and associated documentation	Shantilal Morar	Future
Determine whether an Informative Annex (for Software) is required		Future
Come to agreement on what the top-level document should be. Is it our standard, or a top-level document such as the SDP?		Future
Provide a definition for Software Reliability.		Future
Need to define the software product. For example, When software is burned onto a PROM, is it now hardware or software and does it require a Users’ Manual?		Future