CPE/CSC 580 Spring 2001 Team Project
[NOTE: This is still the description of the CPE 205 class from last term.
It will be slightly modified for this class, but the overall structure
will be similar. -- FJK]
Project Overview
An important part of this course is the term project.
As a member of a design team of around 5 students,
you will apply the methods and skills learned in class
to the design, specification, prototypic implementation,
and evaluation of a realistic application.
The emphasis for this class lies on the specification aspects,
and the implementation will be done in the next quarter.
Project Theme
The theme for the project in this class is the presentation of time-related
developments on maps, such as the change of population density in a country
during the last century, or the correlation between plant diversity and
precipitation in a state during the last 30 years.
Two important aspects of the project are the visual display of the
information (maps of various degrees of detail, focussing on different
aspects), the dynamic display of changes over time. Especially for the last
aspect, the use of computers is essential; similar information can be
displayed on maps only through sequences of images, which are more
difficult to comprehend.
The project is conducted in collaboration with Lori Fisher,
representing a potential customer for the software product to be developed.
Project Organization
Project Grades
The project consists of several parts, which will be graded separately.
Each team has to produce joint deliverables, which will be the basis
for the grades of all team members. The team members will also be asked
for feedback on the performance of the other team members.
This subjective feedback may be used to adjust individual scores.
Team members are also required to document their activities,
e.g. in the form of weekly report sheets.
You can obtain up to 100 points for the project; the allocation of
points to the different parts of the project is given below.
In total, the project contributes 30% to the grade for the class
(see the class syllabus).
Time Log
Each student must keep track of the activities performed for the team project.
These activities are reported in the time log, which must be submitted
every week on Monday (or Wednesday, if Monday is a holiday) by the end
of the lab session. Paper copies for the time log will be handed
out in class, and an electronic version
is available as a spreadsheet.
In your time log, you need to specify the main
emphasis of your work during that week, and then list individual
tasks or action items that you were working on.
Each item should correspond to a task or action item assigned
to you (possibly together with others) in your team, and must
have an entry for the date, the hours spent, the accumulated
time spent on that activity so far, an activity code from
the list of activity codes,
and notes.
You should distinguish between ongoing activities that
are on track with respect to your team's schedule,
late activities, and completed activities (indicate if
they were completed late, or on time.)
Project Part 1: Vision and Scope Document
This part of your project documentation gives a short overview of the intended system, and describes its scope. In some cases, this information appears in
a similar form in an "Executive Summary" of the project.
The vision aspect of the document shows how your system will make the world
a better place, where the "world" of course may be a somewhat restricted
environment in which your system will exist. It should mention the
most important features of the system, and how they influence the
tasks to which it will be applied by the user. It also indicates
the benefits for the client, the end users, and possibly your own
organization.
The scope outlines the range of functionality that the intended system
will provide, and usually also indicates important restrictions
that are relevant for the system.
These can be consequences of technological limitations,
marketing considerations, budget constraints, or other concerns
that can not be overcome within the framework of the intended project.
Further information on this topic, including a brief template for
a vision and scope document, can be found in Chapter 6 of
Software Requirements
by Karl Weigers
(see the textbooks section in the syllabus).
Project Part 2: Project Risks
This document identifies the potential risks your project may encounter.
A risk is the probability that adverse circumstance will actually occur.
The problem here is that you don't know in advance what those risks are,
and by the time you encounter a risk it may be too late, very difficult,
or very expensive to react in an appropriate way. So you should try to do
your best to anticipate possible problems, assess their likelihood,
estimate the impact they would have, examine ways to prevent the risk
from happening or lessen its impacts, and identify measures to be taken
in case the adverse circumstance actually occurs.
In addition to the actual project risks which affect the project schedule
or resources required for the project, you should also consider product
risks (the quality or performance of the software/system to be developed
is affected), and business risks (the organisation pursuing the project
is affected).
The Project Risks Template
can be used as a guideline for your documentation.
Project Part 3: Project Requirements
This document is the core part of your project documentation for this
class, and it will be most important for the actual implementation effort
during the next term. Here you specify the actual requirements for
the product to be developed. These requirements are described
at increasingly more detailed levels of abstraction, starting
from domain and user requirements, down to system requirements.
You have to use one or more requirements specification method more formal
than natural language, and appropriate for the abstraction level and
purpose. My recommendation is to use graphical methods such as
Data Flow Diagrams and UML diagrams, possibly accompanied or
augmented by JavaDocs.
Project Part 4: User Interface
Whereas the project requirements part documents the important aspects for
the developer, and often is the basis for a legal contract between the
customer and the development organisation, the user interface specification
or prototype often plays a very important role in convincing the customer
that the product to be developed is "right" for their needs, and conforms
to high quality standards.
You can also view the development of a prototype with very limited
functionality, but a relatively polished user interface as a sales
and markeding tool.
A frequently used strategy here is to illustrate the actual specification
of the user interface by showing some simulated screen shots that perform
the activities described in important scenarios and use cases.
In addition to that, these scenarios can also be demonstrated with the aid
of a prototype. In the electronic version of your documentation, you may
provide links to such demonstrations.
Project Part 5: Peer Evaluation
One of the effects of being heavily involved in the development of a
project is often a certain "blindness" of the people in the team,
preventing them from recognizing problems that may be obvious to an
outsider. In order to overcome this, peer evaluations are conducted, where
a team with similar qualifications and a comparable background examines
the status of the project, and provides feedback to the development team.
In our case, each project team will perform a peer evaluation of another
team. The evaluation will concentrate on the documents prepared so far
by the development team, in particular the requirements specification.
This feedback can be used by the development team when they put together
the final documentation. Contact between the two teams should be conducted
between two evaluation contact persons (one from each team). I suggest to
use mainly email for this purpose, since in practice it might be difficult
for these two persons to meet face to face regularly. If you happen to have
a friend in the other team, you should not use these personal contacts for
the peer evaluation business.
The evaluation team will give a short presentation in class.
In this case, the document is prepared by the evaluation team and
hosted on their Web pages, but must be linked from the development team's
Web pages.
The task of the evaluation team is not to "tear apart" the efforts of the
development team, but to provide constructive criticism with the goal of
improving the quality of the product, or in our case the documentation.
Make sure that your evaluation is conducted in a professional manner, and
that your evaluation document and the presentation concentrate on important
aspects of the project, not on the choice of colors or tools, aesthetic
criteria, or personal preferences of the development team.
Project Part 6: Final Documentation
The final documentation is essentially the collection of the previous
documents, possibly enhanced by additional sections or appendices.
The documentation should be updated to reflect any changes, as well
as feedback from various sources such as the customer representative,
peer evaluators, or representatives of management.
Project Presentations
Each team must give three presentations: One initial presentation about the
vision and the scope of the document, with an emphasis on convincing the
customer and management to go ahead with the project.
The second presentation is in the team's role of peer evaluators of a
another development team.
In the final presentation, the team presents the overall work done in the
respective framework, possibly including a prototype showing important
aspects of the user interface.
Web pages Copyright © 1996-2001,
Franz J. Kurfess,
Email: fkurfess@csc.calpoly.edu
Last modified: Tue Apr 24 10:46:35 PDT 2001