Project plan - SchemeStation

Document formatted by vherva at Fri Apr 24 11:23:50 1998 on the host schemestation. This document is produced by the SchemeStation project during the Tik-76.115 course.

1 Introduction
1.1 General description
	The SCHEMESTATION project involves designing and implementing a prototype of a new distributed agent-oriented operating system carrying the name of the project. The main use of the finished prototype is to be scientific research. The prominent objective of creating the prototype is to provide an environment for experimenting with distributed agent-based operating systems.
1.2 The Aim of The Project
	The objective of this project is to produce a SCHEMESTATION simulator, main purpose of which is scientific research. The SCHEMESTATION operating system is a proposed agent/actor-based distributed operating system with the following features: persistent actors transparent migration of actors high level of abstraction trust-based security structure
1.2.1 A Brief Description of the SCHEMESTATION System
	The system includes a compiler that produces assembly language code. The assembler module producer bytecode that can be executed in the virtual machine. The instruction set is especially designed to suit this system. Every actor has a heap that includes the executable code and data - the actor sees no other addresses but those in its own heap. There are garbage collector and linealizer -modules to deal with the heap. Linearizing means a bytestring equivalent of the heap. More precice information can be found in Terminology specifications and in Project requirements specification. Every actor has an unique name inside a domain (a domain consists normally of one virtual machine). The actors can transparently migrate from domain to domain (the actor has no way of finding out in what domain it currently resides). This is done through the networking module that implements a packet oriented communication protocol. The security system along the domains is trust based.
1.2.2 The SCHEMESTATION Implementation In This Project
	In this project, a prototype of this operating system is built on the top of a UNIX environment. More specifically, a simulator is designed that runs as a set of UNIX user-level processes. The UNIX system to be used for development is Linux (with Debian distribution). However, the system should be easily portable to most major UNIX systems in order to make the system useful for research in heterogenous environments. Networking will be implemented on top of TCP/IP (socket API).
1.3 The Members of the Project
1.3.1 The Client
	Heikki Saikkonen, Heikki.Saikkonen@hut.fi
1.3.2 Project supervisor
	Mikko Tiusanen, Mikko.Tiusanen@hut.fi
1.3.3 The group
	Email: schemestation@schemestation.cs.hut.fi WWW: http://schemestation.cs.hut.fi/
1.3.4 Project manager
	Antti Huima Email: antti@schemestation.cs.hut.fi Tel. +358-9-468 3157 WWW: http://www.niksula.cs.hut.fi/~ahuima/
1.3.5 Process manager
	Petteri Holländer Email: pete@schemestation.cs.hut.fi Tel. +358-50-529 4570 WWW: http://www.iki.fi/pete/
1.3.6 Testing manager
	Jari Kirma Email: jkirma@schemestation.cs.hut.fi Tel. +358-9-468 2524 WWW: http://vulcan.tky.hut.fi/kirma/
1.3.7 Documentation manager
	Ville Herva Email: vherva@schemestation.cs.hut.fi Tel. +358-50-51 64 500 WWW: http://www.iki.fi/v/
1.4 The Rights to the Result of This Project
	In this paragraph the word "product" refers to the implementation and documentation of the system resulting from the project plus the intellectual property linked with it, including the abstract design of the system. Full rights to the product are owned equally by all the individual project members, and the Laboratory of Information Processing Science in Helsinki University of Technology with the following clarifications: These rights do not include any commercial usage of the project; commercial rights will be discussed later elsewhere. The same terms about rights apply to all direct derivatives of the product. These rights are not exclusive. Full rights to a derivative can be owned by someone else ALSO. Note, that the commercial usage of any derivative is not discussed here. Concerning the original product or any direct derivatives of it, an announcement of these rights and terms must be present in source code, documentation and applications. A direct derivative of the product is a computer application or any amount of computer code that shares code with the product, except for source code that was incorporated into the product from outside the project and is available outside the product. Any party mentioned here is allowed to surrender his or her rights to the product or any of its direct derivatives if he or she wishes so. Any party mentioning here owning full rights to the product or a direct derivate of it is allowed to transfer these full rights to a third party. Note, however, that commercial usage is not discussed here. The full rights to the product include but are not limited to the following rights: right to use the product for any non-commercial usage right to create direct or other derivatives of the product right to distribute it freely and grant full rights to it to third parties Concerning any scientific publications that might concern the product or the project, the following applies: If a publication is about the product itself and its main topic is describing the design of the product or any other aspect of it, then the publication may be published, submitted to a conference etc. only if the original project members agree. Publishing other kinds of publications linked to the product is not restricted.
2 Project phases
2.1 Project design (16.9. - 13.10.)
	This phase involves planning the resource allocation.
2.1.1 Tasks
	Ensuring that all project members are fully aware of the requirements of the project. This is assured by discussing the planned system in detail in the first meeting of the group. Sketching the preliminary system structure. Result of this event will be a figure of the system and its main modules. The figure is sketched in the first meeting. Having the first meeting with the client to establish a consensus on the aims of the project. The client will be shown a draft of the project requirement specification. During this meeting the group, the supervisor, and the client will agree on the project aims. Deciding what tools are used during the project. This includes for example agreeing on the implementation language and the underlying operating system. These decisions are made in the firsts and the second meeting of the group. Allocating the tasks tentatively. The process manager makes a proposal which will be discussed and accepted in the first meeting. Defining the coding policy and documentation discipline. The project manager makes a proposal which will be discussed and accepted in the first meeting. Acquiring the necessary resources These include the host machine, operating system, compilers and other necessary and convenient tools. The responsible person are chosen in the first meeting. Installing the development environment The responsible persons are chosen in the first meeting. Writing the project plan and the requirement specification. The documentation manager is responsible for this task; he is aided by the process mananer and the project manager.
2.1.2 Documentation
	Project plan - SchemeStation Documentation manager Project requirements specification Project manager, Documentation manager Project Progress Report for the Prototype II Phase Documentation manager
2.2 Specification (14.10. - 3.11.)
2.2.1 Tasks
	Making the task allocation decisions. The process manager makes the necessary adjustments in the task allocation plan along with the other group. Allocating tasks in too fine details is naturally impossible, and the process manager makes adjustments if needed. Defining the particular functional requirement of the system as a whole. This essentially involves refining the requirement specification paper and sketching the interfaces. The documention manager is responsible of this. Defining the system performance requirements: speed, effiency, hardware requirements. The project manager and the documentation manager will make these notes in the requirement specification paper. Defining the system structure and its elements. However, it may be convenient to specify some parts (the parts on top of the virtual hardware) of the system later as the group has gained deeper insight on the implementation of the base of the system. Carefully specifying every element functionality and the necessary interfaces between them. The highest parts of the system may be defined more loosely due to the same reason as in defining the structure. Every member of the group is responsible of specifying his own part of the system. The documentation manager is responsible of coordinating this task. This phase will result in having a detailed (possibly later refined) specification on each module of the system. Also the main interfaces will be documentated. Defining all the needed intra- and extra-system protocols. These essentially include networking protocols, thereby the documentation manager has the main responsibility of this. Creating a presentation on the prospective functioning of the system, and agreeing on it with the client.The process manager and the documentation manager make a detailed figure of the semantics of the system. The process manager presents it to the client. Dividing the modules (elements) further into functions and data structures and specifying them. All members are responsible of this, each is responsible for his own modules. This task is mainly done by writing well-documented header files; the documents are then generated from them. Refining the project plan and requirement definition according to the arised facts. The documentation manager writes the necessary additions and changes.
2.2.2 Documents
	Project plan (refined) Documentation manager Requirement Definition (refined) Project manager, documentation manager Functional definition of the system All members; project manager is responsible Functional definition of all the elements (and the corresponding code modules) Definition of all the interfaces All members Definition of networking protocols Documentation manager Progress report Documentation manager
2.3 Implementation design (4.11. - 8.12.)
2.3.1 Tasks
	Choosing the method and algorithms that are best suited for each element and function Each member of the group makes his own decisions; the decisions can be discussed in the group meeting. Specifying the details of compiler and assembler Mainly the project and process managers will decide the instruction set and calling conventions. Specifying the details of heap and garbage collector Project manager, process manager, testing manager. Specifying the details of the virtual machine Project manager, process manager, testing manager. Specifying the details of operating system All members. Writing the testing plan Testing manager.
2.3.2 Documents
	Technical specification Technical specification will be constructed mainly from carefully written and documented header files and code module description files. This process is aided by a script. The documentation manager is responsible for gathering the information and the quality of the documentation. Progress report Documentation manager Testing plan Testing manager will write a testing plan to be used in the prototype 1 -phase.
2.4 Prototype 1 (9.12. - 16.2.)
	Due to the nature of the SCHEMESTATION project, it is inconvenient to develop the a an unit system as a whole. We have to define and code some parts before others to be able to build the system. Due to this, we have chosen the approach that the prototype I does not contain the highest parts of the system. Rather, we will to write with care the hardware related parts of the system, and some of the lower part of the OS.
2.4.1 Main tasks
	Implementing and testing prototype 1 At least the following parts of the system will be implemented and ready for testing: virtual machine heap linealizer compiler assembler garbage collector Writing the testing report. Done by the testing manager. Writing the first version of the manual The documentation manager is responsible for this. Presenting the protype for the client. The project manager will prepare a presentation of the prototype I for the client. This presentation will be held in the meeting with the client and the supervisor. Analysing the response from the client, and drawing together all the ideas and things to be amended Project manager, documentation manager. Designing the implemention of the prototype 2 Based on the client response, found bugs, and group members' opinions, the group will decide which parts of the system need most attention. Making a test plan for all the functionality The testing manager will make a testing plan for the prototype 2
2.4.2 Documents
	Test report Testing manager Manual Documentation manager Summary of client response Documentation manager Testing plan for prototype 2 Documentation manager Progress report Documentation manager
2.5 Prototype 2 (17.2. - 23.3.)
	This prototype should contain all the functionality our SCHEMESTATION-implementation is planned to provide.
2.5.1 Main tasks
	Refining and amending prototype 1 This done by the whole group based on the plan made in the previous phase. Implementing new functionality The first prototype does not provide the complete functionality; the lacking things include: Actor migration SCHEMESTATION persistence Operating System services (e.g. object server) External interface utilization Testing all the functionality Testing manager is responsible of this. Writing the final manual The documentation manager will gather the information for the final manual. All the members will participate writing the manual on the parts of the system they have coded. Presenting the protype to the client Project manager.
2.5.2 Documents
	Test report Testing manager Summary of client response Documentation manager Final manual Documentation manager Progress report Documentation manager
2.6 Handover (24.3. - 24.4.)
2.6.1 Main tasks
	Ensuring that the implemented system meets the requirements The group will step by step go through all the requirements along with the client. Fixing bugs found in prototype 2 Writing the conclusion report The documentation manager is responsible for writing a comclusion report on the project. All members will participate in this.
2.6.2 Documents
	Test report Testing manager Conclusion report Project manager Progress report Documentation manager
2.7 Post-project activity
	The group members shall be available for solving possible problems concerning the SCHEMESTATION. Since the main purpose of the system is educational and scientific research, giving lectures and briefings on the design, implementation and used methods may be possible. This has to be negotiated separately with the client.
3 Resource allocation and schedule
3.1 The Project
	Since our project demands coding the fundamental parts of the system early, the following resource allocation plans for each phase are to be taken as "done by then" - not "done then". The coding goes quietly on in background to ensure all demanded modules will be ready as early as possible.
3.1.1 Using the resources
	Huima Holländer Kirma Herva total PP 32  34  13  30  109  SPEC 38  40  30  30  137  DESIGN 32  32  30  33  127  P1 30  48  51  54  187  P2 35  50  55  55  192  ASSGN 19  10  10  9  48  total 200  200  200  200  800  Holidays: 9.12.1997 - 19.12.1997 (exams) 19.12.1997 - 1.1.1998 (Christmas) During other times, work is done according to the schedule.
3.2 Using the Resources in Each Phase
3.2.1 Project Planning
	Huima Holländer Kirma Herva total Difference Studying 8  5  3  4  20  0  Lectures (course)  2  2  3  4  11  0  Scheme   1  0  0  0  1  0  Operating systems  0  3  0  0  3  0  Compilers   5  0  0  0  5  0  Configuring the machine 2  10  1  4  17  0  Software   2  7  1  4  14  0  Hardware   0  3  0  0  3  0  Project management 2  7  1  1  11  0  Task allocation & general  2  7  1  1  11  0  Documentation 12  4  0  13  29  0  Project plan,   2  2  0  8  12  0  Requirements   9  2  0  1  12  0  WWW-pages   1  0  0  4  5  0  Specificating 10  7  3  5  25  +5  Designing 5  10  5  7  27  +7  Coding 15  8  12  13  48  +8  Meetings 8  8  8  8  32  0  Intra-group   6  6  6  6  24  0  With client and supervisor  2  2  2  2  8  0  TOTAL   62  59  33  55  209  +20  Individual differences   +10  +5  0  +5  +20
3.2.2 Specification
	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 7  3  3  17  30  +3  Designing 8  8  3  3  22  +5  Coding 15  20  25  25  85  +5  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  Documenting 1  2  0  6  9  +1  Project plan   0  2  0  2  4  0  Requirements   1  0  0  0  1  0  WWW-pages   0  0  0  4  4  +1  Host maintenance 1  1  0  1  3  +1  TOTAL 53  51  40  61  205  +13  Individual differences   +6  0  -9  +16  +13
3.2.3 Implementation design
	8.12.1997 Huima Holländer Kirma Herva total Difference Studying 2  2  1  1  6  -10  Project management 2  4  1  2  9  -3  Specificating 4  2  1  2  9  -6  Designing 4  2  2  4  12  -4  Coding 16  13  10  11  50  -10  Testing 6  7  7  6  26  -6  Meetings 8  6  6  6  26  0  Documenting 12  9  8  15  44  +12  Host maintenance 1  1  0  2  4  +1  TOTAL 55  46  36  49  186  -26  Individual differences   -1  -9  -14  -2  -26
3.2.4 Prototype 1
	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
3.2.5 Prototype 2
	22.3.1998 Huima Holländer Kirma Herva total Difference Project management 2  4  0  0  6  +2  Specificating 2  0  0  0  2  0  Designing 4  0  0  2  6  -4  Coding 30  26  22  33  111  +79  Testing 4  6  5  8  23  -9  Meetings 8  8  8  6  30  +4  Intra-group   6  6  6  6  24  0  With client and supervisor  2  2  2  0  6  +4  Documenting 6  5  8  12  31  -1  Host maintenance 0  0  0  0  3  -3  TOTAL 56  49  43  61  209  +68
3.2.6 Delivery
	22.3.1998 Huima Holländer Kirma Herva total Difference Project management 2  6  0  0  5  +3  Coding 22  16  14  14  40  +26  Testing 18  15  26  12  71  +31  Meetings 8  8  8  8  32  +16  Documenting 13  20  8  28  69  +29  Host maintenance 1  0  0  1  2  0  TOTAL 64  65  56  63  248  +105
3.3 Time allocation for each task
3.3.1 Pre-project activities
	Pre-project activities 5,5d  Thu 25.9.97  Thu 2.10.97   Define coding conventions  0,5d  Thu 25.9.97  Thu 25.9.97  Huima  Install production machine  1d  Tue 30.9.97  Tue 30.9.97  Holländer  Find/implement & install utils  1d  Thu 2.10.97  Thu 2.10.97  Holländer
3.3.2 Virtual SCHEMESTATION
	Virtual SCHEMESTATION 56d  Fri 3.10.97  Mon 22.12.97    Heap layout design  1d  Fri 3.10.97  Fri 3.10.97  Kirma  Heap interface design  0,5d  Mon 6.10.97  Mon 6.10.97  Kirma  Heap design  0,5d  Mon 6.10.97  Mon 6.10.97  Kirma  Heap implementation  8d  Tue 7.10.97  Thu 16.10.97  Kirma  GC design  0,5d  Fri 17.10.97  Fri 17.10.97  Kirma  GC implementation  1w  Mon 20.10.97  Fri 24.10.97  Kirma  Heap linearizer design  0,5d  Fri 17.10.97  Fri 17.10.97  Kirma  Heap linearizer impl.  2d  Mon 27.10.97  Tue 28.10.97  Kirma  VM conventions def.  1d  Fri 3.10.97  Fri 3.10.97  Holländer  VM layout design  2d  Mon 6.10.97  Tue 7.10.97  Holländer  VM interface design  2d  Wed 8.10.97  Thu 9.10.97  Holländer  VM implementation  5d  Fri 10.10.97  Thu 16.10.97  Holländer  Event loop semantics  1d  Fri 3.10.97  Fri 3.10.97  Huima  EL interface design  0,5d  Mon 6.10.97  Mon 6.10.97  Huima;Herva  Packet protocol spec.  1d  Fri 3.10.97  Fri 3.10.97  Herva  PP interface design  1d  Fri 10.10.97  Fri 10.10.97  Herva  Packet protocol impl.  1w  Mon 13.10.97  Fri 17.10.97  Herva  Address system spec.  2d  Tue 4.11.97  Wed 5.11.97  Huima  Station-to-station communication conventions  2d  Thu 6.11.97  Fri 7.11.97  Huima  Message handler design  3d  Tue 21.10.97  Thu 23.10.97  Herva  Message handler impl.  7d  Fri 24.10.97  Mon 3.11.97  Herva  Kernel actor interface  1d  Mon 3.11.97  Mon 3.11.97  Huima  Kernel actor design  2d  Tue 4.11.97  Wed 5.11.97  Holländer  Kernel actor impl.  7d  Thu 6.11.97  Fri 14.11.97  Holländer  Scheduler design  2d  Fri 17.10.97  Mon 20.10.97  Holländer  Scheduler impl.  8d  Tue 21.10.97  Thu 30.10.97  Holländer  MigrationManager design  3d  Tue 4.11.97  Thu 6.11.97  Herva  MigrationManager migration manager impl.  7d  Fri 7.11.97  Mon 17.11.97  Herva  First virtual SCHEMESTATION milestone  0d  Fri 31.10.97  Fri 31.10.97    Second virtual SCHEMESTATION milestone  0d  Mon 1.12.97  Mon 1.12.97    Final virtual SCHEMESTATION milestone  0d  Mon 22.12.97  Mon 22.12.97
3.3.3 Virtual SCHEMESTATION Network
	Virtual SCHEMESTATION Network 10d  Mon 17.11.97  Fri 28.11.97    Network dispatcher design  3d  Mon 17.11.97  Wed 19.11.97  Holländer  Network dispatcher impl.  7d  Thu 20.11.97  Fri 28.11.97  Holländer
3.3.4 Virtual SCHEMESTATION terminal
	Virtual SCHEMESTATION terminal 15d  Mon 10.11.97  Fri 28.11.97    User interface design  3d  Mon 10.11.97  Wed 12.11.97  Huima  User interface implementation  4d  Tue 18.11.97  Fri 21.11.97  Huima  X11 support design  3d  Thu 13.11.97  Mon 17.11.97  Huima  X11 support implementation  5d  Mon 24.11.97  Fri 28.11.97  Huima  Terminal milestone  0d  Fri 28.11.97  Fri 28.11.97
3.3.5 Scheme environment support
	Scheme environment support 18d  Wed 8.10.97  Fri 31.10.97    Assembler design  1d  Fri 24.10.97  Fri 24.10.97  Huima  Assembler implementation  5d  Mon 27.10.97  Fri 31.10.97  Huima  Compiler design  2d  Wed 8.10.97  Thu 9.10.97  Huima  Compiler implementation  2w  Fri 10.10.97  Thu 23.10.97  Huima
3.3.6 Scheme environment
	Scheme environment 17d  Mon 3.11.97  Tue 25.11.97    Scheme environment definition  2d  Mon 3.11.97  Tue 4.11.97  Kirma  Scheme environment design  1w  Wed 5.11.97  Tue 11.11.97  Kirma  Scheme environment impl.  2w  Wed 12.11.97  Tue 25.11.97  Kirma
3.3.7 Default actors
	Default actors 22d  Mon 19.1.98  Tue 17.2.98    Actor repository  5d  Wed 21.1.98  Tue 27.1.98  Huima  Default actors def.  2d  Mon 19.1.98  Tue 20.1.98  Huima  Default actors design  1w  Wed 28.1.98  Tue 3.2.98  All  Default actors impl.  2w  Wed 4.2.98  Tue 17.2.98  All
3.3.8 Demo application
	Demo application 11d  Wed 18.2.98  Wed 4.3.98   Demo definition  1d  Wed 18.2.98  Wed 18.2.98  All  Demo design  3d  Thu 19.2.98  Mon 23.2.98  All  Demo implementation  7d  Tue 24.2.98  Wed 4.3.98  All
3.3.9 Project reports & tracking
	Project reports & tracking   138d  Thu 25.9.97  Wed 22.4.98    Requirements analysis  0,5d  Thu 25.9.97  Thu 25.9.97  Huima  Project plan  2d  Thu 25.9.97  Mon 29.9.97  Herva  Functional definition  1d  Fri 26.9.97  Fri 26.9.97  Huima  Technical definition  2d  Mon 29.9.97  Tue 30.9.97  Huima  QA plan  1d  Fri 31.10.97  Fri 31.10.97  Kirma  QA report  2d  Wed 18.3.98  Thu 19.3.98  Kirma  Progress reports  2d  Thu 25.9.97  Fri 26.9.97  Holländer  Project resource track.  1d  Thu 25.9.97  Thu 25.9.97  Holländer  User manual  1w  Thu 5.3.98  Wed 11.3.98  Herva  Maintenance manual  1w  Mon 6.4.98  Fri 17.4.98  Herva  Final project report  1w  Thu 16.4.98  Wed 22.4.98  Huima
3.3.10 Summary
	Project 86d  Wed 10.12.97  Mon 27.4.98    First prototype  0d  Wed 10.12.97  Wed 10.12.97    Second prototype  0d  Wed 18.2.98  Wed 18.2.98    Third prototype  0d  Wed 25.3.98  Wed 25.3.98    Final demonstation  0d  Mon 27.4.98  Mon 27.4.98
3.4 Figure of the Time Allocation
	The figure is rather large. Please click here to view it.
3.5 Costs
	Work 4 * 250h * 250mk/h = 250 000mk The group consists of four people. 200 hours of work per person is a rough estimate: that is the course requirement. Because the group is this small we have estimated, that 250 hours will be spent per member. The hourly rate, 250mk excluding VAT, includes all other tax and other mandatory costs. Unexpected costs 50 000mk + VAT Programs, tools and software are free. The SCHEMESTATION machine is available at no cost The CS laboratory of HUT provides the machine, and it is thereby not taken in consideration when calculating the project costs. TOTAL 300 000mk + VAT
4 Working methods and task allocation
4.1 Tools and hardware
	The SCHEMESTATION simulation host machine: 166MHz Pentium, 64 MB RAM, 2.5 GB hard disk Personal computer of each group member Linux GCC GMake GDB Emacs Other Linux- and Gnu-tools
4.2 Documentation tools
	The documents are written with a text editor in a pseudo-html (.ssdoc) -format. Pictures are made with xfig or a program capable of directly producing gifs or jpegs. Equations are made with TeX. An automatic script will be made, that converts the ssdoc-documents into actual html adding the pictures and equations. Most of the code documentation is done in the code. An automatic script will be made that extracts the comments into a document. The aim is that, all the functions will be documented in this manner. A brief description of the code module will be taken from a separate file and added in the beginning of the code document by the script. A www-based code browsing utility will be installed in the SCHEMESTATION host. Its purpose is to enable the programmers to search the header, code and documentation files and browse the system structure. This will also serve as a gateway for others (restrictions will be specified later) to access the code. The documentation is responsible for making these scripts and they will be functional before 30.10. All the documentation will be gathered and organized (indexed) to the www-page of the project. The documentation manager is responsible for this.
4.3 Working methods
	Meetings are kept whenever any group member considers this necessary. When it is unsuitable to gather the whole groups, the relevant subset of the group will be gathered. To enable time resource accounting, every member emails his weekly hour data to the project manager. The main tool of communication inside the team is email; the most crucial things are also put in to web. All drafts are posted to the SCHEMESTATION NNTP server. Communicating with the client and supervisor is done via email. Face-to-face meetings are also frequently organized. The made decisions will be mailed to schemestation@schemestation.cs.hut.fi, they will be saved in a folder.
4.4 Controlling the risks
	Noticeable risks contain: The client states his unwillingness to continue with the project. The SCHEMESTATION project shall nevertheless be completed. A member discontinues with the project The SCHEMESTATION project shall nevertheless be completed. If the smaller group seems unable to reach the goals the specifications are adjusted accoringly. Specifications have to be adequate for another group member to get acquainted with his work. Unability to follow the schedule Unless it is possible to correct the situation with resource reallocations, some requirements have to be relaxed. A meeting with the client and the supervisor have to be organized, and the goals have to be re-negotiated. Loss of data Backups of generated data have to be done as frequently as possible. All installed software is freely available and can be re-installed directly from the network; the installation procedure is simple, but can cause delay in the schedule. Hardware fault Since the SCHEMESTATION host machine is an out-of-shelf-pc, it can be quickly replaced by any group members' own machine. This can cause a delay of few days. Unability to obtain a crucial tool We plan to use standard UNIX tools, so this is highly improbable. Besides most tools can be easily replaced by a similar (freely available) tool. Unambiguity of the project aims. The project aims are agreed in the first meeting with the group and the client. If uncertainty of the aims arises among the group, a meeting with the client will be organized. Dynamic risk (a risk that arises during the project) control is handled as follows: Each week all group members will name 5-6 most prominent risk factors at that time; this risk accounting is accomplished together with the weekly time accounting. This way there is always visibility of the most prominent risks and preventive actions can be taken before any serious troubles occur.
4.5 The severity and probability of the risks.
	We use the scale from 1 to 10, where 10 stand for probable or severe accident and 1 for improbable and harmless accident. Cause Severity  Likelihood  The level of the risk  Client bails out  1  1  1  Loss of group member  3  1  3  Schedule fault  6  6  30  Data loss  8  2  16  Hardware fault  3  2  6  Shortage on a tool  5  2  10  Ambiguity of the aims  8  1  8
4.6 Task allocation and the roles of the members
4.6.1 Roles
	Project manager - Antti Huima Contacts with the client Responsible for the overall system design and semantics Process manager - Petteri Holländer Organizing tasks and allocating resources Maintaing the schedule and observing the progress Responsible for the functional specification system Defining the system structure Responsible for maintaining the SCHEMESTATION machine Testing manager - Jari Kirma Designing the testing plan Responsible for ensuring that the actual system meets the specifications Responsible for the prototypes Documentation manager - Ville Herva Responsible for the documentation discipline and documentation systems Responsible for manuals and other documentation material Responsible for coding and installing the documentation scripts Maintaing the SCHEMESTATION web site
4.6.2 Task allocation
	Preliminary task allocation which will be refined based on the progress of the group; any member can be assigned to any single forthcoming task. Antti Huima Mainly responsible for implementing the compiler and assembler Support routine implementation Petteri Holländer Mainly responsible for implementing and documenting the VM core Responsible for maintaining the SCHEMESTATION machine Jari Kirma Mainly responsible for implementing and documenting the heap, garbage collector and heap linearizer Ville Herva Mainly responsible for implementation and documenting the network specific parts and adapting the event loop
4.7 References
	[1]Abelsson, Sussman: The Structure ans Interpretation of Computer Programs, 2nd ed. MIT-Press,1996 [2]A. V. Aho, R. Sethi, J. D. Ullman: Compilers: Principles, Techniques And Tools, Addison-Wesley, 1986 [3]A. S. Tanenbaum: Modern Operating Systems, Prentice-Hall, 1992 [4]W. Clinger, J. Rees: Revised4 Report on the Algorithmic Language Scheme, November 1991
5 Management plan
5.1 Observing the state of the project
	Every member of the group is responsible of immediately reporting all matter that might affect the project schedule. This is the only way of being able to reallocate resources soon enough. Reports of spent time resources are delivered to the project manager weekly. Project manager has set minor objectives (milestones) to help the project to keep its schedule (see the time allocation).
5.2 Schedule
	Project phases Project design (16.9. - 8.10.) Specifications (9.10. - 29.10.) Design (30.10. - 12.11.) Prototype 1 (13.11. - 11.2.) Prototype 2 (12.2. - 18.3.) Delivery (19.3. - 29.4.)
5.2.1 Meetings
	The groups has to meet at least once a week face to face. Moreover all progress concerning the state of the project has to be reported without delay to the group via email. Meeting with the supervisor every second week. Meeting with the client whenever necessary.
5.2.2 Course scheduled surveys along with the client and the supervisor
	10.10  The aims of the project  16.10  Project plan and the requirement specification  5.11.-7.11  Functional and technica specification  10.-12.12  Demonstarting the implemented parts of the system  18.-20.2  Demonstrating the complete prototype  25.-27.3  Demonstaring the alpha release of the system  27.-29.4  Final demonstration
5.2.3 Lectures
	18.9  Introduction  19.9  Presenting the project subjects  29.9  Defining the requirement level of implementation and documentation  6.10  Functional specification  27.10  System design  24.11  Prototype demonstration  16.3  Assigning the system to the client