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
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
Alexander Stewart-James
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
AssistantsDoug Wainewright
Alexander Stewart-JamesJason Wade
AssistantsAlexander Stewart-James
Jason Wade
AssistantsDoug Wainewright
Alexander Stewart-James
AssistantsBibasna Dewan
Alexander Stewart-JamesJason Wade
AssistantsDoug Wainewright
Bibasna DewanAlexander Stewart-James
AssistantsBibasna Dewan
Jason Wade
Project CoordinatorShamsheer Syed
AssistantsDoug Wainewright
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
Shamsheer and Jason Giri
21.2.2 External Documentation Reviews
Client, Other External Party
21.3 Audits
This section entails information about the audits to be carried out for this project.
21.3.1 Internal Audit
Shamsheer and Jason Giri
21.3.2 External Audit
Client, Other External Party
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
What is the risk? Probability Impact Consideration Timeframe
Mitigation Plan
Relevancy Damage Control
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
What is the risk? Probability Impact Consideration Timeframe
Mitigation Plan
Relevancy Damage Control
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