Project Plan Document 2012
H3QeHospitalWebApplication
PROJECT PLAN DOCUMENT
Version Number: 1.0
Version Date: 2/28/2012
H3Q eHospital Web Application
1
Project Plan Document 2012
Amendment log
Version
Number
0.1
Date
24/02/2012
1.0
28/02/2012
H3Q eHospital Web Application
Change number
Description
Sections
Changed
First Draft for
Peer Review
Final version
released
2
Project Plan Document 2012
Proposal Approval
The undersigned acknowledge that they have reviewed the H3Q eHospital Web Application.
Business Case and agree with the information presented within this document. Changes to this
Project Plan Document will be coordinated with, and approved by, the undersigned, or their
designated representatives.
Signature:
Date:
Name:
Luong Vo Van
Role:
Client/ Mentor 1
Signature:
Date:
Name:
Nguyen Thi Anh Dao
Role:
Client/ Mentor 2
Signature:
Date:
Name:
Ha Ngoc Chung
Role:
Leader
H3Q eHospital Web Application
3
Project Plan Document 2012
Table of Contents
1. Introduction ........................................................................................................................................5
1.1. Project Background......................................................................................................................5
1.2. Project Scope................................................................................................................................5
1.4. Project Glossary...........................................................................................................................5
1.5. Project Purpose ............................................................................................................................5
2. Project Requirement............................................................................................................................5
2.1. Business Problem .........................................................................................................................5
2.2. Business Requirement ..................................................................................................................5
3. Project Team .......................................................................................................................................6
4. Measurable Organizational Value (MOV)..........................................................................................8
5. Methodology ..................................................................................... Error! Bookmark not defined.
5.1. Introduction Process .................................................................. Error! Bookmark not defined.
5.2. “Score Searching Website For International School” XP Process ......... Error! Bookmark not
defined.
6. Project Cost ....................................................................................... Error! Bookmark not defined.
6.1. Alternative Solutions .................................................................. Error! Bookmark not defined.
6.1.1 Buy a new website................................................................. Error! Bookmark not defined.
6.1.2 Build a new website .............................................................. Error! Bookmark not defined.
7. Cost Benefit Analysis ....................................................................... Error! Bookmark not defined.
H3Q eHospital Web Application
4
Project Plan Document 2012
1. Introduction
1.1. Project Background
1.2. Project Scope
1.3. Project Objective
1.4. Project Glossary
MOV
Value Measurable Organizational Value or MOV is a term coined by Jack
Marchewka as an alternative tool to the more popular Return on Investment or ROI
concept which has become a buzzword within the industry over the last ten years
and has existed for many more. Marchewka defines measurable organizational
value as being “the project’s overall goal and measure of success.”
XP
Extreme Programming (XP) is a software development methodology which is
intended to improve software quality and responsiveness to changing customer
requirements. As a type of agile software development, it advocates frequent
"releases" in short development cycles (time boxing), which is intended to improve
productivity and introduce checkpoints where new customer requirements can be
adopted.
SWOT
SWOT analysis is a strategic planning method used to evaluate the Strengths,
Weaknesses, Opportunities, and Threats involved in a project or in a business
venture
1.5. Project Purpose
2. Project Requirement
2.1. Business Problem
2.2. Business Requirement
H3Q eHospital Web Application
5
Project Plan Document 2012
3. Project Team
CapstoneTeam2 is a young team project, gathering members of enthusiasm, creativity,
dynamism and dedication to the job. A set of high quality students of Duy Tan University. Project
team began working together in a short time so inadequate, but there are always creative ideas.
Above is an overview of our project team.
Strengths:
- The project team has a high sense of responsibility,
the good discipline.
- Having help from professor
- Project team has good professional skill, trained
by teachers from the prestigious of Duy Tan
University.
- The team project are fully equipped to do the job
properly plan, schedule, budget and requirements.
Opportunities:
- There are many opportunities for
learning, knowledge exchange with
external.
- We have a professional environment.
Weaknesses:
- Project team has less experience.
- Not fluent in programming languages.
Threat:
- First worked together, so many
problems.
- Only four members.
- Lack of time to complete project
H3Q eHospital Web Application
6
Project Plan Document 2012
Name
Position
Role
Description
Guide project teams make products
according to customer requirements
and process.
Guide project teams make products
according to customer requirements
and process.
Mr. Tran Kim Sanh
Mentor 1
Supervisor
Ms. Nguyen Thi Anh Dao
Mentor 2
Supervisor
Ha Ngoc Chung
Leader
Manage team
Role of management, design, test
progress, is one of the main factors
determining the success of the project.
Truong Dang Duy Vinh
Member
Analyst
Requirements specification analysis,
analyzing the hardware requirements,
software requirements, the
requirements for infrastructure
Pham Trung Duc
Member
Programmer,
Designer
Database design, interfaces design.
Performing software tasks have been
assigned work, programming, demo.
Vu Hung
Member
Tester
Interface testing, functional testing.
H3Q eHospital Web Application
7
Project Plan Document 2012
4. Work Breakdown Structure (WBS)
4.1
Development of a website or database system using the sdlc
4.2
Production of detailed design report
5.
Schedule
6.
6.1
6.2
6.3
6.4
6.5
6.6
Deliverables 11
Project Initiation
11
Strategy & planning phase 12
Requirements analysis phase
Design report 13
Build, test and document phase
Transition phase
13
7.
8.
9.
10.
11.
Project Responsibilities
14
Risk Management 15
Change Management
15
Issue Management 16
Communication Management
H3Q eHospital Web Application
12
13
16
8
Project Plan Document 2012
12.
12.1
Quality Checklists
Quality Checklist #1 – Project Initiation
Project Team: Please state the degree of compliance with each of the
following:
Quality Checklist #1 – Project Initiation
All members of the team have completed registration in the course
2=Agree
1=Partly agree
0=Do not agree
0,1,2
Kick off meeting held in convivial meeting place
All team members are committed to the project (IF NOT, SAY SO NOW!)
Team members share what they hope to contribute to and gain from the project
Team members agree on open framework and rules
Team contract signed
Communications strategy for team members agreed
Background to project understood by team
Team members agree on their initial responsibilities (project manager, lead
requirements analysis, lead designer, lead tester, client liaison etc.)
Client contacted - good first impression made - meeting time and venue arranged.
Agenda agreed (for meeting with the client)
Project file (A4 lever arch file) started
First Progress Report complete and posted to Team (Group) Pages
Checklist #1 (this one) is completed.
Someone has been designated to deliver Checklist #1 to Box A2, Level 1
Easterfield on time.
Member Comment:
Name
Signature
Date
Member:
Member:
Member:
Member:
H3Q eHospital Web Application
9
Project Plan Document 2012
12.2
Quality Checklist #2 – Planning
Dear Quality Manager (usually the Project Owner): Please assess the
degree of compliance at the end of the stage.
Quality Checklist #2 – Planning
2=Agree
1=Partly agree
0=Do not agree
0,1,2
Quality Check
This checklist was discussed with the Quality Manager (and amended if
necessary) before proceeding with the Strategy & Planning phase.
Any items that are not relevant must obviously be removed before starting.
What, when, why, how and who
The person who will agree quality standards and sign approvals has been
identified. (This is probably the Project Owner)
The identity of all the stakeholders has been established
The background to the project has been understood and documented
The business objectives have been confirmed with the Project Owner
There is a clear, unambiguous, mission statement
Only items that are feasible (given the limited time and resources) have been
taken into the scope. Items excluded from the scope are also listed
Constraints and assumptions have been identified
The basic nature of all the deliverables has been determined
A work breakdown structure (WBS) is complete
Project responsibilities have been defined
A risk assessment has been carried out
There’s a plan to manage change
There’s a plan to manage issues
There’s a plan to manage communication
A realistic and sincere assessment has determined that the project is feasible
given the time and resources available.
Approval
The Project Owner has approved Strategy & Planning document by signing it.
Project Owner Comment:
Member Comment:
Name
Signature
Date
Project Owner:
Member:
Member:
Member:
Member:
H3Q eHospital Web Application
10
Project Plan Document 2012
12.3
Quality Checklist #3 – Requirements Definition
Quality Manager (usually the Project Owner): Please assess the degree
of compliance at the end of the stage.
2=Agree
1=Partly agree
0=Do not agree
0,1,2
Quality Checklist #3 – Requirements Definition
Quality Check
This checklist was discussed with the Quality Manager (and amended if
necessary) before proceeding with the Requirements Definition phase. Any items
that are not relevant must obviously be removed before starting.
The Statement of Requirements (SOR) includes:
An introduction which includes the business objectives, scope, definitions and
acronyms
A set of functional requirements that are necessary and sufficient
A set of non-functional requirements that are necessary and sufficient
(Performance, Information, Economy, Control & Security, Efficiency, Service)
Every requirement statement is feasible, unambiguous, testable and has a clear
success indicator (so that you can test it).
A test strategy (how the testing is to be done and by whom).
Important constraints and outstanding issues to be taken into account during the
design stage
Appendix A: Details of the Fact-Finding processes used (documents reviewed,
interview dates and attendees, questionnaires, any JRP session)
A robust process was used, that is:
All stakeholders were identified and interviewed as appropriate
Appropriate fact-finding methods were used (existing documentation review,
interviews, user interface prototyping, questionnaires)
The SOR was checked for any requirements that are missing, conflicting,
infeasible, overlapping or ambiguous.
The project stakeholders understand the SOR
Issues were raised with the Project Owner for resolution as appropriate
Approval
The Project Owner has indicated approval of the Statements of Requirements by
signing the appropriate section in that document.
Project Owner Comment:
Member Comment:
H3Q eHospital Web Application
11
Project Plan Document 2012
Name
Signature
Date
Project Owner:
Member:
Member:
Member:
Member:
12.4
Quality Checklist #4
Quality Manager (usually the Project Owner): Please assess the degree
of compliance at the end of the stage.
PROJECT # _______
2=Agree
1=Partly agree
0=Do not agree
0,1,2
Quality check
- This checklist was discussed with the Quality Manager before proceeding
with this phase
-
H3Q eHospital Web Application
12
Project Plan Document 2012
Approval
- The key deliverable from this phase has been formally approved with the
Project Owner’s signature in the document itself
Project Owner Comment:
Member Comment:
Name
Signature
Date
Project Owner:
Member:
Member:
Member:
Member:
12.5
Quality Checklist #5 – Build, Document and test
Quality Manager (usually the Project Owner): Please assess the degree of
compliance at the end of the stage.
Quality Checklist #5 – Build, Document and test
Quality Check
This checklist was discussed with the Quality Manager (and amended if
necessary) before proceeding with the Build, Document and Test phase
Execution / Development / Building / Main stage
- The Project Owner was regularly consulted during this stage
H3Q eHospital Web Application
2=Agree
1=Partly agree
0=Do not agree
0,1,2
13
Project Plan Document 2012
- Scope Changes were handled using the Scope Change Management process
Testing
- A comprehensive set of tests were carried out to determine which
requirements were satisfied.
- A comprehensive set of tests were carried out to determine if the products
behaved well or badly under unusual, stressful circumstances.
- End users were involved in the testing
- The results of all tests have been recorded
- All key products were tested including training and documentation
Document
- A technical document has been written to aid maintenance of the system
- A user guide (or help file) has been produced to aid the user
Approval
The Project Owner has provided written approval of the Build, Test and
Documentation phase.
Project Owner Comment:
Member Comment:
Name
Signature
Date
Project Owner:
Member:
Member:
Member:
Member:
H3Q eHospital Web Application
14
Project Plan Document 2012
12.6
Quality Checklist #6 – Transition & Closing
Quality Manager (usually the Project Owner): Please assess the degree of
compliance at the end of the stage.
2=Agree
1=Partly agree
0=Do not agree
0,1,2
Quality Checklist #6 – Transition & Closing
The key deliverable
The key deliverables have been adequately tested against the requirements
The key deliverables meet the requirements stated in the requirements doc.
The key deliverables have been transitioned into use as planned
The system is integrated with other systems as planned
Arrangements have been made to back up data where appropriate
All documentation has been delivered as planned and to the agreed quality
All training has been given as planned
Arrangements have been made for ongoing support of the system as planned
The process
Adequate meetings were held with the project owner
The team recorded issues and managed their resolution
The team identified risks and managed them adequately
Changes to the scope were managed fairly
The team has behaved in a professional manner throughout the project
The team made a presentation of the products and formally handed them over
Final Approval
By signing here, the Project Owner accepts delivery of the final system or
products as meeting the agreed requirements: _________________________
Project Owner Comment:
Member Comment:
Name
Signature
Date
Project Owner:
Member:
Member:
Member:
Member:
H3Q eHospital Web Application
15