top - download
⟦fb0128d67⟧ Wang Wps File
Length: 20412 (0x4fbc)
Types: Wang Wps File
Notes: DIVERSE
Names: »3607A «
Derivation
└─⟦daa99b8e3⟧ Bits:30006185 8" Wang WCS floppy, CR 0401A
└─ ⟦this⟧ »3607A «
WangText
C O M P A N Y C O N F I D E N T I A L
…02…
…02…JAL/841122…02……02…#
INTERN MEDDELELSE NR. 860
…02……02…CAMPS
VEJEN TIL SEKRET@RENS MAVES
VEJEN TIL SEKRET@RENS MAVES
VEJEN TIL SEKRET@RENS MAVES
VEJEN TIL SEKRET@RENS MAVES
VEJEN TIL SEKRET@RENS MAVES
K̲l̲a̲d̲d̲e̲s̲k̲r̲i̲v̲n̲i̲n̲g̲
Skriv helst med uspidset blyant. Lav en masse overstregninger
de for- kerte steder, og pr]v s> at rette det op igen,
men brug endelig ikke viskel`der.
Kan man bruge noget fra andre dokumenter, som ligger
p> WANG g]res det- te bedst ved, at man klipper alt
ud, som kan identificere dokumentet. Dvs. dokumentnavn,
nr. og kapiteloverskrifter. Kan man ikke komme til
at klippe, skal man bruge fjumrebl`k, som ogs> g]r
det umuligt for se- kret`ren, at se hvor det er taget
fra.
Ved opstillinger skal man altid bruge papir uden linier
og tern, laves der en fejl skrives det rigtige oveni,
s>ledes at man ikke kan l`se nogle af tallene.
Er det noget der haster, skal man komme og sp]rge hvert
halve minut om det er f`rdigt. Kom ogs> helst med hastesager
omkring kl. 16.00, sekre- t`rer har nemlig ikke noget
hjem, og er kun taknemmelige for at have et sted at
tilbringe aftenen.
K̲o̲r̲r̲e̲k̲t̲u̲r̲
Her g`lder det om at skrive med blyant, og helst s>
svagt som muligt (blyanter er ogs> billigere end r]de
tusser).
Er der nogle sider eller afsnit der ikke er, hvor de
skal v`re, klip endelig det hele fra hinanden og s`t
det s> rigtigt sammen igen.
Sl>fejl og andre sm>fejl rettes bedst ved at man skriver
oveni, man skal helst ogs> ramme lidt af det rigtige.
N>r du f>r det f`rdige ind, kan du eventuelt "v`lte"
en kop kaffe over det og bede om en ny udskrift.
G̲e̲n̲e̲r̲e̲l̲t̲
Har sekret`ren sp]rgsm>l til din kladde eller korrektur,
s]rg for ikke at v`re p> din plads, g> til m]de uden
at sige det, eller g> slet og ret hjem.
N>r du kommer ind med kladden eller korrekturen, smid
den p> sekret`- rens bord, men det skal v`re, n>r hun
ikke er der.
Timesedler afleveres ikke f]r der er rykket mindst
fem gange.
Hvis det skulle h`nde at du er forhindret i at komme
p> arbejde, skal du ikke g]re dig den ulejlighed at
ringe besked.
Bed altid din familie, venner og bekendte om at ringe
til sekret`ren, hvis du ikke selv er p> din plads,
hun ved som regel hvor du er.
Giv aldrig et varsel n>r du >bner den sidste pakke
papir til kopima- skinen, men sig det f]rst til sekret`ren
n>r du har brugt det sidste stykke, bed hende s> g>
ned efter noget nyt (en kasse vejer kun 25 kg.)
Kaffe, fl]de, papb`gre og sukker tages i k]kkenet.
Er der ikke mere har sekret`ren selvf]lgelig s]rget
for at m]delokalet er velforsynet. Skul- le dette forr>d
ogs> blive t]mt, fort`ller man sekret`ren at der ikke
er mere ude i k]kkenet.
Har man brug for en termokande, er sekret`ren altid
velforsynet med s>- danne, n>r hun har g`ster, kan
hun jo altid finde nogle et eller andet sted.
C̲O̲N̲S̲E̲Q̲U̲E̲N̲C̲E̲S̲ ̲O̲F̲ ̲M̲E̲M̲O̲R̲Y̲ ̲E̲X̲P̲A̲N̲S̲I̲O̲N̲
In addition to delays and increased scope
of the CAMPS software development already
identified, CAMPS is being impacted in two
areas by expanding the memory. One is direct
costs related to the additional memory boards.
The other is related to the changes in system
reliability and availabiity. Each of these
subjects are described below.
D̲I̲R̲E̲C̲T̲ ̲C̲O̲S̲T̲S̲ ̲O̲F̲ ̲M̲E̲M̲O̲R̲Y̲ ̲B̲O̲A̲R̲D̲S̲
Originally CAMPS was proposed with the following
memory configurations:
7 sites: 192 K words
9 sites: 160 K words
In March 1983 a memory expansion and standardization
was agreed between CR and SHAPE (refer ECP
29) by which all sites were to be supplied
by 2 times 512 K words memory boards. The
total number of 512 K memory boards to be
delivered to sites and depots were as follows:
Memory installed in 16 sites = 64
Memory installed in 2 Depmet System = 8
Spares at 16 sites = 16
Spares at depot N = 5
Spares at depot S = 3
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Total memory population = 96
As of today the minimum memory requirements are:
Small sites (7 sites) 3 boards
per PU
Big sites (9 sites) 4 boards
per PU
Depmet (2 depot systems) 3 boards
per PU
Reference System 4 boards
per PU
For standardization purposes SHAPE has requested CR
to install 4 boards per PU in all of the above system.
In addition to the above installed memory boards spares
are required at sites as well as at depots. The number
of spare modules required depends on the reliability
of the memory boards. CR has performed a theoretical
calculation which calculates the M̲ean T̲ime B̲etween
F̲ailures (MTBF) to 3,900 hours. The actual observed
reliability is, however, approximately 15,000 hours.
SHAPE insits that CR is using the theoretical calculated
MTBF value.
Below the number of spares required at site and depots
are presented for the two different MTBF values.
M̲T̲B̲F̲ ̲=̲ ̲3̲,̲9̲0̲0̲ ̲h̲o̲u̲r̲s̲:̲
Site spares (16 sites) 96
Depot spares:
- North 100
- South 68
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Total 274
M̲T̲B̲F̲ ̲=̲ ̲1̲7̲,̲0̲0̲0̲ ̲h̲o̲u̲r̲s̲:̲
Site spares (16 sites) 32
Depot spares:
- North 10
- South 6
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Total 48
S̲U̲M̲M̲A̲R̲Y̲
Based on the above the total number of memory boards
to be installed and spared are:
a) Minimum installed = 134
b) Standardized installed memory con-
figuration of four boards at all
sites = 152
c) Spares (MTBF Theoretical = 274
d) Spares (MTBF observed) = 48
The least costly option is to select a + d, while the
most costly option is b + c. The most likely option
to be selected is b + d.
CR is currently being covered by the costs of 102 512
K memory boards.
VHN/840525 3607A
X̲F̲X̲/̲S̲D̲S̲/̲0̲0̲1̲ ̲p̲>̲ ̲W̲A̲N̲G̲ ̲A̲n̲l̲`̲g̲g̲e̲t̲
Doc. Arkiv
No. Disk.
4961A 0461A TABLE OF CONTENTS
4620A 0442A 1 SCOPE
1.1 APPLICABLE DOCUMENTS
1.2 PROJECT REFERENCES
1.3 TERMS
1.4 ABBREVIATIONS
4631A 0442A 2 SUMMARY OF REQUIREMENTS
2.1 SYSTEM DESCRIPTION
2.2 SYSTEM FUNCTION
2.3 CHARACTERISTICS
2.4 DESIGN AND CONSTRUCTION (HW)
2.5 DESIGN AND CONSTRUCTION (SW)
2.6 DOCUMENTATION
3 ENVIRONMENT
3.1 PHYSICAL ENVIRONMENT
3.2 EXTERNAL INTERFACES
4912A 0470A 3.3 PROCEDURAL INTERFACES
3.4 OPERATOR INTERFACES
4694A 0444A 3.5 POWER INTERFACES
4633A 0442A 4 SYSTEM OVERVIEW
4.1 CONFIGURATION OVERVIEW
4648A 0444A 4.2 FUNCTIONAL FLOW
4642A 0442A 4.3 SYSTEM SUPERVISION
4640A 0442A 4.4 TERMINAL MECHANISMS
4.5 SOFTWARE CONCEPTS
4638A 0442A 4.6 MPF APPLICATION SUPPORT FUNCTIONS
4933A 0470A 4.7 DATA BASES
4637A 0442A 4.8 SECURITY
4.9 AVAILABILITY AND RELIABILITY
4647A 0444A 4.10 RECOVERY AND INFORMATION INTEGRITY
4743A 0454A 4.11 ERROR AND BACK-LOCK HANDLING
4821A 0470A 4.12 SYSTEM MAINTENANCE
4.13 SYSTEM DEVELOPMENT
4681A 0444A 4.14 SYSTEM TESTING
4649A 0444A 5 H/W SUBSYSTEM SPECIFICATION
5.1 SCOPE
5.2 CR80 CRATES
5.3 CR80 BUSES
5.4 CR80 PROCESSOR-SYSTEM
4650A 0444A 5.5 CR80 I/O-SYSTEM
5.6 WATCHDOG-SYSTEM
5.7 MCU HW
4749A 0454A 6 DAMOS Subsystem
A̲P̲P̲E̲N̲D̲I̲C̲E̲R̲ ̲T̲I̲L̲ ̲X̲F̲X̲/̲S̲D̲S̲/̲0̲0̲1̲ ̲p̲>̲ ̲W̲A̲N̲G̲ ̲A̲n̲l̲`̲g̲g̲e̲t̲
Doc. Arkiv SDS
No. Disk.
APPENDIX A Application Support Subsystem
4768A 0454A 005 APPENDIX A1 CAMP System Functions
4803A 0444A 004 APPENDIX A2 System Status and Control
4798A 0461A 007 APPENDIX A3 Table Management
4785A 0461A 006 APPENDIX A4 Message Management System
APPENDIX B I/O Control Subsystem
4814A 0454A 008 APPENDIX B1 VDU DIALOGUE SUPPORT
PACKAGE
4788A 0461A 009 APPENDIX B2 FORMAT HANDLER
4773A 0461A 010 APPENDIX B3 TERMINAL AND LINE HANDLERS
4832A 0470A 011 APPENDIX B4 LTU FIRMWARE
APPENDIX C Application Subsystem
4920A 0470A 012 APPENDIX C1 Analysis Package
4928A 0470A 013 APPENDIX C2 Conversion Package
4910A 0470A 014 APPENDIX C3 Transport Package
4762A 0454A 015 APPENDIX C4 Message Generation Package
4932A 0470A 016 APPENDIX C5 Supervisor VDU Package
4916A 0461A 017 APPENDIX C6 Service VDU Package
4944A 0461A 018 APPENDIX C7 Supervisor Print Package
4765A 0454A 019 APPENDIX C8 Printer Package
4770A 0461A 020 APPENDIX C9 Storage and Retrieval
Package
4838A 0470A 021 APPENDIX C10 Log Package
4718A 0454A 022 APPENDIX C11 Statistics Package
4927A 0470A 003 APPENDIX D MCU Subsystem
MANAGEMENT OF RESEARCH AND DEVELOPMENT…01…******************************************
…01…I̲n̲t̲e̲r̲n̲a̲t̲i̲o̲n̲a̲l̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲I̲n̲s̲t̲i̲t̲u̲t̲e̲,̲ ̲G̲e̲n̲e̲v̲a̲
Week I: "The Strategic Management
of R&D Projects"
Week II: "Managing the Innovative R&D Organization"
B̲a̲c̲k̲g̲r̲o̲u̲n̲d̲
The first week of the course will cover R&D planning
and project selection and management - "The Strategic
Management of R&D Projects". It will address the major
area of the links between corporate strategy and planning
and technological strategy and planning. In particular,
a number of techniques will be discussed which aim
to ensure the harmonization and integration of marketing
and R&D policies and actions. These include analysis
of technological position and potential, the concept
of the technological portfolio, scenario planning,
technological assessment, competitive analysis, etc.
This area of the strategic management of R&D leads
into the effective procedures for project selection
and project planning and control. Here the emphasis
is less on project management as a "text book" procedure,
and more on a process of communication, motivation
and resource management.
The second week of the course deals with the management
of the R&D organization, with particular reference
to the flow of technological information into the R&D
group and the flow of technological innovation out
of R&D to other parts of the organization. Entitled
"Managing the Innovative R&D Organization", this part
of the progam will feature Dr. Thomas Allen of MIT
and will include the management of technical groups
and their careers, particularly in "stable" R&D organizations
as well as the management of new ventures based on
innovation.
P̲a̲r̲t̲i̲c̲i̲p̲a̲n̲t̲s̲
The seminar is intended for directors of R&D Divsions,
managers of large R&D sections and executives responsible
for the R&D activities of organizations, whether they
be in the private or public sector, or in international
organizations.
A̲ ̲Q̲U̲A̲N̲T̲I̲T̲A̲T̲I̲V̲E̲ ̲A̲S̲S̲E̲S̲S̲E̲M̲E̲N̲T̲ ̲O̲F̲ ̲T̲H̲E̲ ̲I̲M̲P̲L̲E̲M̲E̲N̲T̲A̲T̲I̲O̲N̲ ̲…01……01…O̲F̲ ̲A̲ ̲L̲A̲R̲G̲E̲ ̲C̲O̲M̲M̲U̲N̲I̲C̲A̲T̲I̲O̲N̲ ̲S̲Y̲S̲T̲E̲M̲
1 I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The purpose of this paper is to discuss the project
implementation of a large communciation project based
on a quantitative analysis of historical/real project
data.
The subject project has been implemented using state-of-the-art
techniques and methodologies, which are briefly discussed
in this paper.
In addition to a top level overall project analysis,
this paper will analyze the deviations between the
average project performance and the individual sub-
project team performance to highlight problems and
the potential risc factors related to such a large
project implementation.
Finally, it will be discussed to what degree that the
project strategies have been implemented and the reasons
for deviations from these strategies.
1.1 S̲Y̲S̲T̲E̲M̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ ̲A̲N̲D̲ ̲C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
The purpose of the subject communication system was
to improve the efficiency of message processing communication
within and between a large number of organizations
within Europe by automating the existing manual procedures.
The system supports users in drafting messages including
coordination editing and archiving as well as routing
and transmission of messages through the appropriate
communications networks interconnecting the various
organizations. The system, furthermore, performs an
automation, distribution and relay function of incoming
messages.
The system was characterised by a combination of high
performance, reliability, and security requirement,
which imply use of complex fault tolerant computer
design as well as highly sophisticated operating systems.
1.2 P̲R̲O̲J̲E̲C̲T̲ ̲C̲H̲A̲R̲A̲C̲T̲E̲R̲I̲S̲T̲I̲C̲S̲
The contract value of the project was comparable with
the yearly turnover of the company, meaning the new
dedicated organization personel procedures, etc. had
to be established in order to cope with new and complex
situation.
During the project the computer hardware, system software,
and application software were developed in parallel,
adding an extra element of risc to the project.
From the beginning of the project implementation a
very close relationship was established with the customer
and throughout the program. The customer participated
in review of all implementation phases and was characterized
as a very profesional and competent customer with an
understanding for critical issues related to large
projects and capability to take timely decisions when
necessary.
1.3 P̲R̲O̲J̲E̲C̲T̲ ̲S̲T̲R̲A̲T̲E̲G̲I̲E̲S̲
The project philosophy used during the implementation
was as follows:
- to establish a sequence of well defined
tasks/objectives qualitatively as well
as quantitatively leading into an overall
coordinated goal structure.
- to establish checkpoints units for evaluation
of task performance and accoplishments.
- to obtain early warnings when subtasks
have not been accomplished.
The strategies to accomplish this were the following:
- Top-down implementation.
- Baseline management.
- Continous validation and verification.
- Incremental development.
1.3.1 T̲o̲p̲-̲D̲o̲w̲n̲ ̲I̲m̲p̲l̲e̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
Top down implementation starts by a top down requirement
analysis and design during which requirements and design
is developed in a sequence of hierarchical elaborations
of the users information, processing needs, and objectives.
The approach is extended further when an appropriate
use of incremental development, which is described
below, is exercised.
A very important step in top down implementation is
to establish the system/software requirements specifications.
A good requirements specification is crusial to the
project implementation for the following reasons. Top
down design is impossible, for lack of a well defined
top, testing is impossible, because there is nothing
to test against, the user is frozen out, because there
is no clear statement of what is being produced and
management is not in control, as there is no clear
statement of what the project team is producing.
1.3.2 B̲a̲s̲e̲l̲i̲n̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The top down implementation is centered around a sequential
approach made up of a number of phases which normally
consists of: System Requirements, System Design, Preliminary
and Detailed Design, Code and Unit Testing, Integration,
System Verification, and Operation/Maintenance phase.
Each phase culuminates in a baseline made up of one
or more of the following elements: Plans, Specifications,
Design Documents, Manuals, Test Specification, etc.
and products (hardware and/or software). An approved
baseline can only be changed through formal change
procedures to ensure that the baselines are consistent
and complete.
1.3.3 C̲o̲n̲t̲i̲n̲o̲u̲s̲ ̲V̲e̲r̲i̲f̲i̲c̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
In the normal course of software development requirements
and specifications are both incomplete and conflicting.
If these inadequances are not discovered and corrected,
they are incorporated into the design and the problems
are not discovered until the testing phase, which reveals
the need for changes to detailed design which in turn
causes changes in the requirements. Recognition of
errors late in a project
does, therefore, often result in schedule and cost
overruns as well as poor product quality. To avoid
or decrease the above mentioned problems continous
verification and validation actives are very important.
The most frequently used methodologies are requirements
and design reviews, code inspection, walkthroughs,
program verification by module, acceptance and system
and integration testing.
1.3.4 I̲n̲c̲r̲e̲m̲e̲n̲t̲a̲t̲a̲l̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲
Incremental development is the approach by which the
sofware system is built up by adding only one single
new entity at a time to the previous baseline. Incremental
development can be initiated when preliminary design
is complete i.e. design structure/interfaces designed
and budgets for timing storage and accuracy etc. allocated.
The purpose of this concept is to develop and test
functional capabilities which are critical to the project
at an early stage in the project implementation and
, to increase visibility and manageriability of the
system integration activities.
2̲ ̲ ̲O̲V̲E̲R̲A̲L̲L̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲D̲A̲T̲A̲
The purpose of this chapter is to present the overall
project data and discuss these key data. The data which
are being discussed are: distribution of effort project
phase and calendar time respectively, productivity
and error detection data.
Furthermore, some general intrinsic project behavioural
patterns are discussed in order to improve the capability
to evaluate project status and forecasts.
The discussion will firstly address what the data indicate
and secondly the limitations of these data.
2.1 P̲R̲O̲J̲E̲C̲T̲ ̲E̲F̲F̲O̲R̲T̲ ̲A̲N̲D̲ ̲D̲I̲S̲T̲R̲I̲B̲U̲T̲I̲O̲N̲
2.2 P̲R̲O̲D̲U̲C̲T̲I̲V̲I̲T̲Y̲ ̲A̲N̲D̲ ̲E̲R̲R̲O̲R̲ ̲D̲E̲T̲E̲C̲T̲I̲O̲N̲ ̲D̲A̲T̲A̲
2.3 I̲N̲T̲R̲I̲N̲S̲I̲C̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲B̲E̲H̲A̲V̲I̲O̲U̲R̲
3̲ ̲ ̲S̲U̲B̲P̲R̲O̲J̲E̲C̲T̲ ̲P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲ ̲A̲N̲D̲ ̲D̲I̲F̲F̲E̲R̲E̲N̲C̲I̲E̲S̲
This chapter highlights the difference in performance
of the various subprojects and discusses data which
deviates significantly from the average in order to
substantiate the relevance of the data presented.
4̲ ̲ ̲P̲R̲O̲J̲E̲C̲T̲ ̲S̲T̲R̲A̲T̲E̲G̲Y̲ ̲I̲M̲P̲L̲E̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
The extent to which the project strategies have been
implemented compared with the ideal modules are being
discussed in this chapter based on the data presented
and analyzed in the above sections.
Til hvem det m>tte vedr]re
1984-11-15 KNN/vhn
Vedr.: Opg]relse over l]nindt`gter for Mark Chin i firmaet
Christian Rovsing A/S
-----------------------------------------------------------------
Mark Chins l]n for perioden fra 1. juli 1984 til 31. august
1984 har under hans ans`ttelse i firmaet Christian Rovsing A/S
v`ret som f]lger:
1. juli - 13. juli 84,00 timer …1a… kr. 81,00 =
kr. 6.804,00
16. juli - 31. juli 122,00 timer …1a… kr. 81,00 = kr. 9.882,00
1. august - 15. august 119,50 timer …1a… kr. 81,00 =
kr. 9.679,50
16. august - 31. august 52,50 timer …1a… kr. 81,00 =
k̲r̲.̲ ̲ ̲4̲.̲2̲5̲2̲,̲5̲0̲
Total kr. 30.618,00
=============
Denne l]n er eksklusiv feriepenge.
Med venlig hilsen
CHRISTIAN ROVSING A/S af 1984
Kurt Nybroe-Nielsen
Divisionschef
To: KNN
Fm: JAL
S̲u̲b̲j̲e̲c̲t̲:̲ ̲C̲a̲t̲e̲g̲o̲r̲y̲ ̲I̲ ̲p̲r̲o̲j̲e̲c̲t̲ ̲-̲ ̲C̲A̲M̲P̲S̲
Ref.: CPS-Intern Meddelelse 857
a) Total contract value at time of bankruptcy:
Mill. D.Kr. 303.93
See enclosure I.
b) Total remaining contract value:
Mill. D.Kr. 70.441
See enclosure II
c) Estimated cost to complete (option 5):
c1) DPO excl. hardware bought from the estate
Mill. D.Kr. 46.00
c2) Total costs before corporate overhead
Mill. D.Kr. 63.91
c3) Total costs before interest
Mill. D.Kr. 78.89
See enclosure III
d) Expected margin (option 5):
d1) Margin 1* Mill. D.Kr. 74.27
d2) Margin 2 Mill. D.Kr. 56.36
d3) Margin 3 Mill. D.Kr. 41.38
* Sales price option 5 Mill. D.Kr. 209.02
- DPO (c.1) Mill. D.Kr. 46.00
- travel + materials Mill. D.Kr. 22.73
- HW (Sales price - 25%) M̲i̲l̲l̲.̲ ̲D̲.̲K̲r̲.̲ ̲ ̲6̲6̲.̲0̲2̲
Mill. D.Kr. 74.27
e) Scope of effort involved (option 5):
SD effort 822 MM
ILS effort 4̲1̲5̲ ̲M̲M̲
TOTAL 1.237 MM
f) Schedule (option 5)
- Site provisional acceptance june 1986.
See enclosure V
g) Manpower requirements (option 5).
See e).
h) Other departments:
- ILS (Documentation, Training, Installation,
Site Provisional Acceptance, Warranty)
- PD (CR80 Equipment)
- DD (DAMOS Support & enhancements)
- QA (SW & HW QA)
i Budget:
- Subject to NATO approval.
Kind regards,
Jan Lauridsen
