This information is occasionally updated and can be found at www.nada.kth.se/~karlm/softeng_proj.html
The course "mjukvarukonstruktion" has an associated practical coursework, which contributes 2 points to the overall course credits. (The remaining 2 points are obtained through the examination.)
The practical work for the course will consist of group project work to carry out a substantial design of a "large" system according to principles studied in the course. For those students continuing on to study the Project course, (normally everyone) this work will serve as the base for carrying out the actual implementation phase. There will NOT be any programming as part of this coursework itself.
The main aim of the project work is to put into practise a traditional waterfall model of software development. This means that (with the possible exception of graphical user interface components, for which an evolutionary approach may be taken) analysis and design take place before implementation.
As a planning and documentation standard, we will use the ESA standard PSS 05. A copy of this is given in the kursbunt, and 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. Documents are graded by how closely they match the guidelines set out in these templates.
The actual list of projects will be circulated and discussed in class. Students will be instructed as to how to divide up into groups. The group sizes will be determined by the class size, but typically a group will contain 5-7 persons. You MUST meet as a complete group at least once a week, at a time to be determined by the group.
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.
A more advanced book for people using O-O methods (e.g. UML, Java) is
E. Stiller and C. Leblanc, Project-Based Software Engineering: an Object-Oriented Approach, Addison Wesley, 2002. ISBN: 0-201-74225-X.
Both books are especially recommended for project managers, but could be a team purchase.
The project will be divided into the usual three phases of a waterfall model:
(1). User Requirements Analysis,
(2). Software Requirements Specification,
(3). Architectural Design.
Each group will deliver a report at the end of each phase. Each phase and its report carries equal weight for the purposes of credit points.
Before phase 1 there will be an initial project selection and planning phase, which will be 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 remaining phases of a waterfall model, namely the detailed design and implementation phase, the unit and integration testing phases, and the delivery phase, are carried out in the project course itself.
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.
Each phase will end with a written report, which will also be delivered verbally at the scheduled 'example class'. (See Section 5 below.) The delivery dates for reports are shown below. Two persons from each group should prepare and deliver a 15 minute presentation of the report to the rest of the class and myself, using overhead projector slides. You should be prepared to answer technical questions. At the end of the talk, the presenters must hand in a bound typed copy of the report.
Week 4, Tues 20th Jan, E51, 1300-1500: Introduction to project, organisation of project groups, choice of projects.
Week 4, Friday 23rd Jan, E2 1000-1200 : Deadline for choosing a project. Introduction to the Project Planning Document (PPD).
Week 5, Tuesday 27th Jan, E51, 1300-1500: Discussion of the PSS 05 Waterfall model and documentation standards.
Week 6, Tuesday 3rd Feb, E51, 1300-1300: Group presentations and final deadline for the Project Planning Document (PPD).
Week 6, Friday 6th Feb, E2, 1000-1200: Discussion of the User Requirements Document (URD).
Week 8, Tuesday 17th Feb, E35, 1300-1500: Group presentation and final deadline for the User Requirements Document (URD).
Week 8, Friday 20th Feb, E2, 1000-1200: Discussion of the Software Requirements Document (SRD).
Week 10, Tuesday 2nd March, E51, 1300-1300: Group presentation and final deadline for the Software Requirements Document (SRD).
Week 10, Fri 5th March, E2, 1000-1200: Discussion of the Architectural Design Document (ADD).
Week 12, Tue 16th March, E2, 1300-1500: Group presentation and final deadline for the Architectural Design Document (ADD). Discussion of the next phases of the project.
Week 22, Wed 26th May 1000-1200, 1300-1500 : Final presentation of the completed project, delivery of Detailed Design Document, delivery of User Manual. Schedule individual project times for practical software demonstration.
NOTE: Attendance at the 'example class' is compulsory for each individual student and attendance will be registered. It is NOT enough for one student to attend on behalf of the entire group. The purpose of verbal presentation is to sharpen your presentation skills in front of the lecturer and class.
You should record the date and times that you meet as a group, and include this in the end of each phase report. At the start of each group meeting, a secretary should be appointed with responsibility for taking and writing up minutes of the meeting. Here is a sample of a suitable set of meeting minutes. An agenda should be prepared for the meeting (either before hand, or at the start of the meeting.) Normally the agenda will begin with a copy of the minutes of the previous meeting being circulated. It should be agreed by the group that this is a fair and accurate record of the previous meeting. In this case the minutes can be 'accepted'. Otherwise they must be corrected and circulated again at the next meeting.
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 first task: writing the User Requirements Document.
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 must meet every week. Evidence of this meeting, that must be submitted, will be a set of minutes for each meeting. You will submit the most recent minutes with each project deliverable (URD, SRD, ADD, DDD).
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.