Umeå University
OOPU COURSE PAGE
Course TDBC18 is a team project oriented software engineering course. The course focuses on object-oriented approaches to software development. Preliminary knowledge on software engineering is required. Proficiency in object-oriented programming is recommended. Each team consists of 5-7 students. Each team plays four roles during the course.
There is no written exam at the end of the course.
A list of project proposals is provided. Each team may add proposals to
this list. Any non-trivial problem may be added. The effort required
for the project should be about 6-8 person months. The target size of
the final system should be between three and ten thousand lines of
(new and changed) code. Good candidates are renting systems,
simulations, games, etc.
No team must select its own proposal.
Development follows a work product oriented approach (see
[OOTC]). That means that the development process focuses on the
production of certain work products. This approach is also taken in
the Unified Software Development Process (see [USDP]), which
gains more and more popularity.
The course lectures introduce the Unified Modeling Language (UML, see [UML]) for
object-oriented analysis and design. You will use UML during the
analysis and design phases of your project.
No team must completely and solely program its own system. At the end
of the design phase each team must contract with another team for some
part of the (prototype) implementation.
Each team is required to thoroughly evaluate another team`s prototype.
Any popular programming language is accepted (e.g. (Turbo-) Pascal,
Modula-2/3, Ada, Eiffel, C/C++, Java, ...). Third party or embedded
packages (e.g. class libraries) are allowed, but only as a subset of
the final prototype.
A tool (Rational
Rose) supporting the Unified Modeling Language (UML) is available on
the lab-machines. We have licences for RS6000, Solaris, and Windows NT.
Rational Rose supports analysis, design, and code generation. We have
code generators for Java, C++ and Ada95. The use of Rational Rose (or
an equivalent) is mandatory.
In addition we provide further tools to support your project
work. Besides GUI-, programming-, configuration management- (CVS), and
publishing tools, we do even provide tools for projekt planning,
tracking, and control (MS Project). The usage of these tools is is
recommended, but not mandatory. You are free to use your preferred
editors, compilers, etc.
To support teamwork we recommend the usage of a tool that supports
shared workspaces or collaborative editing, like BSCW or Swiki.net.
Each team has to maintain a www-based project workbook with
up-to-date information on the team and its project(s).
Although all deliverables should be available electronically (in some
form) we do also
require certain hard copy deliverables (i.e. paper) for practical
reasons. Hard copies make it easier to comment on your work and/or
give suggestions for improvements. Furthermore it makes it easier to
control deadlines.
The deadlines for all deliverables must be listed in the schedule of
each team (the schedule is a part of the project management
document). Many deadlines can be negotiated to fit a team's actual
project and available resources. Deadlines listed in the course
schedules are mandatory and cannot be negotiated. Renegotiation should
be avoided. Please do not forget to keep your web pages up-to-date.
Detailed descriptions of the purposes and contents of all deliverables
listed in the table below are available in a separate document.
All documentation (paper as well as electronic versions) of a team should
conform to a common format. Each team can define its own guidelines to
achieve that.
Please note that paper deliverables must be self-contained. Simple
print-outs
of web-pages are not acceptable! To avoid duplicate work we recommend
to focus on high quality paper deliverables and put those on-line via
PDF. OOPS! The web-pages must still be browsable, i.e. a few big PDF
documents are no good solution either.
Project Proposals and Project Selection
Development Approach
Subcontracting
Prototype Evaluation
Languages and Third Party Software
Usage of Tools
Deliverables
| No | Deliverable | Type of submission | Comments | ||||
|---|---|---|---|---|---|---|---|
| www | paper | ||||||
| D1 | Team Description | X | - | X | - | ||
| D2 | Project Proposal | X | X | - | Obsolete, if enough (external) proposals are available | ||
| D3 | Project Workbook | X | - | - | See [OOTC] | ||
| . |
| X | - | - | We use a revised version of [OOTC] | ||
| X | X | - | Updates will be checked on-line | |||
| X | X | - | - | |||
| X | X | - | - | |||
| X | X | - | Two paper versions (initial/final) | |||
| X | - | - | Includes the prototype user manual | |||
| X | - | - | Only the subcontract part | |||
| D4 | Subcontract | (X) | X | - | - | ||
| D5 | Prototype Evaluation | (X) | X | - | - | ||
| D6 | Weekly Reports | (X) | - | X | Once a week | ||
| D7 | Final Report | - | X | - | A compilation of previous deliverables, plus some additional stuff | ||
(X) - optional
Examples of complete project documentations from previous courses are available as hard copies. Some of them are even available on-line via the course's home page.
The course contains three presentation tracks. At the beginning of the
course each team presents itself and describes its proposal. In the
second presentation each team gives an overview of the project they
actually pursue. At the end of the course all teams present their
prototypes in a demo session.
Some information about the purposes and contents of the presentations
are available in a separate
document.
Each team has to carry out weekly meetings. Such meetings are very
important to get all team members involved in all tasks and to control
the progress of the project. Minutes of all meetings have to be kept
(to be included into the final project report).
Each team must send weekly reports to its supervisor(s) to keep them
informed about the current status of the project.
Each team member has one or more specialist roles. We recommend to
assign at least two team members to each role to make shure that
each team member has a knowledgable partner to discuss problems with.
Each role is accompanied by a set of special resposibilities. Beeing
responsible for something does not mean that you have to do it all by
yourself, but it is your responsibility that it is done.
Please note that a specific specialist role does not free you
from your overall responsibility to contribute to the project as a
whole.
The roles together with their special responsibilities are listed
below. Please note that some responsibilities are assigned to several
roles.
All team members are expected to familiarize themselves with the
methods, languages, and tools for object-oriented analysis and design
covered in the course.
The responsibilities of all specialists are:
We apply individual grading on the scale U (not passed), 3, 4, 5 (best
grade). Grading is based on a credit syatem. The team earns credits throughout
the project depending on its performance. At the end of the course each
team can freely (more or less) distributed earned credits among its
team members. More details on the grading scheme are available in a separate document.
Presentations
Meetings and Reporting
Project Team Organization
Each team can assign additional specialist roles to support project
management (see [OOTC] for example roles).
Responsibilities of all Specialists
Please note: Taking a specific specialist role does neither
mean that you have to do all the listed tasks by yourself, nor does it
free you from doing other work in your team. This project is a team
effort and you cannot complete the project alone.
Grading
References
http://www.cs.umu.se/kurser/TDBC18/CourseDescription.html
Last modified: Thu Aug 24 10:47:07 MET DST 2000
by jubo@cs.umu.se
Copyright © 1995-2000, jubo