Team Project Overview
Problem
Statement for Fall 2015
Challenges of Team Projects
This course covers the design and engineering of computer software
systems. As a student you have done many computing assignments that
were
likely small problems or single programs. You have not had to face the
problems encountered in designing and implementing a larger system. The
problems of large software systems are much different than the problems
of small systems. Management of the effort and communication becomes
more
difficult than the programming. It's a big challenge to be sure all
team
members share the same understanding of the problem and it's solution.
It's not enough to just solve your part of the problem, but your
solution
must integrate with the work of others. Documentation grows
exponentially
with the size of the project. Configuration and version control arise
as
major project problems. Importantly, undisciplined and individualistic
styles of software development won't work in a team setting and must
mature
into a process-oriented approach.
The result is a whole new set of problems that go far beyond the
pure
technical computer science issues. The reality is that the most
difficult
aspects of any real-world software development effort are NOT the
technical
issues, but the "people" issues. For 95% of software projects, we
KNOW how to solve the technical problems, but projects fail because we
haven't mastered the "people" problems. CSC 308 is about that new set
of
problems.
Most students enrolling in CSc 308 have had no experience of any
systematic
approach to software development. Their concept of software
development
is usually vague and poorly defined. One of the main goals of
this class is for students to learn what are the elements of a
disciplined, process-centered approach to software development.
Since there are many different kinds of software projects, no single
process works for all of them. However there are clearly
recognized ingredients that a successful process will incorporate. The
textbook explains these essential components to successful projects.
The course web site has specific examples. Your challenge will be
to identify what ideas and methods will be useful to your specific
project.
Read this great
advice from former students and examples
of
thrashing.
Project Planning
It is highly recommended that you create a project plan document so
everyone on the team knows how you intend to achieve your goals for the
project. McConnell provides a template and the instructor
has an example
customized for our class.
Software Development
Process
An important of your project plan is
deciding what overall development process your team will use. The
development process defines the key project activities and the order in
which they are performed. Typically, the activities include
Requirements Specification (including
user interface prototyping)
Feasibility prototyping
High level Design
Detailed Design
Implementation
Testing
Deployment
Maintenance
Most projects for this course lend
themselves to some variation of the Waterfall process. The
instructor strongly recommend the "Staged Delivery" implementation
strategy advocated by McConnell.
Infrastructure Activities
Infrastructure activities are those which span the
boundaries
of the phases outlined above. They are pervasive, on-going activities
which
support the entire development effort. For this course, the three
infrastructure
activities we will be emphasizing are Project Management, Quality
Assurance, and Configuration Management (aka Change Management).
Project management is concerned with plans, budgets, schedules,
personnel
assignments, tasks, milestones, and deliverables. It's the
management
task to see that the project gets completed on time and within budget.
Quality Assurance is concerned with ensuring that the product
conforms
to customer requirements.
Configuration
Management is essentially keeping all the project artifacts organized,
especially the different versions of work products and software assets.
Team Effectiveness
One of the course goals is to learn how to work
cooperatively as an
effective team. There are many factors contributing to effectiveness,
including:
achieving milestones on schedule, organizing effective technical
reviews,
submitting status reports, running organized team meetings, exhibiting
professional attitude and behavior, equitable distribution of tasks,
good
communication, clear expectations and responsiblities, cooperation in
resolving
conflicts, and so on.
Since this may be your first experience working in a team, it is not
expected that your team will operate ideally the first try. However,
problems
in team dynamics and functioning are part of the course, and you are
expected
to work toward resolving them. You are encouraged to consult with the
instructor
about strategies for overcoming difficulties. (The "Student
Survival
Guide" reference has many helpful hints.) If your
team is
struggling, it is crucial that you obtain instructor guidance early
while
there is still time to apply corrective strategies.
Mandatory Project Requirements
Your team is given the responsibility to determine the best way to
carry out the project. You are expected to read the textbooks,
the course web site and other resources and apply the principles
appropriately for the specific demands of your project. However,
there are a few requirements the instructor mandates (and even they are
negotiable).
Group Name, Logo, Name Tags
Research has shown that teams with a strong identity are often more
successful than those without. One way to begin to establish an
identity
is by having a team name, logo, and (optionally) a motto. You will be
given
a specific lab activity to create your team name. Your team
name
should be prominently displayed on your web page and on all
submissions.
When you submit individual assignments, like homework, also include
which
team you belong to. Each person will have a name tag that
includes
the team name that will be worn at each team meeting.
Trac / wiki
The instructor will create for each team
a
Trac website
that you are expected to use for all aspects of project control and
tracking. Use the ticket system for tracking tasks (action
items). Use the wiki for collaborative document
preparation. Use the Discussion/forum for asynchronous
discussion. Please use this Trac wiki formatted
home page template.
The template serves to organize your teams work in a standard layout
that makes it easy for the instructor
to find documents you've created.
This template is a skeleton that you will add more
links to as your team creates the necessary documents
for your project. Follow the SiteSetup
directions. Complete the "About
Our Team" section as a group activity.
Ticket guidelines: Create a ticket for any task that is estimated
will require more than 15 minutes to complete. If a task is
estimated to take more than a single work session (e.g., 90 minutes),
decompose the task and create multiple tickets.
Time tracking
Each individual must record all time spent on the project (not lectures
or assigned homework). There are several alternatives for
recording your time.
- The instructor recommends keeping a written time
log. There are several options for recording this data:
- Designated pages in a bound lab notebook.
- Binder pages in a loose leaf binder.
- A specific page on the team wiki.
- Record the
start and end time of each task in the Comments section of a Trac
ticket. Unfortunately not all activities for which you need to
record the time are actually "tasks" with a tangible outcome, and thus
don't belong in Trac. So you'll have to record these using one of
the previous alternatives. (E.g., meetings often don't
result in a concrete outcome, but you need to record the time
anyway. Don't create Trac tickets for planning meetings unless
you intend to create something tangible during the meeting, in which
case the ticket should describe what you are creating not that you are
meeting.)
Schedule
As recommended above your team should create a project plan, a key
element of which is a planned schedule of activities. The schedule
includes when you plan to submit each major work product (a
"milestone"). You must have the schedule completed and
approved by the instructor before the end of week 2.
You may customize this
suggested schedule.
Work Products / Deliverables
View the list of
recommended
project deliverables.
Formal Technical Review
Your must conduct at least one formal
technical
review of a work product with another team as
reviewers. It must be scheduled with another team and the
instructor at least a week in advance. Coordinate with the
instructor so that each team serves both as reviewers and reviewees.
Tools List
Unless otherwise negotiated, it is assumed your team will use the tools
on this list and source code will
conform to the class
coding standard.
Progress Report
The team manager submits a weekly team
progress
report electronically (or verbally - by arrangment) to the
instructor.
Document History
1/2/2012 JD Revised for Winter 2012
9/20/2011 JD Prepared for Fall 2011