Figure 1.2a shows the timeline for the project in which all of these plans will take place. Currently, we are working on Project Planning, and we just completed our Client Review. We are concurrently working on prototyping, creating the basic functionality for the system by this December for the final report.

Figure 1.2b on the next page shows the basic plan for the next semester. We will spend a majority of the time testing the system and adding pseudo-requirements. The basic idea will follow our evolutionary cycle.

Figure 1.2a - CS 425 Timeline

Figure 1.2b - Projected CS 499 Timeline

1.3) Stakeholders

The members of Team Quoridor are the primary stakeholder, since the success of this project will be a key factor in the team’s progress in the Senior Project course. AI students will be another stakeholder, since this program would be helpful in aiding their education in programming AI modules. Professor Klein will also be a stakeholder in this project. He is the client, so he is dependent on Team Quoridor to successfully deliver a successful project.

1.4) Design Decisions

All aspects of design specific to the project can be found in the Quoridor Design Document. This includes such aspects as subsystem decomposition, hardware and software mapping, and user interface design.

2.) Development Process

The purpose of this section is to explain the basic outline of the timeline of the Quoridor project.

2.1) Lifecycle

In our project, we will be using our own model, the Quoridor Model (see Figure 2.1). This model is essentially a hybrid amongst three models. The Software Concept, Requirements Analysis, and Architectural Design phases will all be conducted concurrently, as denoted by the Sashimi Model. This is where we will collect data about Quoridor, get requirements from the client, design the game board and other interfaces, and start deciding on basic ways to implement the system. We divided the system into subsystems, and we will work on those separately through Detailed Design, Coding and Debugging, and Subsystem Testing. At this point in our lifecycle, we will work individually on subsystems in-depth, such as the Game subsystem and Interface subsystem. Then, the subsystems will be integrated into the main system and tested as a single unit. Once this basic product is completed, the additional features will be added to the system, using an evolutionary cycle. These additional features include allowing network play, inserting AI modules, and keeping recorded logs of game moves.

Figure 2.1 - Quoridor Model

2.2) Project Definition

2.2.1. Primary Objectives

(a) Meet with Client:

Talking with the client. This is necessary to continue.

(b) Define the task:

Formulating the project from what is explained from the client.

Defining key dates and milestones involved in the development of the project. This helps to divide the project into smaller sections.

(d) Formulate a plan of action:

Organizing the designed tasks into a logical order. This may take into consideration a Software Lifecycle Model.

2.2.2 Secondary Objectives

(a) Hear out the client with an open mind:

Listening to the client before assessing the situation. The client should give the whole story before deciding how to continue.

(b) Suggest design options:

Giving the client possible design options to help limit the scope of the project. The client may not know what he or she is looking for until we show some examples.

2.3) Requirements Analysis

2.3.1 Primary Objectives

(a) Analyze Problem:

Deciphering and understanding the problem of the client.

(b) Write Project Plan:

Designing a plan of action on how to approach the impending project.

Constraining system design based on client criteria.

(d) Choose project tools:

Determining tools to be used in the system. We will use:

- Microsoft Visual Studio.Net

- Microsoft Word

- Microsoft PowerPoint

2.3.2 Secondary Objectives

(a) Understand customer:

See things from the customer’s point of view to better understand how he envisions the project.

(b) Form tentative design ideas:

Start thinking about ways to design the system based on current specs.

2.4) System Design

2.4.1 Primary Objectives

(a) Design operational programs:

Create programs based on the current project criteria.

(b) Refine project plan:

Alter the Project Plan based on new design ideas.

Step back and see if the design adequately represents the requirements set in the Analysis phase.

2.4.2 Secondary Objectives

(a) Prepare for integration testing:

Design integration tests to link subsystems together.

(b) Set up change management:

Design a plan to deal with possible alterations to the system.

Team members should learn or recall skills for:

- Visual Basic .NET

- Socket Programming in VB

- A.I. Programming basics

- Microsoft Word

- Microsoft PowerPoint

(d) Do initial preparation for system test:

Prepare an test situation which will encompass all subsystems.

(e) Do initial preparation for acceptance test:

Prepare a test situation for the client.

2.5) Basic Prototyping

2.5.1 Objectives

(a) Encompass the design from the Requirements Analysis Document:

Developing a basic prototype from the design in the RAD. Useful for getting a concrete picture of something to start with.

(b) Discover basic pitfalls:

Determining if any aspects of planning or design in the prototype are feasible. It’s a good idea to fix major flaws early on before discovering them later in coding.

2.6) Prime Coding

2.6.1 Primary objectives

(a) Do detailed design, coding, and module test:

Prepare and test code for each module.

(b) Integrate modules:

Test modules together as one unit.

Document test cases for modules and for the system as a whole.

2.6.2 Secondary objectives

(a) Prepare in detail for system test:

Form a plan for testing the system in its entirety.

(b) Prepare in detail for acceptance test:

Form a plan for testing the system at the client’s site.

Form a plan for dealing with questions from the client.

2.7) Initial Testing

2.7.1 Primary Objectives

(a) Test system against Problem Specification:

Test the system to see if the problems defined in the beginning of the project are solved.

(b) Test as ‘live’ as possible:

Test the system in an environment that will match that of the client’s.

Have the system tested by non-computer majors to analyze aspects seen in a different view.

2.7.2 Secondary Objectives

(a) Train customer:

Train the client if he requests help. It is assumed that our client, Mr. Klein will need minimal help due to his background in computers.

(b) Write user documentation:

Compile documentation to aid users with our system. We will provide a Help Menu in the system and a paper User Manual.

2.8) Additional Functionality

2.8.1 Objectives

(a) Program, code, and test pseudo-requirements:

Add additional modules and functionality to the system. Have them tested as all other required functionality was tested.

(b) Determine time restrictions:

Determine how much additional functionality can be done with the amount of time remaining. If the previous parts of the project are running long, then there is no need for pseudo-requirements.

Checking to make sure adding extra features does not distort or place bugs in a working program with all basic functionality working correctly.

3.) Human Organization Plan

The purpose of this section is to organize the hierarchy of control amongst team members, clients, and other personnel.

3.1) Main Organization

Aaron O’Banion is the Project Manager and is responsible for organizing most aspects of the project. All questions and concerns will be forwarded to Aaron, who will make the final decisions for the project. Steven Klein is the main client contact. We will contact Mr. Klein if we would like to meet with the clients or if we have a question. Chris Cobb is the Lead Analyst, Matt Stowe is the Lead Tester, Mark Williams is the Lead Programmer, and Todd Astroth is Lead Documenter.

Rounded Rectangle: Steve Klein
Main client contact Rounded Rectangle: Bernard Waxman
Upper Management

Organization Chart

Figure 3.1 - Basic Organization Chart

3.2) Requirements Analysis Organization

Chris Cobb is Lead Analyst and is in charge of the Requirements Analysis phase of the project. The Lead Analyst will communicate with other team members to analyze what is needed in the system. Questions for the client are forwarded to Mr. Klein through Aaron O’Banion.

Organization Chart

Figure 3.2 - Definition Organization Chart

3.3) Design Organization

The Design phase of the project is mainly a collaborative effort of the whole team. Aaron O’Banion will communicate with other team members to make a final decision on an accurate design of the system. Questions for the client are forwarded to Mr. Klein through Aaron O’Banion.

Organization Chart

Figure 3.3 - Design Organization Chart

3.4) Programming Organization

Mark Williams is Lead Programmer is responsible for assigning programming assignments to other team members. Mark Williams will ensure that the project design is being followed and that the requirements for the project are being met with the programming that is done. Questions for the client are forwarded to Mr. Klein through Aaron O’Banion.

Organization Chart

Figure 3.4 - Programming Organization Chart

3.5) Testing Organization

Matt Stowe is the Lead Tester and will be responsible for coordinating the testing of the system. This includes the module, acceptance, system, integration, and site testing of the system. Questions for the client are forwarded to Mr. Klein through Aaron O’Banion.

Organization Chart

Figure 3.5 - System Testing Organization Chart

4.) Risk Management

The table below in Figure 4 summarizes the risks we have foreseen thus far and how to deal with the risk should it occur.

Risk	Description	Solution
Team Conflicts	Conflicts could arise between team members about the project or personal matters. This would slow the development process.	Private discussion with team leader or Upper Management.
Backtracking Difficulty	Upon development of certain features, such as the networking and AI issues, we may have to backtrack through design.	Team will redevelop design and proceed from there.
AI Functionality	We are unsure how the algorithms of future external AI modules may react.	Provide an error-checking capability to periodically check for problems.
Team Member Lost	A team member may need to leave the team due to reasons beyond the team’s control. This would increase the work load for the remaining members.	The unfinished work will be redistributed amongst remaining team members.
Acceptance Issues	During review, our client Mr. Klein may inform us that an aspect of the system contradicts the view of his expected criteria.	We would refer back to the contract to clear up confusion. If there is an error on our part, we will fix the issue.
Late Finish	The project could drag out as a result of additional functionality becoming more complicated than expected.	Additional features will be left out and the basic system would still be functional.

Figure 4 - Risks in the Quoridor Project

5.) System Testing Plan

The purpose of this section is to define the methods for testing the system and its components during the stages of the project.

5.1) Module Test

5.1.1 Objective

Test each subsystem separately to insure they have no internal errors. Make sure each subsystem satisfies the requirements stated in the Requirements Analysis Document. Make sure each subsystem reflects the design stated in the System Design Document.

5.1.2 Responsibility

Aaron O’Banion, Matt Stowe, Chris Cobb, Mark Williams, and

Todd Astroth. The Lead Tester may contribute more.

5.1.3 Procedure

Each module will be tested to ensure no unwanted results occur. Any linking capabilities with other subsystems will be taken into consideration and dealt with.

5.1.4 Tools

Microsoft Visual Studio .NET

5.1.5 Example

For the AI subsystem (see Design Document for subsystem decomposition):

· Start a game with a human versus an AI.

· Move across the board.

· Play a wall in front of itself at the very end.

· Move left, left, then off the board.

· Shut down after win.

5.2) Integration Test

5.2.1 Objective

The individual modules will be integrated together and eventually tested as one system. Once again, the integrated whole should represent the design laid out in the Design Document.

5.2.2 Responsibility

Aaron O’Banion, Matt Stowe, Chris Cobb, Mark Williams, and

Todd Astroth. The Lead Tester may contribute more.

5.2.3 Procedure

Modules will be grouped together in different combinations, until the groupings increase in size and encompass the entire system.

5.2.4 Tools

Microsoft Visual Studio .NET

5.2.5 Example

For the AI plus Network subsystems (see Design Document for subsystem decomposition):

· Start a game with a human versus an AI.

· Human attempts to take turn out of order.

· Network subsystem halts any such action.

· AI on another computer attempts to take a turn out of order.

· Network subsystem halts any such action.

5.3) System Test

5.3.1 Objective

The system will be tested in an environment similar to that of the cleint’s.

5.3.2 Responsibility

Aaron O’Banion, Matt Stowe, Chris Cobb, Mark Williams, and

Todd Astroth. The Lead Tester may contribute more.

5.3.3 Procedure

Non-computer majors will test the system in an environment much like that of the client’s. The user will play the game and try to give feedback on how the system appears to him or her.

5.3.4 Tools

Microsoft Visual Studio .NET

5.3.5 Example

In this example, we are testing our error-handling.

For the system as a whole:

· Play a specifically scripted game (Hotseat).

· Set Board size to 10x10.

· Set the wall limit to 15 walls.

· Specify 2 players on 1 computer.

· Start the game.

· Attempt to move a token 8 spaces away.

· Attempt to move past a wall.

· Use all 15 walls.

· Attempt to use walls now that there are no more to use.

· Attempt to lock a player in so he cannot possibly win.

5.4) Acceptance Test

5.4.1 Objective

The system should meet all requirements of the client.

5.4.2 Responsibility

Aaron O’Banion, Matt Stowe, Chris Cobb, Mark Williams, and

Todd Astroth. The Lead Tester may contribute more.

5.4.3 Procedure

The system will be tested at the client’s site using all functionality that he requested from the contract.

5.4.4 Tools

Microsoft Visual Studio .NET

5.4.5 Example

In the Quoridor game:

· Play a specifically scripted game which encompasses all error checking (like that seen in Section 5.3.5) for an exhaustive set of player combinations (such as 4 human players, or 3 humans and 1 AI, or 4 AI’s, etc.).

· Manipulate setup options before a game.

· Try suspending a game and restarting.

· Try winning and losing games.

6.) Alterations to the System

This section explains how Team Quoridor will deal with changes to the system during the project.

6.1) Baselines

6.1.1 Problem Specification

This is defined in the Requirements Analysis Document.

6.1.2 Design Specification

This is defined in the System Design Document.

6.2) Proposing a Change

6.2.1 Who May Propose a Change

(a) Team Members:

Aaron O’Banion, Matt Stowe, Chris Cobb, Mark Williams, and Todd Astroth.

(b) Clients and Other Personnel:

Steve Klein, Bernard Waxman

6.3) Investigating a Proposed Change

6.3.1 Who, How, When

All team members will be in charge of investigating a proposed

change. Any major changes to the project structure will result in a version update of any documents involved.

6.3.2 Investigation Report

The team will analyze the change during meeting hours and design solutions to the change. Any discovered major changes will be updated in the applicable documents (RAD or SDD).

6.4) Change Management Board

6.4.1 Membership

Aaron O’Banion, Matt Stowe, Chris Cobb, Mark Williams, Todd Astroth

6.4.2 When it Meets

The change management board will meet during the group’s regular meeting hours: 6pm to 9pm Monday and Wednesday in Dunham Hall 2009.

6.5) Implementing a Change

6.5.1 Approvals Needed

(a) Project Team:

The project team needs to form a general consensus among members. In the end, the Team Leader will make the final decisions.

(b) Client:

The client does not have to approve a change before it can be implemented, unless the change is considered to be outside the boundaries of the client’s scope.

6.5.2 Documenting the Change

Major changes will be updated in the applicable documents affected: namely, the RAD and SDD.

6.5.3 Scheduling the Change

The project will be rescheduled in the event that a major change has been implemented.

7.) Required Documentation

This section maps out our plan for documentation involved in the project. Each major document will adhere to the guidelines set in this section. Major documents include:

§ Requirements Analysis Document

§ System Design Document

§ This Project Plan Document

§ Weekly progress logs (for each team member)

7.1) Publication Procedures and Responsibilities

7.1.1 Preparation and Approval

Documents other than logs will be reviewed by Team Quoridor. If future changes are necessary to these documents, the changes will be executed through the Alteration Plan (see Section 6). The Project Manager will make the final decision on the posting of version updates.

7.1.2 Typing

Each document will mainly be written and compiled by the Lead Documenter. Other the team members can contribute to typing as well. Once each section is completed, the document will be ready for proofreading and editing.

7.1.3 Proofing and Editing

Documents other than the logs will be proofread by the team during regular team meetings. Once the entire document is proofread, the Lead Documenter will edit the document based on the requests of team members.

7.1.4 Distribution

The client may request any documentation at any time. All versions of the documentation will be kept with the Lead Documenter.

7.1.5 Electronic Storage

All documents will be available via the project website at: http://www.cs.siue.edu/SeniorProjects/f05g1/

7.2) Project Document Template

7.2.1 Title Page

All project documents other than logs will have a title page that contains the following: the name of the document, the Quoridor logo, the authors of the document, and the version of the document.

7.2.2 Numbering

All documents other than logs will be numbered numerically with subsections indicated with decimals. After two decimals, sections will be alphabetically labeled.

8.) Human Training Plan

This section provides what training will be needed for both internal and external sources. Internal sources include members of Team Quoridor, and external sources include the client and other spectators.

8.1) Internal Training

8.1.1 Coding Languages

Team members have used Visual Basic before, team members will need to recall their Visual Basic skills. Also, members need to learn how to use socket programming for manipulating networks.

8.1.2 Interfacing With Other Subsystems

Team members will need to understand how to link subsystems together over a network in order for the system to function as a whole.

8.1.3 AI Modules

Team members are responsible for understanding how to implement basic Artificial Intelligence modules so that we can add this functionality to the system later. We should also be able to make this functionality as easy to use for our client and intended audience.

8.2) External Training

8.2.1 Installing the Software

The team will install the finished Quoridor project on the computer(s) of the client’s choice. The team will train the client if the situation is deemed necessary.

8.2.2 Using the System

Once again, the team may provide help to the client with the system if it is needed. We will provide a User Manual and a Help Menu for the system to help answer most user questions.

9.) Review and Reporting Plan

This section explains how we will review and report the group’s progress during the Senior Project. Reviews and reports are generally formed on a regular basis. Written content can be found on our website. More information about written documentation can be found in Section 7.

9.1) Reviews

9.1.1 Documents

The team will create three major documents – namely the Requirements Analysis, Software Design, and Project Plan documents. These will be submitted to Upper Management to review.

9.1.2 PowerPoint Presentations

The team will create presentations to review what we have done so far. These presentations will take place at regular intervals during both semesters. The audience will mainly include other team members and Upper Management. During Final Presentations, other Computer Science staff and the client will be attending.

9.1.3 Client Acceptance

The team will contact the client when a major milestone has been completed or when a major question or concern has come up.

9.1.4 Upper Management Acceptance

In addition to reviewing the documentation mentioned in 9.1.1, Upper Management will provide verbal feedback about the status of the project and the team.

9.2) Reports

9.2.1 Individual Weekly Team Member Logs

Each team member will report what he does with regards to the project each week. These will be compiled and checked for consistency by the Team Manager each week. These logs will be turned in to Jason Morris as a means for Upper Management to assess Team Quoridor each week.

9.2.2 Meeting Notes

On occasion, the Lead Documenter will compile a list of important notes based on discussions from group meetings. These notes will generally be in a Word document.

10.) Installation and Operation Plan

In this section, we define how and where we will install and operate our completed system.

10.1) Installation

10.1.1 Responsibility

The development team – namely Aaron O’Banion, Matt Stowe, Chris Cobb, Mark Williams, and Todd Astroth – will install the system at the client’s site.

10.1.2 Schedule

The installation of the system will occur on or before April 25, 2006.

10.1.3 Multiple-Site Considerations

Team Quoridor will be responsible for the installation of the system

at the client’s site only. The system may be distributed from that point forward as the client wishes.

10.2) Operation

10.2.1 Responsibility for Operation

The client will be responsible for all aspects of operating the software after it has been installed by the team.

10.2.2 Responsibility for Maintenance and Tuning

No maintenance or tuning will be provided for.

10.2.3 Duration of Responsibilities

The Quoridor team will be responsible for the software product until the client accepts the final product or until the end of the Spring semester 2006.

11.) Hardware and Software Requirements

Expected hardware for the project will include a PC with the appropriate specifications to run a current version of Windows XP. Microsoft Visual Studio will be used for programming and designing our application. We will need access to a computer network for designing games between multiple computers.

12.) Contributions

Project Plan:

Todd Astroth – Initial rewriting and editing (all sections) of Project Plan Document

Aaron O’Banion – Wrote basic outline of PPD, proofreading and editing of Project Plan Document

Matt Stowe – Designed the plan for the project, extensive proofreading and editing of Project Plan Document

Mark Williams – Designed the plan for the project, extensive proofreading and editing of Project Plan Document

Chris Cobb – Designed the plan for the project, proofreading and editing of Project Plan Document, designed test cases

Project Plan Presentation:

All team members are responsible for designing and presenting their respective speaking sections of the presentation.

Website:

Chris Cobb

Poster:

Chris Cobb