Project plan - SchemeStation
Project plan - SchemeStation
SchemeStation documentation
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
1.3.2 Project supervisor
1.3.3 The group
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
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 |