DD1365 and DD143X MVK PRACTICAL PROJECT WORK

Autumn 2009 - Spring 2010

Karl Meinke,
karlm@nada.kth.se


This information will be regularly updated.

1. Goals and Methods.

The courses DD1365 and DD143X have an associated practical project work, which contributes 15 points to the overall course credits (DD1365 = 6 points, DD143X = 9 points).

1.1. Goals.

The practical work for the course will consist of group project work to carry out a substantial design, implementation and test of a "large" system according to principles studied in the course.

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. Templates for this are provided on the course home page, and also below. Every student must read these templates 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 will be graded, and one criterion is how closely they match the guidelines set out in the templates.

1.2. Project List.

A list of projects will be circulated and discussed in class. Students will be instructed as to how to divide up into groups.

Typically a group will contain 10-12 persons. You should meet as a complete group at least once a week, at a time to be determined by the group. You must attend unless you have strong reasons not to.

1.3. Course Texts.

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 providing professional level advice is: Bob Hughes and Mike Cotterell, Software Project management, McGraw Hill, 2002. ISBN: 0-07-709834-X. This book will probably still be useful after you graduate.

1.4. Organisation of the Project.

The project will be divided into six phases of a waterfall model:

(1) Project Planning and Feasibility Study,
(2) User Requirements Analysis,
(3) Software Requirements Specification,
(4) Architectural Design.
(5) Detailed Design and Coding.
(6) Testing and Delivery.

Each group will deliver a report at the end of phases 1-4. The phase 5 deliverable is simply code, while the phase 6 deliverable is a group presentation of the project for the class, followed by an individual software demo for the course leader. Each phase and its deliverable carries equal weight for the purposes of credit points and delivers a grade U/G/VG.

Phase 1 is an initial project planning and feasibility study phase, which will be summarised in the project planning document (PPD). This is described below. The formats of the other reports (Phase 2 URD, Phase 3 SRD, Phase 4 ADD) are described in the PSS 05 templates, and will be discussed in class.

The group will be marked as a whole. Students who leave the course prematurely, or do not participate in the project work to an acceptable standard will not be assigned a grade, and must repeat the course. In the case of a project dispute (these sometimes happen) I will step in to resolve the problem, if I am notified in time.

1.5. Progress Reporting.

Each phase will end with a written report, which will also be delivered verbally at a scheduled lecture. (See Section 5 below.) The delivery dates for reports are shown below. Two persons from each group should prepare and deliver a 5 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.

1.5.1. Timetable.

Week 45, Tues 3rd Nov 2009, D1, 1500-1700: Introduction to projects and choice of projects.

Week 47, Tues 17th Nov 2009, D1 1500-1700 : Presentation and submission of Project Planning Document (PPD).

Week 50, Wed 8 Dec 2009, D1, 1500-1700: Submission and Presentation of User Requirements Document URD.

Week 6, Tues ?? Feb 2010, D1, 15.00-17.00 : Submission and Presentation of Software Requirements Document (SRD).

Week 12, Tues ?? Mar 2010, D1, 15.00-17.00: Submission and Presentation of Architectural Design Document (ADD).

Week ??, May 2010, D1, ????-????, ????-???? : Final presentation of the completed project, delivery of User Manual. Schedule individual project times for practical software demonstration.

NOTE: Each project member must make at least one oral presentation in front of the class during the course.

1.5.2. Project Minutes.

You should record the date and times that your project group meets as a group, and include all recent minutes at the back of each phase deliverable 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.


2. Phase 1: Project Planning and Feasibility Study.

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 and feasibility study 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 and understood joint set of objectives and approaches. It will also lower the level of project risk attached to your project. (A more detailed risk analysis comes later.) Furthermore, it should help you prepare for your first major task: writing the User Requirements Document (URD).

2.1. Goal.

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 must submit a set of the most recent minutes with each project deliverable (URD, SRD, ADD).

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 perform an audit of the skills available in the group, and the technical strengths (and weaknesses!) of each of the group members (e.g. Unix expert, Windows expert, graphics expert, etc.) Team members need to be honest and open about this to avoid unpleasant surprises later.

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.)

Project leader Responsible for overall co-ordination, and ultimate decisions and responsibility, deep understanding of the project and the PSS 05 standard.

Project secretary Responsible for writing/delegating documentation and report writing, taking minutes of meetings, deep understanding of the PSS 05 standard.

Chief programmer An optional role, but a model favoured by many in industry, senior responsibility for coding, a person who delegates simpler programming tasks.

Programmer A more flexible programming role that might also include documentation and testing responsibilities.

Documentation Manager An optional role that could be separated from the secretary role. A person who writes and/or produces reports.

Report Writer A technical writer, assigned tasks by the secretary or documentation manager.

Tester Responsible for unit module and system testing. Receives tasks assigned by the project leader or chief programmer. Typically programmers are not allowed to test their own code.

Requirements Analyst An optional role, responsible for capture, exploration and analysis of end-user requirements. Usually by an iterative process, and often with the help of rapid prototypes including GUI designs, interviews, focus groups, etc. Good social skills are important for this role, as well as technical ability.

Designer Responsible for problem analysis, solution inception and software design at different stages in the project. Tasks normally assigned by project leader.

GUI expert An optional but common specialist role, a chance for specialist skills to shine and deepen. Tasks assigned by project leader/ chief programmer.

Project planner An optional role that could otherwise be performed by the project leader and/or secretary. The project planner may also monitor progress and reschedule tasks to incorporate change.

Customer Account Manager Industrial end-users tend to be very busy, so one single person who is a (reliable!) unique point of contact often reduces confusion and makes communication work best. Excellent social skills are important for this role which does not suit a shy or introverted person.

NOTE: with the exception of the optional roles, all the above project 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.

2.2. Phase 1 Deliverable: the Project Planning Document (PPD).

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, culminating in a feasibility assessment. It also identifies any learning objectives necessary to carry out the project.

The PPD must have the following standard structure.

Cover page, Contents page, Abstract page

This document must have three separate pages: a title page, giving the date, group name, project title and all project member names. After this there must be a contents page, followed by an abstract on a third separate page which summarises the contents of the document (1-2 paragraphs).

1. Statement of the Problem

You must describe the problem chosen.

1.1. Statment of the Problem.

A description of the problem, in significantly greater detail than the description handed out in the project list. You must provide your own thoughts and interpretation of the problem. This section should include all the new information you have obtained by talking to your end-user.

1.2. Motivation.

Explain why you chose this project. Why is it important for the group? Does it enhance job skills. Does it satisfy some interests?

1.3. Goals

What do you hope to achieve with this project (a) technically, i.e. what will you build? (b) educationally, i.e. what will you learn?

1.4. Skills Baseline

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?

2. Background to the Problem

This section should be a study of examples of the type of system that you intend to build. Your study will be based on a literature survey: (books, magazines, trade newspapers) and a web search. One aim of this study is to compile a list of possible product features, that can be used to steer Phase 2, the user requirements phase.

2.1. Commercial background

(If appropriate)

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 mature or immature?

What is the "best available product" of this type. Why is it best? What features make it the best? You may be able to consult industry analyst reports produced by such companies as Gartner Group. How many of these features 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.

2.2. Scientific background.

(If appropriate)

If you have a research oriented project there may be little or no commercial literature available. This might be the case if your end-user is a teacher or researcher at KTH. In this case you will need to use course notes, research journals, conference proceedings and library books extensively.

What algorithms and data structures might be needed for the project? What research subjects are related to this project? What could a commerical product look like in the distant future? Are there experts at KTH in this subject?

2.3. Technical Background.

In this section you should describe what platform, Operating System and programming language(s) would be appropriate. Can you use any commercial-off-the-shelf (COTS) products to solve parts of the problem? e.g. a commercial database, spread-sheet front end, web browser interface etc. Can you use application generator tools, e.g. Yacc, Lex, Javacc or component libraries e.g. Swing?

3. Conclusion: Feasibility Assessment.

In this section you need to draw conclusions about the feasibility of your project, based on the time and work force available, the level of ambition of your project (based on project features), and the skill set available in your group. At this early stage you should already be able to identify the most significant risks of your project, and this information will later be extended to a more detailed risk analysis.

Appendix

The PPD must contain an appendix with the list of all group members, their personal numbers (personnummer) and their e-mail addresses (for my records). The Appendix must list all the job roles used in the project, and for each adopted job role the name (or names) of individuals with that responsibility.


Karl Meinke
Last modified: Oct 23 2009