top - download
⟦d26605e47⟧ Wang Wps File
Length: 33975 (0x84b7)
Types: Wang Wps File
Notes: SD/PRC/001
Names: »4499A «
Derivation
└─⟦61f87be83⟧ Bits:30006024 8" Wang WCS floppy, CR 0420A
└─ ⟦this⟧ »4499A «
WangText
…00……00……00……00……00……13……02……00……00……13…
…12……0c……12……0f……12… …11……08……11……0a……11……00……11……01……11……05……10……0c……10…
…10……06……0f……09……0f……0c……0f……00……0f……01……0f……06……0f……07……0e……08……0e……0d……0e……0e……0e……86…1 …02… …02… …02…
…02…SD/PRC/001
…02…JHO/840130…02……02…#
INTERNAL STATUS REPORTS
…02……02…SYS.DIV.
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
1 SCOPE ..........................................
4
2 STRUCTURE OF THE STATUS REPORT .................
5
3 DESCRIPTION AND EXAMPLES OF SHEETS .............
6
3.1 PROJECT STATUS .............................
6
3.1.1 Accomplishments ........................
6
3.1.2 Near Term Activities ...................
6
3.1.3 Problems/Issues ........................
7
3.1.4 Master Schedule ........................
8
3.1.5 Contractual Value ......................
10
3.1.6 Quotations or Extensions ...............
11
3.1.7 Budget and Account .....................
11
3.1.8 Manpower and Organization List .........
13
3.1.9 Used Manpower Resources ................
14
3.1.10 Contract Deliverables Status .........
16
3.2 FINANCIAL STATUS ...........................
18
3.2.1 Accumulated Invoiced Sales .............
18
3.2.2 Overdue Payments .......................
18
3.3 HARDWARE DEVELOPMENT AND FABRICATION .......
21
3.3.1 Development of Hardware Items ..........
21
3.3.2 Order Hardware Items ...................
23
3.3.3 Hardware Integration Status ............
25
3.3.4 Update of HW-baselines .................
27
3.4 SW DEVELOPMENT STATUS ......................
29
3.4.1 SW Development - Preliminary and
Detailed Design ........................
29
3.4.2 SW Development - Code and Unit Test and
Package Test ...........................
29
3.5 SYSTEM INTEGRATION AND TEST ................
34
3.6 ILS STATUS .................................
37
3.6.1 ILS-Installation .......................
37
3.6.2 ILS-Training ...........................
40
3.6.2 ILS-Documentation ......................
42
3.6.3 ILS-Maintenance ........................
44
3.6.4 ILS-Repair .............................
44
1̲ ̲ ̲S̲C̲O̲P̲E̲
The purpose of this procedure is to state the mandatory
requirements to the content and the layout for company
internal project status reports.
It is only acceptable to omit status report sheets,
when these are not applicable to the project concerned.
Additional report sheets may be used, when necessary
to describe essential subjects of the project status.
The project manager is responsible for preparation
of the status report. The status report shall be submitted
to the systems division manager on his request as part
of a formal monthly status report on the project.
2̲ ̲ ̲S̲T̲R̲U̲C̲T̲U̲R̲E̲ ̲O̲F̲ ̲T̲H̲E̲ ̲S̲T̲A̲T̲U̲S̲ ̲R̲E̲P̲O̲R̲T̲
The status report is structured into three parts:
- a verbal introduction with highlights of accomplishments
and near term activities
- a project status related to the project as a whole
concerning contract, finance and schedule
- a detailed status report concerning each of the
major items in the project: hardware, software,
system integration and integrated logistics support.
The purpose with this structure is to give a top-down
description of the status and to avoid too many details
in the beginning of the report.
The layout of the status report is fitted for a wordprocessor-system.
A monthly status report can be created from the last
one by an update of the wordprocessor-file. Only few
additional sheets with graphic status presentation
have to be updated by other means.
Appendix A includes a status report with blank sheets
to use f.i. for the first status report.
3̲ ̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲ ̲A̲N̲D̲ ̲E̲X̲A̲M̲P̲L̲E̲S̲ ̲O̲F̲ ̲S̲H̲E̲E̲T̲S̲
3.1 P̲R̲O̲J̲E̲C̲T̲ ̲S̲T̲A̲T̲U̲S̲
A verbal introduction to the project status shall give
the highlights of
- accomplishments
- near term activities
- problems/issues.
3.1.1 A̲c̲c̲o̲m̲p̲l̲i̲s̲h̲m̲e̲n̲t̲s̲
The accomplishment sheet shall describe the items accomplished
together with the dates. Only items related to the
contractual deliveries or to the customer should be
included and only, if they are accomplished in the
period covered by the status report.
An example of an accomplishment sheet is given in figure
3.1-1.
3.1.2 N̲e̲a̲r̲ ̲T̲e̲r̲m̲ ̲A̲c̲t̲i̲v̲i̲t̲i̲e̲s̲
The "near term activities"-sheet shall include the
activities related to the contract or the customer
1-2 months ahead.
The scheduled date for the completion of the activity
shall be included and - of course - be in accordance
with the detailed status.
A̲C̲C̲O̲M̲P̲L̲I̲S̲H̲M̲E̲N̲T̲S̲
Figure 3.1.1-1 Example of an accomplishment-sheet
described later on.
An example of a "near-term-activities-sheet" is given
in figure 3.1.2-1.
3.1.3 P̲r̲o̲b̲l̲e̲m̲s̲/̲I̲s̲s̲u̲e̲s̲
Major problems or issues having a considerable effect
on the progress of the project may be brought up, if
the decision has to be taken on or supported at a higher
level than the project manager level.
N̲E̲A̲R̲ ̲T̲E̲R̲M̲ ̲A̲C̲T̲I̲V̲I̲T̲I̲E̲S̲
Figure 3.1.3-1 Example of near-term-activities-sheet.
The problem/issue brought up shall be accompanied by
one or more suggestions to solve the problem.
The decisions made on the problems/issues listed are
the most important results of the status meetings.
They shall be covered in the minutes-of-meeting.
3.1.4 M̲a̲s̲t̲e̲r̲ ̲S̲c̲h̲e̲d̲u̲l̲e̲
The Master Schedule for the project shall describe
only the items defined in the contract, f.i. deliveries
or milestones for which the schedule only can be moved
by an update to the contract.
The schedule shall cover the entire period, the project
is running. The schedule shall reflect the contractual
agreed schedule. Updates not reflected in the contract
shall only be added as pen-and-ink changes to the schedule
with a different marking.
In appendix A a form for program schedules is shown:
It is not mandatory, that this form is used, if another
layout has the same content.
The schedule shown in the status report shall be updated
to the date of the status report. A comment to the
updates of the master schedule may be appropriate.
An example of the status report is shown in figure
3.1.4-1.
Figure 3.1.4 Example on a master schedule for a project.
3.1.5 C̲o̲n̲t̲r̲a̲c̲t̲u̲a̲l̲ ̲V̲a̲l̲u̲e̲
In order to keep track of the contract value, the different
amendments or letter-of-intents shall be listed together
with the acceptance dates and the contract value (preferably
in D.kr.).
If several contracts are running together in the department,
the total of all contracts should be given.
The purpose of the list is to evaluate the sales activity
in form of amendments and extensions to existing contracts.
Furthermore the contract value is used in the calculation
of work-in-progress.
An example of a status sheet for the contractual value
is given in figure 3.1.5-1.
Figure 3.1.5-1 Example on contractual status sheet.
3.1.6 Q̲u̲o̲t̲a̲t̲i̲o̲n̲s̲ ̲o̲r̲ ̲E̲x̲t̲e̲n̲s̲i̲o̲n̲s̲
For each project a list of submitted or requested quotations,
options in the contract together with possible extensions
should be listed.
If the subject is a submitted quotation or an option
in the contract the validity date should be stated.
The purpose of the list is to estimate the future sales
and to support the activities of the marketing department.
An example of a "quotation or extension"-list is given
in figure 3.1.6-1.
Q̲u̲o̲t̲a̲t̲i̲o̲n̲s̲ ̲o̲r̲ ̲p̲o̲s̲s̲i̲b̲l̲e̲ ̲e̲x̲t̲e̲n̲s̲i̲o̲n̲s̲:
Relay Function 3,727,054
SW Development System 7,553,757
Test Drive System 14,120,925
In Circuit Test Programs 1,396,736
MSPs for SW dev. ̲3̲,̲5̲0̲0̲,̲0̲0̲0̲
Total 30,298,472
Figure 3.1.6-1 Example on a "Quotations or extension"-list.
3.1.7 B̲u̲d̲g̲e̲t̲ ̲a̲n̲d̲ ̲A̲c̲c̲o̲u̲n̲t̲
For each project the financial status of the project
should be presented.
The output from the CRAS' finance system has to be
included directly. Major deviations between accounts
and budgets has to be commented.
Two tables have to be presented and commented:
First the budget and the accounts for the project from
start of year until now. Each of the 8 keyfigures in
the budget should be compared and commented.The purpose
of the table is to evaluate if the performance during
the financial year is in accordance with the budgetted
values.
The second table presents the total financial project
status from the beginning of the project with revised
cost-to-complete until end-of-project.
The purpose of the second table is to evaluate the
overall project performance. The effect of dispositions
this year may first occur next year.
All deviations between last budget and the new budget
have to be explained.
Examples of the two tables are given in figure 3.1.7-1
and figure 3.1.7-2.
Budget Account Comment
Period: xx.xx - xx.xx 1000 Dkr. 1000 Dkr.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Net Sales
- D̲i̲r̲e̲c̲t̲ ̲P̲r̲o̲d̲u̲c̲t̲i̲o̲n̲ ̲C̲o̲s̲t̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
= M̲a̲r̲g̲i̲n̲a̲l̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
- Sales & Distribution Costs
- G̲e̲n̲e̲r̲a̲l̲ ̲&̲ ̲A̲d̲m̲i̲n̲i̲s̲t̲r̲a̲t̲i̲v̲e̲ ̲C̲.̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
= N̲e̲t̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲R̲e̲s̲u̲l̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
C̲a̲p̲i̲t̲a̲l̲ ̲C̲o̲s̲t̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
N̲e̲t̲ ̲I̲n̲c̲o̲m̲e̲ ̲b̲e̲f̲o̲r̲e̲ ̲T̲a̲x̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Comments:
Figure 3.1.7-1 Budget and Account cumulated this year
Period: Total Project
Revised
Budget Budget Comment
1000 Dkr. 1000 Dkr.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Net Sales
- D̲i̲r̲e̲c̲t̲ ̲P̲r̲o̲d̲u̲c̲t̲i̲o̲n̲ ̲C̲o̲s̲t̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
= M̲a̲r̲g̲i̲n̲a̲l̲ ̲C̲o̲n̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
- Sales & Distribution Costs
- G̲e̲n̲e̲r̲a̲l̲ ̲&̲ ̲A̲d̲m̲i̲n̲i̲s̲t̲r̲a̲t̲i̲v̲e̲ ̲C̲.̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
= N̲e̲t̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲R̲e̲s̲u̲l̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
- C̲a̲p̲i̲t̲a̲l̲ ̲C̲o̲s̲t̲s̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
= N̲e̲t̲ ̲I̲n̲c̲o̲m̲e̲ ̲b̲e̲f̲o̲r̲e̲ ̲T̲a̲x̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Figure 3.1.7-2 Revision of Total Project Budget
3.1.8 M̲a̲n̲p̲o̲w̲e̲r̲ ̲a̲n̲d̲ ̲O̲r̲g̲a̲n̲i̲z̲a̲t̲i̲o̲n̲ ̲L̲i̲s̲t̲
The purpose of the list is to define the persons assigned
to the project and their responsibilities in the organization
of the project. Especially should the different managers
in the project be clearly defined. The managers f.i.
as in the example figure 3.1.8-1 be marked by underlining.
If the persons only are working parttime or on consultancy
basis on the project in the period concerned, the monthly
workload should be stated by a percentage.
Figure 3.1.8-1 Example on Manpower & Organization List.
3.1.9 U̲s̲e̲d̲ ̲M̲a̲n̲p̲o̲w̲e̲r̲ ̲R̲e̲s̲o̲u̲r̲c̲e̲s̲
The use of manpower resources should be followed every
month for each of the line items at the highest level.
The use of manpower resources every year until now
should be stated too.
The use of manpower resources this year "until now"
should be compared with the budget for use of manpower
resources this year until now.
The purpose of the table is to evaluate if a delay
in schedule is caused by missing manpower. An example
of the report is shown in figure 3.1.9-1.
Figure 3.1.9-1 Example on "used manpower resources".
For the system engineering manpower and software development
manpower a split in the different phases is appropriate.
The table with "planned and actual resources used to
establish functional baselines and software development"
is in accordance with the estimation process used in
software development. Based on experience the estimation
of cost-to-
complete can be done more accurate for this especially
risky part of a project.
An example of a table with actual resources is given
in figure 3.1.9-2.
Figure 3.1.9-2
Example on "Actual resources used to establish baselines."
3.1.10 C̲o̲n̲t̲r̲a̲c̲t̲ ̲D̲e̲l̲i̲v̲e̲r̲a̲b̲l̲e̲s̲ ̲S̲t̲a̲t̲u̲s̲
The purpose with the list of contract deliverables
is to give the status of each deliverable defined in
the contract. The table should state
- the line item,
- the subject and the dates for
- scheduled delivery
- actual delivery
- submittal to customer
- for approval by customer, and
- invoice forwarded.
Comments to the status could be added. Only deliverables
where the customer is contractual involved by some
sort of approval or by a payment should be included
in the list.
If approval is not applicable to a delivery before
invoicing or if a payment is not connected to the delivery,
these facts should be marked on the list.
An example on a list is given in figure 3.1.10-1.
Figure 3.1.10-1
Example on a contract deliverables status list.
3.2 F̲I̲N̲A̲N̲C̲I̲A̲L̲ ̲S̲T̲A̲T̲U̲S̲
A more detailed description concerning the financial
status shall be submitted. The status reports should
be based on the reports from the CRAS' finance system,
but at least two tables are mandatory:
- accumulated invoiced sales and
- overdue payments.
3.2.1 A̲c̲c̲u̲m̲u̲l̲a̲t̲e̲d̲ ̲I̲n̲v̲o̲i̲c̲e̲d̲ ̲S̲a̲l̲e̲s̲
In a graphic presentation the accumulated invoiced
sales (the actual cash flow) shall be plotted for the
actual year. For each month the following accumulated
values for the project shall be plotted:
- budgetted invoiced sales
- actual invoiced sales
- actual paid amounts.
The purpose with the figure is to control that the
actual invoicing follows the budget and to control
that the payment follows the invoicing.
An example is shown in figure 3.2.1-1.
3.2.2 O̲v̲e̲r̲d̲u̲e̲ ̲P̲a̲y̲m̲e̲n̲t̲s̲
A list of o̲v̲e̲r̲d̲u̲e̲ payments from the customer shall
be submitted. The list shall contain
- invoice number
- invoice date
- due date
- unpaid amount
- items covered by the invoice.
Comments concerning customer arguments for withholding
payment may be added.
An example is shown in figure 3.2.2-1.
FIGURE 3.2.1-1
Budgetted and actual cash flow.
Figure 3.2.2-1.
Overdue Payments
3.3 H̲A̲R̲D̲W̲A̲R̲E̲ ̲D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲A̲N̲D̲ ̲F̲A̲B̲R̲I̲C̲A̲T̲I̲O̲N̲
The hardware part of a project has different phases:
- develop new items or systems
- order hardware items
- integrate and test the hardware
- update of baselines (engineering change orders).
For each of these phases one or more status sheets
shall be used.
3.3.1 D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲o̲f̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲ ̲I̲t̲e̲m̲s̲
For all HW items where the development is controlled
by the project, a status list should be submitted.
The standard phases to be controlled are:
- product specification
- technical manual
- reliability report
- critical design review
- test procedures
- test report
- factory qualification test procedure
- factory test report
- serie 0 release
- functional test release 0
- release for production.
Completion or scheduled completion should be marked
on the list. If a more detailed report is necessary
to describe the actual status, other subjects may be
added to the list.
An example of a status report for development of HW
is given in figure 3.3.1-1.
Figure 3.3.1-1 Example on status on development of HW.
3.3.2 O̲r̲d̲e̲r̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲ ̲I̲t̲e̲m̲s̲
For all HW-items ordered at subcontractor a status
list shall be submitted. A̲l̲l̲ items with a lead time
on more than 1 month or with a unit price on more than
1500 Kr. shall be included in the list. Even if the
items are not yet ordered at the subcontractor, they
shall be included too.
The list shall cover the following subjects:
- name on subcontractor
- name of item
- number ordered by the customer under the contract
- number ordered at subcontractor
- number received by the project
- number accepted by incoming inspection and - if
applicable - certificate of conformance by QA
- number invoiced to the customer.
The purpose of the list is to give the status of the
hardware deliveries before the hardware is integrated
and tested.
A comment sheet may be attached to the order status.
An example is given in figure 3.3.2-1.
Figure 3.3.2-1 Example on HW order status.
3.3.3 H̲a̲r̲d̲w̲a̲r̲e̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲i̲o̲n̲ ̲S̲t̲a̲t̲u̲s̲
The hardware integration status for all systems gives
an overview for each system of
- hardware delivered to integration (yes or no) perhaps
with comments on missing hardware
- total no. of test cases in the integration and
acceptance testing
- number of test cases completed successfully
- scheduled date for factory acceptance testing
- completion date for factory acceptance testing
- date for submittal of FAT report
- date for approval of FAT report by the customer.
This sheet will give an overview over all systems to
be integrated.
If only the integration status of one system is to
be described, a graphic presentation as shown in figure
3.3.3-1 may be used.
Figure 3.3.3-1
3.3.4 U̲p̲d̲a̲t̲e̲ ̲o̲f̲ ̲H̲W̲-̲b̲a̲s̲e̲l̲i̲n̲e̲s̲
During incoming inspection or factory acceptance test
the hardware is tested according to a certain baseline.
If, at a later point in time, an error is detected
causing an engineering change order (eco) the baseline
has to be changed for all items.
The purpose with this report is to present the status
of the update process for the hardware items.
The list shall cover only those hardware items, which
are
- not yet baselined,
- erroneous i.e. with a pending eco,
- with an eco submitted,
- or in an update process.
For each item the list shall contain:
- the date for issue of eco
- the date for update of internal documentation
- submittal date of ecp to customer
- date of approval of ecp by customer
- submittal date of the updated version of the system
design to the customer
- number of modules affected by the eco
- number of modules already updated.
An example is given in figure 3.3.4-1.
Figure 3.3.4-1 Example of an update of HW-baselines
3.4 S̲W̲ ̲D̲E̲V̲E̲L̲O̲P̲M̲E̲N̲T̲ ̲S̲T̲A̲T̲U̲S̲
The software development is divided into several phases:
- preliminary design
- detailed design
- code and unit test
- package test
For each of these phases one or more status sheets
shall be used.
3.4.1 S̲W̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲-̲ ̲P̲r̲e̲l̲i̲m̲i̲n̲a̲r̲y̲ ̲a̲n̲d̲ ̲D̲e̲t̲a̲i̲l̲e̲d̲ ̲D̲e̲s̲i̲g̲n̲
The status sheets for the preliminary and the detailed
design phases may be the same. For each workpackage
(WP) the size of the work, f.i. in number of typed
pages shall be described. The following shall be described:
- the original plan
- the latest plan
- the status of the draft
- the status of typing
- no. of pages reviewed in critical design reviews
- no. of pages updated and completed in design.
All items shall be added to a total.
3.4.2 S̲W̲ ̲D̲e̲v̲e̲l̲o̲p̲m̲e̲n̲t̲ ̲-̲ ̲C̲o̲d̲e̲ ̲a̲n̲d̲ ̲U̲n̲i̲t̲ ̲T̲e̲s̲t̲ ̲a̲n̲d̲ ̲P̲a̲c̲k̲a̲g̲e̲ ̲T̲e̲s̲t̲
The code and unit test may be followed in the same
way through the different working phases.
Each workpackage may be described in the unit kilo-lines-
of-code (kloc) under the headlines:
- originally planned
- latest plan
- coded
- tested
- subpackage integrated and tested
- package integrated and tested
- system integrated and tested.
A total of all workpackages should be calculated for
each column.
An example is shown in figure 3.4.2-1.
A graphic presentation of the same information showing
the development over the time shall be added too. See
example figure 3.4.2-2.
To support the status of the testing the SW development
status shall be described in number of test cases too.
For each workpackage the number of test cases
- originally planned
- latest planned
- completed successfully
shall be described in each of the phases:
- subpackage integration and test
- package integration and test
- system integration and test.
A total for each column shall be calculated too.
The status of the update of the SW documentation may
be described as in the example figure 3.4.2-3.
Figure 3.4.2-1 Example on SW Development Status
Figure 3.4.2-2 Example on SW Development Status Graphics
Figure 3.4.2-3
Example on Update of SW As-Built Documentation
3.5 S̲Y̲S̲T̲E̲M̲ ̲I̲N̲T̲E̲G̲R̲A̲T̲I̲O̲N̲ ̲A̲N̲D̲ ̲T̲E̲S̲T̲
The phase: System Integration and Test shall be followed
by the status of the test cases and on the error statistics.
For each testgroup the total number of test cases shall
be defined together with the number of test cases executed
successfully.
A total shall be given of all test cases.
An example of this table is given in figure 3.5-1.
The error statistics shall include only the software
under configuration control and submitted to system
integration and test.
The table shall be given for a defined period (a week,
a month, etc.).
For each package the following shall be reported:
- the no. of errors detected
- the no. of errors correcting
- the no. of errors outstanding at the end of the
period
- the accumulated no. of errors.
A total shall be calculated, as an acceptance test
may be connected to a limit on this number.
A graphic presentation may be as in figure 3.5-2.
Figure 3.5-1
Example of System Integration and Test Status
Figure 3.5-2
Example on SW Error Statistics
3.6 I̲L̲S̲ ̲S̲T̲A̲T̲U̲S̲
Integrated Logistics Support will submit status reports
for each of the contract line items
- installation
- training
- documentation
- maintenance
- repair.
3.6.1 I̲L̲S̲-̲I̲n̲s̲t̲a̲l̲l̲a̲t̲i̲o̲n̲
The status report shall for each site describe the
scheduled dates for
- submittal of civil work requirements
- as-to-be-built drawings
- delivery of cables etc.
- site verification before site installation
- site installation start
- site acceptance test start.
A special signature shall be given, if the item has
been submitted and, if it has been accomplished and
accepted.
Comments may be added to the list.
An example is shown in figure 3.6.1-1.
If not covered by the master schedule a schedule for
the installation shall be included too.
An example is shown in figure 3.6.1-2.
Figure 3.6.1-1.
Example on Site Implementation Milestones.
Figure 3.6.1-2
Example on Installation Schedule
3.6.2 I̲L̲S̲-̲T̲r̲a̲i̲n̲i̲n̲g̲
The status report of Training shall be divided into
two sheets.
The first one shall for each course given the status
of all training material necessary before start of
training. The second one is the schedule of all courses
shown together.
The first sheet shall describe the scheduled dates
of:
- preliminary version (PV) submitted
- customer comments on PV
- final version (FV) submitted
- FV approved
- FV printed.
A special signature shall be used if the item has been
accomplished.
An example on a training schedule is shown in figure
3.6.2-1.
Figure 3.6.2-1
Training Schedule
3.6.2 I̲L̲S̲-̲D̲o̲c̲u̲m̲e̲n̲t̲a̲t̲i̲o̲n̲
The status report shall for each documentation item
describe the scheduled dates for
- submittal of preliminary version (PV)
- comments from customer on PV
- submittal of final version (FV)
- FV approved
- FV printed.
A special signature shall be given, if the item has
been accomplished.
An example of another version of the documentation
status report is given in figure 3.6.2-1.
On overdue items a remark shall be made.
Figure 3.6.2-1
Example on Status of Documentation
3.6.3 I̲L̲S̲-̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
For maintenance documentation the same status sheet
shall be used as for documentation, i.e. scheduled
dates for:
- submittal of PV
- comments from customer on PV
- submittal of FV
- FV approved
- FV printed,
and a special signature, if the item has been accomplished.
3.6.4 I̲L̲S̲-̲R̲e̲p̲a̲i̲r̲
The status of the Repair function shall be divided
into two sheets:
- repair before customer warranty
- repair under customer warranty.
The report submitted shall cover a defined period.
For each HW item the status of no. of items
- incoming to repair
- repaired
- on stock unrepaired ultimo
- out-of-house for repair,
shall be given.
APPENDIX
Draft Status Report
STATUS REPORT
............................ (project)
FOR
............................. (period)
Date:
Issued by:
A̲C̲C̲O̲M̲P̲L̲I̲S̲H̲M̲E̲N̲T̲S̲
Item: Date:
P̲R̲O̲B̲L̲E̲M̲S̲/̲I̲S̲S̲U̲E̲S̲
Problem/Issue: Suggested Actions:
N̲E̲A̲R̲ ̲T̲E̲R̲M̲ ̲A̲C̲T̲I̲V̲I̲T̲I̲E̲S̲
Activity: Date:
PROJECT STATUS
including
o Master Schedule
o Contract Status
o Quotations or Extentions
o Budget Status this year
o Man-power List
PROGRAM SCHEDULE
CONTRACTUAL
VALUE
FOR
...........
̲ ̲ ̲A̲m̲e̲n̲d̲m̲e̲n̲t̲ ̲o̲r̲ ̲l̲e̲t̲t̲e̲r̲-̲o̲f̲-̲i̲n̲t̲e̲n̲t̲ ̲ ̲ ̲ ̲ ̲ ̲D̲a̲t̲e̲ ̲ ̲ ̲ ̲ ̲ ̲C̲o̲n̲t̲r̲a̲c̲t̲ ̲V̲a̲l̲u̲e̲ ̲ ̲ ̲ ̲ ̲
Orig. contract
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Total contract
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Q̲u̲o̲t̲a̲t̲i̲o̲n̲s̲ ̲o̲r̲ ̲E̲x̲t̲e̲n̲s̲i̲o̲n̲s̲
̲ ̲S̲u̲b̲j̲e̲c̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲V̲a̲l̲i̲d̲i̲t̲y̲ ̲D̲a̲t̲e̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲A̲p̲p̲r̲.̲ ̲V̲a̲l̲u̲e̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Total Value
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
B̲u̲d̲g̲e̲t̲ ̲a̲n̲d̲ ̲A̲c̲c̲o̲u̲n̲t̲
D̲a̲t̲e̲:̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
P̲r̲o̲j̲e̲c̲t̲:̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
P̲e̲r̲i̲o̲d̲:̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Budget Account Comment
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲0̲0̲0̲ ̲D̲k̲r̲.̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲0̲0̲0̲ ̲D̲k̲r̲.̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Net Sales
- Direct Production Costs
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
= Marginal Contribution
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
- Sales & Distr. Costs
- General & Adm. Costs
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
= Net Operating Result
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
- Capital Cost
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
= Net Income before Tax
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
C̲o̲m̲m̲e̲n̲t̲s̲:̲
B̲u̲d̲g̲e̲t̲ ̲S̲t̲a̲t̲u̲s̲
D̲a̲t̲e̲:̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
P̲r̲o̲j̲e̲c̲t̲:̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
P̲e̲r̲i̲o̲d̲:̲ ̲T̲o̲t̲a̲l̲ ̲P̲r̲o̲j̲e̲c̲t̲
Revised
Budget Budget Comment
dated dated
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲0̲0̲0̲ ̲D̲k̲r̲.̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲1̲0̲0̲0̲ ̲D̲k̲r̲.̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Net Sales
- Direct Production Costs
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
= Marginal Contribution
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
- Sales & Distr. Costs
- General & Adm. Costs
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
= Net Operating Result
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
- Capital Cost
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
= Net Income before Tax
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
C̲o̲m̲m̲e̲n̲t̲s̲:̲
M̲a̲n̲p̲o̲w̲e̲r̲ ̲L̲i̲s̲t̲
P̲r̲o̲j̲e̲c̲t̲:̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
D̲a̲t̲e̲:̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
P̲R̲O̲J̲E̲C̲T̲ ̲M̲A̲N̲A̲G̲E̲R̲:̲
S̲E̲C̲R̲E̲T̲A̲R̲I̲A̲T̲
H̲A̲R̲D̲W̲A̲R̲E̲
S̲Y̲S̲T̲E̲M̲ ̲E̲N̲G̲I̲N̲E̲E̲R̲I̲N̲G̲
S̲O̲F̲T̲W̲A̲R̲E̲
I̲L̲S̲-̲T̲R̲A̲I̲N̲I̲N̲G̲
I̲L̲S̲-̲I̲N̲S̲T̲A̲L̲L̲A̲T̲I̲O̲N̲
I̲L̲S̲-̲M̲A̲I̲N̲T̲E̲N̲A̲N̲C̲E̲
I̲L̲S̲-̲D̲O̲C̲U̲M̲E̲N̲T̲A̲T̲I̲O̲N̲
U̲S̲E̲D̲ ̲M̲A̲N̲P̲O̲W̲E̲R̲ ̲R̲E̲S̲O̲U̲R̲C̲E̲S̲ ̲(̲M̲M̲)̲
P̲r̲o̲j̲e̲c̲t̲:̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Used this Budget this
year until year until
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲Y̲e̲a̲r̲/̲P̲e̲r̲i̲o̲d̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲n̲o̲w̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲n̲o̲w̲ ̲ ̲ ̲
Program Management
Systems Engineering
H/W Development
S/W Development
Fabrication
Installation
Acceptance
Logistics
Documentation
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Total
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Accumulated
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
P̲L̲A̲N̲N̲E̲D̲
A̲N̲D̲
A̲C̲T̲U̲A̲L̲
R̲E̲S̲O̲U̲R̲C̲E̲S̲
used to establish Functional Baselines and Software Development.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Planned % Actual use
(pr. ) (pr. )
Requirements Baseline
Systems Design Baseline
Preliminary Design
Detailed Design
Code and Unit Test
Package Integration
System Integration
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Total 100%
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
C̲o̲n̲t̲r̲a̲c̲t̲ ̲D̲e̲l̲i̲v̲e̲r̲a̲b̲l̲e̲s̲ ̲S̲t̲a̲t̲u̲s̲
Date Comments
̲L̲I̲ ̲ ̲S̲u̲b̲j̲e̲c̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲S̲c̲h̲e̲d̲u̲l̲e̲d̲ ̲ ̲ ̲S̲u̲b̲m̲i̲t̲t̲e̲d̲ ̲ ̲ ̲A̲p̲p̲r̲o̲v̲e̲d̲ ̲ ̲ ̲I̲n̲v̲o̲i̲c̲e̲d̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
C̲o̲m̲m̲e̲n̲t̲s̲:
