CPSC-546 Software Project Management
Software Development Plan
XXX Project
May 15, 2009
Submitted By
Dang, Steven
Desai, Kunal
Jeyabalan, Inita
Maisuriya, Amit
Submitted to
Prof. Allen Holliday
California State University, Fullerton
i
Table of Contents
1
2
3
4
5
6
7
8
Overview ................................................................................................................................... 1
1.1 Project Summary ............................................................................................................... 1
1.1.1 Purpose, Scope, and Objectives.................................................................................. 1
1.1.2 Assumptions and Constraints ..................................................................................... 2
1.1.3 Project Deliverables ................................................................................................... 2
1.1.4 Schedule and Budget Summary.................................................................................. 2
1.2 Evolution of the Plan ......................................................................................................... 2
Reference Materials .................................................................................................................. 2
Definitions and Acronyms ........................................................................................................ 3
Project Organization ................................................................................................................. 3
4.1 External Interfaces ............................................................................................................. 3
4.2 Internal Structure ............................................................................................................... 3
4.3 Roles and Responsibilities ................................................................................................. 4
Managerial Process Plans.......................................................................................................... 4
5.1 Startup Plan........................................................................................................................ 4
5.1.1 Estimation Plan........................................................................................................... 4
5.1.2 Staffing Plan ............................................................................................................... 5
5.1.3 Resource Acquisition Plan ......................................................................................... 6
5.1.4 Project Staff Training Plan ......................................................................................... 6
5.2 Work Plan .......................................................................................................................... 6
5.2.1 Work Activities .......................................................................................................... 6
5.2.2 Schedule Allocation ................................................................................................. 11
5.2.3 Resource Allocation ................................................................................................. 12
5.2.4 Budget Allocation..................................................................................................... 12
5.3 Control Plan ..................................................................................................................... 12
5.3.1 Requirements Control Plan....................................................................................... 14
5.3.2 Schedule and Budget Control Plan ........................................................................... 15
5.3.3 Quality Control Plan ................................................................................................. 15
5.3.4 Reporting Plan .......................................................................................................... 15
5.3.5 Metrics Collection Plan ............................................................................................ 15
5.4 Risk Management Plan .................................................................................................... 16
5.5 Project Close-out Plan ..................................................................................................... 16
Technical Process Plans .......................................................................................................... 17
6.1 Process Model.................................................................................................................. 17
6.2 Methods, Tools, and Techniques ..................................................................................... 17
6.3 Infrastructure Plan ........................................................................................................... 18
6.4 Product Acceptance Plan ................................................................................................. 18
Supporting Process Plans ........................................................................................................ 18
7.1 Configuration Management Plan ..................................................................................... 18
7.2 Testing Plan ..................................................................................................................... 19
7.3 Documentation Plan......................................................................................................... 20
7.4 Quality Assurance Plan.................................................................................................... 20
7.5 Subcontractor Management Plan ..................................................................................... 20
7.6 Process Improvement Plan .............................................................................................. 20
Additional Plans ...................................................................................................................... 21
i
1 Overview
In order to enhance the business operations and customer support, Tool Co Company needs better
approach for the services. The website is considered as the enhancement factor. This website will deliver
an online platform for the customers to place orders online. The system will also enable inventory and
internal management team to catch up with the dynamic updates and make well thought decisions. The
website will offer range of the tools online for the selection purposes.
1.1 Project Summary
After project is available for operational use it would add number of functionalities to the overall
functioning of the system. It would computerize internal and external interfaces. The system would be
helpful to give a better approach to customer service. It would come up with a diverse range of
commercial options for the users and for that the database will be layered according to product line
requirements. It would add more predictability to inventory system. It would make the system more
integrated.
1.1.1 Purpose, Scope, and Objectives
Purpose:
The website will give company a cheap, fully integrated and more available system over the time. The
issues, which were faced by the company because of old telephonic system, were very intense. The old
system was not available all the times. The website will be available for all the customers for 24 hours.
This website will enhance the availability of the product.
The website will highly focus on integrating inventory system with other departments. With this website,
company’s departmental integrity will increase. Now, sales department will always know that how much
stock is available before committing a particular product to the customer.
Instead of hiring customer service people, the website will take care of the ordering and customer support.
This way website will play a major role in cost reduction.
The system will also help people in warehouse to locate the particular product in the process.
Scope:
In scope

Order placement facility

Advanced and customized search for the products

Product description

User data authentication

Synchronization with inventory management

Ware house product location search
Out of scope
Shipping facility (The system will provide a feature to select the shipping services but once transaction
takes place, system will hand over the whole shipping transaction system to shipping vendor).
Purchase Order (The system will help in synchronizing with the inventory management and out-of stock
notifications, but it will not purchase items itself when it reaches reorder threshold).
1
Objective
The prime objective of the system is to deliver integrity in the data flow. System will take care of the
customer care in a way that of a customer wants to an order then he gets full range of the choices and if he
buys something then subsequent tasks like delivering the product, notifying to the carrier and making the
changes to the inventory will be taken care of.
1.1.2 Assumptions and Constraints
a) The system can be access anywhere regardless of user’s location through the internet.
b) Each user must have user id and password
c) There is always at least one Administrator.
d) Server must run under Windows System
e) Internet connection is mandatory.
f) Proper Browser must be installed.
g) PDF reader must be installed to view online invoice and help files.
1.1.3 Project Deliverables
 An operational website, which can be used by customers to place orders and can also be used by
managerial people.
 A synchronized inventory system.
 A website manual.
 Project documentation.
1.1.4 Schedule and Budget Summary
Overall budget
Overall duration
$ 260,000
01-Jun-2009 to 23-Nov-2009 [Nov 17th the
release date of the product]
The budget summary:
Estimated amount for employees: $235,120 [Calculated]
Level of effort that might be required: 2% ($ 5,200) [Assumption]
Buffer amount: $19,680 (7.6%) [Remaining]
1.2 Evolution of the Plan
Firstly initial draft will be created and delivery for reviewing comments and any changes if required.
Further the changes and comments will be considered and approved by the respective authorized person
and then second draft will be implemented, incorporating preliminary review comments and changes and
delivered for final review. After this final complete draft will be prepared under the change control,
further draft will be keep on revised as per the change control process and maintained under change
control.
2
In normal scenario, the basic evolution plan will be followed but if there are sudden changes then they
can be accommodated with permission of change control manager.
2 Reference Materials

Software Engineering: A Practitioner's Approach by Roger Pressman (7th Edition).

Software Engineering by Ian Sommerville (7th Edition)
3 Definitions and Acronyms
QA- Quality Assessment
DBA- Database Administrator
WBS- Work Breakdown Structure
LOE- Level Of Effort
SRS- Software Requirement Specification
UML- Unified Modeling language
CM- Configuration manager
ORM –Object relational modeling
ISP- Internet Service Provider
4 Project Organization
4.1 External Interfaces
Company President
The president wants a high quality Web Order System to take orders, fulfill orders, and manage inventory
with on-time completion
Users
The sales people, customers, and warehouse workers want a fast, easy to use, and reliable system that
helps them support consumers.
4.2 Internal Structure
Director
Configuration/
Change Control
Manager
QA Manager
Project Manager
DBA Manager
Build Team
QA Team
Web Development
Team
DBA Team
3
Web development team consists of a project manager and a group of software engineers, graphic
designers, and database engineers. This team responsible for designing and implement web order
application. Project Manager’s goal is to complete the project successful and be seen as an up-and-coming
manager with well respected. Under high pressure, he is willing to trade features and quality with cost
and schedule.
QA Team consists of a QA manager and a quality assurance team to test system functionality and ensure
it meets client’s requirement.
Change Control team consists of a Configuration/Change Control manager and a build team to label
control project versioning and taking care deployment.
Director will oversee the whole project and ensure the timely delivery of the system.
4.3 Roles and Responsibilities
Title
Responsibility
Director
Oversee the operation of the project and ensure the
project complete on time.
Project Manager
Oversee the web development operation, assign the
best fit resource for the task, project planning, and
ensure system build with high quality and complete
web development on time.
QA Manager
Oversee the QA, delegate right resource to test and
ensure all objectives in QA plan meet requirement.
Configuration/Change Control manager
Manages iteration build, allocates resources to
build the system. Also manages that the changes to
the system are introduced in a controlled and
coordinated manner
DBA Manager
Oversee DBA personnel and monitoring database’s
health.
5 Managerial Process Plans
5.1 Startup Plan
5.1.1 Estimation Plan
The schedule estimation plan:
Based on the WBS the precedence diagram of the project plan is formed and then the critical path is
identified. The below estimation of the schedule is obtained from the precedence diagram. If any delay in
the completion of the critical component, then it affects the completion date of the below components. So
it will be well managed such that the critical component gets completed on time, in order to prevent any
delay in the release date.
4
Component
Description
Date Expected
Prototype demonstration
Different layout including presentation and
demonstration of whole system will be
available for demonstrating whole system.
06/29/09
The executable architecture
design modeling
Whole Web Order system design and
architecture will be prepared and further
system is ready for implementation.
07/22/09
The critical component
demonstration
The certain critical components will be
checked and verified according to the
requirement and if any modification is
required then it will be considered and further
improvement will be done.
08/04/09
Alpha release
Certain testers will be analyzing whole Web
order system and if any bug or error identified
it would be fixed.
10/07/09
Beta release
Certain client will be given the product for
reviewing and evaluating the whole Web
order system.
11/03/09
Final product
The Web order system will be delivered to the
client.
11/17/09
The cost estimation plan:
The total cost of the employees is calculated as = (salary per day) * total no. of days
Salary per day is calculated as below:
Number of weeks/year = 52
Eligible vacation/year = 2 weeks [Assumption]
Number of work weeks/year = 52-2 = 50 weeks
Total work hrs/year = 50 * 5 days* 8hrs = 2000 hrs.
Average pay/hr for an employee = annual salary/2000
Average pay /day for an employee = annual salary/250
The environment [software/hardware, tools] that is required for this project is available in-house. So as
per the current scenario purchase of hardware/software or any specific tools is not required.
Hence total cost = Employee cost
5.1.2 Staffing Plan
Staff members
Salary/year Employee id
Total
Count
Salary
/Day
Director
$150k
1
$600
ED:01
5
Configuration/Change
Control Manager
$100k
EM:01
1
$400
QA Manager
$80k
EM:02
1
$320
Software Architect
$100k
EA:01
1
$400
Project Manager
$100k
EM:03
1
$400
Business Analysts
$75k
EB:01 – EB:04
4
$300
Application Programmers $75k
EP:01 – EP:08
8
$300
QA Testers
$50k
ET:01 – ET:04
4
$200
System
Programmers/Admin
$50k
ES:01 – ES:03
3
$200
Database Admin/Support
$75k
EDA:01 – EDA:03
3
$300
Network Admin
$65k
EN:01 – EN02
2
$260
For the details of each employee’s duration of work, refer 5.2.1
5.1.3 Resource Acquisition Plan
In this project all tools and technology including software, hardware as well as services will be obtained
from company. Any resource not available will be requested through the helpdesk into the company with
the permission of authorized person. With the help of different software tools and technology the progress
of project as well as deliverable of software development plan will be available. Demonstration of project
as well as training will be provided by the company.
5.1.4 Project Staff Training Plan
This project involves a few well trained and experienced programmers and testers, and moreover this
project does not involve any recent technology. Hence as per the current scenario, any specific training on
technology might not be required for this project. But training might be conducted on ‘as needed’ basis on
any specific feature that might be requested particularly by the client.
5.2 Work Plan
5.2.1 Work Activities
The Work Breakdown Structure (WBS).
WBS ID
A
Task Name
Duration
Float
Employee id
0
ED:01, EM:03, EB:01
0
EB:01, EM:03
8
EA:01, EM:03
Management
AA
Inception phase management
AAA
Business case development
AAB
Software project development plan
AAC
Elaboration phase WBS baselining
ES: 06/01/09 EF: 06/02/09
LS: 06/01/09 LF: 06/02/09
(2wd)
ES: 06/03/09 EF:06/08/09
LS: 06/03/09 LF:06/08/09
(4wd)
ES: 06/09/09 EF: 06/15/09
LS: 06/19/09 LF: 06/25/09
(5wd)
6
AAD
Elaboration phase release specifications
AAE
Inception phase project control and status
assessments
AB
Project schedule and budget planning
ABB
Manage requirements gatherings
ABC
Planning user acceptance criteria
ABD
Human Resource planning
ABE
Stakeholder communication planning
ABF
Construction phase WBS baselining
AC
Elaboration phase project control and status
assessments
Quality control planning
ACB
Risk management planning
ACC
Test planning
ACD
Change control planning
ACE
Integration planning
ACF
Maintenance planning
ACG
Deployment phase WBS baselining
AD
ADA
ADB
EM:03
0
ED:01, EM:03
ES: 07/02/09 EF: 07/06/09
LS: 07/02/09 LF: 07/06/09
(3wd)
ES: 07/07/09 EF: 07/13/09
LS: 07/21/09 LF: 07/27/09
(5wd)
ES: 07/14/09 EF: 07/15/09
LS: 07/28/09 LF: 07/29/09
(2wd)
ES: 07/16/09 EF: 07/17/09
LS: 07/30/09 LF: 08/02/09
(2wd)
ES: 07/18/09 EF: 07/21/09
LS: 08/03/09 LF: 08/04/09
(2wd)
ES: 07/22/09 EF: 07/24/09
LS: 08/05/09 LF:08/07/09
(3wd)
ES: 08/08/09 EF: 08/11/09
LS: 08/08/09 LF: 08/11/09
(2wd)
0
EP:01, ES:01, EDA:01,
ED:01, EM:03
10
EM:03
10
EB:01, EM:03
10
EM:03
10
EM:03, EM:01,
ED:01,EM:02,EB:01
10
EM:03
0
EM:03, ED:01
ES: 08/12/09 EF: 08/14/09
LS: 09/01/09 LF: 09/03/09
(3wd)
ES: 08/15/09 EF: 08/20/09
LS: 09/04/09 LF: 09/09/09
(4wd)
ES: 08/21/09 EF: 08/26/09
LS: 09/10/09 LF: 09/15/09
(4wd)
ES: 08/27/09 EF: 08/28/09
LS: 09/16/09 LF: 09/17/09
(2wd)
ES: 08/29/09 EF: 09/07/09
LS: 09/18/09 LF: 09/25/09
(6wd)
ES: 09/08/09 EF: 09/09/09
LS: 11/03/09 LF: 11/04/09
(2wd)
ES: 09/10/09 EF: 09/14/09
LS: 11/05/09 LF: 11/09/09
(3wd)
ES: 11/10/09 EF: 11/11/09
LS: 11/10/09 LF: 11/11/09
(2wd)
14
EM:02, EM:03
14
EM:03
14
EM:02
14
EM:01, EM:03
14
EM:01
40
EM:03
40
EM:01, EM:03
0
ED:01, EM:03
ES: 11/12/09 EF: 11/13/09
LS: 11/12/09 LF: 11/13/09
(2wd)
ES: 11/20/09 EF:11/23/09
LS: 11/20/09 LF: 11/23/09
(2wd)
0
EM:03
0
ED:01, EM:03
Construction phase management
ACA
ACH
8
Elaboration phase management
ABA
ABG
ES: 06/16/09 EF: 06/17/09
LS: 06/26/09 LF: 06/29/09
(2wd)
ES: 06/30/09 EF: 07/01/09
LS: 06/30/09 LF: 07/01/09
(2wd)
Construction phase project control and status
assessments
Transition phase management
Prepare closure activities
Transition phase project control and status
assessments
7
B
Environment
BA
Inception phase
BAA
Hardware requirements planning
BAB
Design development environment architecture
BB
Development environment installation and
administration
BBB
Development environment integration and custom
toolsmithing
BC
Database formulation
Development environment administration
BCB
Database maintenance
1
ES:01, ES:02, ES:03
ES: 07/07/09 EF: 07/08/09
LS: 07/07/09 LF: 07/08/09
(2wd)
ES: 07/09/09 EF: 07/10/09
LS: 07/09/09 LF: 07/10/09
(2wd)
ES: 07/11/09 EF: 07/13/09
LS: 07/11/09 LF: 07/13/09
(1wd)
0
ES:01, ES:02, ES:03, EN:01,
EN:02
0
ES:01, ES:02, ES:03, EN:01,
EN:02
0
EDA:01, EDA:02, EDA:03
08/12/09 to 11/09/09
[LOE]
08/12/09 to 11/09/09
[LOE]
ES:01, ES:02, EM:03
EDA:01, EM:03
Transition phase
BDA
Development environment administration
BDB
Database maintenance
C
ES:01, EN:01, EM:03
Construction phase
BCA
BD
1
Elaboration phase
BBA
BBC
ES: 06/09/09 EF: 06/09/09
LS: 06/10/09 LF: 06/10/09
(1wd)
ES: 06/10/09 EF: 06/12/09
LS: 06/11/09 LF: 06/15/09
(3wd)
ES: 11/12/09
LS: 11/12/09
(8wd)
ES: 11/12/09
LS: 11/12/09
(8wd)
EF: 11/23/09
LF: 11/23/09
0
ES:01, ES:02, EM:03
EF: 11/23/09
LF: 11/23/09
0
EDA:01, EM:03
ES: 06/09/09
LS: 06/09/09
(2wd)
ES: 06/11/09
LS: 06/11/09
(3wd)
EF: 06/10/09
LF: 06/10/09
0
EB:01,EM:03
EF: 06/15/09
LF: 06/15/09
0
EB:01, EB:02, EB:03
ES: 07/07/09
LS: 07/07/09
(2wd)
ES: 07/09/09
LS: 07/09/09
(3 wd)
EF: 07/08/09
LF: 07/08/09
0
EB:01, EB:02, EB:03, EB:04
EF: 07/13/09
LF: 07/13/09
0
EB:01
Requirements
CA
Inception phase
CAA
Requirements vision specification
CAB
Use case modeling
CB
Elaboration phase
CBA
Business and system requirements definition
CBB
Use case model baselining
CC
CCA
CD
CDA
D
Construction phase
Requirements maintenance
08/12/09 to 11/09/09 [LOE]
EM:01
Transition phase
Requirements maintenance
ES: 11/12/09 EF: 11/23/09
LS: 11/12/09 LF: 11/23/09
(8wd)
0
EM:01
ES: 06/16/09 EF: 06/19/09
LS: 06/16/09 LF: 06/19/09
(4wd)
0
EA:01
Design
DA
DAA
Inception phase
Software architecture prototyping
8
DB
Software architecture design modeling
DBB
Design demonstration planning and conduct
DBC
Software architecture description
DC
Component level detailed design modeling
DCB
Architecture design model maintenance
DDA
E
ES: 07/14/09 EF:07/16/09
LS: 07/14/09 LF:07/16/09
(3wd)
ES: 07/21/09 EF: 07/22/09
LS: 07/21/09 LF: 07/22/09
(2wd)
ES: 07/23/09 EF: 07/23/09
LS: 07/23/09 LF: 07/23/09
(1wd)
0
EA:01
0
EA:01,EM:03
0
EA:01
ES: 08/12/09 EF: 08/16/09
LS: 08/12/09 LF: 08/16/09
(3wd)
ES: 10/07/09 EF:10/08/09
LS: 10/07/09 LF: 10/08/09
(2wd)
0
EA:01
0
EM:03, EA:01
ES: 11/12/09 EF: 11/23/09
LS: 11/12/09 LF: 11/23/09
(8wd)
0
EM:03, EA:01
ES: 06/20/09 EF: 06/26/09
LS: 06/20/09 LF: 06/26/09
(5wd)
ES: 06/27/09 EF: 06/29/09
LS: 06/27/09 LF: 06/29/09
(1wd)
0
EP:01, EP:02, EP:03
0
EM:03,EP:01, EP:02
ES: 07/24/09
LS: 07/24/09
(5wd)
ES: 08/04/09
LS: 08/04/09
(1wd)
EF:07/30/09
LF:07/30/09
0
EP:01, EP:02, EP:03, EP:04,
EP:05
EF:08/04/09
LF:08/04/09
0
EM:03,EP:03, EP:04
ES: 08/17/09 EF: 09/25/09
LS: 08/17/09 LF: 09/25/09
(30 wd)
ES: 09/26/09 EF: 09/30/09
LS: 09/26/09 LF: 09/30/09
(3wd)
ES: 10/09/09 EF: 10/22/09
LS: 10/09/09 LF: 10/22/09
(10wd)
ES: 10/23/09 EF: 10/26/09
LS: 10/23/09 LF: 10/26/09
(2wd)
ES: 10/27/09 EF: 10/30/09
LS: 11/04/09 LF: 11/09/09
(4wd)
0
EP:01, EP:02, EP:03, EP:04,
EP:05, EP:06, EP:07, EP:08
0
ET:01, ET:02, ET:03
0
EP:01, EP:02, EP:03, EP:04,
EP:05, EP:06, EP:07, EP:08
0
ET:01, ET:02, ET:03
6
EM:01, EP:01, EP:02
ES: 11/12/09 EF: 11/23/09
LS: 11/12/09 LF: 11/23/09
(8wd)
0
EM:01,EM:03
Construction phase
DCA
DD
Transition phase
Architecture design maintenance
Implementation
EA
Inception phase
EAA
Implementation of software component prototype
EAB
Prototype demonstration
EB
Elaboration phase
EBA
Critical component coding and integration
EBB
Critical component demonstration
EC
Construction phase
ECA
Alpha release component coding
ECB
Alpha release component stand-alone testing
ECC
Beta release component coding
ECD
Beta release component stand-alone testing
ECE
Develop migration scripts
ED
EDA
F
Elaboration phase
DBA
Transition phase
Software component maintenance
Assessment
9
FA
FAA
FB
Inception phase
Assessment planning
Test modeling and test cases preparation
FBB
Architecture test scenario implementation
FBC
Critical component test scenario implementation
FC
Component demonstration assessment and release
descriptions
Execute automated tests
FCB
Execute alpha component integration testing
FCC
Execute beta component integration testing
FCD
Execute user acceptance testing
FCE
Beta release assessment and release description
FDA
G
EM:02
ES: 07/14/09
LS: 07/14/09
(2wd)
ES: 07/17/09
LS: 07/17/09
(2wd)
ES: 07/31/09
LS: 07/31/09
(2wd)
ES: 08/05/09
LS: 08/05/09
(1 wd)
EF: 07/15/09
LF: 07/15/09
0
ET:01, ET:02, ET:03, ET:04
EF: 07/20/09
LF: 07/20/09
0
ET:01, ET:02
EF: 08/03/09
LF: 08/03/09
0
ET:03, ET:04
EF: 08/05/09
LF: 08/05/09
0
EM:02, ET:01
ES: 10/01/09
LS: 10/01/09
(1wd)
ES: 10/02/09
LS: 10/02/09
(3wd)
ES: 10/27/09
LS: 10/27/09
(3wd)
ES: 10/30/09
LS: 10/30/09
(2wd)
ES: 11/03/09
LS: 11/03/09
(2wd)
EF: 10/01/09
LF: 10/01/09
0
ET:01, ET:02
EF: 10/06/09
LF: 10/06/09
0
ET:01, ET:02, ET:03, ET:04
EF: 10/29/09
LF: 10/29/09
0
ET:01, ET:02, ET:03, ET:04
EF: 11/02/09
LF: 11/02/09
0
ET:01, ET:02, ET:03, ET:04
EF: 11/04/09
LF: 11/04/09
0
EM:02, ET:01, ET:02
ES: 11/18/09 EF: 11/19/09
LS: 11/18/09 LF: 11/19/09
(2wd)
0
EM:03, EM:01
ES: 06/18/09 EF: 06/19/09
LS: 06/26/09 LF: 06/29/09
(2wd)
6
EM:01
ES: 08/06/09 EF: 08/07/09
LS: 08/06/09 LF: 08/07/09
(2wd)
0
EM:01, EM:03
ES: 11/05/09 EF: 11/09/09
LS: 11/05/09 LF: 11/09/09
(3wd)
0
EB:01, EB:02, EB:03,
EB:04
ES: 11/14/09 EF: 11/17/09
LS: 11/14/09 LF: 11/17/09
(2wd)
0
EM:03
Construction phase
FCA
FD
6
Elaboration phase
FBA
FBD
ES: 06/16/09 EF: 06/17/09
LS: 06/24/09 LF: 06/25/09
(2wd)
Transition phase
Product release assessment and release
descriptions
Deployment
GA
GAA
GB
GBA
GC
GCA
GD
GDA
Inception phase
Deployment planning
Elaboration phase
Schedule releases and user training
Construction phase
User manual documentation
Transition phase
Product transition to user
10
In the WBS table, in the transition phase there are certain maintenance activities mentioned, although the
float for these activities are mentioned as 0, we did not display them under critical path, as these tasks are
performed only on a need by basis, and also these activities gets executed in parallel with the other
transition phase tasks. So these maintenance activities will get completed as the major tasks complete.
The total working days specified in the table is the duration within which these tasks might be performed.
These maintenance activities happen for few days after the product release date.
In the construction phase, we have given the maintenance task’s durations between which these tasks
might be performed on a need by basis.[Float is not calculated for these tasks]
5.2.2 Schedule Allocation
In the below diagram the highlighted section show the critical path along with the starting date as well as
ending date of the project. The starting date of the project is 06/02/2009 and its ending date is 12/24/2009.
During the entire project life cycle everything which is not in critical path is going in parallel. Moreover
the diagram also indicates the start date and end date of each task along with its total days to complete
that task. In the below precedence diagram certain task’s duration is given as LOE [level of effort]. These
tasks duration will depend on the level of effort required. But these tasks can happen only within a
particular start and end date.
11
Business case
development
06/01/09 to 06/02/09
2 Days
Software project
development plan
06/03/09 to 06/08/09
4 Days
Hardware
requirements
planning
06/09/09 to 06/09/09
1 Day
Design
development
environment
architecture
06/10/09 to 06/12/09
3 Days
Requirements
vision specification
06/09/09 to 06/10/09
2 Days
Use case modeling
06/11/09 to 06/15/09
3 Days
Elaboration phase
WBS baselining
06/09/09 to 06/15/09
5 Days
Assessment
planning
06/16/09 to 06/17/09
2 Days
Elaboration phase
release
specifications
06/16/09 to 06/17/09
2 Days
Software
architecture
prototyping
06/16/09 to 06/19/09
4 Days
Implementation of
software
component
prototype
06/20/09 to 06/26/09
5 Days
Prototype
demonstration
06/27/09 to 06/29/09
1 Day
Deployment
planning
06/18/09 to 06/19/09
2 Days
Inception phase
project control and
status assessments
06/30/09 to 07/01/09
2 Days
Project schedule
and budget
planning
07/02/09 to 07/06/09
3 Days
Manage
requirements
gatherings
07/07/09 to 07/13/09
5 Days
Business and
system
requirements
definition
07/07/09 to 07/08/09
2 Days
Development
environment
installation and
administration
07/07/09 to 07/08/09
2 Days
Planning user
acceptance criteria
07/14/09 to 07/15/09
2 Days
Human Resource
planning
07/16/09 to 07/17/09
2 Days
Stakeholder
communication
planning
07/18/09 to 07/21/09
2 Days
Construction phase
WBS baselining
08/22/09 to 08/24/09
3 Days
Use case model
baselining
07/09/09 to 07/13/09
3 Days
Development
environment
integration and
custom
toolsmithing
07/09/09 to 07/10/09
2 Days
Database
formulation
07/11/09 to 07/13/09
1 Day
Software
architecture design
modeling
07/11/09 to 07/13/09
3 Days
Critical component
coding and
integration
07/24/09 to 07/30/09
5 Days
Software
architecture
description
07/23/09 to 07/23/09
1 Days
Design
demonstration
planning and
conduct
07/21/09 to 07/22/09
2 Days
Architecture test
scenario
implementation
07/17/09 to 07/20/09
2 Days
Test modeling and
test cases
preparation
07/14/09 to 07/15/09
3 Days
Critical component
test scenario
implementation
07/24/09 to 07/30/09
2 Days
Critical component
demonstration
08/04/09 to 08/04/09
1 Day
Component
demonstration
assessment and
release
descriptions
08/05/09 to 08/05/09
1 Day
Schedule releases
and user training
08/06/09 to 08/07/09
2 Days
Elaboration phase
project control and
status assessments
08/08/09 to 08/11/09
2 Days
Deployment phase
WBS baselining
09/10/09 to 09/14/09
3 Days
Maintenance
planning
09/08/09 to 09/09/09
2 Days
Integration planning
08/29/09 to 09/07/09
6 Days
Change control
planning
08/27/09 to 08/28/09
2 Days
Test planning
08/21/09 to 08/26/09
4 Days
Risk management
planning
08/15/09 to 08/20/09
4 Days
Quality control
planning
08/12/09 to 08/14/09
3 Days
Component level
detailed design
modeling
08/12/09 to 08/16/09
3 Days
Develop migration
scripts
11/27/09 to 12/02/09
4 Days
Beta release
component standalone testing
11/25/09 to 11/26/09
2 Days
Beta release
component coding
11/11/09 to 11/24/09
10 Days
Architecture design
model maintenance
11/07/09 to 11/10/09
2 Days
Execute alpha
component
integration testing
11/04/09 to 11/06/09
3 Days
Execute automated
tests
11/03/09 to 11/03/09
1 Day
Alpha release
component standalone testing
10/29/09 to 11/02/09
3 Days
Alpha release
component coding
08/17/09 to 10/28/09
30 Days
Execute beta
component
integration testing
11/27/09 to 12/01/09
3 Days
Execute user
acceptance testing
12/02/09 to 12/03/09
2 Days
Beta release
assessment and
release description
12/04/09 to 12/07/09
2 Days
User manual
documentation
12/08/09 to 12/10/09
3 Days
Development
environment
administration
08/12/09 to 12/14/09
[LOE]
Database
maintenance
08/12/09 to 12/14/09
[LOE]
Transition phase
project control and
status assessments
12/23/09 to 12/24/09
2 Days
Software
component
maintenance
12/15/09 to 12/24/09
8 Days
Product release
assessment and
release
descriptions
12/19/09 to 12/22/09
2 Days
Architecture design
maintenance
12/15/09 to 12/24/09
8 Days
Product transition
to user
12/17/09 to 12/18/09
2 Days
Requirements
maintenance
12/15/09 to 12/24/09
8 Days
Construction phase
project control and
status assessments
12/11/09 to 12/14/09
2 Days
Prepare closure
activities
12/15/09 to 12/16/09
2 Days
Database
maintenance
12/15/09 to 12/24/09
8 Days
Development
environment
administration
12/15/09 to 12/24/09
8 Days
12
Requirements
maintenance
08/12/09 to 12/14/09
[LOE]
The schedule distribution by phase:
Phase
Start Date
End Date
Schedule
Inception
6/1/2009
7/1/2009
18.3%
Elaboration
7/2/2009
8/11/2009
23.0%
Construction
8/12/2009
11/11/2009
52.4%
Transition
11/12/2009
11/23/2009
6.3%
Total
5.2.3
100%
Resource Allocation
Refer 5.2.1 for the allocation of resources to the specific tasks or activities. The total number of working
days required from each employee is given in the below table:
Employee id
ED:01
EM:01
EM:02
EM: 03
EA:01
EB:01
EB:02
EB:03
EB:04
EP:01
EP:02
EP:03
EP:04
EP:05
EP:06
EP:07
EP:08
ET-01
ET-02
ET-03
ET-04
ES:01
ES:02
ES:03
EDA:01
# of days in this project
Salary/Day
15
39 +LOE
14
101 +LOE
28
23
8
$600
$400
$320
$400
$400
$300
$300
$300
$300
$300
$300
$300
$300
$300
$300
$300
$300
$200
$200
$200
$200
$200
$200
$200
$300
8
5
58
55
51
46
45
40
40
40
21
20
17
12
19 +LOE
15 +LOE
7
12 +LOE
13
Total cost
$9,000
$15,600+LOE
$4,480
$40,400+LOE
$11,200
$6,900
$2,400
$2,400
$1,500
$17,400
$16,500
$15,300
$13,800
$13,500
$12,000
$12,000
$12,000
$4,200
$4,000
$3,400
$2,400
$3,800+LOE
$3,000+LOE
$1,400
$3,600+LOE
EDA:02
EDA:03
EN :01
EN :02
1
1
5
4
$300
$300
$300
$300
$260
$1,300
$260
$1,040
Total
Salary $235,120+LOE
Total cost = Total Salary + LOE
LOE – Level of effort. Certain tasks like the maintenance tasks will be performed only when required.
Certain employees will be assigned to these tasks when it’s required.
5.2.4 Budget Allocation
The budget distribution by workflow: (It is the percentage distribution over [$235,120])
First Level WBS Element
Budgeting
Management
$46,080 (19.6%)
Environment
$20,040 (8.5%)
Requirements
$10,600 (4.5%)
Design
$14,000 (5.96%)
Implementation
$123,400 (52.5%)
Assessment
$14,200 (6.04%)
Deployment
$6,800 (2.9%)
Total
$235,120 + LOE
The budget and effort distribution by phase: (It is the percentage distribution over [$235,120])
Phase
Budgeting
Effort
Inception
$27,500 (11.7%)
10.8%
Elaboration
$42,540 (18.1%)
18%
Construction
$131,880 (56.1%)
58.9%
Transition
$33,200 (14.1%)
12.3%
Total
$235,120 + LOE
5.3
Control Plan
5.3.1 Requirements Control Plan
All the requirements that are captured during requirement engineering are stored in SRS document and
that is the final reference for all kind of requirements.
14
•
If there is any change in the requirements after the SRS has been finalized then it should be
approved by configuration management.
•
Any change in the requirement can be accommodated within inception and elaboration phases.
Requirements are finalized once elaboration phase completed. Hence, when the project is in construction
phase it is really tough to accommodate any changes and those changes become subject to next release.
•
If there is a minor change and does not affect the architecture then the chances are higher that it
will be accepted by configuration management.
5.3.2 Schedule and Budget Control Plan
Here is the set of decision taking policies and the tasks when project manager comes in to the play. He is
the highest authority who has authority to approve or change the schedule and budget allotments.
•
To keep things in control and make sure that everything is under control, project manager will
review a weekly status assessment, provided by teams of developers.
•
There will be regular weekly meetings and project manager will get briefed by all the teams and
their budget and time estimates will be reassured.
•
This section will give estimation, using the COCOMO model, for the budget that will be spent.
The basic COCOMO model yields a rough estimate, based on assumptions about productivity, namely 16
lines of code for a simple project and 4 lines of code.
According to COCOMO model, the type of this project is moderate. The formula to calculate the personmonths needed for a moderate projects is given by PM = 3 * KLOC .
5.3.3 Quality Control Plan
To ensure the product meets customer’s requirement, all deliverable items are required to go
through review process. All reviews must meet acceptance level of quality before deliver to customer.
Formal review will also be executed for each task to ensure the correctness and maintain integration. This
will ensure the quality meet customers expectation and resolved the issued as soon as possible.
5.3.4 Reporting Plan
Each member of development team needs to provide a status report to their managers regarding
their current status weekly. The report should contain information such as the percent completion, the
issue encounter, whether the task is on stay on track, etc... QA also need to provide QA report of the
testing process. These reports would help management identify the current position in the project and
forecast the timeline.
5.3.5 Metrics Collection Plan
Assess Project and Product/Service results
Measure project performance and product/service results:
1. Identify the project's level of complexity
2. Evaluate the selected methodology and developed plans on basis of the expected results and the results
delivered by those methodologies.
3. Evaluate the project's performance and adherence to the developed plans. If the project deviated from
the initial development plan then we have to take it into account as an adjustment. This fact will help us in
upcoming projects as a knowledge source.
15
4. Identify the reasons for deviations from the plan and improvements to be made in project management
methods.
5. Evaluate the product/service's conformance and satisfaction of the requirements. If the final deliverable
does not match to the listed requirements in SRS then we can say that we have missed something.
Update organization metrics
Gather, analyze, and project performance metrics:
1. Gather data required for updating or adding to your organization's metrics. Metrics can include such
information as:
* Number of objects, classes, programs, modules and level of complexity
* Skill-set required completing different task types.
* Level of effort required for different task types by resource type
2. Update (or provide project metrics to responsible party) your organization's metrics (as required).
This knowledge can be used for further analysis.
5.4 Risk Management Plan
Risk Management is an important aspect in software development. A small issue could become an
emergency issue due to unplanned risk. Various factors should be identifying in other to analysis risk.
Risk analysis should be perform before implementation and all factors should take in consideration in a
“what if” manner. It is important to identify the risks in risk management plan and reduce the impact as
much as possible.
There are several risks need to consider such as

What to do when web server down?

When is an error occurring, what is the proper way of handling it?

Disaster happens and all orders are lost, what are ways to recover it?

When system is hanging, is there a way to know?
All risks will handle by risk management plan and steps to take action when it occurs.
5.5 Project Close-out Plan
Close Contract(s)
When third parties have been contracted to provide products/services:
1. Determine whether the contractor has satisfied all contractual obligations according to the contract
terms and conditions.
2. Once all contractual obligations have been satisfied, provide the contractor with formal notification that
the contract is complete.
Obtain Project (phase) Acceptance
Obtain formal project (phase) acceptance:
Follow the agreed upon project management process as documented in the approved project
management plan.
16
Closure report
Document the results of the project assessment in the form of a closure report.
6 Technical Process Plans
6.1 Process Model
The development process of our web project follows the rational unified process model. It uses an
iterative approach to build the system incrementally, starting from basic partial system features and
progressively adding more features till the entire system is built. Here we deal with different modules
(Requirement collection, Analysis and Design, Implementation, Testing, Evolution and Planning)
repeatedly in order to increase the capability of the system as well as software quality.
6.2 Methods, Tools, and Techniques
List and description of software tools, methods and techniques which we are going to use for this project
as well as designing tools, programming and coding tools, debugging and maintenance tools and
database which are suitable for this project.
Methods:
The web development project follows an iterative approach where for every iteration a finite set of
requirements are defined and the requirements get added incrementally and hence the features. At the end
of every iteration few components get completed and finally it evolves to the end product.
Tools:
Environment:
•
Windows XP
Server:
•
JBOSS Application server
Programming and coding tools:
•
Java
•
JSP/Servlets
•
XML
•
JavaScript
Database:
•
Oracle
Software tools:
•
Eclipse
•
TOAD
•
Dreamweaver
•
Hibernate
•
Flash
17
•
Crystal reports
Techniques:
The process follows the object oriented methodology and the software architecture design is represented
using the unified modeling language (UML) notations. Coding will be done in Java with Oracle as the
database and Hibernate being the ORM (Object relational management) tool. The artifacts include
requirement documents, design documents, user documents and technical documents.
6.3 Infrastructure Plan
6.3.1 Web Architecture
WebOrder application will be made using Java. Further the Servlets and JSP files will be handled by
JBOSS application Server. High-speed internet connection as well as Internet Service Provider (ISP) will
be used for WebOrder application. The user requests are all HTTP based requests. Further the network is
in such a way that the application has access to the database.
6.3.2 Database Management System
The weborder application uses Oracle as the database and the database exists in a clustered fashion. By
using Oracle we can have strong, secure and reliable database.
6.3.3 Server Platform
The WebOrder application runs on a JBOSS application server. Further both the JBOSS application
server and the Oracle database server run in a multi processor windows machine with minimum RAM of
4GB.
6.3.4 Client Platform
WebOrder application is compatible with Internet Explorer 4.0+, Mozilla Firefox 2.0+, Google Chrome
and Netscape Navigator 4.0+. Since it’s a web application, the only thing the user would need is a
machine with standard peripherals such as monitor, CPU, keyboard, mouse and a browser support with
internet connectivity as well as Windows XP operating system in it.
6.4 Product Acceptance Plan
Based on the requirements document, test cases are developed that would validate the structural and
functional aspects of the application's features against the requirements. Also the performance and quality
acceptance criteria are obtained from the client and those are added to the document as well. They are
then reviewed with the client and approval is obtained for the test case document. Once the product is
ready to be tested, Quality Assurance is done to test the functionalities and performance aspects of the
application and bugs are reported. The client-defined criterion for the acceptable number of bugs is
obtained and defined as the threshold for product acceptance. Also other quality acceptance criteria
namely code coverage, coding style metrics and other such metrics are also obtained from the client.
7 Supporting Process Plans
7.1 Configuration Management Plan
Configuration management will be divided into four major parts:
1.
Requesting changes
2.
Evaluating changes
3.
Approving or disapproving the changes
18
4.
Implementing the changes
1. Requesting the changes
Changes can be of many types. For example changes can be requested for a module and its
code, or can be requested for schedule change or budget change or project evolution plane change.
Module level changes
If there is any module level change then most probably it will be requested by its
developer. When a developer requests a change then he has to submit request to the in charge of that
particular module.
Schedule and budget change
Any higher level change like schedule or budget level change can be requested managerial level
people and the request should be submitted to the project manager.
Project evolution plan change
This change can also be considered as a higher level change and any request regarding this change
should be submitted to project manager and he will take the appropriate decision.
2. Evaluating the changes
All the evaluation of requested changes will be done by configuration management but the
decision should be taken in consent with project manager.
3. Approving or disapproving the changes
Any work on the change can start only after any approval from configuration management is
given. If CM disapproves any requested change then no work can be initiated. Moreover, the criteria to
approve any change will be decided by management (both project manager and configuration manager).
The criteria can also be set dynamically according to ongoing work performance or according to any
request from the customer.
Sometimes, if there are some changes requested by developers for the module development then they
can be approved by their team leader which is handling that particular module. But any change approved
by team leader should be notified to project manager and CM.
4. Implementing the changes
If the changes are at a module level and if they concern only the development team then developers
can implement the change themselves. But if the changes are concerning the managerial level things (like
schedule and budget change) and if they are approved then a manifesto about how to accommodate the
change in original plan will be issued by configuration manager.
7.2 Testing Plan
Unit testing
Unit testing will be done at very regular intervals to make sure that all the modules under the development
are up to date and are up to the mark.
 Every week a unit test will be performed on under development modules.
19
 Every unit will also go under extreme testing.
Integration test
An incremental method of integration testing will be used. Two dependent modules will be linked
together and put through the integration test.
Testing deliverables
At the end of testing phase, we can have testing deliverables in following forms:
 List Cases when the system breaks.
 If the system does not break under any circumstances then stamp the system as deliverable.
 A detailed testing report.
 If any error is found in integration testing then the report should be sent to both module managers
for a review.
Responsibilities
 All the tests should be carried out by a designated testing team.
 Including unit testing and integration testing team is also responsible for final testing.
 Development team will also contribute with testing team in respective unit testing.
7.3 Documentation Plan
The documents that will be delivered to customers are Software Development Plan, Requirement
Specification, Configuration Management Plan, Quality Assurance Plan, Testing plan and User Manual.
From a customer’s perspective, it is understandable that they would want to know whether the project is
worth its value spent on the development. In order to show customers the effort in building the product,
we deliver Software Development Plan, Requirement Specification, Management Plan, Quality
Assurance Plan and User Manual. Documents that will not be delivered to customers are Configuration
Management Plan, Architecture & Design document and Process Improvement Plan.
7.4 Quality Assurance Plan
The quality assurance plan shall include the following: Project Plan, Communication Plan, Unit Tests,
System Test, Integration Test, “Go No Go” decision. Formal review and peer review need to check off
by Project Manager before QA process begin. The bugzilla tool is used as a defect/bug tracker in order to
maintain certain quality standards. All testing results need to be documented to keep track of the issues.
7.5 Subcontractor Management Plan
Not Applicable
7.6 Process Improvement Plan
In order to improve the process, we are implementing following practices:
Standardize the operations
All the operation is n the development process will be standardized. It means that all the processes will
be following a standard template. If they meet a particular format of the standard then and then only they
will be accepted otherwise they will be revisited for review.
Continuous process review
20
Processes will be under a continuous review all the times. That is the reason why we have included
weekly meetings concept in the agenda. It adds supervision capability of the process.
Comparison with old projects
If there is a project in the library which had the same scope and which was following the same process
then that project becomes a comparable entity for the ongoing project.
This way we can have an idea that whether we are running ahead or behind the schedule and budget.
8
Additional Plans
In our basic plan, we don’t have any intention to work with any third party of any sub contractor. But
if in case, we have to work out with subcontractors then the following policies will be a applicable.
Basically, subcontractors come into the pictures for many purposes. So organization needs a particular
way to deal with them.
The way to deal with them includes how we are e going to select, communicate with and pay the sub
contractors.
Selection
The selection criteria for the subcontractors will be bifurcated into two subsections.
Old supplier
If we have been working with a particular subcontractor for a while then he will be given the highest
preference for the choice.
New supplier
If the subcontractor is new and we have to make selection among many sub contractors then the
contractors with good feedback and competitive price rate will be selected. As this project is a low budget
project, price will also be a matter of consideration.
Communication
Concerned department head will be in touch with the subcontractor until the product is delivered.
A prototype before the final delivery is also preferred just to make sure that if few are not satisfied with
any of the delivery artifact then the changes can be accommodated in the second iteration.
Payment Policies
Organization will follow an installment payment policy to deal with any kind of subcontractors. It means
that the subcontractor will receive his payment after he has delivered some fraction of the product and it
has been tested and approved by the organization.
21