top - download
⟦cc5632a2a⟧ Wang Wps File
Length: 5289 (0x14a9)
Types: Wang Wps File
Notes: Problem Hdl. std.
Names: »0120A «
Derivation
└─⟦84647c47a⟧ Bits:30005817 8" Wang WCS floppy, CR 0014A
└─ ⟦this⟧ »0120A «
WangText
…02…SD/STD/007
…02…19801120…02……02…#
PROBLEM HANDLING STANDARD
…02……02…GENERAL
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 TBD ..........................................
4
2 TBD ..........................................
4
3 PROBLEM HANDLING .............................
4
3.1 GENERAL ..................................
4
3.2 PROBLEM DEFINITION .......................
4
3.3 PROBLEM REPORT ...........................
5
3.4 RESPONSIBILITY ...........................
6
3.5 TEMPORARY SOLUTIONS ......................
6
3.6 REPORT FORM ..............................
6
1̲ ̲ ̲T̲B̲D̲
2̲ ̲ ̲T̲B̲D̲
3̲ ̲ ̲P̲R̲O̲B̲L̲E̲M̲ ̲H̲A̲N̲D̲L̲I̲N̲G̲
3.1 G̲E̲N̲E̲R̲A̲L̲
In order to assist the project personel in solving
problems - a standard procedure is established for
formal and uniform handling of problems which arise
during system development:
3.2 P̲R̲O̲B̲L̲E̲M̲ ̲D̲E̲F̲I̲N̲I̲T̲I̲O̲N̲
Problems are any matter in which the designers need
support of any kind from sources outside himself, whatever
that source is in house or not.
Of course the procedure shall not be used for trivial
problems which can be solved by asking a question.
The designers should use their power of judgement to
decide if the severity of the problem justifies its
placement in this system.
The following list of potential problem areas can be
used as guideline for categorizing a problem. However,
problems may also arise in several areas not foreseen
by this list
a) requirements:
describe all requirements which
- are vague, badly phrased or otherwise difficult
to interpret
- are conflicting with other requirements
- are impossible to implement
- rise problems such as a very intricate design,
out of proportion size or time consumption
etc.
b) Interrelations:
Describe all problems with relations between units
e.g.
- missing information in ICD's
- wrong or conflicting info in ICD's
- discrepancies between design of a module and
system/package design
c) Coding:
List problems with
- coding language
- compilers
- etc.
d) Testing:
include description of
- hardware problems
- missing input from other units
- etc.
3.3 P̲R̲O̲B̲L̲E̲M̲ ̲R̲E̲P̲O̲R̲T̲
Whenever a problem has been identified a Problem Report
(PR) shall be issued using the form described in section
3.6
The PR is immediately handed over to the systems engineer,
who will enter the report in the problem file.
If the problem relates directly to a software unit
for which a UDF is established a copy of the PR shall
be inserted in section 2 of the UDF in accordance with
the rules in UDF Standard SD/STD/006.
3.4 P̲R̲O̲B̲L̲E̲M̲ ̲F̲I̲L̲E̲
It is hence-forth the responsibility of the systems
engineer to sort and register the problems and to initiate
the actions necessary to solve the problems.
All problem reports together with any material pertinent
to the problem handling shall be kept in a problem
file giving easy access to the status of all open problems.
Note that the systems engineer's responsibility in
problem solving will only be the formal framework -
take initiatives, standardize handling and formal correspondance.
- No action may be taken without involving the appropriate
designers, section leaders or technical managers.
3.5 T̲E̲M̲P̲O̲R̲A̲R̲Y̲ ̲S̲O̲L̲U̲T̲I̲O̲N̲S̲
As the final solution often may take time (through
correspondance and negotiations with other parties)
the system engineer - after coordination with the responsible
section leader - can authorize an assumption as being
the temporary baseline from which to procede the work.
3.6 R̲E̲P̲O̲R̲T̲ ̲F̲O̲R̲M̲
A form sheet as the attached shall be used as the basis
of each problem report. If the fields of the form are
too small the fields shall be given a reference to
extension sheets which are attached to the form.
The fields shall be used as follows:
(1)- Shall contain the PR number - The number can
be obtained from the systems engineer who will
maintain a number list connected with the problem
file.
(2)- The date the PR is issued
(3)- Identificaion of originator
(4)- The type of problem is indicated by a mark
in the appropriate box. If the problem relates
directly to a specific document the lines following
the box is used to identify that document.
(5)- The problem is given a brief title which is
suitable for future references to the problem.
(6)- The description of the problem is given in
this field.
(7)- If the originator of the report is able to
suggest a solution to the problem this field
is used. The field may also be used for expression
of an opinion about the problem.
(8)- These fields are used by the system engineer
(11)- when initiating actions to solve the problem.
The fields shall be used as appropriate to:
- describe the action
- identify an actionee
- establish a due date
- show the date of the closure of the action
