Project Plan
For
Content Management System
Document Revision #
Date of Issue: 2008-10-13
Project Manager: Sweeper
Approval Signatures
Approved by: Business Project
Leader
Approved by: IM/IT Project
Leader
Sweeper
Prepared by: Business Project
Manager
Prepared by: IM/IT Project
Manager
Jane
Emma
Reviewed by: Quality Assurance
Manager
Table of Contents
Document Change Control ......................................................................................................3
1. Project Overview............................................................................................................4
. Purpose, Scope, and Objectives ............................................................................................4
. Assumptions, Constraints and Risks.....................................................................................4
. Assumptions .....................................................................................................................4
. Constraints ........................................................................................................................4
. Risk Assessment ...............................................................................................................5
. Project Deliverables ..............................................................................................................5
. Schedule and Budget Summary ............................................................................................6
. Schedule and Milestone....................................................................................................6
. Budget...............................................................................................................................7
. Evolution of the Plan.............................................................................................................8
. References.............................................................................................................................8
. Definitions and Acronyms ....................................................................................................8
2. Project Organization......................................................................................................9
. External Interfaces ................................................................................................................9
. Internal Structure...................................................................................................................9
. Roles and Responsibilities ....................................................................................................9
3. Managerial Process Plans............................................................................................10
. Start-up Plan........................................................................................................................10
. Estimates.........................................................................................................................10
. Staffing ...........................................................................................................................10
. Resource Acquisition......................................................................................................11
. Project Staff Training .....................................................................................................11
. Work Plan ...........................................................................................................................12
. Work Breakdown Structure ............................................................................................12
. Schedule Allocation........................................................................................................13
. Resource Allocation........................................................................................................13
. Budget Allocation...........................................................................................................13
. Project Tracking Plan..........................................................................................................13
. Issues Management.........................................................................................................13
. Schedule Control ............................................................................................................14
. Budget Control................................................................................................................14
. Quality Control ...............................................................................................................14
. Reporting ........................................................................................................................14
. Project Metrics................................................................................................................14
. Risk Management Plan .......................................................................................................15
. Project Closeout Plan ..........................................................................................................15
. Project Review Meeting Plan..............................................................................................15
4. Technical Process Plans ...............................................................................................16
. Process Model .....................................................................................................................16
. Infrastructure.......................................................................................................................16
. Product Acceptance.............................................................................................................16
5. Supporting Process Plans ............................................................................................16
. Configuration Management ................................................................................................16
. Verification and Validation.................................................................................................17
. Documentation ....................................................................................................................17
. Quality Assurance ...............................................................................................................18
. Reviews and Audits ............................................................................................................18
. Problem Resolution.............................................................................................................18
. Subcontractor Management ................................................................................................18
. Process Improvement..........................................................................................................18
6. Additional Plans ...........................................................................................................19
Annex A - Bi-weekly progress report ...................................................................................19
Annex B - Project Risk Checklist..........................................................................................19
Document Change Control
This section provides control for the development and distribution of revisions to the Project
Charter up to the point of approval. The Project Charter does not change throughout the project
life cycle, but rather is developed at the beginning of the project (immediately following project
initiation approval, and in the earliest stages of project planning). The Project Charter provides an
ongoing reference for all project stakeholders. The table below includes the revision number
(defined within your Documentation Plan Outline), the date of update/issue, the author
responsible for the changes, and a brief description of the context and/or scope of the changes in
that revision.
Revision Number Date of Issue Author(s) Brief Description of Change
2008-09-09 Sweeper Build Doc
2008-09-19 Jane Revision
2008-09-20 Jane Revision
2008-09-23 Sweeper Revision
2008-09-23 Jane Revision
2008-09-25
Emma
Lili
Jack
Revision and Review
2008-09-26 Jane Check English
2008-09-27 Sweeper Revision
2008-09-26 Project Team Release One
2008-10-06 Sweeper Add Review Meetings Plan
2008-10-10 Jane Release Two
2008-10-12 Sweeper Update Plan Sync Update1
1. Project Overview
The project plan for Content Management System (CMS) of Manufacturing Trade
Association (MTA) is written by Final Fantasy Company according to the original requirements
of the project. It will provide a definition of the project, including the project’s goals and
objectives, etc. Additionally, the Plan will serve as an agreement between the following parties:
Project Sponsor, Steering Committee, Project Manager, Project Team, and other personnel
associated with and/or affected by the project.
. Purpose, Scope, and Objectives
The project is developed for a large Manufacturing Trade Association (MTA) with over 2000
members. The purpose for this project is that MTA works closely with enterprises of all sizes to
help them unlock the value of their unstructured content.
The objective of deploying the CMS is to facilitate the creation and manipulation of content
on a website and to enhance collaboration by making it possible to collect information generated
within the organization and facilitate its distribution.
The preliminary scope of the CMS defined by MTA includes:
Tools for managing users and workflow. The separation of content and the visual display
makes it easier to maintain a consistent look-and-feel across the entire website.
Support collaboration tools such as discussion forums and document management.
Support customized information retrieval - sophisticated search tools can allow users to
locate just the information they are looking for.
Web-based interfaces to selected information in the databases can facilitate data sharing
between the organization and its stakeholders.
Make it easier for non-technical staff to add and edit content, thus streamline the process
of maintaining a website.
Developing the CMS will be about 4 months. It will complete the requirement research,
analysis, design, development, test, deploy and finally deliverable.
. Assumptions, Constraints and Risks
. Assumptions
The stakeholders of MTA include:
Executive Council of MTA, consisting of 15 executive members who made decision on
running MTA
Office staffs of MTA who carry out the day-to-day operation of MTA, under the
direction of the Executive Council
MTA Members who receive newsletters and event announcements
Universities which support some of MTA's events
Other trade associations which support some of MTA's events
Government and IT vendors who sometimes sponsor events organized by MTA
General public who receive announcement on important events of MTA.
. Constraints
MTA has requested that open source software be used whenever possible. In particular, they
suggest using Linux operating system; Apache web server, MySQL database, etc.
The CMS must be deployed by Dec. 31 this year, about 4 months from the project start date
of September 1.
. Risk Assessment
Risk Area Assessment Impact Mitigation
Communicati
on and
Collaboration
High
This is a temporary team. It will
be lack of practices of
cooperating and communicating
between team members.
Have a weekly meeting
and a bi weekly report.
Use GOOGLE Code
Manager to control
Code vision and issues
Staffing
Resources Medium
1. Success of project depends on
ability to members with credible
experience in the technical
areas.
2. Resource conflicts or
shortages will cause that the
project cost and schedule
(primarily schedule) could
overrun
1. Share technical
issues, experience and
information in each
member in order to
improve personal
ability.
2. Create an alternate
resource plan for critical
tasks.
Cost Medium
Potential requirement change
cost and maintenance cost.
Develop a total life
cycle cost estimate
during concept
validation as part of the
milestone decision. And
establish a change
control process.
Schedule Medium
This project will be developed
about 4 months. Due to the
spare time each member spent, it
is difficult to manage schedule.
Strictly, each member
must spend not less than
7 hours in each week.
And each member must
ensure the timely
deliverable.
Scope Low
Successful completion of
concept validation will result in
a client-wide implementation.
Quality Unknown This risk factor will depend on the results of concept validation.
Strictly SQA process
control.
. Project Deliverables
Deliverable Due date Quantities Required Delivery Location
Project plan Week 4
Project planning includes development of the
overall project team structure, the various activities,
effort and work plan that will form the basis of the
project management throughout the project
lifecycle.
PM
It will provide an integrated planning for CMS
project, such as timeline and milestone, staffing
resource distributed, risk estimation and mitigation.
System
requirements
specification
Week 4
The system requirement specification should
describe the functional requirements of the system
in precise detail. When possible, it identifies the
entities (components, sections, and areas of
functionality) that make up the system and
characterizes the properties, states, functions, and
interrelationships of each entity.
According to the requirement of MTA and industry
information, the document will describe a business
case study and scope, functional and nonfunctional
requirement.
Designer
SQA plan Week 6
The Software Quality Assurance Plan (SQAP)
defines the techniques, procedures, and
methodologies that will be used to assure timely
delivery of the software that meets specified
requirements within project resources. The SQAP
describes the SQA activities to be performed and
defines a set of standardized techniques for
performing those activities.
SQA
Design
document Week 6
It forms the interface between the requirements
document and the code itself and describes how the
software will be constructed. It will include system
use case, database structure, and user interface and
so on.
Designer
Test plan Week 7
A Test Plan is a document that describes the
objectives, scope, approach, and focus of a software
testing effort.
Tester
Mid-term
progress
review and
presentation
Week 8
Review the completed deliverables, sum up issues,
and share experience. PM
Source code Week 9 Deliver the compiled source code for the first time, including wholly or partly function.
Program
mer
Test results
report Week 11
A Test Result Report is a document that formally
summarizes the results of all testing. Tester
Defect log Week 11
The Defect Log records all defects/issues reported
by team members and customers and gives a clear
indication of the quality of the software application.
Various statistics can be generated from the defect
log, such as the number of Open defect, number of
Fixed defect, etc.
Tester
Program
mer
Post project
report Week 14
The Post Project Review consists of activities
performed by a project team at the end of the
project's life cycle (or at the end of significant
phases of work) to gather information on what
worked well and what did not, so that future
projects can benefit from that learning.
PM
Presentation Week 15 Show overall project for client, including issues, PM
on the project experience, evaluation, etc.
CMS Week 15 Deploy a real environment to ensure normal running. PM
. Schedule and Budget Summary
. Schedule and Milestone
This project will be divided into three phases to complete, and total time is about 4 months. The
following represent key project milestones, with estimated completion dates:
A1 Initial Team Formation Meeting PM 09/01/08 09/01/08
A2 Team formation notice PM 09/02/08 09/07/08
A3 Build Project Plan PM 09/08/08 09/27/08
A4 Finish Requirement Analysis Designer 09/08/08 09/27/08
B1 Build SQA Plan SQA 09/28/08 10/12/08
B2 Finish Design Designer 09/28/08 10/12/08
B2.
1 Change Plan Sync Update1 PM 10/13/08 10/13/08
B2.
2 Change SRS Sync Update1 Designer 10/14/08 10/14/08
B2.
3 Change Design Doc Sync Update1 Designer 10/15/08 10/15/08
B3 Build Test Plan Tester 10/13/08 10/19/08
B4 Finish Coding Coder 10/13/08 11/02/08
B5 Mid-term progress review and presentation PM 10/20/08 10/26/08
C1 Test and Fix Defect Coder/Tester 11/03/08 11/16/08
C2 Finish Test Tester/PM 11/17/08 12/01/08
C3 Finish deploy PM 12/02/08 12/17/08
C3 project report PM 12/02/08 12/19/08
. Budget
Project Cost & Time Estimates
All project costs and dates are estimates. Projects are charged only for actual time spent.
Design Phase estimated costs
Kickoff meeting; requirements and preferences 1days
Develop design alternatives (2) - home and secondary pages 3days
Present design alternatives 3days
Basic design chosen, alterations identified 2days
Incorporate alternatives, develop further page designs 5days
Post design updates for review and feedback 3days
Receive client feedback 2days
Incorporate final alterations and post 5days
Sign-off on design 1days
Design phase project management 5days
Design phase total 30days
Design Phase Cost-Reduction Option:
If clients can choose a design and complete all alterations on it in 2 reviews instead of 3, cost of
design phase can be reduced.
Build phase estimated costs
Designer time 30days
Programmer time 30days
Project management 15days
Documentation 10days
Training sessions 10days
Quality Assurance testing 15days
QA fixes and launch preparation 30days
Post-launch monitoring and support 2days
Factor of safety @10% 1days
Build phase total hours 143days
Project Resource
Project Role %Time Dates Needed( Range) Name of Manager
Project Manager 15 Week1-week15 Sweeper
Designer 15 Week2-week4 Jack
Programmer 30 Week6-week15 Lili
Tester 15 Week10-week15 Jane
QA 30 Week5-week15 Emma
documentation 5 Week1-week15 Sweeper
Systems support 5 Week10-week15 Sweeper
. Evolution of the Plan
The structure of this Project Plan is in compliance with the IEEE STD 1058-1998.
After project members review the plan, the release version will be placed under
configuration management.
. References
[1] WebCT - COMP5231 Project Practice and Case Studies, Hareton Leung
[2] DonewsBlog - Developing the Project Plan
Juven
[3] Project Manager Union
[4] Capability Maturity Model* Integration (CMMI), CMMI for Software
Engineering (CMMI-SW, VI. 1) Staged Representation CMU/SEI-2002-TR-029 ESC-TR-2002-
029 August 2002
[5] A Business case for CMMI based Process Improvement, Dave Walden, General
Dynamics Advance Information Systems, and PSM Conference July 2002.
[6] Simplifying development through activity-based change management, Allan Tate &
Karen Wade, IBM Software Group, October 2004.
[7] Capability Maturity Model) Integration (CMMI), Version for Software
Engineering (CMMI-SW, VI. 1) Continuous Representation CMU/SEI-2002-TR-028ESC-TR-
2002-028 August 2002.
[8] A spiral model of software development and enhancement, Boehm, B. W. (1988), IEEE
Computer, 21(5), 61-72.
[9] The six sigma project planner, Tomas Pyzdek (2003)
. Definitions and Acronyms
MTA Manufacturing Trade Association
CMS Content Management System
SQA Software Quality Assurance
PM Project Manager
RUP Rational Unified Process
2. Project Organization
. External Interfaces
PM will be responsibility for the communication bridge between the project and external
entities.
Customer - A large Manufacturing Trade Association (MTA) with over 2000 members.
The stakeholders of MTA include:
Executive Council of MTA, consisting of 15 executive members who made
decision on running MTA
Office staffs of MTA who carry out the day-to-day operation of MTA, under the
direction of the Executive Council
MTA Members who receive newsletters and event announcements
Universities which support some of MTA's events
Other trade associations which support some of MTA's events
Government and IT vendors who sometimes sponsor events organized by MTA
General public who receive announcement on important events of MTA.
. Internal Structure
Project Team Organizational Structure
Project Manager SQA
Design
ers
Programmer
s
Test
ers
. Roles and Responsibilities
Role Responsibilities Participant(s)
Project Sponsor
Ultimate decision-maker and tie-breaker
Provide project oversight and guidance
Review/approve some project elements
Hareton Leung
Project Manager
Coordinate the activities of team members
Organize team meetings
Prepare Team Formation Notice
Writes project plans
Writes system requirements document
Update the project plan if needed
Prepare Post Project report
Prepare progress reports to client and senior management
Prepare mid-term progress review and presentation
Prepare final project presentation
Deliver all presentations
Sweeper
Designer
Contribute to the system requirements document
Prepare design document
Write drafts of the user manual and installation guide
Provide User Training
Report progress to PM on a weekly basis
Assist PM to prepare mid-term progress review and
presentation
Assist PM to prepare final project presentation
Sweeper
Lili
Jack
Programmer
Code all software features
Perform unit testing
Report progress to PM on a weekly basis
Assist PM to prepare mid-term progress review and
presentation Assist PM to prepare final project presentation
Lili
Jack
Jane
Tester
Prepare test plan
Perform system testing
Prepare Test Result report
Log all defects found
Assist Designer to write drafts of the user manual and
installation guide
Report progress to PM on a weekly basis
Assist PM to prepare mid-term progress review and
presentation
- Assist PM to prepare final project presentation
Emma
Jane
QA Analyst
Prepare SQA plan
Monitor QA activities
Report progress to PM on a weekly basis
Assist PM to prepare mid-term progress review and
presentation
Emma
3. Managerial Process Plans
This section of the Project Management Plan specifies the project management processes for
the project. This section defines the plans for project start-up, risk management, project work,
project tracking and project close-out.
. Start-up Plan
. Estimates
This project is a timer plan, so it must be completed in the official hour. MTA has requested
that open source software be used whenever possible. In particular, they suggest using Linux
operating system, Apache web serve, MySQL database, etc.
So according to the above factors, we will adopt JAVA and MySQL to develop CMS project.
There is not purchase cost because of free open source tools. We will use GOOGLE free code
manger service to manage code and Issues, and we will post wiki on it.
. Staffing
This project team has only five members. Each member will try their best and unleashed
potential to develop this project. The following is the simple introduction of members.
Sweeper: There is development experience more than ten years and rich management
experience. So he will undertake PM role in the team.
Lili: There is rich development experience and strong coding ability. So she will undertake
primary programmer role in the team. At the same time, she will analyze requirement as an
assistant of primary analyst.
Jack: Because of rich experience of requirement analysis, he will undertake primary analyst
role. At the same time, he will also be responsibility for coding.
Jane: There is rich experience of software development and comprehensive ability in the
phase of software life cycle. So she will take part in each phase, such as project plan, testing, etc.
Emma: there is rich experience of SQA. SQA and tester role will suit her best.
. Resource Acquisition
One Team, One Goal. The team formation is voluntary. We own the same goal – Develop a
CMS product for MTA successfully.
The team doesn’t need to buy any hardware resource, because team members will solve the
hardware resource by themselves.
For software resource, the team will adopt the way of share through the internet. So software
resource also has no need to be bought.
. Project Staff Training
Most of members have the programming experiences with JAVA and MySQL. So members
will study technique knowledge by themselves. But members are not familiar with CMS business
knowledge. So it is necessary for CMS business training.
Because this is a temporary team, it is difficult to work together. So finally we will adopt a
network meeting for a knowledge share and discussion on the internet to instead traditional face
to face training.
This network meeting will be holding in the phase one. In the share and discussion, team will
refer to some mature CMS products in the market, and compare with the requirement of MTA in
order to improve the knowledge of CMS business process.
. Work Plan
. Work Breakdown Structure
Content Timeline Content Timeline
0. Establish team Week 1 3. Showing First Week 14
Contact with members Iconically Show Product
Deliver team formation. Widely Publicity
1. Prior to coding (Research and analysis) Week 4 Milestone Mark
Grope experience Control Process of Project
Learn requirement Coordinate Environment Change
Milestone Mark Test Product System
indicate blueprint and increase
confidence Track Issues
Define Product Milestone Mark
Analyze Requirement Adjust at team best
Establish Project Plan Union is strength
Deliver Project Plan and System
Requirement Specification Entered into the spirit of team
Milestone Mark Milestone Mark
Kick off the first work 4. Released (Operation and Maintenance ) Week 15
Training Track and Feedback
Milestone Mark Monitor Product in the market
2. Development Phase (Design and Structure) Week 9 Milestone Mark
Comprehensive Viewpoint Summary Experience
Consult questions with professor Maintenance Plan for product
lookup CMS information Collect Statistical Data
Milestone Mark Evaluate and Improve
Control and legislators: to act as different Update and Complete User
roles Manual
Establish Test Plan Ready for next project
Work on the test plan Commendation
Track program change Evaluate Members
Preview deployment
Deliver Test Plan, SQA Plan, Design
Document
Milestone Mark
Establish a good work environment
Establish work standard.
Share Information
Solve Conflict
Deliver Test results report and Source
Code
Milestone Mark
. Schedule Allocation
The detailed timetable has been described by “”.
. Resource Allocation
The detailed HR resource has been described by “”. The team has no
need of the other resource expect human resource and software resource.
. Budget Allocation
Mostly, the team will comminute through the internet and telephone. There are few meetings
on the free time of weekend lessons. Team has no need to travel and go on errands. So project
budget only has the workload budget.
. Project Tracking Plan
The free tool – Google Code will be used for the project tracking.
. Issues Management
The following issues management procedures will be used:
Major issues (any that will significantly affect the scope, schedule, or budget for the project)
will be registered in the project Major Issues log.
The Project Manager and Client Project Manager will determine how to address the issue and
identify how it will affect the scope, schedule and budget for the project.
On the Project Status Report, the project manager will report the issues currently being
worked on, their status, and the projected date of resolution. Any critical unresolved issues that
are impacting the scope, time, cost, or quality of the project will be highlighted in the status report.
When an issue is resolved, merged with another issue, or withdrawn, the issue log will be
updated.
When an issue is closed the resolution is logged and it is moved to a closed status.
Minor issues will be logged and managed using the Google Code issue tracking program,
which all project participants and the Client PM will have access to.
Requirements Management
The information contained within the Project Plan will likely change as the project
progresses. While change is both certain and required, it is important to note that any changes to
the Project Plan will impact at least one of three critical success factors: Available Time,
Available Resources (Financial, Personnel), or Project Quality. The decision by which to make
modifications to the Project Plan (including project scope and resources) should be coordinated
using the following process:
Step 1: As soon as a change which impacts project scope, schedule, staffing or
spending is identified, the Project Manager will document the issue.
Step 2: The Project Manager will review the change and determine the associated
impact to the project and will forward the issue, along with a recommendation, to the
Steering Committee for review and decision.
Step 3: Upon receipt, the Steering Committee should reach a consensus opinion
on whether to approve, reject or modify the request based upon the information contained
within the project website, the Project Manager’s recommendation and their own
judgment. Should the Steering Committee be unable to reach consensus on the approval
or denial of a change, the issue will be forwarded to the Project Sponsor, with a written
summation of the issue, for ultimate resolution.
Step 4: If required under the decision matrix or due to a lack of consensus, the
Project Sponsor shall review the issue(s) and render a final decision on the approval or
denial of a change.
Step 5: Following an approval or denial (by the Steering Committee or Project
Sponsor), the Project Manager will notify the original requestor of the action taken. There
is no appeal process.
*Tags: In this project, team members will act as the Steering Committer role. And the
teacher will act as the Project Sponsor.
. Schedule Control
The weekly schedule will be shown intuitively in the CMS Gantt chart, and then be shared to
team members. And the PM will release “Bi-weekly Report Week” half month. So for the delay
tasks, PM will try to adjust resources to bring down influence.
*Tags: refer to the document “”.
. Budget Control
This project doesn’t need to control the budget, and only need to control the plan.
. Quality Control
There is a professional SQA role to control quality in this project. SQA staff will provide a
SQA plan and test plan for quality control. PM and SQA staff will follow the plans to control
quality.
See “SQA Plan”, please.
. Reporting
A Bi weekly report will deliver to teacher by PM. It will report current status and issues for
this project.
*Tags: the template of Bi weekly report refers to the Annex A.
. Project Metrics
Some project status will be tracked and collected, including workload process status, work
deviation case, defects, etc. The workload process status and work deviation case will be
collected semimonthly. The defects status will be collected in the process of testing. The checklist
will be used in the document check and the efficiency of process executed.
. Risk Management Plan
PM will manage the risk on a weekly basis, including identifying risk, tracking and analyze
the identified risk. When the risk happened, PM will use the required measures. The checklist of
risk refers to the Annex B.
. Project Closeout Plan
It is necessary to project closeout process to ensure orderly closeout of the project.
Project Manager will provide a Skeleton Closeout Report. The closeout Report would
have information regarding the project scope, risk and the original plan’s schedule.
PM will have a closeout meeting with customers. In the meeting, they will review the
following agenda.
Executive Summary of the project plan
Project result
Analysis of project objectives achieved
Real deliverables to those described in the plan
It is necessary to a post mortem meeting in the team. Project personnel will write
post-mortem debriefings and discuss lessons learned.
. Project Review Meeting Plan
It is necessary to project review meetings in order to ensure work objective and quality.
In the project process, we will hold the review meetings in each phase. The following is the step.
Meeting Time:
At 9:00 every weekend.
two days before the end of each milestone
Venue: The meeting will be held on the internet through QQ Group.
Team leader will give members the email for the meeting. At the same time, the deliverables
will be sent in the email.
Members will review the deliverables, and then send comments back to team leader.
Team leader will sort out the information from members. An informal list of discussion
topics will be formed.
According to the informal list of discussion topics, team will discuss them and draw
conclusions one by one.
Finally, team leader will record the conclusions in the transaction track system (Google
Code). Corresponding member will be in charge of the tasks according to the conclusions.
Team leader will follow up the process of the tasks.
4. Technical Process Plans
. Process Model
The iteration process of RUP will be used in the CMS project. The following step:
Analyze Requirement
Condense Requirement
Design CMS
Condense Designs
Coding
Integration Testing
Deployment.
. Infrastructure
The free system for JAVA and MySQL will be used in this project. It is cross platform, so
foreseeingly this project will be deployed in many platforms.
. Product Acceptance
The teacher will act as the customer role. In other words, product acceptance will depend on
the teacher’ review. If the teacher has any suggestions and opinions, the team will perfect the plan
at the right moment.
5. Supporting Process Plans
. Configuration Management
Google Code Tool will be used in issues management in the project. When there is an issue, it
will be placed in the following link:
Then PM will track this issue and assign tasks to the person responsible. The status of issue
also will be tracked until to be completed. When the sponsor approves the issue, the issue will be
closeout.
The documents and programs in the project process will be carried out the configuration
management, and adopt the unique identification. After the review passed, they will be placed
under the configuration management. When the change happened, the change control process will
be adopted.
. Verification and Validation
All the team members will review all the documents for this project. The program will be
tested comprehensively by testers. Finally, the teacher will verify the product – CMS of MTA.
Pressure test software will be used in the project. The JUnit tool is recommended to
programmers used in the phase of coding in order to quality assurance.
. Documentation
Deliverable Responsible staff
Team formation notice PM
Project plan PM
System requirements specification PM
SQA plan QA
Design document Designer
Test plan Tester
Mid-term progress review and presentation All members
Source code Programmer
Test results report Tester
Defect log Tester
Post project report PM
Presentation on the project All members
Progress report (submit bi-weekly) PM
Successful project All members
Checklist All members
. Quality Assurance
We will have the following simple arrange for quality assurance.
SQA will provide a SQA plan and establish an implement process according to the SQA
plan.
Testers will provide a test plan and establish a test process according to the test plan.
. Reviews and Audits
Peer review will be used in the project. In the process of peer review, team members can
improve overall ability in the aspect of software development. The following is the detail review
process.
First, a deliverable will be completed mainly by one of members. The other members will
be an assistant for the member.
Then, the deliverable will be peer reviewed by team members.
Next, team leader (PM) will hold a meeting to discuss the issues and share the experience.
Finally, deliver to the customer (teacher).
. Problem Resolution
When there are issues in the project, team will adopt the network discussion through the
internet, such as QQ, MSN, BBS, etc. If the result of discussion is not agreement, this issue will
be reported to teacher. All the information in the discussion will be recorded in the meeting
record.
. Subcontractor Management
Our project has no subcontractor.
. Process Improvement
When some problems happen in the process of project development, we must lookup the
reasons and location problems. Then we will improve the development process according to the
process area standard of CMMI. The improved process will be applied to the next iteration
process.
We will improve development process in the project according to the descriptions as above.
6. Additional Plans
When the customer has any requirement for our product, we must give quick feedback. After
the team discussed and confirmed, the requirement will be changed in the phase of design
and code. So the requirement needs to keep flexibility.
When the phase of code is completed, the program will be configured on the computers of
team members.
The team must ensure the synchronous and quick data updating.
PM and testers will provide service support for the product.
PM, designers and programmers will be responsibility for product maintenance.
Annex A - Bi-weekly progress report
Project Name:
Project Phase:
Reporting Period:
Reporting Team:
Reporting Date:
Specific aims
Past activities:
Current activities:
Current problems:
Future activities:
Annex B - Project Risk Checklist
Stakeholders
* Have you identified all stakeholders?
* Have you identified from all groups the leader or spokesman?
* Have you ever met the stakeholders?
* Do you have information on the background of the stakeholders (history)?
Stakes –Fears
* Do you know what the fears are generally for the type of stakeholders you have (.
programmers)?
* Do you know what the fears are of the stakeholders per group?
* Do you know what the fears are for each individual?
* Do you know how this project affects the fears of the stakeholders?
Wishes
* Do you know what the wishes are generally for the type of stakeholders you have (.
programmers)?
* Do you know what the wishes are of the stakeholders per group?
* Do you know what the wishes are for each individual?
* Do you know how this project affects the wishes of the stakeholders?
Requirements Product
* Are the cause and goal of the project clear to you?
* Is the project scope identified and does it include what you can change, what you must change,
and what you can't change?
Process
* Are the constraints identified (money, time, people)?
* Do you have any idea how much room there is to negotiate these constraints?
* If there are already estimations, do you know how much you can trust them?
* Is the project strategy clear and easy?
* Is the project organization identified? Does every member have added value to the project?
Project management
* Are you able to negotiate?
* Are you able to think in win-win situations?
* Are you risk averse?
* Do you include your own stakes into the process?
* Are you able to give the project back in case it smells like a trap?
Feedback
* Is everyone aware for the need and use of giving feedback?
* Have you any idea how to provide feedback?
* Not really understand the techniques you want to use.
* Did you schedule (time, money, people) activities to provide the feedback?
