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.
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.
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.
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:
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).
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 (
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.