Project Progress Report for the Delivery Phase

Project Progress Report for the Delivery Phase
SchemeStation documentation

1 The last phase

Having completed in essence all the required functionality of the system in the previous phase, the major programming tasks for this phase were testing, fixing bugs and tuning the performance. However, most of the attention was paid to completing the documentation. This included cross-inspecting all the documents once more, so that somebody else than the author of the document reviewed it. This revealed fair amount of typos and flaws.

We also put some effort in making the documentation as readable as possible. We made the headers appear smaller on Windows machines, added links in order to ease the navigation, recategorizated the documents and made the documentation available in both PostScript and plain text format in addition to the html format. Also, Final report: SchemeStation and Notes on Implementing the SchemeStation Security Paradigm in the SchemeStation Simulator were produced.

Testing got on as planned, focus mostly being on integration testing. In practice, we ran the SchemeStation with different configurations on different platforms executing as many different agents as possible. This gave us the possibility the develop the example agent at once. In fact, the debugging applied sometimes to the agents rather than the SchemeStation itself. However, we were still able to trace and eliminate some bugs in the actual system. Also, we used some time in commenting and cleaning up the code.

As the performance of the system still was not too stunning, we used some time for making modest optimatizations in the system. This meant rewriting part of the heap module, and reimplementing the virtual machine (now known as the VM2). We have no chance to make big changes such as replacing the interpreter-like virtual machine with a just-in-time-compiler, so no drastic improvements in performance can be expected. For future directions, however, see the Future Work section in Final report: SchemeStation.

New features added in this phase include remapping of network addresses, so that migrating agents don't have to receive their messages through every domain they´ve visited. This is a considerable performance gain in multi-domain (multi-cpu) configurations.

1.1 Summary of tasks completed in this phase

1.1.1 Programming

1.1.2 Documentation

1.2 Requirements updates

During the delivery phase we had also discussions with the client where we decided to change certain project requirements. These changes do not reflect resource shortages or project failures. They are necessary because some of the ideas at the beginning of the project have turned out to be unimportant, unnecessary, uninteresting, or impossible to implement. The following changes were agreed upon:

2 The result of the Project

The result of the project is analyzed in Final report: SchemeStation.

3 Used time resources

The work concerning the final demonstration of the project (including the presentations and the demonstration programs) in addition to document polishing took much more effort that anticipated. Overall, all the aspects of this final phase were little underestimated, perhaps due to the success of the previous phase.

Updated: 23.04 9:30 AHPHJKVHTotalPlannedDifference
Meetings 
Meetings8888   321616
Project management 
General management26     853
Programming 
Programming22161414   664026
Testing 
Testing18152612   714031
Documenting 
Documenting1320828   694029
System maintenance 
Maintenance1  1   220
Total64655663000248143105

4 Concerns, risk control

There is one true concern (which is not exactly a risk) left when considering the SchemeStation project: was it all worth the effort? This questions should be observed from the aspect of usage, that is, will there be anyone outside the project group that will use the system? This is something outside the scope of the project, but it puzzles the minds of the project team.

The last risk of the project itself is the demonstration event. It has been prepared carefully, but these kind of presentations tend to have the "Murphy's Law" -effect builtin. And how do we react to possible disasters during the presentation?