Team Project Overview
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.

Read this great advice from former students and examples of thrashing.

Project Phases

Phase 1: Requirements Analysis (a.k.a. Requirements Engineering)
In this phase, you come to understand the problem and write a system specification that describes the problem and explains WHAT needs to be accomplished to solve the problem. The key word WHAT says everything; in Phase 1 you discuss WHAT you will do but refrain from describing how you will do it.

Phase 2: User Interface Design
In this phase you design how the user will interact with the system.  In this class the UI design is expressed in the form of a prototype you will construct.  There are several styles of prototypes.  You will negotiate with the instructor which is appropriate for your project.

Some projects may be required to complete a Proof-of-Concept prototype. This is not a UI prototype, but an exploratory system which demonstrates the technical feasibility of the software architecture. For example,  if your project were to add GPS navigation to the Palm Pilot, a proof-of-concept would demonstrate that the Palm OS can actually read the signals from the GPS hardware.

Phase 3: Software Design
In this phase you determine HOW the system is going to work. The Design has two sub-phases. High Level Design describes the overall structure of the system, and Low Level (or Detailed) design describes the algorithms of each module.  You will express your completed design with module headers that can be compiled in the target implementation language.

Phase 4: Stage 1 Implementation
"To proof of the pudding is in the pie," so to verify that your design will work you will implement some restricted but core functionality of your system.
 
Phase 5: Stage 2-n Implementation, Integration, Testing, and Release
You will use a "staged delivery" approach to releasing several version of your product. 

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 two infrastructure activities we will be emphasizing are Project Management and Quality Assurance.

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.

Other infrastructure activities that will play a minor role in 308 but will be more important in 309 are Tool Support, Documentation, and Configuration Management.


The Project Plan Document
           The Project Plan is the central document that describes and defines all project activities.  The instructor has provided a project plan template.  Your team is assigned to customize and tailor the plan to your specific project.  You may modify it in any way you like, subject to approval by the instructor.  Your team should create a Project Web Site whose key feature is your project plan.  This is due by the end of the second week of class.  When this task is completed, you take responsibility for the plan -- it becomes YOUR plan.  It should describe what your team is actually planning to do and should be kept current to reflect changes as the project proceeds.

Software Process
            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.  

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.


Administrative Guidelines
  1. Job Assignments
    Each person must have an assigned job in each phase.  It's crucial that the project tasks be equitably divided among everyone one the team.  If the bulk of the product is created by one or two, the team will be given a failing grade.
  2. Group Name and Logo
    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, motto, and (optionally) a logo. 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.
  3. Deliverables
    Every deliverable must be completed in a professional manner.  Pretend you are working for a corporation and are turning in something to your boss. Some specific requirements are:

Document History
 
Date  Author Changes
9/21/08
 JD
 Revised for Wtr '08
1/2/06
 JD
 Revised for Wtr '06
9/23/01 JD Revised for Fall '01
1/5  JD Moved prototype descriptions to Document Formats/Prototype
1/17 JD Fixed linked to WPE scoring page/Prototype
9/17/00 JD Removed sections on "The Boss" and "Notebook"