IEEE WG 12 Software Meeting
06
May 31st &
June 1st, 2000
Approved Meeting Minutes
The
sixth meeting of the working group was held on May 31st & June
1st, 2000 at WABCO Transit Division offices in Spartanburg S.C.
The
agenda was accepted as distributed.
Document: sw agenda 06
The
meeting 05 minutes from April 5 & 6, 2000 were distributed and no corrections
were made. The minutes were approved by
voice vote.
Our
standard, P1588 will be presented to the full committee by end of this year. We
do not have enough representation to be a voting group. Our standard will be presented to a group of
app. 50 people for approval.
The
next working group meeting will be September 12th and 13th
in Spartanburg S.C.
Byron
F. presented the action item database and it will be posted on the web.
George H. reviewed
IEEE 1483 Verification of Vital Functions in Processor-Based Systems Used in
Rail Transit Control and stated that this standard is relevant to our
standard. He suggested that it should
be referenced from within our standard. Linda M. clarified that IEEE 1483 only
deals with verification, not validation and that the IEEE 1483 working group is now looking at validation. Linda M.
stated that IEEE 1483 is a System standard dealing with safety. It was stated that during the creation of IEEE
standard P1588, we need to address vital versus non-vital systems. Linda M will be responsible for assuring
there is consistency between IEEE 1483 and P1588.
Shanti
M. presented the straw man for the SDP.
It was discussed that we are not really changing existing standards, but
interpreting the industry standards.
Tom T. suggested that if we are modifying a standard, that we include
the rationale for deviating from or tailoring the standard.
Each
work product that we are requiring from within P1588 should describe exactly
what we want to see; and should describe the tailoring that we want to see
applied. The annex will show the method
of presentation of the information. Paul J. will discuss this topic with the
IEEE editors to determine if we can perform tailoring in the body of the
standard and presentation in the annex.
The
issues we are addressing include the rationale as to why we did what we did,
the presentation of the information and the tailoring.
Tom T.’s suggestion on how to approach the work:
1.
Define
the documents (work products) our standard is addressing
2.
Define
the standards to apply to each work product
3.
Provide
guidance for using the work product
4.
Describe
tailoring
5.
Presentation
of work product
Tom
T. suggests a change control board philosophy, where each working group member
brings forth changes to the standard for discussion at each subsequent meeting.
Martin
C. and Bill M. presented an approach to document mapping. It was stated that
P1588 will not be dependent upon the type of model used (waterfall, spiral…).
It was agreed that our standard will not dictate when a work product must be created. For example, should the STP be produced during the Requirements phase, or should it be described under the testing phase? Our standard should focus on the content of the documentation to be supplied by the vendor and not when it should be submitted.
Linda
M. suggested that Safety Documents that are required for vital software
functions should be described as input to our Requirements Phase. These
documents may be out of the scope of our standard, but should be mentioned as
an input. This was agreed upon.
There
was a discussion on the various types of systems that are to be covered by
P1588. It was confirmed that the scope
of our standard is loose enough to cover the following:
-
OCC
-
Wayside
Systems
-
Carborne
The
P1588 working group must address how to deal with legacy software versus new
development within our standard. This is a future action item for the working
group. The working group must also define what a software item is.
Review of Work Products to be addressed by our
standard:
The following notes coincide
with the document mapping matrix that Martin C. presented and updated during
the course of Meeting 6.
·
RTM
is a required work product
Bill M. proposes we include an RTM to the list of our work products.
The working group accepted this idea. Traceability through every phase of
development should be addressed by our standard. The introduction of our
standard must address the effect on legacy software. The issues our standard
must include guidance on:
- What is a requirement,
- Define how to make the
traceability useful
- Define to what level
traceability shall be provided
·
SDP
is a required work product
Risk and Schedule should be
addressed within this work product
·
SQAP
is a required work product
·
SCMP
is a required work product
·
SVVP
is a required work product
·
STP
is a required work product
·
SRS
is a required work product
Should be clear that the human interface (GUI) is to
be addressed
·
IRS
is a required work product
·
SDD
is a required work product
May need to further define the levels of design required at different
phases, for example architectural design versus detailed design. Further definition to the levels of design
detail will be addressed at a later point in time, when we develop the content
of the SDD.
·
IDD
is a required work product
·
DBDD
is a required work product
This document shall stand on its own, based on the precedent set by
J-STD-016
·
STD
is a required work product
·
STR
is a required work product
·
TD
is not a requirement of our standard but will be referenced herein
Test descriptions are outside the scope of P1588,
but are required during system development.
These are the test descriptions for system qualification testing.
·
TR
is not a requirement of our standard but will be referenced herein
Test reports are outside the scope of P1588, but are required during system development. These are the test reports for the system qualification testing.
·
SIP
is a required work product
·
SVVR
is a required work product
·
SUM
is a required work product
·
SVD
is a required work product
Describes the versions of compilers, operating systems, application
software that is or has been installed
·
Maintenance
Documents
Lori K. and Tom T are to evaluate if the 4 maintenance documents (SPS,
SVD, CPM, FSM) that are required by the J-STD-016-1995 are required as separate
work products or can be combined.
Load Control Procedure (LCP) is a suggested new name for FSM.
·
Source
Code is not a required work product
The group exhaustively discussed whether the source code work product
should be addressed from within our standard. We do not want to list all
software standards (such as ANSI) within our standard. We want to ensure that
software coding standards are being followed.
Our standard should require the developer to reference back to the SDP
to ensure the developer is adhering to the coding standard as specified in the
SDP.
·
Software
Safety Program Plan is not a required work product.
The working group needs to determine what other documents (or parts of documents) must be considered if we have safety critical software?
No
separate documents are required for subcontractor management. Each work product should address
subcontractor issues from within the scope of that document.
The
group discussed the “…minimum requirement for application software
documentation…”. It was discussed that
this minimum set may be different based on the type of system (embedded versus
control center).
The
working group discussed how to best determine the list of applicable standards.
We will assume that there are no contradictions between J-STD-016 and other
IEEE standards. Are we singling out
J-STD-016 or do we say that all applicable IEEE standards are applicable? The suggestion was made that the working
group take each document, look at all the standards that are applicable, and
present the standards. This is an action item for all working group members.
Related
to above, the action item from the last meeting for Paul J. to compile a list
of standards and make available was mentioned.
Paul J. did get a copy of IEEE 498 from George H., but didn’t distribute
it. George H. proposed a rule that we ignore obsolete standards like 498 –
which turned into J-STD-016.
Paul J. to ask the IEEE staff support person: Is J-STD-016 ready for issue? How does it
differ from 1995 document?
There
was discussion on what will be our “base” set of standards. We will be using J-STD-016 (what year to be
determined), ISO 12207, and the rest of the IEEE software engineering standards
as our base. If anyone finds something
else that is applicable, let the rest of us know and make a case for it.
The
current set of IEEE standards is the “four volume” bound set (also available on
CD-ROM). We should all acquire the
standards (those that don’t have them).
Now
that we have the “fundamental” list of documents, the approach decided on was
to start writing the standard now, in parallel with investigations into
guidelines for tailoring of the existing standards for our use.
Paul J. and
Lori K. will work on the outline of our standard document and Paul J. will
write the introduction.
For
the process of addressing each document and proposing tailoring of the
standards for our use, we will divvy up the work and declare a book captain for
each work product (or type of work product).
The
documents will be divided up roughly according to “lifecycle phases.”
The
captain is responsible for receiving input on the tailoring suggestions and
rationale for those suggestions, also suggested additional guidance or
exclusions. The group will keep in
touch via e-mail; if there are areas of contention, these should be brought up
at the next meeting.
Our
standard will, for each document, provide the following information:
Purpose / Contents / Nature
of the document (i.e. what is the purpose and general contents of the document,
and what is/are the applicable standards?)
Tailoring – what tailoring
of the referenced standard can / should be done? Provide a rationale for the tailoring, and also supply an
importance factor – high / medium / low priority
Guidance – guidance for
tailoring and use
Examples – some good
examples of the document
Is
there information from other industries that we can plagiarize? Linda M. is to send around a list of links
to other good examples.
The following
document assignments were made. The first
person listed is the “book captain” for the team. The team is to develop the information outlined above (Purpose,
Tailoring, Guidance, Examples) and work through the “book captain.”
|
SDP,
including SQAP, SCMP, and SVVP |
Shanti,
John, Byron |
|
The
four maintenance ones, (SPS, SVD, CPM, FSM/LCP) and SIP and SUM |
Lori,
Tom and Real |
|
STD,
STR, STP |
Denise,
Leroy |
|
SRS
/ IRS / SDD / IDD / DBDD |
Bill,
Linda and George |
|
SVVR |
Shanti,
John, Byron |
|
RTM |
Martin,
Paul J. |
The
priority for working on these documents was decided to be: start with planning
documents, then the technical documents (requirements and design), then testing
documents.
NOTE:
please note that the December working group meeting will be in Rancho
Cucamonga, CA. This was confirmed after meeting 6 was adjourned.