Course Project

The purpose of the group projects is to have the students apply the principles they learn in class on a group project that is large enough to exercise the project management techniques being discussed while small enough to be feasible within a one term course.

Work Products

During the course you will prepare the following work products. Each completed work product must be
  1. posted to your Group Website, and
  2. emailed to your TA before class on the date due.
Each document must have a revisions section in which changes to the document are tracked.

Marking

Each work product will be marked on the following basis:

Software Craft

All projects are expected to be conducted in a professional manner. Software craft will be a component of each groups marks. Marking will consider at least the following:

Deliverables

1. Group Website

Each group should pick on a "Group Name" and solicit project ideas. Then each group should create a group website which contains on the front age the following information:
  1. Group name
  2. List of group members
  3. List of prospective projects
  4. Pointer to the Meeting Minutes.
  5. Access to the running Demo System
  6. Anything else you think is important

Initial Demo

The initial demo consists of two parts:

1) The client demo should consist of a 10 minute demo and 5 minutes for questions. The goal is to pitch the project to the project sponsor. What is the project going to do? How does it work? What does it look like? The idea is to evoke the final project and get user feedback. The software will not be finished at this stage so some of what you show will be working prototype, some half working code, and other bits pure mock-up. A demo is theatre. Rehersal and planned story telling are as important running code.

2) The technical demo should consist of a 10 minute walk though the main design diagram and the software infrastructure and code base. Imagine that you are trying to pursade the clients technial advisor that you are up to the job. Your technical demo should answer the following questions:

  1. What is your development environment?
  2. Do you have a version control repository?
  3. Is compilation, server deployment (if necessary), and configuration done through a simple 'one-click/button/command'?
  4. Do your unit tests cover both normal and exceptional cases?
  5. Are defects documented, categorized, and prioritized?

3. Design Documents

3a. Project Charter and Feasibility Doc

The Project Carter is usually the first project document produced. It authorizes the project, describes the Why, What, How, Who and When. It is a concise high-level description of at least
  1. The customer,
  2. A problem statement (the business problem to be solved?),
  3. Project Description (the approach to be taken?),
  4. Goals, Objectives, and Design principles (How do you know if you are successful? What do you value?)
  5. The project scope (What is specifically included and excluded),
  6. Critical success factors (What is key to success, what are the key risks, and mitigation plans),
  7. Any assumptions and/or constraints
  8. Project organization, 
  9. Major milestones, and
  10. Roles and responsibilities.

A well written Project Charter anchors a project helping the team avoid mid project drift. Every project needs a charter! If the sponsor doesn't provide it, the development team should create one and get it approved! See the Templates Directory for a number of Proejct Charter Templates.

3b. SRS & Project Plan

Using one of the provided templates create a SRS document. Note that the functional requirements should be specified using the Use case methodology described in class and in your text book. Also at least one part of the system should be described with a Data Flow diagram. With respect to a project plan you can either 1) Augment the charter document, or 2) Create a seperate project plan. Regardless please look at the Project Plan Template for guidence regarding content.

SRS Evaluation

Imagine that you are handed this SRS and are asked to design  the associated system. Are the requirements spelled out clearly enough? The more comments you make the better. You should consider at least the following: Please use track changes in MS Word to added your commend and then send them by the due date to both the TA and the members of the other group.

4. Design Review (Not required for Winter 2013)

Each group X is to review the SRS of group Y = (X + 1) mod N whereis the number of groups (ie. your group number plus 1 unless you are the last group that does the first groups) . The list of groups and a pointer to their web pages with design documents can be found here. Imagine that you are handed this set of design documents and are asked to either build or create test cases for the associated system. Is the design described in enough detail? The more comments you make the better. You should consider at least the following:

5. Test Plan and Cases

6. Final Group Project Demo

Each group is to give a demos consisting of three parts:
  1. A short powerpoint overview of your project including the client, project goals, main requirements, high-level architecture. Be concise! Use lists and pictures/diagrams. Avoid using too many words on each slide. 
  2. A demo of your running system. Lead the audience through one or two of the main uses cases. 
  3. A question and answer period. Have all of your documents, your code repository, and meeting notes available for display. A typical question will ask you to trace a requirement from the Project Charter, to the SRS, through the test cases, into the code, and to its correspondence in the running system. BE READY! 

Please be sure to complete parts 1 and 2 in 15 minutes to leave time for questions. Note that I will stop you when 15 minutes is over. Please have all your materials arranged in a well structured way on a memory stick to assist in quickly accessing material. 

Project Website (Due on the final Demo Day)

Each group should have a website with at least
  1. Group name
  2. List of group members
  3. Pointer to the Meeting Minutes.
  4. Access to the running Demo System
  5. Anything else you think is important

7. Final Set of Work Products for Group Project

For final submission please prepare a binder containing printed copies of  at least the following:

The more evidence you can add that shows how your improved your work based on feedback from the marker and other students the better. Your code base should be made available on disc or zipped emailed to me. If  your code is available for me to run please provide me instructions.

Note on System Design & Detailed Design Docs
A complete set of design documents that cover both the architectural level and the detailed design level. Taken together the design documents should cover the architecture, description of module level system design, and documentation associated with database schema and UI as required. The goal is a paper investigation of the system design that can be refined before it is frozen in code. The design documents should also support verification that the system meets the requirements described in the SRS and support the creation of test plans and cases.

8. Project Post-Mortem

EACH STUDENT, should complete a Project Post-Mortem and email it to arc@cs.dal.ca. A template is provided in the template directory. Failure to submit a Project Post-Mortem will result in a zero for student participation.