During the prototype I phase of the project, the project group was split in two teams, one of which continued working on the C source, while the other began to implement the standard scheme library. The C source team has mainly completed the core system. The core system has mainly been tested in per unit manner, and the integration testing has also begun.
The group has managed to have a meeting once week after the Christmas holidays (over one month break in development). The meetings have proved crucial in keeping the project in schedule. Keeping track of the statusof the tasks would be impossible without regular meetings.
Before the deadline, we had to compromise the planned division in sub-groups, and reorganize the labour in order to get the C source related tasks --- mostly testing --- done. Also, writing the manual and test reports was done extensively by the whole group.
We have reached the internal milestone we set -- the core system has been tested and the scheme standard library has been almost completed. There are some (new or otherwise not so important) modules that have not yet been tested. Also, as the idea of separate integration and system testing has become more and more artificial -- it may well be, that the integration and system testing facilities are the same, only the targetting is different -- the integration testing has not yet been finished (note: the system has been integrated, and it is used as a platform for the actual schemestation development. Therefore, it is constantly under informal testing.).
At this point in time the project is on schedule; the integration of the units is almost tested, most of the core modules are tested. The implementation scheme standard library has almost been completed and the documentation is close to the state planned for this phase. The required features of this second spiral have been specified and mostly designed.
The coding started at the early stage of the project. This has proven to be the right choice; we have both been able to implement the core system and gather a fair amount information and experience for designing the rest of the system.
This phase started quite well, because of the Christmas holidays, but the work has intensified towards the deadline. We have had some problems balancing the workload, as the individual resources are not uniform (and the project group members participate in other projects too).
The amount of work done in this phase exceeded the amount scheduled. This was something that we could expect, and like in the previous phases, the extra time was spent documenting, testing and documenting the tests.
| 16.2.1998 | Huima | Holländer | Kirma | Herva | total | Difference |
|---|---|---|---|---|---|---|
| Studying | 0 | 0 | 0 | 0 | 0 | -8 |
| Meetings | 8 | 6 | 6 | 6 | 26 | 0 |
| Project management | 2 | 3 | 0 | 1 | 6 | -4 |
| Specificating | 5 | 0 | 0 | 0 | 5 | +3 |
| Designing | 7 | 3 | 1 | 5 | 16 | +6 |
| Coding | 30 | 15 | 8 | 20 | 73 | +33 |
| Testing | 20 | 25 | 6 | 17 | 58 | +13 |
| Documenting | 25 | 17 | 2 | 30 | 74 | +42 |
| Host maintenance | 1 | 1 | 0 | 1 | 3 | 0 |
| TOTAL | 98 | 70 | 23 | 80 | 271 | +85 |
| Individual differences | +51 | +22 | -22 | +34 | +85 |
Writing the manual seemed somewhat inconvenient forehand --- what to say about an user interface that has not yet been completely planned nor implemented? However, we chose to bravely start writing and after sketching the table of contents, we actually realized, that most of the parts could be written already. The result may prove inaccurate when the project gets on, but the needed modifications should not be too huge.
Anyhow, we believe that the resulting manual is comprehensive enough --- one has to take consideration the nature of our project also. For an OS it not easy to "accurately describe ALL the input and outputs" the system might produce, nor is it easy to describe all the error situations one might run into.
The persons responsible of specifying, planning and implenting the module were also responsible for planning and testing it. For every major module a test case file were produced that executed the functions within that module, and checked wheter the results were sane. For each module, a test report was written, also. These per module reports were summed together in the SCHEMESTATION test report document.
During this phase, the risk managing plans we had made in the early phases of the documentation proved insuffiecient. The risk managing plan did not take in concideration the possibility of a traffic strike (or any other "Force Majeur" events) that did in fact occur and halted the traffic between Otaniemi and Helsinki, which was lethal for the plan of doing some work home also.
When it comes to the last two phases of the project, a decision has been made not to add any significant features after February. This feature freeze deadline is a part of the two-phase spiral development model. Another deadline is the end of March, which should denote the end of development of the freezed feature set. This would result in a situation where we would have the whole of April to test, document and polish the product.
Risk control has now also been extended to priorization of the project goals. This implies that we have a list of features that can be omitted in case of emergency (e.g. missing one of the previously mentioned internal deadlines).
This list is in reverse priority order:
These are the remaining tasks of the SCHEMESTATION project, presented not in any particular order: