top - download
⟦04d2228e6⟧ Wang Wps File
Length: 11638 (0x2d76)
Types: Wang Wps File
Notes: UDF Standard
Names: »0080A «
Derivation
└─⟦83a4a04d1⟧ Bits:30005815 8" Wang WCS floppy, CR 0002A
└─ ⟦this⟧ »0080A «
WangText
…02…SD/STD/006
…02…SVO/801020…02……02…#
U D F STANDARD
…02……02…GENERAL
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
S̲e̲c̲t̲i̲o̲n̲ ̲1̲
…02…1 SCOPE ................................... 4
…02…2 PURPOSE ................................. 4
…02…3 UDF - UNIT DEVELOPMENT FOLDER ........... 5 to 6
…02……02…3.1 UNIT DEFINITION ..................... 5
…02……02…3.2 GENERAL RULES ....................... 6
…02……02…3.3 DETACHED VOLUMES .................... 6
…02……02…3.4 UDF FORMAT .......................... 6
…02…4 UDF SECTIONS ............................ 7 to 12
…02……02…4.1 CONTROL INFO ........................ 7
…02……02…4.2 ACTIONS AND PROBLEMS ................. 8
…02……02…4.3 NOTES ............................... 9
…02……02…4.4 FUNCTIONAL CAPABILITIES ............. 9
…02……02…4.5 REQUIREMENTS ........................ 10
…02……02…4.6 INTERFACES .......................... 10
…02……02…4.7 DESIGN .............................. 10
…02……02…4.8 CODE ................................ 11
…02……02…4.9 TEST SPECIFICATIONS AND PROCEDURES .. 11
…02……02…4.10 TEST RESULTS ........................ 11
…02……02…4.11 SUPPORT TOOLS ....................... 11
…02……02…4.12 AUDIT REPORTS ....................... 12
1̲ ̲ ̲S̲C̲O̲P̲E̲
This standard is a derivative of software standard
man- ual SD/STM/003 and has the same scope and applicability.
2̲ ̲ ̲P̲U̲R̲P̲O̲S̲E̲
A UDF - U̲nit D̲evelopment F̲older has a series of pur-
poses as listed and described below:
a) U̲n̲i̲t̲ ̲I̲d̲e̲n̲t̲i̲f̲i̲c̲a̲t̲i̲o̲n̲
When a software system is broken up into several
units in order to facilitate development, means
of identifying and describing the units are needed.
b) C̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
During the development of a unit a lot of material
is produced - collecting this material in one place
should make it easier to perform the work on the
unit.
c) O̲r̲d̲e̲r̲
It is obvious to most people that order in such
a collection of material is necessary. However,
ex- perience shows that many workers need aid and
ad- vise on how to keep order. The UDF is (among
other things) an offer to such people as a tool
which they can utilize in their work.
d) S̲t̲a̲n̲d̲a̲r̲d̲s̲
In making the collection and ordering in accordance
with a standard the project as a whole is made
less independent of the availability of specific
per- sons. Also standardizing makes cooperation
between
the members of a team much easier as everybody
is able to understand the work of the others.
e) V̲i̲s̲i̲b̲i̲l̲i̲t̲y̲
A well ordered up to date UDF makes it much easier
for the management of the project to follow the
progress of the work. This benefits both the man-
ager in his project control as well as the worker
as he cannot be suspected of improper effort.
f) M̲i̲n̲i̲m̲i̲z̲i̲n̲g̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
If a team employs a well functioning UDF system
the project control procedures can be much simpler
and easier to work with than would otherwise be
ne- cessary.
…01…3̲ ̲ ̲U̲D̲F̲ ̲-̲ ̲U̲N̲I̲T̲ ̲D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲F̲O̲L̲D̲E̲R̲
For every unit considered an independent entity during
development a UDF shall be established.
3.1 U̲N̲I̲T̲ ̲D̲E̲F̲I̲N̲I̲T̲I̲O̲N̲
A unit is any independent piece of software.
A software system may be divided into packages, mo-
dules, routines, and elementary processes, or any other
division using different designation at the various
levels.
The word unit is used to designate any piece of soft-
ware regardless of its size or its level in a hierarchy.
Whenever the development of a software system leads
to the definition of such a unit and this unit is given
some kind of independence in the further development,
a UDF shall be established, (the system itself is the
first unit to be identified).
3.2 G̲E̲N̲E̲R̲A̲L̲ ̲R̲U̲L̲E̲S̲
The UDF shall be kept up to date at all times - this
is an absolute demand and not just a polite request.
The UDF shall be kept readily available at the site
of development and shall be marked in a way that makes
it easy identifiable.
The UDF shall be open for audit and review by everybody
(whatever internal or external personnel) authorized
to such activities.
3.3 D̲E̲T̲A̲C̲H̲E̲D̲ ̲V̲O̲L̲U̲M̲E̲S̲
Any section (see chapter 4) exept 1. CONTROL and 14:
AUDIT REPORT may during unit development expand to
a size which is impractical to have as part of the
UDF. In such cases the whole section shall be detached
from the UDF and inserted in a special volume dedicated
to this use.
This detached volume shall be marked very clearly in
a way showing its relation to a specific UDF. Also
an entry shall be made in the volume control list in
sec- tion 1.
3.4 F̲O̲R̲M̲ ̲O̲F̲ ̲U̲D̲F̲
The actual format in which the UDF and its detached
volumes are established shall be whatever is most suit-
able for the material in question.
The person responsible for the unit development may
select what is most appropriate whether this is simple
cardboard folders, binders, or other.
4̲ ̲ ̲U̲D̲F̲ ̲S̲E̲C̲T̲I̲O̲N̲S̲
A UDF shall be divided into 12 sections into which
all the development material shall be sorted. The
section headers shall be as follows:
1- CONTROL INFO
2- ACTION ITEMS & PROBLEMS
3- NOTES
4- FUNCTIONAL CAPABILITY
5- REQUIREMENTS
6- INTERFACES
7- DESIGN
8- CODE
9- TEST PROCEDURE(S)
10- TEST RESULTS
11- SUPPORT TOOLS
12- AUDIT REPORTS
The content of each section shall be as described in
the following:
4.1 C̲O̲N̲T̲R̲O̲L̲ ̲I̲N̲F̲O̲
This section shall contain all information necessary
to identify the unit and control responsibilities re-
garding the unit. This includes:
a) Identification of the Unit
b) Responsible personnel list
c) Schedule for development
d) Action item and problem tracking list
e) Work item status list (optional)
f) List of detached volumes comprising the UDF
g) List of documents directly referenced in develop-
ment of the unit and their status.
h) List of related units
- Units which include this unit
- Units included in this unit
- Units with which this unit communicates in
or- der to perform its functions
i) List of milestones encountered.
All information in this section shall be entered on
form sheets as shown in Appendix.
4.2 A̲C̲T̲I̲O̲N̲S̲ ̲A̲N̲D̲ ̲P̲R̲O̲B̲L̲E̲M̲S̲
a) This section shall contain a record of all action
items assigned to the unit development, regardless
of the source of the action, and a record of all
problems in the development for which outside assistance
is necessary.
An action item and problem tracking list shall
be kept which always shows the actual status of
actions and problems.
b) If the action is given on an official form sheet
this sheet is inserted, otherwise the action is
described with its source and due date, and the
description is inserted.
c) Problems encountered during the development shall
result in a problem report and through this be
entered into the projects problem handling system,
while a copy of the report is inserted here.
For further definition of problems and their handling
see problem handling standard SD/STD/007.
This section may also be used to contain descriptions
of work items defined by the development team itself.
If such descriptions are established and accounted
for in a work item status list, planning within the
team will be facilitated.
4.3 N̲O̲T̲E̲S̲
A section meant to contain all additional information
concerning development of the unit.
This is mainly MMO's technotes, telexes - etc. which
contain e.g. answers to questions raised, clari- fications
etc.
4.4 F̲U̲N̲C̲T̲I̲O̲N̲A̲L̲ ̲C̲A̲P̲A̲B̲I̲L̲I̲T̲I̲E̲S̲
This section shall contain
a) description in user oriented terms of the unit
with special emphasis on which part of the system/-
package functions shall be performed by this unit.
A similar description may be contained in the requirement
section and if this is found adequate a reference
will suffice. This section is, however, meant to
be informational for the user and therefore an
expansion and/or rephrasing of the requirements
may be appropriate.
b) A list of all the elements of the units functions
in which the status at the development of the functions
can be checked.
This list will be specially useful in cases where
the unit is made available for a user or for integration
into a system before the development is completed.
4.5 R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
This section shall contain the requirements for the
unit.
Establishing requirements may be part of the unit de-
velopment in a requirement analysis phase. In this
case all information relating to requirements are col-
lected here.
Requirements may have been established in a larger
scope before the unit is identified as an independent
development item. In that case the relevant part(s)
of the requirement document are copied and inserted
here.
4.6 I̲N̲T̲E̲R̲F̲A̲C̲E̲S̲
This section shall contain all descriptions of inter-
faces between this unit and other units.
Establishment of interfaces may be part of the unit
development in which case all information relating
to the interface is collected here.
Interfaces may have been established in a larger scope
before development of the unit starts. In that case
the relevant part(s) of the interface document are
copied and inserted here.
4.7 D̲E̲S̲I̲G̲N̲
All papers containing design information shall be col-
lected in this section.
During the design phase first all notes and drafts
pro- duced are collected. As work proceeds those may
be replaced with typed and drawn material for eventually
ending up with a complete design document.
The format of this document as well as the method em-
ployed during development shall comply to standards.
If official issues of design documents or parts hereof
are made, such issues shall be included here and hence-
forth be the basis of design work.
4.8 C̲O̲D̲E̲
The coded unit shall be kept in this section:
Coding sheets are collected here until code is trans-
ferred to machine readable medium, and then replaced
by printer listings.
If source code is kept in datasets on disc or tape
re- ferences to those shall be present here.
4.9 T̲E̲S̲T̲ ̲S̲P̲E̲C̲I̲F̲I̲C̲A̲T̲I̲O̲N̲ ̲A̲N̲D̲ ̲P̲R̲O̲C̲E̲D̲U̲R̲E̲S̲
During development all descriptions of test specifi-
cation and procedures shall be kept here .
Test procedures exclusively used for development tests
may be in draft form.
Test procedures used also for qualification tests shall
eventually be issued as part of a verification report
and at that time be entered in the volume control list.
4.10 T̲E̲S̲T̲ ̲R̲E̲S̲U̲L̲T̲S̲
All information necessary to follow the status of the
tests shall be kept here.
This is mainly a log of which tests have been performed
and which results have been obtained.
Reference to run time listings containing test results
shall be kept.
4.11 S̲U̲P̲P̲O̲R̲T̲ ̲T̲O̲O̲L̲S̲
This section shall contain information of all support
tools used during development and test of the unit.
The special conditions necessary to run test of the
unit shall be described whatever software, hardware,
system software or operating personnel are in question.
4.12 A̲U̲D̲I̲T̲ ̲R̲E̲P̲O̲R̲T̲
Whenever a review or audit concerning the unit has
taken place, the resulting comments or reports shall
be placed here.
