1 Status of the project

1.1 Overall

The rather aggressive schedule has, however, yielded a lot of ready code, see accomplished tasks.

The group has gathered together once a week, but sometimes the coordination might have needed tighter communication.

The roles of the group members have got clearer since the first phase, and every member has taken the necessary responsibility of the project. However, there should have been more control over the individual assignments to avoid unnecessary retro-actions. What this means in practice that some interfaces have not been discussed enough in public, causing a bit of rework and renegotiation.

The overall status of the project is at this stage encouraging: we are only a few days (1-3) behind the original schedule, and the pressure due to the course requirements is diminishing.

1.2 Schedule

The group has decided to start the coding fairly early. This along with the demanding documentation and planning tasks has resulted into a fairly tight schedule.

The resource allocation plan has been followed quite strictly, altough first difficulties have been encountered with the heap module. The resources allocated for implementing the heap proved to be too modest and some additional labour had to be attached to that task. This revealed that such difficulties with implementation have to be reported earlier to the project and process manager.

The group's internal aim is to accomplish a working prototype of the system with vm, compiler, assembler and heap integrated next week. There is a possibility to have the networking, addressing and messaging modules added to this prototype, too. !

As far as the next phase, implementation design, is concerned, it is well underway and should not cause any particular difficulties.

The criticism concerning the overaccuracy of the schedule has not been an issue; on the contrary, there has clearly been situations where even a more precise schedule would have helped to clarify the current status of the project.

1.3 Used time resources

Time resources used for the specification phase:

2.11.1997	Huima	Holländer	Kirma	Herva	total	Difference
Studying	8	3	2	0	13	-4
Lectures (course)	0	0	0	0	0	-8
Scheme	2	0	2	0	4	+3
Operating systems	0	2	0	0	2	-1
Compilers	6	1	0	0	7	+2
Project management	2	8	1	2	13	0
Task allocation & general	2	8	1	2	13	0
Specificating	10	6	6	20	42	+3
Meetings	11	6	6	7	30	-10
Intra-group	6	6	6	6	24	-8
With client and supervisor	5	0	0	1	6	-2
Documentating	7	7	5	11	30	+4
Project plan	0	2	0	2	4	0
Requirements	1	0	0	0	1	0
Specifications	6	5	5	5	21	+3
WWW-pages	0	0	0	4	4	+1
Host maintenance	1	1	0	1	3	+1
TOTAL	39	31	20	41	131	-7
Individual differences	+1	-10	-9	+11	-7

Altogether the schedule of this phase has been a success; but the individual time planning has not been very accurate, due to the fact that document production for this phase has been more demanding than estimated earlier. However, there is no reason to reschedule the project now, but more attention has to be paid to ensure proper work balance between team members.

2 Accomplished tasks

The project has continued with a lot of planning, design and implementation work. The architecture of the core system has been quite completely designed. The implementation of the core system has also begun, and a large partition of it has already been written. This includes

• the virtual machine
• the scheduler
• the heap with its garbage-collector and linearizer
• the compiler
• the assembler
• the event loop
• the networking module
• the messaging module (partly)
• the addressing module (partly)

Some of the documents on the specifications and the implementation of these modules have also been done:

• Virtual machine definition
• VM instruction numbers
• Networking Specification
• Virtual machine layout and interface definition
• Networking Specification
• Networking Implementation
• Heap layout
• Scheduler definition

  2.1 OS specification

  Much work has been done specifying the SCHEMESTATION Operating System [Operating system specification] although that is not part of the project as such.

  2.2 Functional specification

  The most important task in this phase has been the functional specification. The group has done a lot of work trying to documentate all the functionality the SCHEMESTATION simulation should provide. This is not easy, however, for an operating system simulation, and the recommentations on the courses homepage seem to have to been aimed mostly for a database application having a graphical UI (business application). It is not meaningful to describe either the UI or the database structure of an operating system.

  2.3 Code-browser and documentation tools

  The Code-Browser utility has been implemented up to stage. It is now capable of building the structural index of the C header files and scheme files, searching the index for a specified function or file, listing the functions (their definations and descriptions), fontifying the C code (scheme not yet ready) and making hyper text links from the include directives and function calls to corresponding header file. There is a more detailed document of the code browser: Code-Browser Utility.

  The builddocs script has been refined to automatically make documentation of header files (this is based on the code browser header index).

  3 Risk control

  The overall risk management is based on the observations of the team members; this has both positive and negative aspects: feedback is immediate but there can be blindness to some problem areas.

  So far there have been identified risks concerning the scheduling and some technical aspects of the design (or algorithms to be used). These have not been too severe and have been resolved. The scheduling will be very vulnerable to every kind of difficulties in the future as well -- the only way to address this is to maintain visibility to the schedule as clear as possible (very short individual tasks).

  The most critical identified risk/problem which almost resulted in a severe schedule overrun was a semi-published interface which was misunderstood. Hopefully the meaning of publishing interfaces and the discussions concerning them has been now understood.