Initial Projec Plan

PROJECT MANAGEMENT PLAN
FOR
ONLINE UNIVERSITY
REGISTRATION SYSTEM
Version 1.0 approved

Date of issue: March 02, 2009
Company: Blackmoon Solutions
Prepared by:
Đậu Quang Nam
Bùi Tá Duy
Trần Đình Hoà
Project plan URS 1.0
Change History
Date of issue Revision Filename Document format

number
03/02/09 1.0 InitialProjectPlan_v1.pdf Portable Document Format
Approval signatures
Project Manager Business Analyst
Technical writer
Page 2
Table of Contents
1. Project Overview......................................................................................................................4
1.1. Purpose, Scope and Objectives.....................................................................................................4
1.2. Assumptions and Constraints........................................................................................................4
1.3. Project Deliverables......................................................................................................................5
1.5. Evolution of the Plan....................................................................................................................5
1.6. References and Definitions...........................................................................................................5
2. Project organization.................................................................................................................8
2.1. External Interfaces........................................................................................................................8
2.2. Internal Structure..........................................................................................................................8
3. Managerial Process Plans......................................................................................................11
3.1. Start-up Plan................................................................................................................................11
3.2. Work Plan...................................................................................................................................12
3.3. Risk Management Plan...............................................................................................................15
4. Technical Process Plans.........................................................................................................18
4.1. Process Model.............................................................................................................................18
4.2. Methods, Tools and Techniques..................................................................................................19
4.3. Infrastructure...............................................................................................................................20
4.4. Product Acceptance.....................................................................................................................20
5. Supporting Process Plans......................................................................................................20
5.1. Verification and Validation..........................................................................................................20
5.2. Documentation plan....................................................................................................................20
Appendix.....................................................................................................................................21
Page 3
1. PROJECT OVERVIEWS
1.1. Purpose, Scopes and Objectives
University Registration System (URS) is a web-based software system which be developed for ABC University
to improve the education quality. Purpose of the system is given students and lectures better way to deal with
academic semesters, avoid the disadvantages of the traditional way, organize the courses and setup the
connections between students, lecturers and staffs on the web-based system.
The scopes of the project are:

• Organizing all the courses and student's academic information in a web-based tool, which will be used by
students, lecturers, administrators.
• The registration system is intended for use by all students.
• Newly-admitted students will receive an information package containing Student ID, and a set of instructions
for using the system.
The objectives for this project is create a system that satisfies the following requirements:
• Students should be able to register their courses in a semester completely through the internet, avoid the waste
of time and money, more effective than the traditional method.
• Students can search through the courses catalog, check academic history, check status, print their timetable,
add or drop classes for the semester
• Administrators have the ability to managed courses and student accounts for each semester, they can add,
delete and update based on the requirements of students an the lecturer.
1.2. Assumptions and constraints

Assumptions:
• Initial project management plan should be prepared at first
• Blackmoon Solutions has 7 members and each works for 30 hours/week
• All members have computers
• Development team have to work with customer at certain milestones
• Customer provide related servers.
Constraints:
• Java, CSS and xHTML will be used for implementation
• MySQL will be used for database management
• PHPMyAdmin will be used for database designing
• SmartDraw 2008 and Dia Diagram Editor will be used for modeling
• The documentation have to meet the IEEE Standard
• The website have to run smoothly on popular browsers
Page 4
1.3. Project deliverables
Blackmoon Solutions will deliver URS 1.0 and associated documents to the client no later than May 24, 2009.
In addition, a final report and presentation will be given to the client at about that time. These deliverables are
described in figure 1.
1.4. Evolution of the plan

This document is the initial version of URS project management plan. This also contains the update versions of
initial plan. Project management plan explains all management and process events about the project.
1.5. References and Definitions
References:
• IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans.
• Software Engineering, 8th Edition, Ian Sommerville, Addison-Wesley Publishers.
• http://en.wikipedia.org/wiki/Gantt_chart
• http://en.wikipedia.org/wiki/Waterfall_model
• http://en.wikipedia.org/wiki/Work_breakdown_structure
Definitions:
IEEE Institute of Electrical and Electronics Engineers
CASE Computer-Aided Software Engineering
WBS Work Breakdown Structure
SRS Software Requirements Specifications
SDS Software Design Specifications
URS University Registration System
J2EE Java 2 Enterprise Edition
MySQL Multi-user database management system
GUI Graphic User Interfaces
Page 5
Figure 1: Project milestones and deliverables
Page 6
Page 7
2. PROJET ORGANIZATION
2.1. External interfaces
This figure shows the organizational boundaries between URS and external companies.
External interfaces list:

• Customer: ABC University
• Development company: Blackmoon Solutions
2.2. Internal structure

About us
Name Blackmoon Solutions
Field Web Design and Development
Location HCMC, Vietnam
Website http://blackmoonsolutions.com
Emails contact@blackmoonsolutions.com
support@blackmoonsolutions.com
sales@blackmoonsolutions.com
We are one of the most successful web design and outsourcing companies in Vietnam and we work with clients
from all over the world. We can outsource design and web design departments of your company, your university
as well as we can offer you all services as separate one.
We supply services of web application development, professional e-commerce online shopping system, school
registration/admission system, e-learning system. Especially, we focus on products that support education and e-
learning system.
Page 8
Blackmoon Solutions features an integrated team of web consultants, creative designers, writers, developers and
marketing professionals that know how to get online results.
Our business-driven approach separates us from typical web design companies. For more than five years, we
have built a reputation for creating a positive return on investment for our clients.
Strategic thinking, top web design, personal attention, competitive prices, real world results - discover the
Blackmoon Solutions difference.
URS Project
In URS project, internal structure will be consist of System analysis team, Development team, Documentation
team and Testing team. All of these teams will cooperate with the project manager. In fact, one member can
attend more than one team in project.
Figure 3: Internal Structure
2.3. Roles and responsibilities

Roles Responsibilities
Client ABC University, the organization that specifies the requirements for and
delivery of USR and its documentation
Consultant Dr. Hoang Phan, the person who will concern the required level of quality is
achieved in product
Team member Blackmoon Solutions, the members who will attend and work on the
project.
Explanation of the roles
Page 9
Team member Roles Contact information

Đậu Quang Nam Project manager Email: namdq.nu@gmail.com
Technical architect
Developer
Technical writer
Bùi Tá Duy Business analyst Email: dicky_pei@yahoo.com
Technical writer
Nguyễn Quốc Việt Developer Email: lun_iu@yahoo.com.vn
Designer
Trần Tiến Thành Developer Email: x_nova2k@yahoo.com
Database engineer
Technical writer
Trần Minh Hiền Database engineer Email: minh_hien1357@yahoo.com.vn
Designer
Đặng Huê Tân Technical writer Email: badboy_vt1209@yahoo.com
Testing engineer
Trần Đình Hòa Technical writer Email: hoa05032003@yahoo.com
Testing engineer
Roles of team members
Roles Responsibilities
Project manager The member who will be worked on the management side and
responsible for the project
System analysis team The members who will be worked on the requirements analysis and
specification phases of the project
Development team The members who will be worked on the design and implementation
phases of the project
Documentation team The members who will be worked for all the associated documents of the
project
Testing team The members who will be worked on the testing, verification and
validation of the project
Explanations of internal roles
Page 10
3. MANAGERIAL PROCESS PLAN
3.1. Start-up plan
• Estimation plan
Time estimation:
Initial Project Plan 8 days
URS Requirements Specifications 8 days
Final Project Management Plan 5 days
URS Design Specifications 19 days
URS Implementation 23 days
URS Testing 13 days
Finish all documentation 3 days
Prototype and Demonstration 3 days
Holiday 2 days (30/4 and 1/5)
Total 83 days
Resources estimation:
Resources name Cost Resource type
CPU: Xeon Dual Core E3110 3.0GHz - 1333 MHz Hardware
L2 Cache: 6MB L2 Cache
Memory: 2 x 512MB PC2 – 5300 667MHz ECC DDR2-
Server computer: SDRAM/ 8GB
IBM SERVER
HDD: 250 GB 7,2K SATA $1,220.00
System x3200
M2 Network: Integrated Gigabit Ethernet (GbE), Gigabit
10/100/1000
Power supply: 400 W NHS 1/1
PCI disk Controller: Four channel SATA controller
Microsoft Ofice Project Professional 2007 $999.95 Software
SmartDraw 2008 $197.00 Software
Total $2,416.95
Salary estimation:
Page 11
Work hours: (83-2)*5 = 405 hours

Number of members: 7
Salary = cost per hour * work hours
Name Cost per hour Salary

Nam $4.50 $1,822.50
Duy $4.00 $1,620.00
Việt $4.00$1,620.00 $1,620.00
Thành $4.00 $1,620.00
Hiền $4.00 $1,620.00
Hòa $4.00 $1,620.00
Tân $4.00 $1,620.00
Total $11,542.50
Total cost = $2416.95 + $11542.5 = $13959.45
3.2. Work plan

• Work breakdown structure: Figure 4: Work breakdown
Page 12
Page 13
Page 14
• Risk management plan
Risk identification:
Type Possible risks
Technology – Basis technology choices may be inadequate (e.g J2EE)

– MySQL may not meet the requirements when the numer of user get increasing
– The changing technology is so quickly, maybe to make the project become
superannuation.
Budget – Wrong budget estimation, cost overruns and project scope expansion.
Organizational – Blackmoon Solutions is restructured so that different management is responsible

for the project.
Tools – The code generated by CASE tools is inefficient.

– CASE tools cannot be integrated (e.g NetBeans and Eclipse have bugs)
– The developers may not like some of the tools used, or may not like to learn a
new language, or using a new testing environment.
People – Some of the members in group may not feel committed to the project, and would
take the milestones seriously.
– Members in group have differences skill, expectation, attitude, experience work.
– Members of groups are ill and unavailable at critical times.
Requirements – Changing of customer's requirements

– Customers fail to understand the impact of requirements changes.
– Developing wrong user interfaces.
Estimation – Project schedule get slip and wrong time estimation.

– The rate of defect repair and the size of the software are underestimated.
– Failure to identify complex functionalities and time required to develop those
functionalities.
Page 15
Risk analysis and prioritizing:
Risk Effects Probability Participants

J2EE may be an inadequate choice Moderate Serious Product risk
The changing technology is so quickly, Moderate Serious Product risk
maybe to make the project become
superannuation
The developers may not like some of the High Catastrophic Product risk
tools used, or may not like to learn a new
language, or using a new testing
environment.
Some of the members in group may not feel Low Serious Project risk
committed to the project, and would take the
milestones seriously.
Project schedule get slip and wrong time Moderate Serious Project risk
estimation.
Failure to identify complex functionalities High Serious Project risk
and time required to develop those
functionalities.
Unexpected project scope expansions of Moderate Tolerable Project risk
software.
Wrong budget estimation, cost overruns and High Catastrophic Project risk
project scope expansion.
The code generated by CASE tools is Low Serious Product risk
inefficient.
Changing of customer's requirements Low Serious Project risk
Customers fail to understand the impact of Moderate Tolerate Project risk
requirements changes.
The rate of defect repair and the size of the Moderate Tolerable Product risk
software are underestimated.
The organization is restructured so that Low Catastrophic Project risk
different management is responsible for the
project.
Members of groups are ill and unavailable at Moderate Serious Project risk
critical times.
Developing wrong user interfaces. Low Serious Product risk
Members in group have differences skill, High Serious Product risk
expectation, attitude, experience work.
Page 16
Risk management planning
Risk Management Planning Strategy

Technology problem Giving all advices to customers about risks, benefits and method to using
software. Develop a friendly graphic user interface.
Budget problem Finding sources of funding more in project.
People problems Publish weekly status and review reports. Help any team member who is
having problems meeting the schedule or deliverables.
Tools problems Investigating the possibility of buying higher-technologies.
Members of group illness Reorganizing team so that there is more overlap of work and people
therefore understand each other’s jobs.
Requirements change Usually communicate with customers about URS. Derive traceability
information to assess requirements change impact, maximize information
hiding in the design. Set a firm day finalizing of requirements. Consider
an incremental development paradigm that can defer changes to later
development increments
Organizational restructuring Preparing a briefing document for senior management showing how the
project is making a very important contribution to goals of the business.
Estimation problems Use prototypes as part of requirements or design phase for user and
developer gain a better understanding of final product requirements.
Force the members of group following to the project plan. Reducing at
least complex functionalities. Definite exactly the time required to
complete product.
Risk monitoring
Risk types Potential indicators

Technology Late delivery of hardware, not develop and support hardware, many reported
technology problems.
Budget Spend irrational in implementation project.
Budget cuts upset project plans
Organizational Organizational gossip.
Tools Reluctance by team members to use tools, complaints about CASE tools.
Amount of reused software impact risks.
People Poor relationships amongst team members. Operation in an unfamiliar or unproved
software environment causes unforeseen problems
Requirements Many requirements change requests, customer insists on new requirements.
Customer communication time (e.g. time to answer requirements-clarification
questions) is slower than expected
Eliminations Failure to unite schedule, failure reports weekly.
• Notes: Risk management will update more after requirements analysis and negotiation.
Page 17
4. TECHNICAL PROCESS PLAN

4.1. Proces model
URS is developed follows waterfall model. We choose waterfall model for this project because the requirements
of ABC University are well understood, it is unlikely to change radically during development process, and
documentation is produced at each phases. The figure below illustrates the overall tasks associated with
software process model. Waterfall is the most suitable one for this project
Figure 4: Process model
Page 18
4.2. Methods, tools and techniques
Development methodology The waterfall life cycle model shall be used for the
development process of URS
Programming language Java, focus on J2EE 5 platform: Servlets, JSP
Extra languages CSS, HTML/xHTML to deal with presentation layer
Development environment and tools JDK 6 Update 12 with Java EE
NetBeans 6.5 and plugins
Eclipse 3.4 and plugins
Bluefish Editor 1.0.7
Firebug (Firefox's add-on)
PHPMyAdmin
Firefox 3
Internet Explorer 7
Opera 9
Safari 4 Beta
Database MySQL 5
Application servers GlassFish v3 Prelude
Apache Tomcat
Document editor OpenOffice Writer 3.0.1
Project management tools Microsoft Project 2007
Modeling tools SmartDraw 2008
Dia Diagram Editor
Software project management plan Based on IEEE Std 1058-1998
document
Software requirements Based on IEEE Std 830-1998
specifications document
Software design description Based on IEEE Std 1016-1998
document
Page 19
4.3. Infrastructure
For developing URS, each member will use well-equipped computers that we are provided.
Detailed infrastructure is described below.
Workstations Member's houses

Meeting room at company
Hardware 7 standard PC of members
Network Internet access
Local area network at office
Operating System Windows XP Professional SP2
Ubuntu 10.8
4.4. Product acceptance

Firstly, URS will be prepared with the project's consultant. Development team will receive the comments and
corrections from consultants and keep working to improve the URS quality. After that, the documents will be
presented to ABC University by development team at the meetings. Team members will consider the feedback
from ABC University and working on the documentation. The published documents should be presented to
Quality Assurance Manager before the deadline, no delay is acceptable. Quality assurance manage will examine
the published documents and send it back to development team if there is any error or misunderstanding.
Finally, URS will be installed and operated at ABC University, it will be used by students and lecturers. And if it
has some problems, the team have to fix it as fast as possible.
5. SUPPORTING PROCESS PLAN

5.1. Verification and validation plan
Verification and Validation (V&V) is the process of checking that a software system meets specifications and
that it fulfills its intended purpose. V&V is normally part of the software testing process of a project.
In URS project, V&V is handled by Hòa and Tân for verification purposes. After the bugs and errors are fixed,
updated URS will be delivered to Tân for validation purposes. The schedule of testing depend on the delivery
dates of the software project deliverables. After all, Nam will review all V&V works. The verification and
validation processes will be realized according to the software development process model of the software
project.
5.2. Documentation plan

The documentation plan should include plans for generating non-deliverable and deliverable products.
Organizational responsibilities for providing, generating and reviewing should be included in this plan. The
deliverable documents of URS software project are:
• Initial Project Plan
• System Requirements Specifications Document
• Final Project Management Plan Document
• System Design Specifications Document
• User Manual
Page 20
APPENDIX
Page 21
Page 22

Initial Projec Plan

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Initial Projec Plan

Uploaded by

Copyright:

Available Formats

PROJECT MANAGEMENT PLAN

Version 1.0 approved

Date of issue Revision Filename Document format

Project Manager Business Analyst

The scopes of the project are:

1.2. Assumptions and constraints

1.4. Evolution of the plan

1.5. References and Definitions

Figure 1: Project milestones and deliverables

External interfaces list:

2.2. Internal structure

Figure 3: Internal Structure

2.3. Roles and responsibilities

Explanation of the roles

Team member Roles Contact information

Roles of team members

Explanations of internal roles

Work hours: (83-2)*5 = 405 hours

Name Cost per hour Salary

Total cost = $2416.95 + $11542.5 = $13959.45

3.2. Work plan

Type Possible risks

Technology – Basis technology choices may be inadequate (e.g J2EE)

Organizational – Blackmoon Solutions is restructured so that different management is responsible

Tools – The code generated by CASE tools is inefficient.

Requirements – Changing of customer's requirements

Estimation – Project schedule get slip and wrong time estimation.

Risk analysis and prioritizing:

Risk Effects Probability Participants

Risk management planning

Risk Management Planning Strategy

Risk types Potential indicators

4. TECHNICAL PROCESS PLAN

Figure 4: Process model

Workstations Member's houses

4.4. Product acceptance

5. SUPPORTING PROCESS PLAN

5.2. Documentation plan

You might also like