This web page is under construction!
The course 2D1343 part E2 has an associated practical project, which contributes 2 points to the overall course credits. (The remaining 6 points are obtained through the part E1.)
The practical work for the course will consist of group project work to carry out a requirements analysis and build a "large" system according to principles studied in the 2 course lectures.
The main aims of the project work are (1) to give experience of working in a group, (2) to gain experience of writing and analysing software requirements, and (3) to gain experience of working in a large team (about 10 people) on a large piece of software based on a set of formal requirements.
This means that (with the possible exception of graphical user interface components, for which an evolutionary approach may be taken) requirements analysis takes place before implementation.
As a requirements documentation standard, we will use the ESA standard PSS 05. This standard can be found below. It will be discussed in class. Every student must read this document carefully.
Here is an annotated set of templates for the PSS 05 documents URD, SRD and ADD online. You can use these to help you write each document. The final software you submit will be evaluated by how closely it satisfies the requirements which you set out in your URD.
Here is a list of project suggestions. You do not have to choose one of these. You can make your own suggestion.
Here is an updated version of the project rules.
Here are some tips for writing the URD.
Students may buy a copy of:
Ian W. Ricketts, Managing Your Software Project: a Student's Guide, Springer Verlag, 1998. ISBN: 3-540-76046-6
if they feel the need for simple practical guidance in running a project.
The project will be divided into three phases (which loosely correspond with a waterfall model):
(1). Project Planning Phase
(2). User Requirements Specification,
(3). Software Design and Implementation.
The deliverable for phase 1 is a report of minimum length 3 pages (excluding title page). The deliverable for phase 2 is a report of minimum length 12 pages. The deliverable for Phase 3 is the software, which will be demonstrated to the teacher. To pass the course all deliverable must be submitted and accepted.
For phase 1 there is be an initial project selection and planning phase, which is summarised in a planning report. This is described below. The format of the other reports is described in PSS 05, and will be discussed in class.
The group will be marked as a whole unless there are exceptional reasons why the marks should be distributed differently for an individual group. (e.g. extended illness of a group member, dispute etc.) In the case of a project dispute (these sometimes happen.) I will step in to resolve the problem, if notified in time.
Phases 1 and 2 will end with a written report. (See Section 5 below.) The delivery dates for reports are shown below. Each group must hand in a bound typed copy of their report.
|Vecka 36, 2007||Kurser||Moment||Lokaler||Anmärkning|
|Tis||4 sep||15:00-17:00||Datalogi||Frl||E2||Group organisation and PPD|
|Vecka 37, 2007|
|Mån||10 sep||17:00||Deadline||My mail tray, Plan 4||Submit 2 paper copies of PPD|
|Tis||11 sep||15:00-17:00||Datalogi||Frl||E2||User requirements and PSS05 reporting standard|
|Vecka 46, 2007|
|Mån||12 nov||17:00||Deadline||My mail tray, Plan 4||Submit 2 paper copies of URD|
|Vecka 12, 2008|
|23 April||Deadline||Computer lab or my office||Demo software|
In order that your project progresses smoothly, it is important that you function "as a group". This may involve getting to know one another as students (perhaps with different skills, interests and experiences) as well as establishing standards for discussion, reaching agreement and resolving disagreements. These are all part of a normal and important parts of a software project. You will need considerable "team spirit" to function succesfully.
The project planning phase is not officially part of the PSS 05 standard. However, if carried out succesfully, it will connect you as a coherent group, with an agreed set of objectives and approaches. In particular, it should help you prepare for your second task: writing the User Requirements Document URD.
As soon as possible you must meet as a group and establish a regular weekly meeting time that is convenient for everybody. You can meet in any location you wish. The meeting will be unsupervised. It is suggested that from time to time smaller working groups can meet. However, to maintain progress you should ideally meet once every two weeks.
Your first task is to assign yourselves a group name (legal and decent), and collect your names, e-mail addresses and telephone numbers.
Your next task is to examine the skills available in the group, and the technical strengths possesed by group members (e.g. Unix expert, Windows expert, graphics expert, etc.)
On the basis of skills, interests and personalities you must assign the following roles to group members (note that one member can have more than one role.)
(responsible for overall co-ordination, and ultimate decisions and responsibility, deep understanding of the project and the PSS 05 standard)
(responsible for writing/delegating documentation and report writing, taking minutes of meetings, deep understanding of the PSS 05 standard)
(an optional role, but a model favoured by many in industry, main responsibility for programming, delegates simpler tasks)
( usual tasks plus documentation and testing responsibilities )
(an optional role that could be separated from the secretary, writes and produces reports)
( a technical writer, assigned tasks by the secretary or documentation manager)
( testing responsibilities, assigned by project leader or chief programmer )
( problem analysis and software design at some stage in the project, duties assigned by project leader )
( an optional but common specialist role, a chance for specialist skills to shine and deepen, duties assigned by project leader/ chief programmer)
( an optional role that could support the project leader and/or secretary )
( a "pretend role", simulating the behaviour and wishes of an end user - projects with industrial connections may have a real end user)
NOTE: with the exception of the optional roles, all the above roles must be manned by some person. These roles will be recorded in the planning document. Although you may have specific technical roles, everyone is expected to contribute to the project ideas and decision making. You will be democratic, although in the case of dispute the project leader will have the final say.
The output from this phase is the Project Planning Document (PPD). This document describes your initial project management decisions. It summarises your background research into the problem. It also identifies any learning which must be done in order to carry out the project.
The PPD must have the following standard structure.
You must describe the problem chosen.
Explain why you chose this project. Why is it important for the group? Does it enhance job skills. Does it satisfy some interests?
What skills do you have in the group. Are there individuals with specialist skills? Will you need to learn any new skills? How will you learn these?
What commercial tools exist of this kind? (You can include freeware, shareware). Who makes them? What do they cost? Who buys them? Are they for computer experts or beginners? Are they national or international? What skills does a typical user have? Is the market established or new?
What is the "best available product" of this type. Why is it best? What properties make it the best? How many of these properties could you implement in the time available? What features could be classified as (a) economy version, (b) standard version, (c) deluxe version.
Expect to use a web search, magazines and trade newspapers extensively here.
Expect to use course notes and library books extensively here. What algorithms and data structures might be needed for the project. What research subjects are related to this project. What could a product look like in the future? Are there experts at KTH in this subject?
What platform, Operating System and programming language(s) would be appropriate. Can you use any commercial off the shelf products (available within NADA) to solve parts of the problem? e.g. a database, or tools, e.g. Yacc, Lex, Javacc, Swing.
In order for you to divide up the programming work among group members, and in order for the teacher to have objective criteria for assessing you final software solution, it is necessary to write a user requirements document (URD). This is normal on all large software engineering projects, irrespective of what kind of software lifecycle model is adopted.
Here is an example of a URD written according to the PSS05 model.