You are on page 1of 13

1

THOMPSON RIVERS UNIVERSITY








Open Learning
COMP 3521
Assignment 6

Report: Software Project Management Plan (SPMP) for a
Small Custom Software Application for a Small Home-Based
Business

Prepared for
Kevin O Neil
Thompson Rivers University


Prepared by
Tiasa Mondol
Student ID: T00047472
Bachelor of Computing Science
Thompson Rivers University

2

Contents
Overview ................................................................................................................................................. 4
Project Summary ................................................................................................................................. 4
Purpose, Scope & Objectives .......................................................................................................... 4
Assumptions and Constraints ......................................................................................................... 4
Project Deliverables ........................................................................................................................ 4
Schedule and Budget Summary ...................................................................................................... 5
Evolution of the Project management Plan ........................................................................................ 5
Reference materials ................................................................................................................................ 5
Definitions and Acronyms ....................................................................................................................... 6
Project Organization ............................................................................................................................... 6
External Interfaces .............................................................................................................................. 6
Internal Structure ................................................................................................................................ 6
Roles and Responsibilities ................................................................................................................... 7
Managerial Process Plans ....................................................................................................................... 8
Start-up Plan ....................................................................................................................................... 8
Estimation Plan ............................................................................................................................... 8
Staffing Plan .................................................................................................................................... 8
Resource Acquisition Plan ............................................................................................................... 9
Project Staff Training Plan ............................................................................................................... 9
Work Plan ............................................................................................................................................ 9
Work Activities ................................................................................................................................ 9
Schedule and Resource Allocation .................................................................................................. 9
Budget Allocation ............................................................................................................................ 9
Control Plan ........................................................................................................................................ 9
Requirement Control Plan .............................................................................................................. 9
Schedule Control Plan ................................................................................................................... 10
Budget Control Plan ...................................................................................................................... 10
Quality Control Plan ...................................................................................................................... 10
Reporting Plan ............................................................................................................................... 10
Metrics Collection Plan ................................................................................................................. 10
Risk management Plan ...................................................................................................................... 10
Project Close-out Plan ....................................................................................................................... 11
3

Technical Process Plans......................................................................................................................... 11
Process Models ................................................................................................................................. 11
Methods, tools & techniques ............................................................................................................ 11
Infrastructure Plan ............................................................................................................................ 11
Product Acceptance Plan .................................................................................................................. 11
Supporting Process Plans ...................................................................................................................... 12
Configuration management Plan ...................................................................................................... 12
Testing plan ....................................................................................................................................... 12
Documentation plan ......................................................................................................................... 12
Quality Assurance Plan ..................................................................................................................... 12
Reviews and Audit Plan ..................................................................................................................... 12
Problem Resolution Plan ................................................................................................................... 12
Subcontractor Management Plan ..................................................................................................... 12
Process Improvement Plan ............................................................................................................... 12
Additional plans .................................................................................................................................... 13
Verification and Validation Plan........................................................................................................ 13


4

Software Project Management Plan
(SPMP) for a Small Custom Software
Application for a Small Home-Based
Business
Overview
Project Summary
Purpose, Scope & Objectives
The project is essentially a small custom software application for a small home-based business that
requires a stand-alone PC application, written in C#, and that connects to an access database and
stores personal information about clients of the business. The business is a home-based cosmetic
sales business and the system must track clients and provide the ability to email product information
to them, as well as keep a history of their purchases and produce sales reports on demand. The key
item is that it will be a small, simple and inexpensive software application.
Assumptions and Constraints
Assumptions:
The team expects to achieve the following:
The software can be installed in any home-based machine
It will also works on Windows RT tablets
It will be small , simple and inexpensive
Constraints:
Due to the nature of the project and its dependability on already existing solutions and
technologies, third party software and already available solutions will be used in the project
as needed.
Additional financial resources may not be available for the project because of its inexpensive
nature
Project Deliverables
1. Preliminary Project Plan 2014.06.06
2. Requirements Specification 2014.06.13
3. Analysis [Object model, Dynamic model, and User interface] 2014.06.20
4. Architecture Specification 2014.07.02
5. Component/Object Specification 2014.07.11
6. Source Code 2014.07.18 - 2014.07.23
7. Test Plan 2014.07.18 - 2014.07.23
8. Final Product w/ Demo 2014.07.18 - 2014.07.23
5


Schedule and Budget Summary
Project Milestone Project Artifact Due Date
Project start 01/06/2014
1
st
presentation P1 10/06/2014
2
nd
Presentation SRS, SOW, SPMP, P2 12/06/2014
3
rd
Presentation P3 20/06/2014
Phase 1 completion and
presentation
Phase 1 delivery, SQAP, SCMP,
P4
30/06/2014
Phase 2 completion and
presentation
Phase 2 delivery, P5 15/07/2014
Phase 3 completion and Final
Project Presentation
Phase 3 delivery, user and
developer documentation, P6
01/08/2014
Table 1 Schedule
Since the software application will be inexpensive we shall try to plan the schedule to be cost-
effective, less complicated and can be delivered on time.
Evolution of the Project management Plan
This document will be updated as the project progresses. Updates should be expected in the
following sections:
i. References - updated as necessary
ii. Definitions, acronyms, and abbreviations - updated as necessary
iii. Organizational Structure will be updated as the team leaders are assigned for each phase.
iv. Technical Process - this section will be revised appropriately as the requirements and design
decisions become clearer
v. Schedule as the project progresses, the schedule will be updated accordingly

Reference materials
Schach, S. R. (n.d.). Object - Oriented and Classical Software Engineering. McGraw - Hill.
Sommerville. (n.d.). Software Engineering.
Case Study:
1. Automated Ordering System at restaurants, Author : Tiasa Mondol, Anton Bukreev,
Thompson Rivers University
2. Synergy Project, Goran Momiroski, University of Waterloo
IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans, IEEE 1998
Chris F. Kemerer Software Project Management Readings and Cases, Irwin, 1997
William Milam, Alongkrit Chuitinan SmartVehicle Challenge Problems Model Composition and
Analysis Challenge Problems, Ford Motor Company, 2001
Ken Butts, Dave Bostic, et al. Usage Scenarios for an Automated Model Compiler, Ford Research
Laboratory, 2000
Watts S. Humphrey, Introduction to the Team Software Process, Addison-Wesley
6

Definitions and Acronyms
SPMP Software Project Management Plan
SLOC Source Lines of Code
LOC Lines of Codes
AMC Automated Model Compiler
COTS Commercial off The Shelf
ADL Architecture Description Language
WBS Work Breakdown Structure
SQAP Software Quality Assurance Plan
SCMP Software Configuration Management Plan
MSE Master of Software Engineering
SEI Software Engineering Institute
HCI Human Computer Interaction
P Presentation
TSP Team Software Process
MoBIES Model Based Integration of Embedded Software
PIP Process Improvement Process
Project Organization
External Interfaces
The client for this project is a home-based cosmetic sales business. All formal communication
between the client and the team is facilitated by the customer liaison. The communication is done
via e-mail on as need basis and through regular team meetings with the client.
All client meetings will be performed by means of conference calls. Team members are expected to
participate in the client meetings. Correspondence with the client shall be recorded and made
available for later retrieval.

Internal Structure

Figure 1 Internal Team Structure
7

Figure 1 shows the internal team structure with the team roles separated. The team structure is
hierarchical. There is a team leader, and the rest of the roles are assigned to the other team
members. All team members have their own area of responsibility and everyone is expected to
contribute equally to the project.
Also, the team has access to a technical writer that will help the team produce better documents.
The team mentors will the team and will help the team in achieving its goals. The technical writer
and the team mentors cannot be assigned any tasks other than document proofing and team
mentoring. The members of the team are encouraged to provide input for the decisions that the
team makes. Decisions are being made using a voting mechanism in which each team members
vote is counted equally. It is expected that each team members will change his/her the role in the
project at a time convenient to them. This will allow the team members to be involved in more than
one role. The team will engage in regular weekly meetings. Additionally team members will
communicate by e-mail on as needed basis. Personal communication between team members is
strongly encouraged.
Roles and Responsibilities
There are two types of roles and responsibilities that are shared among the members of the team:
Process roles are allocated to each of the team member according to the TSP roles. These roles
specific to TSP are summarized in Table 2.
Development roles are allocated to each of the team members.
Role Responsibilities
Team leader - Motivate the team members to perform their
tasks
- Help the team in allocating the tasks and
resolving issues
- Creates and maintains SOW
- Creates and maintains SRS
Development manager - Lead the team in producing the development
strategy
- Lead the team in producing the preliminary size
and time estimates for the products to be
produced
- Lead the development of SRS
- Lead the team in producing the high-level
design
- Lead the team in producing the design
specification
- Lead the team in implementing the product
- Lead the team in developing the build,
integration and system test plans
- Lead the team in developing the test materials
and running the tests
- Lead the team in producing the products user
8

documentation
Planning manager - Lead the team in producing the task plan for
the next development cycle
- Lead the team in producing the schedule for
the next development cycle
- Lead the team in producing the balanced team
plan
- Track the teams progress against the plan
- Creates and maintains SPMP
Process manager - Lead the team in producing and tracking the
quality plan
- Alerts the team to quality problems
- Lead the team in defining and documenting its
processes and in maintaining the process
improvement process
- Establish and maintain the teams development
standards
- Act as the teams inspection moderator
- Act as recorder in the teams meetings

Support Manager - Lead the team in determining its support needs
and in Software Project Management Plan
obtaining the needed tools and facilities
- Manage the configuration management system
- Maintain the project notebook
- Maintain the system glossary
- Maintain the teams issue and risk tracking
system
Table 2 Roles and Responsibilities
Managerial Process Plans
Start-up Plan
Estimation Plan
As soon as the high level architecture is created and the system is decomposed into subsystems
/modules the team will prepare a size estimation plan and include it as a part of the SPMP. Before
creating a size estimation plan, the team will have a discussion about the method that will be used
for that purpose.

Staffing Plan
The team has a fixed staff that will be set at the beginning of the project and is mandated by the
MSE program.
9

Resource Acquisition Plan
The expectation is that all of the resources will be available from the beginning of the project until
the project completion and they should not change for the duration of the project. The resources
needed for completion of the project can be separated into the following categories:
Hardware resources.
Software resources.
Other resources.

Project Staff Training Plan
There is no explicitly defined staff training plan for this project. The main training sources for this
project are the program courses, which include training in following areas: Methods of software
development, software architecture, analysis of software artifacts, management of software
development, models in software development, etc.
Work Plan
Work Activities
ID Task Name Start Date Finish Date
1 Education and
Requirements phase
01/06/2014 10/06/2014
2 Tools Education 10/06/2014 12/06/2014
3 Requirements phase 12/06/2014 20/06/2014
4 Required documents
preparation
20/06/2014 30/06/2014
5 Presentation 30/06/2014 15/07/2014
6 Phase 1 - 4 15/07/2014 01/08/2014
7 Finalization 01/08/2014 30/08/2014
Table 3 Work Activities

Schedule and Resource Allocation
The schedule for each of the team members will be established once for each phase of the project at
the beginning of the phase. Additionally the team will make adjustments in the schedule for the
team members depending on the workload that each of the members have for the given period.
That will help ensure that the team workload is as balanced as possible.
Budget Allocation
The team manager will hold meetings to allocate budget for each phase and the members will try
their best to meet the requirements.
Control Plan
Requirement Control Plan
There are two aspects of the requirements control plan:
10

Traceability. Traceability means that every artifact that is produced by this project should be
traceable back to the requirements documents. Traceability will be addressed during the review
meetings as well as deign and code walkthroughs.
Change control. Even though that we do not expect any major change in requirements, once the
SRS is formally released all changes will be approved and documented using the guidelines
established in the Configuration Management Plan.
Schedule Control Plan
This is a responsibility of the planning manager. The planning manager gathers information about
the individual tasks for each team member and creates a plan for each project phase at the
beginning of the phase. Each team member shall record the time spent on the project by updating
the time log by the deadline time for each week. The time log will be posted on the projects
document folder. This time shall be recorded by the planning manager and the projects plan shall
be updated accordingly. Additionally, the time spend on tasks shall be reviewed during the teams
weekly meetings. If slippage occurs in the plan the team shall make corrective measures to: (1) make
a more reasonable schedule and (2) make sure that the schedule is followed.
Budget Control Plan
In order to better track the work completed, milestones are further broken down into sub tasks.
Earned value will be derived from sub tasks completed of actual to planned expenditures and the
cost of sub tasks completed as well as escalate awareness of the projects status and expenditures as
outlined in the reporting plan. The budget requires review and approval of the change control board
at the end of each phase pf the project. Reporting will be done against baselines to reveal project
slippage on the critical path and the earned value
Quality Control Plan
Software quality control has a significant role in all of the stages of the project. The main drivers for
quality control are:
Make sure that the projects artifacts meet certain quality criteria.
Provide the ability to verify that the project satisfies the requirements.
Be able to find and remove defects in the earlier stages of the project.
Reporting Plan
Based on each team members status report, submitted to the planning manager by the given
deadline each week, the planning manager will provide a team status report that will be discussed at
each weekly meeting. The team mentors are invited to the team weekly meetings. Additionally, each
of the team members will have regularly scheduled personal meetings with their mentor.
Metrics Collection Plan
The metrics for the project shall be limited to collecting the time spent on projects tasks. Later,
during the development cycle the LOC and defects found will be also collected.
Risk management Plan
Risk Factors:
I. Market risk
II. Financial risk
11

III. Technology risk
IV. People risk
V. Structure/process risk

The SPMP shall specify:
Risk management plan for identifying, analysing and prioritizing project risk factors.
Procedures for contingency planning and the methods that will be used for tracking certain risk
factors, changes in levels of the factors and responses to those changes.
Project Close-out Plan
The team will:
Provide the client a copy of all the documents in electronic format.
Conduct a project post-mortem.
Archive all the projects artifacts (documents, source code, project plans, user documentation
etc.).

Technical Process Plans
Process Models
The project will follow an incremental and an iterative development model for its deliverables. The
development will be done in several phases and each phase will represent a complete development
cycle, with certain functionality of the system delivered at the end of each phase.
Methods, tools & techniques
The team will consider using object-oriented methodology. Also, use of software patterns is greatly
encouraged.
Additional tools that will be used are: Visual Studio, MS Access, Git HUB, Matlab, Simulink and MS
Office 2010.
Infrastructure Plan
Each one of the team will have a Github account to share the code and update it dynamically. Plus
they will also have laptops and other necessary softwares installed on them.
Product Acceptance Plan
Every milestone of the project will be accepted formally by the client by signing appropriate
acceptance documentation. At the end of every phase the client will install the product and perform
an acceptance test. This may result in additional requests for change and improvements.
12

Supporting Process Plans
Configuration management Plan
The team configuration management plan is about how the database and the software will be
configured in the machines as per the team members. The members will let their leaders know
about their preference so that there is overall symmetry.
Testing plan
Each phase will be tested by the members, the team leads and finally the consumer to assure its
quality.
Documentation plan
There are a number of documents that will be produced during the lifetime of the project. All
documents are responsibility of the project team members. The list of documents that will be
created and maintained under version control include:
Requirements specification defines the functionality that is required by the client.
Design specifications defines the structure of the system.
Test scripts and test results tests that are executed have to be recorded.
Risk analysis reports involves risk handling issues.
Defect log log of all the defects and their current status.
Change log log of all requested changes.
Metrics log log of collected metrics data.
Reviews review documents of all phases of the project
Quality Assurance Plan
This plan will assure the quality of the software application the client requires.
Reviews and Audit Plan
The SPMP will specify the plan, schedule and methods to be used in conducting product reviews and
audits. It is expected that in the future the details about the review and audits will be maintained
within the QA Plan.
Problem Resolution Plan
The SPMP will specify the plans, methods and techniques for reporting and resolution of problems
created during the project. The SPMP will be updated accordingly should the need for such a plan
arises.

Subcontractor Management Plan
The team will specify the level of interaction with the sub-contractor teams and the leaders from
both teams will determine the methods and media of communication.
Process Improvement Plan
Process improvement will be done as a part of the final project evaluation and lessons learned
phase. At that time the process improvement plan will be created.
13

Additional plans
Verification and Validation Plan
The SPMP shall contain the verification and validation plan for the software project and it shall
include tools, techniques and responsibilities for the verification and validation work activities. The
verification and validation plan will be part of a separate document and will be maintained
accordingly.

You might also like