Project-work information, PUM-I, TDDB062
Date: 2001-09-18
Goal
The projects are there to give you experience. For some of you this is the first time you participate in a practical development team. The world is not perfect and the goal is not to create
a perfect solution to the task you will get. The goal is to learn as much as possible from trying
to create a feasible solution.
Organisation
The projects are performed in four system groups, all with the goal of creating a scheduling
system for a university.
Each system group is divided in five component groups of 6-8 persons each. If we can not
fill all component groups we might split an 8-person group to two smaller groups.These groups
are responsible for one component each of the system, namely:
1. A database holding all information about the schedule, teachers, courses and studygroups.
2. A set of optimization algorithms that will calculate the best schedule given the wishes and
constraints.
3. An applet for navigating for students and teachers. It should be possible to check your
schedule from a URL.
4. An application for teachers giving input to the system, such as slots needed for the course,
preferences of distribution of activities and constraints.
5. An application for administrators optimizing the entire scheduling of the university.
Each component group should have a project organisation with at least an identified project
leader. Other roles are up to you. You are supposed to negotiate interfaces with other component groups in your own system group. The components should be specified, designed, coded,
tested, demonstrated and hopefully also integrated with the other components in the same system group.
This is problem-oriented education, so you need to find the information from many sources.
We will give you hints, but not solutions.
There are 8 project weeks distributed as follows:
project
week
real week
number
1
40
2
41
3
43
4
44
5
45
6
46
7
47
8
48
Each component group will meet an hour every project week with the appointed instructor.
Each system group will have two seminars, preliminary these will take place October 25 th
13-15 and December 4th 10-12. All component groups shall present their plans and results at
these seminars with the instructor and the rest of the system group as audience.
Each component group is required to hand in the following documents to its instructor:
1. a requirement specification, (Dead-line 2001-10-12)
2. a design description, (Dead-line 2001-11-05)
3. a test report and (Dead-line 2001-11-30)
4. an experience report (Dead-line 2001-12-07).
The experience report is very important and the instructor will give you written feed-back on
that. The other documents will be discussed during weekly meetings. I will provide you with
some suitable headlines for the documents. Mainly they are a selection from IEEE standards.
You might need to adapt the headlines to suit your particular project.
The project part is 2.5 academic credits which corresponds to at minimum 100 hours work
per person. For a six-person group this means that we expect you to spend 600 hours in total.
Examination
To pass the project you should have:
1. Participated in a project group, which has fulfilled the specification, design, coding, testing,
demonstration and integration of a component. The software should perform calculations
and data processing in a 3rd generation language, such as Java, C++, LISP or Ada. It is
not sufficient to only link a set of HTML-pages to display an intended behaviour even
though this might be a part of the system.
2. Participated in a project group which have handed in a requirement specification, a design
description, a test report and an experience report before the dead-lines above.
3. Participated in the two system group seminars.
The project work will be graded with UK, 3, 4, 5 per component group by the instructor, who in
turn conferences with the examiner. (You probably have to behave really odd to get a UK.)
Higher grades are given to groups who either produces a lot and/or learn a lot. Your individual
grade is derived from the table below,
Grade from written exam
Grade from project work
Final individual grade
UK
UK, 3, 4, 5
UK
3, 4 or 5
UK
UK
3
3
3
3
4
4
3
5
4
4
3
4
4
4
4
4
5
5
5
3
5
5
4
5
5
5
5
Please note that this table is valid only for the three exams that belong to this study-year (October, January, August). I can not promise that the course will be organised by me next year.
Project start
You will sign up for a component group on a list of my door. There will be four system groups.
Group number 4 is especially dedicated to groups who want to try the eXtreme Programming
paradigm. You are not forced to use XP in system group 4, but the instructor is prepared of
supporting those who want to try.
The components within a system group will be assigned by random. You are free to change
components within the system group.
If I were you...
As you see from the Examination requirements you are almost free (and responsible for) how
you organise your work and realise the software. You are supposed to run into real-life difficulties and solve these the best you can. However, I’m not a purist in PBL so I will give you some
hints that I would have followed if I had your assignments.
Apart from the project manager, I would specify and assign the following roles:
• Architect with the technical responsibility. The architect negotiates interfaces with other
component groups and is responsible for writing the Design description.
• Test leader. Testing comes late in the projects and needs to be thoroughly planned. If noone is responsible it is so easy that this is forgotten. The test leader is responsible for the
Test report.
• Knowledge manager who is responsible for recording the experience gained during the
project. Such a person keeps track of questions, decisions and remarkable events. This
record is the basis for reflection which goes into the Experience report.
Note that one person can have more than one role.
I would also strongly recommend you to make a planning document with some kind of regular follow-up. One good thing is to create a time diagram of mile-stones. As the project goes
on, new estimates for mile-stones are added on top of the original one. Example:
project weeks
= milestone
= current time
3
2
1
0
calendar time
For a short project like this I would run a water-fall model with 2-3 ambition levels. The requirements will be grouped in these levels and the plan should aim for fulfilling the highest ambition level. If I run out of time later in the project I will cut high-ambition requirements.
Configuration management is important. Either I would use cvs or a binder where the latest
version is always available. It might be a good idea to appoint the role of a project librarian.
Keeping up a good spirit is important. At least twice I would do something fun or relaxing
with my team, such as a longer coffee-break with apple-pie, good lunch, bowling etc.
Document deadlines are important. You should plan to deliver the documents a day or two
in advance. Printers are never reliable and you might need to reinspect some parts. Inspecting
a document is a powerful way to increase quality. I would at least inspect the Requirements
specification and the Experience report with all team members before delivery.
Use the tools that are available, we have Rose and JBuilder, maybe you can find other good
solutions. In Rose I would use use cases and identify classes that can realise these. I would
probably not invest too much into other diagrams for this short project.
In the course we will offer you to try the Blackboard system, you will get an URL and a password to access the system if you are on the course mailing list. This system can be used for
communicating technical issues by, for instance, creating link libraries, broadcasting messages, creating focused discussion groups. There is even a virtual classroom. You should at least
read the announcements.
Good luck!
Kristian