Documentv6

Software Project Management Plan

(SPMP)

Project Title: Accelerated Maths - Gifted Education

Team Name: The Mathemagicians

Term Definition

Application, (The) The Program developed as the project solution: EG The “Accelerated Maths” application.

Client Ararat Community College, Joanne Tate

Client Environment Hardware/Software used by the client to host the application/solution

Development Environment Coding/applications that will be used to develop the application, e.g. WAMP server, Microsoft FrontPage, etc.

Project Development Team/Project Team/Development Team

Team A – The Mathemagicians.

Solution, Project Solution The project Deliverables developed by the Project Team, as specified by the client

TBA To Be Announced

SPMP Software Project Management Plan

WAMP Windows Apache MySQL PHP(An open source software package designed to encompass the needs of web based database access and web site creation).

1. Project overview

This section is designed to give an overview of the project.

1.1 Project name

Accelerated Maths.

1.2 Project description

The sequence covers concepts typically found in an accelerated curriculum appropriate for students who are self-motivated and have strong independent learning skills.

Sets, Logic and Probability Arithmetic of Integers Measurement, Graphs and Equations Fractions and Decimals Geometry

Students progress in areas of addition, subtraction, multiplication, division, fractions, decimals, number concepts, equations, word problems, geometry, measurement, probability, statistics, graphs, functions, logic, and set theory.

New concepts are introduced through brief animated lectures. Exercises that follow lectures reinforce concepts, and students receive immediate feedback. As students master concepts, they are moved more rapidly through material. Students needing more explanation or practice in a particular area are given additional drills. Math Races, a game within the sequence, provides drills on arithmetic operations.

1.3Scope

This section of the document describes the boundaries of the application to be developed.

1.3.1 The computing environment

The computers are operating on Microsoft Windows XP The computers have Office XP installed The computers use Internet explorer to navigate the web. There are approximately 120 computers in the school. The solution is expected to be installed on all computers. The computers do not have DVD drives (CD-ROM’s only)

1.3.2 The Mathematic problems

At this point the project team are to provide the mathematical problems At the start of each session, a small mathematics game will be presented to

engage the student. A session should be expected to last approximately 20minutes. The client would like to have the option of scaling up the problems, or adding

new problems at a later date.

1.3.3 The lesson environment

At the end of a session a list of suggested homework should be presented. At each problem a button should be displayed to allow a mini lesson explain-

ing a key concept. Reports should be made available to teachers. The student should have available bookmarks to jump to certain sections.

1.3.4 The game

The game should be a fun engaging game Some sort of racing or time based tests for score Some sort of car or diver. Short game, more of a warm-up

1.3.5 The solution

The client has no clear choice as to actual solution technology No problem with internet or CD based solution Internet would be good for the dissemination practices This is to be based of the john Hopkins educational CD

1.3.6Target Audience

The target audience is students in the year levels 7 and 8 The advanced aspect of the subject is students performing mathematics 2

year levels ahead of their current year level. The students are expected to have solid core computing skills, and a general

skill set in using the internet. The staff responsible for maintaining the solution have an advanced IT skill

set, and are familiar with using the internet.

1.3.2 Objectives

This section describes the objectives required to be met, in order for the project to be deemed successful.

1.3.2.1Team Objectives

The primary objective is to create a piece of educational software for deployment across the entire secondary school, targeted (at the initial release) for students in year 7 and 8 who are conduction studies in advanced mathematics. Further details about the specifics of the software can be found elsewhere in this document.

The secondary objective is an educational exercise for the project team. As students at the University of Ballarat there are certain requirements outside of the clients expectations that the team needs to fulfill. These objectives are over and above any statements of work or other estimations shown in this document.

Any tertiary objectives refer to any educational milestones or achievements and will not

be considered here.

1.3.2.2 Client Objectives

The client’s primary objective is to obtain a free piece of educational software for deployment at their school. Through client communication, it is clear that this software will be used at an educational aid.

1.3.2.3 Project Objectives

The project is to be appropriate for junior high school students who are interested in advanced mathematics, advanced mathematics refers to math’s problems aimed at students 2 years above their current year level (e.g. an advanced year7 student would be solving year 9 math’s problems).

1.3.2.4 Supervisor Objectives

Since the supervisor has an interest in mathematic studies he chose to be the supervisor for this project. His personal objectives are private at this point.

1.3 Project Website

All stakeholders will have access to a website which will contain information and documentation related to this project. The website will be available for use 24 hours a day, and will be regularly updated with current information. For more information, refer to section 22 of this document.

1.5 Schedule

1.6 Deliverables

Throughout this project, the following deliverables will be provided to the client. For further details about the deliverables to the client, refer to X.X Deliverables to Client.

Prototype-model of Advanced Mathematics application Compact Disk of application Maintenance & support Team ‘A’ Mathemagicians Website Presentation Documentation of a user manual (if required)

1.7 Stake Holders

Stakeholders are all the people that are interested and involved in the success of a system. The stakeholders are categorized in three various groups:

1. The Users: Students and Staff of Ararat Community College

2. The Clients: Ararat Community College (Joanne Tate, Maths lecturer)

3. University Support: Project 1 Coordinator ( Shamsheer Syed ), ‘Team A’ Supervisor (Jason Giri )

4. Project team: ‘Team A’ members (Jason Wade, Alexander Stewart-James, Douglas Wainewright, Bibasna Dewan )

1.7.1 The User Stakeholders

The users are the students of Ararat Community College who will be using the application. The application’s aim is to satisfy the users as the new system may affect their academic results.

1.7.2 The Client Stakeholders

Joanne Tate and Peter are the clients or the project sponsor that must be prepared to make time available for the team to discuss needs and requirements for the project. This commitment is essential for the accurate outcome of the application.

1.7.3 University Support Stakeholder

Shamsheer Syed and Jason Giri are the universities stakeholders for this project. As course coordinator and project supervisor respectively, they aim to keep the universities involvement in other projects, by ensuring all projects completed are to standard.

1.7.3.1 Project Coordinator

The project coordinator Shamsheer Syed, monitors the progress made by the team throughout the project. The coordinator ensures that the team has appropriate information regarding the project proposals and other approvals.

1.7.3.2 Project Supervisor

Jason Giri is our project supervisor who will provide guidance and support for the entire period of the project. The supervisor will have responsibilities such as giving feedback and advice at a regular basis to help the team progress in various phases of the project. Supervision is the ultimate responsibility to ensure that good communication exists between the members of the team, supervisor and clients.

1.7.3.3 Team A Members

The Team members Jason Wade, Alexander Stewart-James, Douglas Wainewright and Bibasna Dewan are expected to understand the purposes of each task completed. The members of Team A are the greatest stake holders due to the fact that their course grade, finances and reputation rely on this project. Team A will provide various development reviews and documents to the client and supervisor, in order to receive feedback from them.

1.8 Project Sponsor

1.9 Project Co-ordinator

1.10 Project Supervisor

1.11 The Team This section of the document will briefly describe the project team.

1.11.1 Team NameThe Mathemagicians.

1.11.2 Team member details

The Technical Staff

The Client

The users

Project ManagerJason Wade

SupervisorJason Giri

Project CoordinatorShamsheer Syed

Team Members

The ClientArrarat Community Colledge

(Joanne Tate)

The Users

Student Name Student ID Phone Email Address Jason Wade 2352251 0421 470 353 [email protected] Alexander Stewart-James 2251167 0423 983 770 [email protected] Douglas Wainewright 2352213 0409 192 755 [email protected] Bibasna Dewan 2352839 0424 597 652 [email protected]

Project Supervisor Location Phone Email Address Jason Giri University of Ballarat T124 (03)5327 9261 [email protected]

1.11.3 Team objectives

Team objectives: As a team, we are aiming to create highly effective software with our diverse

skills. Put forward our organizational and team-working skills. Surpassing all requirements of the project in the highest of standards. All of the team members want to excel in Project 1 with a High Distinction(HD).(See X.X)

1.11.4 Team member roles and responsibilities

Roles MemberProject Manager Jason WadeAssistant Project Manager Alexander Stewart-JamesLead Developer Alexander Stewart-JamesAssistant Developers Whole TeamDesign Bibasna Dewan, Jason WadeTesting/Debugging Bibasna Dewan, Douglas WainewrightQuality Assurance Bibasna Dewan, Jason WadeSecretary Douglas WainewrightChief Librarian Douglas Wainewright, Alexander Stewart-JamesWeb Manager Alexander Stewart-James, Douglas WainewrightLead Programmer Alexander Stewart-JamesAssistant Programmer Whole TeamLead Analyst Bibasna DewanAssistant Analysts Whole TeamDocumentation Whole TeamRisk Manager Jason Wade

2 Solution Engineering Plan

This section of the document describes solution standards to be used throughout the project.

2.1 Solution Standards

mailto:[email protected]



TBA

2.2 Version Control

This section of the document describes code and document versioning rules for the project.2.2.1 Documentation Version Control

Version control rules are in place to track all documentation for this project. For more information on document version control methods used, please refer to section X.X of this document.

2.2.2 Code Version Control

Version control rules are in place to track all code for this project. For more information on coding version control methods used, please refer to section X.X of this document.

2.3 Naming Standards

Documentation naming conventions will be used on all documentation related to this project. For more information on version control methods used, please refer to section X.X of this document.

2.4 Programming Specifications

TBA

2.5 Data Privacy

TBA

2.6 Development Environment Control Plan

This section deals with the environment used for the applications development, and controls that will be placed to ensure it is kept to standard.

2.6.1 Hardware

TBA

2.6.2 Software

TBA

3 Test Plan

This section outlines the policies and procedures used to describe the project testing requirements and specifications.

3.1 Overall Test Strategy

This test plan is produced in order to outline how the ‘Accelerated Maths’ Project is to be made reliable and compliant with guidelines specified by the client. Contained within this test plan are the procedures for testing and testing requirements, in order to ensure that requirements outlined in the project scope are met successfully.

The majority of testing will be undertaken by the Project Development Team (Team A – Mathemagicians), except for User Acceptance Testing, which will be undertaken by the Client, at their request, and on their time, at a date to be announced.

The types of testing undertaken will consist of the following tests:

Unit Tests

System Tests

Use case tests

Black Box Tests

Installation Tests

Recovery Tests

User Acceptance Tests

The Testing of the system will be undertaken during the development phase of the project, during/after the majority of the initial application coding has taken place. User acceptance testing will take place after the Tests that are required to be undertaken by the Project Development Team (Team A – Mathemagicians) have completed.

3.2 Unit Tests

Unit tests will be completed by the Project Development Team (Team A – Mathemagicians) during the production of the application code, and after the majority of the code has been written. Tests will need to be documented and executed by the test team.

The Tests will be developed by the test team based upon the application code, to determine accurate functionality of each coding unit, and bug-free operation.

Unit Tests will test for

Negative test cases.

Positive test cases.

Alternative test cases.

3.3 System Tests

System Test will also be undertaken by the Project Development Team (Team A – Mathemagicians). It will involve testing of the application as a whole.

The System tests will be developed by the test team based upon the application code, to determine accurate functionality of the system as a whole and bug-free operation.

System Tests will test for:

System failure cases.

o Including System Operation as a whole.

Server-Client Interoperability

o Including Load testing

o Data Transfer testing

3.4 Use Case tests

Use case tests involve mapping out all the different ways a user can perform a certain task in the project, and then ensuring that each method can be ‘stepped out’ and works as expected. These cases will then be documented and added to any existing testing documentation and at a later date the user documentation.

3.5 Black Box Tests

Black Box testing will be conducted to ensure that expected output occurs due to the input of test data. The Tests will be conducted by the Project Development Team. Again, the tests will be conducted after the majority of functional code has been written.

Black Box testing will test for:

Expected output matches pre-determined input.

3.6 Installation Tests

Installation tests will be conducted to ensure seamless installation of the Project Solution on the Client environment. The test will take place on a replica of the Client Environment, and also later on the actual client environment. This will be conducted by the Project Team and by the client during User Acceptance Testing.

Installation Tests will include the following:

Installation of solution on a replica of the Client Environment (IBM-Compatible personal computers, Windows XP)

Installation of solution on the actual Client Environment.

3.7 Recovery Tests

The Recovery Tests will be undertaken by the Project Development Team on a replica of the Client Environment. The test will be undertaken to ensure that the solution can be restored in the event of a failure.

This test will also be carried out on the Client environment if they request it.

Confirmation that Re-installation can be performed with minimal problems, e.g. No data corruption due to currently installed files.

3.8 User Acceptance Tests

User Acceptance testing will consist of the user performing a test of the application in order to determine of the application has met their requirements. User acceptance testing will occur after all other tests have occurred, and will be conducted by the client.

User acceptance testing will include the following:

Full Installation of the Application and other required software components.

Usage of the application by the client to determine if application functionality meets requirements.

(Detailed Test Plan? Master Test Plan? – Separate Doc?)

4 Work Schedules

4.1 WBS

4.1.2 Milestone ScheduleWork Schedule

Work Progress TrackingThrough use of meetings?

5 Organisation and People

Organisational Structure (flowchart)

Resources Plan:(Timely Estimates of resource usage for each phase of SDLC)Skills Development Plan (Training - NA?)

6 Dependencies Management Plan

The Dependencies Management Plan exists in order to manage potential issues with

factors that the project may depend on.

The Accelerated Maths project has few critical dependencies. An outline can be found as follows:

6.1 External Dependencies

Finding and implementing an appropriate Version of PHP server, e.g. apache, WAMP etc.

Any special licensing requirements (NA as of 13/03/2006, due to the open-source nature of the development environment) that may arise due to any implemented change.

Any problems with external dependencies that need to be resolved can be brought to the attention of the external party by the Project Development Team, by the most effective communication channel (Email, Phone call, face-to face meeting). If an immediate solution can not be found, then an alternative must be developed by the Project Management Team, in accordance with an official change request.

Conversely, if the Problem is bought to the attention of the Project Development Team by the external party, the Development team will attempt to resolve the problem as quickly as possible. If an immediate solution can not be found, then an alternative must be developed by the Project Management Team, in accordance with an official change request.

6.2 Internal Dependencies

None Applicable.

6.3 Client Dependencies

Availability of Client to conduct meetings

Provide adequate Scope details, and notify the Project Team of any required changes, and additional requirements.

Eventual Acceptance of the project solution.

Any problems with client dependencies that need to be resolved will be brought to the attention of the client by the Project Development Team, and an immediate resolution sought. Conversely, any problems bought to the attention of the Project Development Team by the client will also have to be resolved. If an immediate solution can not be found, then an alternative must be developed by the Project Management Team, in accordance with an official change request.

6.4 Subcontractor Dependencies

There are no subcontractors currently assigned to this project so they have no dependencies at this time. If subcontractors are added this section will be amended.

6.5 Supervisor Dependencies

To provide timely and accurate feedback in regards to any aspect of the project solution development, e.g. Documentation, work requirements, deadlines, etc.

If any dependencies are not met by the supervisor, the Project Development Team will contact the supervisor as soon as possible, by way of a meeting. Conversely, if the supervisor requires action by the Project Development Team to meet a requirement, the supervisor will communicate with the Project Development Team at the earliest convenience.

6.6 Inspection and acceptance process

Any dependency-related deliverables that need acceptance will be referred to the client for sign-off. The client must then review the dependency and decide upon a course of action. The dependency review-for-acceptance can be undertaken anyway the client prefers, providing that it is completed in a timely manner, and does not hold up the project.

The sign off must occur before the dependency can be implemented. A verbal sign-off is sufficient providing that it is recorded in meeting minutes.

6.7 Reporting and reviewing process

Dependency reviews will initially be conducted by the Project Development Team.

Dependency-related problems are to be reported to the Development Team by the most convenient means necessary/available. This can take the form of a phone message, Email, Face-to-face meeting, etc.

Any problems encountered with dependencies are to be discussed with the affected party, e.g. Any licensing dependency problems will be resolved by either consulting the service providing the license, or the service will be withdrawn and an alternative will be formulated by way of an official change request brought about by the Project Team and/or Client.

The following is an outline of the reporting and reviewing process for dependency-related issues:

Dependency-related issue discovered

Issue bought to the attention of the involved party

Issue resolution conducted, by way of a meeting, research, etc.

Dependency issue solved

Issue resolution carried out by way of a change request.

8 Financial Management

Not Applicable

9 Quality Management

This section of the document contains information regarding the requirements

9.1 Quality Assurance Tasks

Quality Assurance is the process designed to evaluate and ensure that an information system meets quality standards. The quality assurance tasks are a set of activities that are performed periodically throughout the project. The tasks involve identifying inconsistencies and fixing the errors to build systems appropriately, satisfy the planned requirements that were set for bug-free programs, testing activities, and assessment of these measures taken.

To avoid the derailing of Quality Assurance Tasks, the team shall integrate Quality Assurance from the initial stage of the project. Quality Assurance will also be established well with the team environment of sincerity, openness and respect amongst one another. This allows the Quality Assurance Tasks to be effective as the suggestions and feedback impact on the end result of the product.

The Quality Assurance Managers will scrutinize the quality tasks. All quality evaluation and records will be safely stored to avoid loss or deterioration of the project.

10 Project Management Controls

10.1 Change Management

10.2 Issues Management

11 Deployment, Maintenance and support Plans.TBA

12 Team Information

This section gives detailed information on the project team.

12.1 Team Name

The Mathemagicians.

12.2 Team Management

This section gives a detailed description of the management of the team.

12.2.1 Management Style

The team management style for this project and project team will aim to allow all members an equal input in the decision making stages. The final decision will be made by the project manager if no compromise can be reached. Any decisions made by the project manager may be over-ruled by the project supervisor or course coordinator.

12.2.2 Team Member Roles

Specific roles have been devised for this project, and divided between team members to spread the workload, and reduce total project creation time and overlapping of tasks.

The roles are as follows:

Project Manager Assistant Project Manager Lead Developer Designer Testing/Debugging Quality Assurance Analyst (Internal) Secretary Chief Librarian Web Manager Lead Programmer Assistant Programmer Lead Analyst Assistant Analyst Documenter Risk Manager

12.2.3 Role Definition

The roles defined in section X.X above, are detailed as follows:

Project Managero This role requires management of team members, team meetings and

interviews with the client, as well as keeping track of risks, issues, milestones and other related information, in regard to the project. This role requires a person with outstanding team work, organisational and communication skills.

Assistant Project Managero This role is designed to create a fallback for the Project Manager role,

should unforeseen problems occur. This role requires the same understanding of the team and project as the Project Manager role. If the Project Manager is unavailable, the Assistant Project Manager should take over his/her role, ONLY for as long as is necessary..

Lead Developero

Designer Testing/Debugging

Quality Assurance Analyst (Internal) Secretary Chief Librarian Web Manager Lead Programmer Assistant Programmer Lead Analyst Assistant Analyst Documenter Risk Manager

12.2.4 Role Structure

The following diagram illustrates the role structure for this project.

Project SupervisorJason Giri

Lead ProgrammerAlexander Stewart-James

Chief LibrariansDoug Wainewright

Alexander Stewart-James

Risk ManagerJason Wade

AssistantsDoug Wainewright


AssistantsBibasna Dewan

Jason Wade

Assistant Project ManagerAlexander Stewart-James

Lead DeveloperAlexander Stewart-James

DesignerBibasna Dewan

Jason Wade

Lead AnalystBibasna Dewan

Testing/DebuggingBibasna Dewan

Doug Wainewright

Quality Assurance ManagersBibasna Dewan

Jason Wade

SecretaryDoug Wainewright

Web ManagersAlexander Stewart-James

Doug Wainewright

Project ManagerJason Wade


Alexander Stewart-JamesJason Wade

AssistantsAlexander Stewart-James

Jason Wade




Alexander Stewart-JamesJason Wade


Bibasna DewanAlexander Stewart-James


Jason Wade

Project CoordinatorShamsheer Syed


Bibasna DewanJason Wade

12.2.5 Team Member ResponsibilitiesRoles that team members are responsible are listed below, for further description of these roles, refer to section X.X of this document.

12.2.6 Team GuidelinesThe Team Guideline section outlines areas such as the decision making process, dispute rectification guidelines and escalation chains, in order to help guide team members through the project lifecycle. It also gives team members a chance to set personal expectations for this project.

12.2.7 Decision Making ProcessTeam decisions based around project creation will be reached through a process of mediation between team members. It is hoped that this process will negate the possibility of a dissatisfied team member, with decisions being reached which allow all team members to feel as if they have had an equal input.

12.2.8 Dispute Rectification GuidelinesThe team members involved in the project are strongly encouraged to come forward with ny minor or major disputes or differences they feel should be recognized. The aim of this mentality is to ensure that differences are resolved as soon as possible and without major discourse to the project, thus ensuring a smooth creation phase, with no major errors or unwanted behaviors.

12.2.9 Dispute Escalation ChainThe following report to chain will be used when dealing with an issue or valid dispute regarding the project.

12.2.10 Personal Expectations

12.2.10.1 Douglas Wainewright

I expect to utilise my time, skills and experience to help my team achieve a significant mark for our selected project. At the same time, I hope to produce a useful application for the client, that can be utilised in full for their intended purpose. At all times I expect to

act in a professional and dignified manner in order to acheive my project goals.

I expect that the extra experience gained during the course of this project will help me to obtain a better working attitude, and enable me to become more employable.

12.2.10.2 Alexander Stewart-James

As a part of this project team, I expect that all team members will contribute equally to the project, and that we will achieve all milestones set within the project guidelines. I expect that all milestones will be achieved to the fullest of their potential, on time and on budget.I expect to gain extra skills and experience in PHP and WAMP, as well as team work and communication.

12.2.10.3 Jason Wade

12.2.10.4 Bibasna Dewan

13 Meeting Outline And ScheduleThis section outlines schedule information and guidelines in regards to the administration of team, supervisor and client meetings.

13.1 Team Meeting Schedule

The majority of Team meetings will be held on a designated basis, which the team has scheduled for Tuesday Evenings at 5:30 PM – after the guidelines for the next requirement for Project1 have been set in the tutorial held on Tuesdays at. 4:30 PM. The meeting will endure for approximately 1 hour.

A further meeting time slot will be provided for the night before a work requirement needs to be submitted. This will generally be a Monday night, and will endure for as long as necessary to collaborate the individual team member's work, and to format the final submitted work document/assignment.

Any further meetings will be scheduled as necessary, and will endure for as long as necessary.

Meeting minutes will be documented by the Team Secretary, or in the absence thereof, a designated stand-in.

13.2 Team Meeting Guidelines

All team members will need to be aware of each planned meeting. Accordingly, each team member will need to inform the group of any meeting absence before the fact, except in the case of extreme circumstances.

Meeting Minutes will be conducted by the team Secretary, and in the case of the secretary's absence, a designated stand-in.

Meetings will typically follow the following format:

1. Team meets in the airport lounge at designated meeting time.2. Team relocates to a room with unused computers3. Meeting/project requirements are discussed and/or formulated.4. Task requirements are allocated to individual team members5. A task deadline is implemented, typically the day before the requirement is

due, in order to collaborate and/or seek feedback from a third party (e.g. supervisor/lecturer/client.)

6. Any other meeting/task requirements are discussed7. Any other issues raised.8. Meeting Adjourned9. Official Minutes are composed10. Entry into team Diary recorded.

13.3 Supervisor Meeting Schedule

Supervisor meetings will generally be held as required on an informal basis. Jason Giri (team Supervisor) is mostly available at the following times:

Monday between 10:30 and 12:30 Tuesday between 9:30 and 11:30 Thursday between 9:30 and 11:30

Jason Giri will be available weekly for meetings during the Thursday meeting time slot.

13.4 Supervisor Meeting Guidelines

It is a requirement of the Team Supervisor's that we notify him early of any meetings that we need to undertake. The meeting shall follow the typical format:

1. Team Requests meeting2. Supervisor accepts/denies meeting, or offers an alternative3. Team meets with supervisor at agreed time4. Project issues are discussed5. Issues resolved or prompted for further investigation6. Other requirements discussed7. Overview of team's progress delivered to Project Development Team.8. Meeting summation9. Meeting adjourned10. Meeting minutes formulated11. Entry recorded in team diary.

13.5 Client Meeting Schedule

Client Meetings will not follow any typical schedule (as of 13/03/2006) due to the client's availability. Meetings will be scheduled when necessary, by the Project Team or the client, and will need previous notification by the meeting initiator.Meeting schedule is due to change subject to the client's availability.

13.6 Client Meeting Guidelines

Most meetings will be conducted via phone meeting, due to the physical distance between the project team and the client. Any face-to-face meetings will require planning to organise transportation.

A typical meeting would follow the format:

1. Meeting requested by the project team/client/supervisor2. Meeting time, location and format (phone, face-to-face, other method)

planned3. Meeting initiated4. Project status update performed5. Issues/concerns discussed6. Any other requirements discussed.7. Meeting summation8. Meeting Adjourned9. Meeting Minutes formulated10. Entry recorded in team diary

14 Documentation requirements

This section of the document contains the information regarding the required documentation throughout the duration of the project.

14.1 Document Listing

The table displays the documentation requirements regarding the Unit Description for CP 783 in Semester 1, 2005 and is to be handed to the Unit Coordinator (Lecturer).

Figure (from Unit description)

The documents required from all teams for this unit is as listed:

Tender bid or Project Proposal Software Project Management Plan (SPMP) including Project scope Project Journal including Weekly Timesheets, Meeting agendas, Minutes for

each Team meetings and Supervisor meetings. Software Requirements Specification (SRS) and Requirements Analysis. Design Notes or a Technical Design Document (Software Architecture Design

Document) Test plan and test reports Other documents regarding client/project needs User documentation including support or technical documentation, user

manual (if requested). Final research report for client and supervisor. Signed-off SRS Design decision logs Final client sign-off statement

14.2 Maintenance Of Documents

15 Documentation Descriptions

This section describes various documents to be completed as part of this project.

15.1 Tender bid or Project Proposal:

A proposal made for approval of a contract to perform a service or create an item.

15.2 SPMP (Software Project Management Plan)

The SPMP is used to define the scope, emphasizes on the outline of the team regulations and responsibilities of each team member and identifies the expectations of the project. This project plan is updated constantly throughout the project to meet requirements.

15.3 Project Scope

The Project Scope is part of the SPMP which gives an outline of the target audience, the Project environment, and possible solutions. To determine the scope, each task that is required or desirable in the project is to be rated its significance. This process of identifying, categorizing and prioritizing the functions of the system are used to manage the decisions.

15.4 WBS (Work Breakdown Structure)

List of all the phases, activities, and tasks of a project that are structured in a hierarchy of levels and scheduling that leads to project completion.

15.5 SRS (Software Requirements Specification)

SRS is a detailed outline that focuses on the analysis of the current system based on the client’s needs. SRS is focused on prioritizing the quality measures taken rather than the functional requirements. Hence, project boundaries are carefully set in features and functionality that the system hopes to provide. The project requirements set out by the client are documented in SRS in their own understandings. A client sign off and list of acceptance criteria records the agreement to these specifications.

15.6 Final research report

-compare and contrast the various PHP

15.7 Test plan and Test reports

15.8 User Manual (If required)

16 Internal Documentation

Internal and external documentation will be kept throughout the duration of the project. This internal documentation will be produced to record the workings within the team for the use of the project unit and the client

16.1 Meeting Minutes

Refer to Section 13 of the SPMP to view meeting guidelines.

Meeting Minutes are required to be kept in regards to every meeting.Minutes will be documented by the Team Secretary, or in the absence thereof, a designated stand-in. These minutes are required to be presented as a document to the supervisor. (See documentation requirements X.X)

Meeting minutes will include the following information: Date of Meeting Meeting Number Team Name Attendees Agenda The next meeting's agenda Signature space for all (Team Member) attendees.

The following is an example of the Official Meeting document:

Official Meeting MinutesDate: Meeting #: Group: Team A (The Mathemagicians) Attendees:

Alex Stewart-JamesBibz DewanDoug WainewrightJason Wade

Agenda:

EXAMPLE ONLY

Next meeting's Agenda:

Signed:

_______________ _______________ _______________ _______________

A Meeting Template exists, and can be used to create additional meeting documents. The template can also be printed as a hardcopy, to be used to record details of the meeting as it is happening, but this hardcopy must be translated into an official Meeting minutes document and saved in the appropriate directory.

16.2 Meeting Agenda’sAgendas will be written for all meetings. (See Team meeting guidelines X.X)The Team Meeting Agenda Template that provides the format for all meetings are to be used on a regular basis. These templates are available on the unit website. (website link?) The agenda topics will be specified for the next meeting and can be accessed in the website and storage directory (See X.X) These agenda topics are then required to be presented as a document to the supervisor. (See documentation requirements X.X)

16.3 Storyboard

The storyboard is a technique used to sketch sequences of the display screen during a dialog. Designer will use Visual Basic in order to do simple sketches and is able to put an emphasis on the fundamental design ideas. The story board will then be produced and presented as a document to the supervisor. (See documentation requirements X.X)

16.4 Document Template

All documents will have a template that has been created for general use. The document

templates are available on the unit website. (website link?)A meeting minute and agenda template has also been produced to record all meetings that will take place. They can also be located on the unit website, see X.X)

17 Document And Code Tracking

17.1 Documentation

17.1.1 Documentation Conventions

17.1.2 Document Version Control

Document version control is used to ensure that new versions of updated documnents, are easily logged incase of data loss, or confusion.

Versions of the documentation will be controlled as follows.

Versions will begin with the number ‘1’, and will increase in incrememnts of 1 for each major update or change (ie. ‘tender_bid_V1’ after being updated will become ‘tender_bid_V2’).

17.1.3 Documentation Naming Conventions

For each document produced for this project, the following naming standard will be implemented.

document_name_Vversionnumber

document_name – This refers to the name of the document produced, using a ‘_’ character instead of spaces for names with more than a single word. All parts of the name will be written in lower case (ie. ‘tender_bid’). In the case of an acronym in the place of writing a documents full name. all uppercase characters will be used (ie. ‘SPMP’).

The following is an example of the naming standard for the meeting document filename:

meeting_number_DD_MM_YY.doc

number – This refers to the meeting number since the start of the project life cycle (ie. For the second meeting for the project, the minutes would read ‘minutes_2’).

DD_MM_YY – This refers to the current date when the meeting is held (ie. If meeting 2 is held on the 6th of October 2006, the name would read ‘minutes_2_06_10_06.doc’).

The following is an example of the naming standard for the meeting document filename:

timesheet_name_DD_MM_YY.doc

name – This refers to the name of the team member which the document belongs to (ie. A document timesheet produced by Alex Stewart-James would read ‘timesheet_alex’).

DD_MM_YY – This refers to the week ending date when the meeting is held (ie. If the timesheet is for the week ending on the 6th of October 2006, the name would read ‘timesheet_alex_06_10_06.doc’).

These standards are to be followed to ensure that documents can be recorded in an easy-to-find manner.

17.1.4 Storage Of Documentation

All documentation will be primarily stored electronically. A single hard copy of each required document, will be submitted to the supervisor and course coordinator in hard copy.

17.1.5 Documentation Backup

Documentation will be stored primarily on the website server, used for the project. Backups of all documents will also be stored on a memory stick, and team members hard disk drives, to ensure little to no data is lost under the worst of circumstances. Code for the project application will be stored on both a test server primarily, followed by the live (production) server upon completion. The data will also be stored on compact disc and memory stick, to ensure no data loss.

17.2 Coding

This section gives a detailed description of the coding and naming standards to be used for this project.

17.2.1 Coding Conventions

17.2.2 Coding Version Control

Versions of the code will be controlled as follows.

Versions will begin with the number ‘0.1’, and will increase in incrememnts of .1 for each update or change (ie. ‘algebra_0.1’ after being updated will become ‘algebra_0.2’). After being tested, code added to the application will increase to the next whole number (ie. ‘algebra_0.2’ will become ‘algebra_1.0’).

17.2.3 Coding Naming Conventions

For each code file produced for this project, the following naming standard will be implemented.

file_name_versionnumber

file_name – This refers to the name of the file produced, using a ‘_’ character instead of spaces for names with more than a single word. All parts of the name will be written in lower case (ie. ‘print_score’).

_versionnumber – This refers to the version number of the file. The version number will always be preceeded by a ‘_’ (ie. ‘_1.6’).

17.2.4 Storage Of Code

All code will be stored electronically.

17.2.5 Coding Backup

To ensure minimal loss of code during development, deployment and updating, all code will be stored on a development server, as well as on a separate machine and memory stick.

18 Deliverables To Client

This section outlines the Deliverables that will be delivered to the client. This includes entities outlined within the scope that were requested by the client.

18.1 Detailed Deliverables Description

18.1.1 Key Deliverables (as of 13/3/2006)

Compact Disk: The Advanced Mathematics application

For years 7-8 students, with advanced mathematical equations (typically two years higher mathematical equations) including the following: Sets, Logic and Probability Arithmetic of Integers Measurement, Graphs and Equations Fractions and Decimals Geometry

Application contains a number of 20-minute sessions for students, pre-ceded by a short, engaging game. The client would prefer some type of ‘race’ style game, in which the student’s progress increases with each correct answer.

A placeholder function that records the current progress of the student, in-cluding score, records of previous answers, and current location within the application.

Report generating/Printing function – for teachers to check the progress of the students.

Any required third-party software needed to run the application Most likely WAMP PHP, as client has no real technology preference. This

application would require hosting on the computer being used to run the application.

Installer – to simplify installation of the Advanced Mathematics applica-tion, and any required third-party software.

Documentation/help to be specified by the client (if required) – to be an-nounced at a later date. This would require either hardcopy or softcopy help/user documentation, as specified.

Installation of application on client showcase machine.

19 Task Management

This section describes the various tasks undertaken throughout this project, and how they will be successfully managed.

19.1 Task Definition

19.2 Task Allocation

19.3 Task Schedule

19.4 Task Progress Tracking

19.5 Task Reassignment

19.6 Task Duration Recording

19.7 Task Completion

19.8 Task Deficiency

20 Acceptance Criteria

20.1 Approval process for accepting designs

20.2 Approval process for accepting images and sounds

20.3 Approval process for accepting final documentation

21 Reviews and Audits

This section is describes the review and audit processes to be used during this project.

21.1 Product Reviews

This section describes the product reviews to be carried out as part of this projects processes.

21.1.1 Internal Product Reviews

Shamsheer and Jason Giri

21.1.2 External Product Reviews

Client, Other External Party

21.2 Documentation Reviews

This section describes the documentation reviews to be carried out as part of this projects processes.

21.2.1 Internal Documentation Reviews


21.2.2 External Documentation Reviews


21.3 Audits

This section entails information about the audits to be carried out for this project.

21.3.1 Internal Audit


21.3.2 External Audit


22 Team Website

This section is designed to describe the team website used for this project.

22.1 Website Contents

The team website is designed for access by both the project team, and all other stakeholders. It will contain 5 main pages (‘Main/Index’, ‘Project’, ’Team’, ‘Documents’ and ‘Contact Us’). The site will be used to store links to documentation, as well as stakeholder contact information, project information and latest news.

22.1.1 Index Page

The Index Page will contain any project announcements as they come to hand. It will also contain links to team resources as well as a team member list as well as a team member list and next scheduled meeting.

22.1.2 Project Page

The project page will display a description of the projects scope. It will also contain links to team resources as well as a team member list and next scheduled meeting.

22.1.3 Team Page

The team page will display a list of team members, with a description of each member and their primary role. It will also contain links to team resources as well as a team member ‘to do’ list. a next scheduled meeting time and place details will also be available on this page..

22.1.4 Documentation Page

The documentation page will contain links to all documents relevant to the project. Each will be sorted by specific document version. It will also contain links to team resources as well as a team member list and next scheduled meeting.

22.1.5 Contact Us Page

The contact us page will contain contact information for members of the project team, which can be used by the client. Each name will have a phone number and email address link. It will also contain links to team resources as well as a team member list and next scheduled meeting.

22.2 Updating Website

The web site will be updated on a weekly basis, in order to ensure that meeting schedules and document links are kept up to date. This will also ensure that the client will have a simple method of tracking project progress.

23 Risk Management Plan

This section describes the meaning and use of risk management.

23.1 Purpose of Plan

The purpose of the Risk management plan is to negate any possible risks which are related to this project, by creating plans to prevent risks before they occur.

A risk is defined as a possible event or condition that can result in the project taking a longer duration than the date of scheduled completion. A systematic process can be used to avoid the risks called Risk Management which identifies and mitigates the software development risks. No matter what the approach maybe taken to develop the project, various types of risks exist. However, the Risk Management Plan’s intentions are to identify the risks, try and resolve the outcome and estimate the probability and schedule delay.

The Risk Manager will use the following steps for each risk.

What risk? : What type of risk is it? Probability: What is the possibility of this happening? Impact: The extent to which it will adversely affect the project. Consideration timeframe: How to determine when to consider the risk? Mitigation Plan: How to minimize the expected schedule delay? Relevancy: How important is the risk – prioritizing risks? Damage Control: How to diminish the impact if it occurs? Prevention: How to try and avoid the risk from occurring?

23.2 Risk Identification

This section identifies possible risks for this project.

Risk Identification

What is the risk? Probability Impact Consideration Timeframe

Mitigation Plan

Relevancy Damage Control

Prevention

Failure to attend meetings

No proof that team members have done their tasks. Tasks may be reassigned hence, adding workload to other team members. The team would have restriction in progressing from one phase to another.

Moderate Variable depending on the project’s progress. Restriction in progressing from one phase to another.

Entire project duration

Relocation of work to other team members, reschedule meetings

Relevant Early detection of failure to attend meeting would allow the team members to be prepared to send information about the meeting to the absent member.

Early notice, Constant reminders and verification of the meeting times for appropriate members.

Limited contribution of a Team Member

Team member that has restricted contribution towards the various phases and tasks during the development of the project.

Low Delay or failure in submitting tasks which also means more workload for other team members

Entire project duration and verifying the member’s allocated tasks before

Extra help from other team members and guidance by reading extra materials

Relevant The earlier the team is aware of this risk occurring, the scale of the problem minimizes.

Early notice of the various task difficulties of team members.

Reallocation of Team Members

Team members leave or gets replaced by other members

Low Rearrangement or replacement of the project roles, revise the documentation.

As soon as it is known

Organize a team meeting to reassign the roles of the team and update the documentation

Relevant Manage the team to get organized and to collaborate with the new changes.

Cooperate with each other and use the team-working skills to develop a comfortable and working environment

Risk Identification


Mitigation Plan


Prevention

No agreement on a work breakdown structure (WBS) schedule

There is no settlement on the work breakdown structure schedule

Low Messy approach to the development of the project without a convincing and organized completion.

Before creating the WBS and updating it.

Decision making process. See (12.2.7 Decision Making process) for more details

Relevant Project manager makes sure the WBS is finalized with team mediation

The earlier the WBS is considered, the more time remains for alterations.

Failing to meet unit deadlines

Not meeting unit deadlines

Low Vital for passing the unit with good marks

Immediately and throughout the entire project

Planning ahead by scrutinizing the unit deadlines and WBS. Ensuring we complete the tasks a week before the deadline.

Highly-relevant

Team mediation to decide the priorities.

Organizing an effective timetable for the team to meet the various deadlines for the unit

Task completion does not meet accepted

standardsNot meeting client expectations

The final product does not satisfy or meet the client’s expectations or requirements.

Moderate Critical for customer satisfaction to be met.

Before scope documentation sign-off

Scope sign-off by client.

Highly-relevant

Actively involving the customer in all phases of project planning

Ensuring the scope is well-understood by both team members and client

Creating a system that is not viable

Producing a system that is unusable

Low Customer satisfaction is not met

Before planning and designing stages of the project.

A product prototype is tested by the client.

Highly-relevant

Revise and modify the system

Focus on the testing stages before the development process.

Risk Identification


Mitigation Plan


Prevention

Assumptions Assumptions Moderate Different assumptions results in blurry

Continuously throughout the duration of the project.

Use the SRS to create a list of assumptions that the team members should be aware of during the project.

Relevant. Ensure that all team members revise and understand the list of assumptions clearly

Not developing a secure system

Building an insecure system

Moderate Security breach Before the design and development phase of the system

Ensure that the system is tested continuously to avoid security breaching.

Highly relevant

Continue the testing of the system.

Test the system and allow for changes to be made if system fails to be secure

Late platform change

Last minute changes to the platform

Low Change in the entire

Continuously throughout the

Highlyrelevant

Sign-off

programming of the system

entire project

Unforseen Risks

No preparation for an unknown risk

Low Extends the duration of the project and have to make alteration to the project schedule.

Throughout the entire project

Act as soon as the risk is identified

Relevant Use the steps taken to identify details of a risk.

Avoid creating a tight schedule for the entire project –allow for some extra time gaps that could be used for unexpected risks.

23.3 Risk Assessment

23.3.1 Risk Probability

23.3.2 Risk Impact

23.4 Documenting Risks

23.5 Risk Mitigation

23.6 Mitigation Tracking

24 Reference Material

24.1 Textbooks

Satzinger, J W. (2004). Systems Analysis & Design in a Changing World. (3rd ed). Thomson.

24.2 Lecture Material

24.3 Websites

24.4 Manuals

24.5 Journals

24.6 Other references