Project Management Plan Business Analysi

Project Management Plan
for
Circuit-building Learning Platform

Version 1.0
Prepared by:
Members:
12/30/2014
Bitwise & Otherwise Software Project Management Plan 2
Approvals
Title Printed Name Signature Date

Client Representative
Customer
Representative
Project Manager SME
Project Leader
Software Lead
Development
Software Quality
Control
Revision Change Record
Revision Revision Date ECO Description of Author

Number Number Change
1 30-Dec-2014 Original
Table of Contents
Title Page 1
Approvals 2
Revision Chart 3
Table of Contents 4
List of Figures 5
List of Tables 5
1. Introduction 6
1.1 Project Overview 6
1.2 Project Deliverables 6
1.3 Evolution of the SPMP 7
1.4 Reference Materials 8
1.5 Definitions and Acronyms 8
2. Project Organization 11
2.1 Process Model 11
2.2 Organizational Structure 15
2.3 Organizational Boundaries and Interfaces 16
2.4 Project Responsibilities 17
3. Managerial Process 19
3.1 Management Objectives and Priorities 19
3.2 Assumptions, Dependencies, and Constraints 19
3.3 Risk Management 21
3.4 Monitoring and Controlling Mechanics 28
3.5 Staffing Plan 28
4. Technical Process 30
4.1 Methods, Tools, and Techniques 30
4.2 Software Documentation 30
4.3 Project Support Functions 31
5. Work Packages, Schedule, and Budget 33
5.1 Work Packages 33
5.2 Dependencies 33
5.3 Resource Requirements 37
5.4 Budget and Resource Allocation 38
5.5 Schedule 39
6. Additional Components 41
7. Index 41
8. Appendices 41
List of Figures
Figure 2.1.A Waterfall Workflow 11
Figure 2.2 Development Team Structure 16
Figure 5.1.A illustrates the Work Breakdown Structure 34
Figure 5.3.A illustrates the Resource Graphs 37
Figure 5.4.A illustrates the Resource Cost Overview 38
Figure 5.4.B illustrates the Resource Allocation 38
Figure 5.4c illustrates the Budget overview 39
Figure 5.5a illustrates the Project Schedule 40
List of Tables
Table 1.5.1 Definitions 8
Table 1.5.2 Acronyms 9
Table 1.5.3 Abbreviations 10
Table 2.1.B Major Project Functions and Activities 12
Table 2.1.C Prototype Phase Diagram 14
Table 2.2.A Development Team Titles and Responsibilities 15
Table 2.3.A Organization Boundaries and Interfaces 16
Table 2.4.A Possible Client and Development Team Positions and Responsibilities 17
Table 3.1: Risk Estimation and Evaluation 21
Table 3.2: Position Skills and Required Education/Training 28
Table 5.2.a: Dependencies diagram of the Circuit Building Learning Application 35
Table 5.2.b: Dependencies diagram of the Software development phase 36
1. Introduction
This document is the Software Project Management Plan (SPMP) for the development of
Bitwise & Otherwise's (B&O) Circuit Building Learning Application. The SPMP is based on the
OCD for the Circuit Building Learning Application. This plan provides information regarding
the project pertaining to the project organization, managerial process, technical process,
scheduling and budget. The SPMP is the controlling document for managing this project and will
be maintained and referenced in order to satisfy project requirements.
1.1 Product Overview

The Circuit Building application will be an inexpensive and easily accessible way to
introduce people interested in electronics to electrical circuits. The application will be designed
to work on multiple platforms, have game elements to keep users interested, and introduce
concepts fundamental to the building of electrical circuits. The application will also make use of
the SQL database to store user generated circuits in the cloud. This will allow for the creation of
a community built circuits.
The Objectives of the project are to
● Create an application that correctly simulates the operation of electrical components.
● Allow users to build circuits using a virtual breadboard.
● Allow users to save circuits to the cloud.
● Allow users to load circuits from the cloud.
● Introduce users to the basic concepts of electrical engineering.
The intended audience for this document consists of:

● The B&O development team.
● The customer (as listed above on the document).
● Any interested parties requesting to review this document.
● Those individuals responsible for updating the software.
1.2 Project Deliverables
B&O will deliver to the customer at the completion of the project all the following
documents in electronic format:

● Operational Concept Description (OCD)
● Software Project Management Plan (SPMP)
● Software Requirements Specification (SRS)
● Software Design Description (SDD)
● Software Test Plan (STP)
● Software User Manual (SUM)
● Weekly Status Reports
● Prototype
B&O will also deliver a presentation to University faculty. The client is invited to attend
this presentation. The presentation will cover:
● Software Overview
● Software Design
● A demonstration of the delivered Prototype
1.3 Evolution of the SPMP
This section covers how the SPMP may be changed and revised to meet the future
requirements of the project. A list of personnel assigned to titled positions referenced in this
section can be seen in the Approvals Table located at the beginning of this document and in
Appendix A. If personnel get reassigned then the Approvals Table will be updated to reflect new
assignments. The Project Manager is responsible for ensuring that personnel are accurately
updated.
All members of B&O will have the responsibility of identifying possible revisions and
corrections to the SPMP. At any time during the development of the documents any member
may elevate the suggested change to the Project Manager for review. The Project Manager will
have the responsibility of reviewing the suggested changes before allowing the member make the
suggested changes to the master document.
1.4 Reference Materials
- How to Use a Breadboard. Accessed on December 6, 2014 from

https://learn.sparkfun.com/tutorials/how-to-use-a-breadboard
- Pressman, R. (2010). Software engineering: A practitioner's approach (7th ed.), New York:
McGraw-Hill Higher Education.
- Tweaking4all. Breadboard Basics. Accessed on December 6, 2014 from
http://www.tweaking4all.com/hardware/breadboard/
- What is a Breadboard? Accessed on December 6, 2014 from
http://tangentsoft.net/elec/breadboard.html
- Hagen, Kirk (2009). Introduction to Engineering Analysis (3rd ed.) New Jersey: Pearson
Prentice Hall.
- Software Process Models Accessed on December 9, 2014 from
http://www.nada.kth.se/~karlm/mvk/mvk08_lec2.pdf
- Bitwise && Otherwise Operational Concept Document, 2014.
1.5 Definitions and Acronyms

1.5.1 Definition
Table 1.5.1 Definitions
Android A Linux-based mobile phone operating system.
Application A program designed for end-users.
Breadboard The grid area where the components are placed

to create a circuit within the application.
Circuit A combination of a power source, conduit, and

a load to form a closed path that electrons can
flow. In the application the user places
components on a breadboard to make circuits.
Cloud The ability to store and access data through the

Internet.
Component Can also be referenced to as circuit elements.

Components are the resistors, power supply,
switches, and diodes that provide a load on the
circuit. Wires, which are used as the conduit, are
also considered components in the circuit
board’s design.
Database A library of circuits that have been saved by

users.
Flash Player Free software for viewing multimedia, executing

Internet applications, streaming video and audio.
Gantt Chart Gantt charts make it easy to visualize project

management timelines by transforming task
names, start dates, durations, and end dates into
cascading horizontal bar charts.
Hybrid A hybrid application (hybrid app) is one that

combines elements of both native and Web
applications. Native applications are developed
for a specific platform and installed on a
computing device.
MS Project Microsoft Project is a project management

software program, developed and sold by
Microsoft, which is designed to assist a project
manager in developing a plan, assigning
resources to tasks, tracking progress, managing
the budget, and analyzing workloads.
Prototype The original model of the application, which will

ultimately be upgraded to better versions.
Resources Resources are required to carry out the project

tasks. They can be people, equipment, facilities,
funding, or anything else need for completion of
a project activity.
Sandbox Style of game in which minimal character

limitations are placed on the gamer, allowing the
gamer to roam and change a virtual world at
will.
Tablet Internet-enabled computer that works in a

similar way to smartphones, with touchscreens
and downloadable apps.
1.5.2 Acronyms
Table 1.5.2 Acronyms
Acronym Definition
GB Gigabyte
GUI Graphical User Interface
I/O Input/output
ISP Internet Service Provider
MB Megabyte
MHz Megahertz
OCD Operational Concept Document
OS Operating System
PC Personal Computer
PM Project Manager
RAM Random Access Memory
SME Subject Matter Expert
SQL Structured Query Language
WBS Work Breakdown Structure
1.5.3 Abbreviations
Table 1.5.3 Abbreviations
Abbreviation Definition
AIR Adobe Integrated Runtime
App Application
B&O Bitwise & Otherwise
COTS Commercial Off The Shelf Software
Demo Demonstration
ed Edition
iOS iPhone Operating System
SDK Software Development Kit
Ver Version
Web World Wide Web

2. Project Organization
2.1 Process Model
In order for the software development to flow in an efficient manner, a software process
model was selected to dictate the course of development. A Waterfall approach will be used to
develop the Circuit Building Learning Application. A diagram of this model can be found in
Figure 2.1.A. The Waterfall Model will allow for easy implementation of a systematic and
sequential approach. It will also reinforce acceptable industry habits- define before design and
design before code, by emphasizing planning in the early development stages.
Figure 2.1.A Workflow of the Waterfall Process Model
As shown in Figure 2.1.A, there will be six stages, which are:

● User Requirements- All potential requirements from the client for the program are
discussed and documented. The constraints and goals of the Circuit Building Learning
Application will be established.
● Software Requirements- All potential requirements on the software are discussed and
documented. The system specifications will be established based off of the specifications
documented in the User Requirements stage. The program’s functions will be clearly
defined during this stage.
● Architecture Design- The documented specifications are studied and the software design
is prepared. Hardware requirements are also determined.

● Detailed Design & Coding- The prototype of the program is designed based on
specifications acquired in previous stages.
● Testing- All components of the program code are tested for accuracy. The program will
also be measured to make sure it has met the software and user requirements
documented.
● Delivery- Once the program meets the acceptance criteria; it will be given to the client.
Table 2.1.B discuss the project functions and activities with the corresponding purpose or
description and dates. This timeline will be maintained throughout the duration of the project.
Additional project team meetings or meetings with the client can be scheduled as needed.
Table 2.1.B Major Project Functions and Activities
Function/Activity Purpose/Description Date

Project Initial review of the project and planning of 29 Nov 2014
initialization specifications
Progress Report Report progress to management 30 Nov 2014
Project Planning B&O will discuss goals, objectives, and issues. 3 Dec 2014
Meeting
OCD final Present Operational Concept Document 5 Dec 2014
Progress Report Report progress to management 7 Dec 2014
OCD signoff Management verifies OCD meets standards 9 Dec 2014
Meeting
Question responses Deliver answers to management and customers 12 Dec 2014
questions
SPMP draft Deliver draft version of Software Project 16 Dec 2014
Management Plan
Meeting
SPMP final Present final version of SPMP to management 19 Dec 2014
SPMP signoff Management verifies SPMP meets standards 23 Dec 2014
Meeting
Question responses Deliver answers to management and customers 26 Dec 2014
questions
SRS draft Draft preliminary version of Software 30 Dec 2014
Requirements Specification (SRS)
Program design Begin initial design of the application 30 Dec 2014
Meeting
SRS final Present final version of SRS to management 1 Jan 2015
Progress Report Report progress to management 4 Jan 2015
SRS signoff Management verifies SRS meets standards 6 Jan 2015
Software Design Software Architect begins functional design 6 Jan 2015
Document Draft development for programmatic representation
(top-level) of data
Project Planning B&O will discuss goals, objectives, and issues. 7 Jan 2015
Meeting
Software Design Present final version of Software Design 9 Jan 2015
Document Final Document (top-level) to management
(top-level)
Software Design Management verifies Software Design 13 Jan 2015
Document Signoff Document (top-level) meets standards
(top-level)
Software Design Software Architect begins functional design 13 Jan 2015
Document Draft development for programmatic representation
(detailed) of data
Meeting
Question responses Deliver answers to management and customers 16 Jan 2015
questions
Software Design Present final version of Software Design 20 Jan 2015
Document Final Document (top-level) to management
(detailed)
Software Testing Draft preliminary version of the Software 20 Jan 2015
Manual Draft Testing Manual
Meeting
Software Design Management verifies Software Design 27 Jan 2015
Document Signoff Document (top-level) meets standards
(detailed)
Meeting
Software Testing Present final version of Software Testing 30 Jan 2015
Manual Final Manual to management
Software User’s Draft preliminary version of the Software 30 Jan 2015
Manual Draft User’s Manual
Question responses Deliver answers to management and customers 30 Jan 2015
questions
Progress Report Report progress to management 1 Feb 2015
Software Testing Management verifies Software Testing Manual 3 Feb 2015
Manual Signoff meets standards

Software User’s Present final version of Software User’s 3 Feb 2015
Manual Final Manual to management
Project Planning B&O will discuss goals, objectives, and issues. 4 Feb 2015
Meeting
Proof-of-concept Demonstrate a working prototype based on 6 Feb 2015
Circuit Building specifications
Learning App
Test Report Draft Draft preliminary version of Test Report 6 Feb 2015
Software User’s Management verifies Software User’s Manual 10 Feb 2015
Manual Signoff meets standards
Meeting
Test Report Final Present test results to management and 13 Feb 2015
customer
Question responses Deliver answers to management and customers 13 Feb 2015
questions
Meeting
Test Report Signoff Management verifies Test Report meets 20 Feb 2015
standards
Meeting
Formal project Formally present the product to management 27 Feb 2015
presentation and the customer
Product prototype Deliver product prototype to customer 28 Feb 2015
Table 2.1.C illustrates the major milestones of the Circuit Building Learning Application
prototype development phase. Phase diagrams for subsequent development will be based on the
results of the prototype effort.
Table 2.1.C Prototype Phase Diagram
Deliverable Date
12/9 12/23 1/06 1/13 1/27 2/3 2/10 2/20 2/27
Operational Concept X
Document
Software Project X
Management Plan
Software Requirements X
Specification
Software Design X
Document (top-level)
Software Design X
Document (detailed)
Software Testing X
Manual
Software User’s Manual X
Test report X
Product prototype X
2.2 Organizational Structure
The development team is organized into specific task areas. These areas are listed and
described below. A list of the personnel assigned to each task can be found in Appendix A. The
responsibilities of the development team are the following:
Table 2.2.A Development Team Titles and Responsibilities
Position Responsibilities
Project Manager SME (PM) 1. Overall supervision of project and
team
2. Delegates requirements
3. Maintains project plan
4. Performs implementation
5. Arbitrates issues that may arise
Project Leader 1. Performs the tasks of the Project

Manager SME when the PM is
unavailable
2. Analyzes software requirements
3. Manages all project documentation
Software Lead Developer 1. Oversees corrections received from

the Quality Control Manager
2. Implements software changes
3. Updates software
Software Architect 1. Designs program code

2. Performs implementation
Software Quality Control Manager 1. Checks software against documents

2. Test changes made by Software Lead
Developer
App Community Manager 1. Manages app community

2. Updates software available in the App
Store
3. Responds to community feedback
4. Monitors community submissions
Figure 2.2 shows a diagram of the organizational structure that will command the Bitwise
& Otherwise program development team. The personnel assigned to these positions is listed in
Appendix A.
Figure 2.2 Development Team Structure
2.3 Organization Boundaries and Interfaces
This section will layout the administrative and managerial boundaries between the
client’s organization and the project team’s organization. Table 2.3.A outlines those boundaries
and what each position will offer to the project development.
Table 2.3.A Organization Boundaries and Interfaces
Position Responsibilities
Analyst Ensures requirements are established
correctly.
Change Control Board Approves changes to project requirements,

budget, timeline
Client Project Manager Primary contact on the Client’s end

Configuration Management Department
Database Administration Department Designs the database used for the project
Development Department Builds the solution
Project Manager Manages the budget, schedule, and all project

management procedures of the project
Project Sponsor Provides the business direction and actively

assists departments to address and resolve
risks and issues
Project Sponsor Provides project funding, resolves issues and

changes, approves deliverables, and provides
high-level direction
Quality Management Department Manages corrective action, process

improvement, and auditing projects
Security Management Department Ensures that the program meets security

standards and designs test cases
Stakeholder Individuals who have a stake or interest in the

outcome of the project
Steering Committee Responsible for providing guidance on

strategic direction.
Subject Matter Expert Offers expert direction and instruction to the

project team
Suppliers/Vendors Supplies the project with expertise, material,

equipment, hardware, software, or supplies
Software/Hardware Tester Ensures the solution meets the requirements

and contains no errors or defects
2.4 Project Responsibilities
This final section of the project organization will identify the major project functions. It
will also assign each function to a position within the development team.
Table 2.4.A Possible Client and Development Team Positions and Responsibilities
Tasks Position
Project Project Software Lead Software Software App
Manager SME Leader Developer Architect Quality Community
Control Manager
Manager
Requirements
definition X X X X
Requirements
analysis X X X X
Process
management X
Scheduling X X X X X X
Data collection X X X X X X
Database design X X X
Database
development X X X X
Configuration
Management X X X X
Hardware setup/
maintenance X X X
Integration X X X
Quality
Assurance X X X
Testing X X X X X X
3. Managerial Process
This section of the SPMP shall specify management objectives and priorities; project
assumptions, dependence constraints; risk management techniques; monitoring and controlling
mechanisms to be used; and the staffing plan.
3.1 Management Objectives and Priorities

The main objective of Bitwise & Otherwise for the development of the Circuit Building
Learning Application is to produce a low-cost, easy-to-use application to help novice users learn
basic circuit building principles. The immediate objective is the development of a functional
prototype to allow the customer and development team to more clearly specify requirements for
the fully capable application. Priority is given to developing a functional model that
demonstrates the basic functions outlined by the customer. Bitwise & Otherwise management
goals are to maintain project cost and scheduling deadlines, provide customer interaction
throughout all stages of the project and provide all tools to manage and maintain a cohesive team
environment throughout the project. As a time critical process, each team member will monitor
the development schedule and report any setbacks to the project lead. The customer will be kept
apprised of current team progress through weekly progress reports, and there will be weekly
group discussions with both the team members and the customer present to monitor development
and discuss any new criteria for the project. Email will be the primary medium used to keep the
customer and members up to date in between group meetings.
3.2 Assumptions, Dependencies, and Constraints

This subsection of the SPMP shall describe the philosophy, goals, and priorities for
management activities during the project. Topics to be specified may include, but are not limited
to, the frequency and mechanisms of reporting to be used; the relative priorities among
requirements, schedule, and budget for this project; risk management procedures to be followed;
and a statement of intent to acquire, modify, or use existing software.
3.2.1 Assumptions
● It is assumed that the Circuit Building Learning Application users will be able to download
Android mobile applications and utilize Web-based services.
● It is assumed that users will be utilizing the application through an Android-based mobile
phone or tablet or through a web browser on a Windows-based computer.
● It is assumed that the customer will have a cloud-based SQL database available for user
storage of application data.
● It is assumed that application users will have a functional Internet connection with the
designated server.
● It is assumed that all authorized users of the application will have user accounts and
passwords for the designated cloud-based SQL database.
3.2.2 Dependencies
● An Android-based mobile phone with at least a 550MHz processor and 256MB of RAM,
or a Windows-based computer with at least a 1.6GHz processor and 512MB RAM.
● Android OS ver. 2.3 or above, or a Web browser equipped with Flash Player ver. 10.1 or
above.
● A cloud-based SQL Server.
3.2.3 Constraints
Time is considered the greatest constraint in developing the Circuit Building Learning
Application prototype. The prototype will be produced during the ten-week period of 19
December 2014 and 27 February 2015. Starting 4 January 2014, eight weeks will be available
for procurement of all required documents and a demonstration of the prototype. Completion of
a functional model is targeted for 6 February 2015 to provide 22 days for refinement of the final
prototype.
Because of the limited development time, document submissions must not vary too far
from the stated deadlines. Steady progress must be maintained at a consistent pace to deliver the
required documents and application prototype by the target dates. As most team members work
full-time jobs, development time is highly limited. Performing software development tasks
during respective working hours is highly discouraged.
The budget for the project is severely limited and would normally prevent the acquisition
of Commercial-off-the-shelf (COTS) software for development purposes. However, a majority of
the COTS software is already available to the development team and is being provided by them
at no charge. Various types of software are required for the development process:
● Computer code development and compilation tools,
● Documentation tools,
● Online Communication tools,
● Project scheduling and management tools.
Development of the prototype will also require hardware and software. Development
team members already are in possession of PCs and laptops. Additionally, an Android
application developer’s account at the Android Apps Store and cloud-based SQL server access
are also required.
3.3 Risk Management

The Circuit Building Learning Application development team will conduct risk analysis
and management throughout the software development process. Areas of the software
development project that involve potential technical, budget, or schedule risks will be identified,
analyzed and prioritized. Some of the risks that need to be taken into consideration include any
other software in the market that provides the same function as the product being developed,
time, database interface issues, security, debugging software errors, and Android/Flash
compatibility. Table 3.1 identifies identified risks to the project, the category of the risk,
probability that it will occur, and overall impact. A risk factor is then calculated and risks with a
factor of 9 or greater will have a dedicated mitigation plan developed.
Table 3.1 Risk Estimation and Evaluation
No. Risk Category Probability Impact Risk

Factor
1 Customer decides Customer 3 4 12

specified system does
not meet needs
2 Updates to Flash Software 3 4 12

software or Android OS
cause app to stop
working
3 Product team falls Management 3 3 9

behind schedule
4 Software execution time Programming 3 3 9

lags system response
5 Hacker corrupt Security 3 3 9

privileged database data
6 Software contains Programming 5 1 5

bugs/logic errors
7 Application fails to Software 1 4 4

interface with database
8 Personnel leave/are Management 1 3 3

removed from project
9 Product size too large Programming 1 3 3
10 Specific browser fails to Software 1 2 2

correctly display
application
Probability: (1- Low, 3- Med, 5-High) Impact: (1-Negligible, 2-Marginal, 3-Critical, 4-
Catastrophic)
3.3.1 Risk Tracking/Monitoring

All team members are responsible for monitoring the project’s risk factors. Each
development team member shall have the programming software installed and running on one or
more local machines to support software development. Any issues which represent a risk to the
successful completion of the project are to be reported to the Project Manager. The project
manager will outline the problem and possible solutions and email a copy to each team member.
The problem will then be put on the agenda of the next group meeting and discussed in detail to
find a solution.
The activities of the risk planning process are as follows:
- Risk scenarios are developed for high severity and high impact risks.
- Resolution alternatives are considered for those risks.
- A resolution approach is selected.
- Action is taken, or a plan is developed.
Risk #1: Customer decides specified system does not meet needs.
Risk Scenarios:
During the Testing phase (alpha version of the product) and after the design and the development
phase, the client has informed us that the software does not meet some requirements.
Alternatives:
Establishing a formal peer review process to ensure client’s requirements, developing a complete
requirements analysis report, and sign-off the SRS document will help reduce the probability of
this risk.
Risk Resolution Approach:

Risk Reduction Approach will be used to reduce the probability of occurrence of this risk or the
severity of an occurrence.
Actions Taken:
Detailed interview with the customer and creation of new Software requirements specification,
that the customer must sign-off.
Schedule:
Adjustments will be made to the Software Development Plan to compensate for any delays,
resulting from additional required time.
Risk #2: Updates to Flash software or Android OS cause app to stop working.
Scenarios:
This issue is common problem for both web and mobile application. It can occur unexpectedly.
Alternatives:
To make responsive design of the application, that will be tested on different platforms and
browsers (Chrome, Mozilla, IE).

Actions Taken:
Developers should use responsive tools, such as proportion-based grids, flexible images, CSS3 media
queries and @media rule.
Schedule:
Adjustments will be made to the schedule of the Software Development Plan to compensate
for any delays, resulting from additional required time.
Risk #3: Product team falls behind schedule.
Scenarios:
This issue is common problem when developing software products. It can occur because of lack
of experience of the project manager, but also due to objective reasons (new client demands etc.).
Alternatives:
To avoid the risk of wrong schedule – careful planning should be done. The project manager
should talk to the development team while creating the schedule.

Actions Taken:
Either the development team should be increased (populated with new people), or the development plan
(schedule) should be changed on time.
Schedule:
Risk #4: Software execution time lags.
Scenarios:
This issue is common problem when developing software products. It can occur because of un-
optimized coding, database issues, wrong design patterns etc.
Alternatives:
To avoid the risk of software time lags - the project manager and the development team should
choose proper design patterns, optimized coding templates, database optimization etc.

Actions Taken:
The project manager and the development team will choose proper design patterns, optimized
coding templates, database optimization.
Schedule:
Risk #5: Hacker corrupt of privileged database.
Scenarios:
Hacker intrusions are common security problem for all web-based software products. It can
occur because of poor security measures on the web server etc.
Alternatives:
To avoid the risk of hacker intrusions - the project manager and the development team should
apply security measures on the server – LDAP authentication, firewall protection etc.

Actions Taken:
The project manager and the development team will apply security measures on the server –
LDAP authentication, firewall protection etc.
Schedule:
Risk #6: Software contains bugs/ errors.
Scenarios:
This issue is common problem in developing of all software products. It can occur always, but it
should be reduced within the testing and debugging phase etc.
Alternatives:
To avoid the risk of software bugs - the testing and debugging phase should be planned and
performed carefully etc.

Actions Taken:
The project manager and the development team will plan and perform in-deep testing and
debugging phase in order to avoid software bugs.
Schedule:
Risk #7: Application fails to connects with the database.
Scenarios:
This issue is rare problem in the production phase, since it can be tested and resolved prior to
deployment (it should be reduced within the testing and debugging phase).
Alternatives:
To avoid the risk of this software bug - the testing and debugging phase should be planned and
performed carefully.

Actions Taken:
The project manager and the development team will plan and perform in-deep testing and
debugging phase to avoid database connection problems.
Schedule:
Risk #8: Personnel leave from the project team.
Scenarios:
This issue is important in every type of project. The team should be composed carefully and
should remain complete until the project delivery.
Alternatives:
To avoid the risk of personnel insufficiency - the good motivation (benefits) should be provided
to the key developers.

Actions Taken:
The project manager will provide good motivation (benefits) to the key developers. Also, backup
personnel members should be planned.
Schedule:
Risk #9: Product size too large.
Scenarios:
This size of the software project is an important issue in terms of project finishing. The size can
be consider as twofold - memory space (due to device limitations) and project scope (number of
functionalities that should be implemented).
Alternatives:
To avoid the risk of oversizing of the project - the good definition of customer’s requirements
should be done (which functionalities will be implemented).

Actions Taken:
The project team will perform good definition of customer’s requirements (which functionalities
will be implemented).
Schedule:
Risk #10: Specific browser does not open the app correctly.
Scenarios:
This issue is a common problem for all web-based applications. It can be avoided by proper
testing of the application on different browsers (Chrome, Mozilla, IE, Safari etc.).
Alternatives:
Developers should perform deep testing prior to deployment. For development - they should use
responsive tools, such as proportion-based grids, flexible images, CSS3 media queries and @media rule.

Actions Taken:
Developers should use responsive tools for development, such as proportion-based grids, flexible images,
CSS3 media queries and @media rule.
Schedule:
3.4 Monitoring and Controlling Mechanisms

Project monitoring will adhere to the provisions of the SRS. Project monitoring will be
done in all weekly meetings and approved by the Project Manager. The major monitoring
mechanism is the testing phase of the project. Suggestions with regard to documents can be
made by individual team members, senior management, and/or the customer and shall be
approved by the Project Manager.
3.5 Staffing Plan

The number of personnel initially assigned to the project is limited to four. The number
of team members will remain static until the prototype version of the product is delivered. The
software will eventually require a larger team for development, maintenance, and
implementation of the modest version of the application. The skill level of the personnel will
increase over the duration of the project. Training is not a factor for the prototype version.
Table 3.2 specifies the skills and education/training required for the various project positions.
Table 3.2 Position Skills and Required Education/Training
Position Skills # Education/Training

Project Manager SME Communication, project 1 Prior project management
management experience preferred.
Project Leader Documentation control, 1 Good oral/written

technical writing, communication skills,
communication technical writing
experience.
Software Lead Developer Software development, 1 ActionScript 3, SQL,

troubleshooting, Flash, Android app
mentoring, development experience.
communication
App Community Database design, 1 SQL, prior database

Manager configuration, and implementation experience
management,
communication
Software Quality Control Quality Assurance, 1 Programming knowledge,

Manager communication, test software testing
management experience, reading
comprehension skills
Software Architect Software development, 4 ActionScript 3, SQL,

troubleshooting Flash, Android app
development experience.
4. Technical Process
4.1 Methods, Tools, and Techniques
This project will use multiple systems to develop, maintain, and manage this application.
During the development Adobe Flash CC will be used to manage graphics. Flash will also be
used to implement cross platform compiling of the byte-code. The Apache Flex SDK 4.14.0 is
needed to encode the code to byte-code. It is maintained by the Apache Software Foundation.
The application Flash-Develop will be used to write source code for the project.
Google Drive will be used to store and share all development documentation. Google
Drive is a free web based file sharing tool. There will also be a file maintained on the drive
which will hold the current code base in development as well as all past iterations of the code.
Each iteration will be given revision number and a description of milestones reached for each
revision will be stored in a readme document. The readme document will be stored with the
revisions.
The creation of the MySQL database will be done using the free the free MySQL setup
GUI provided by 1&1. 1&1 will also host the database online and manage all aspects of network
support needed to keep the database online during the duration of this project.
Maintenance of the Database will be handled by a Database management utility. This
application will allow the customer to perform three functions. First, the utility will let the
customer promote circuits uploaded to the database. These promoted circuits will appear at the
top of the list of community created circuits. The second function will allow the customer to
delete circuits form the database. Last, the utility will allow the customer to shadow ban users
from uploading anything from to the database in the future. Shadow Ban is the process of
banning a person without informing them or providing any form of feedback. A shadow banned
person will have no idea they have been banned, there uploaded circuits will just not get added to
the database.
4.2 Software Documentation

The software documentation for this project will be stored in the cloud on Google Drive.
All files will be stored on the drive in Google's native file format. This allows multiple to edit the
files at once in real time. In the event that a document is edited improperly Google Drives
revision control will be used to restore the document. The member that restored the document to
a previous edit is required to leave a comment on the reason for the restoration. All members of
B&O are responsible for maintaining and correcting the documentation. Prior to submitting
documentation to the client it will be exported to a MS Word .docx file. The documentation will
include:
● Operational Concept Document (OCD)
● Software Project Management Plan (SPMP)
● Software Requirements Specification (SRS)
● Software Design Document (SDD)
● Software Test Plan (STP)
● Software User’s Manual (SUM)
All document file names will use the following format:

<Document>-<Team>-<Date>
4.3 Project Support Functions

An App Community Manager will be identified by the project Manager. This position
will take on the role and responsibility of managing the app community. They will have access to
the store accounts where the app is uploaded. They will be in charge of uploading new versions
of the software to those store accounts. They will be responsible for collecting feedback and
responding to posts by google play users. They will identify possible improvements and bugs
found by the community and submit them to software Quality Assurance. The ACM will also be
in charge of managing circuits submitted by the community using the Database Management
Utility. They are then responsible for removing inappropriate or non-functional circuits that get
by the submission filter.
Software Quality Control Manager will be assigned by the Project Manager. QA will
ensure that the software functions per the documentation descriptions. Any deviations from the
documentation will be submitted to Software Development for review or correction. Any bugs or
suggestions submitted to QA from the app Community Manager will be reviewed for feasibility,
accuracy, and usability. They will determine if the submission should be elevated to the Software
Development for correction or implementation. QA will also test all changes made by the
Software Lead Developer prior to submitting the updated app to the App Community Manager
for upload.
Software Lead Developer will receive submissions to improve or correct the software
from the Quality Control Manager. They will be responsible for implementing changes to the
software per the request of QA. They will also be responsible for keeping the software up to date
and ensuring that the byte code remains compatible with the Flash Player. After major version
changes to the web Flash Player and the Android operating system the Developer will recompile
the byte-code and submit it to QA for review before it gets re-uploaded to the store accounts
online.
5. Work Packages, Schedule, and Budget
5.1 Work Packages
A work package is a group of related tasks that are defined at the same level within a work
breakdown structure. The work package pictured below in Figure 5.1.A is divided into three
functional sections:
● Software Engineering
This section encompasses all the essential engineering research, planning, design and
required documentation.
● Software Quality and Test
This section involves testing and validation of the project design and documenting the
development process
● Software Implementation
This section involves software integration and module programming need for a successful
project implementation.
5.1.1 Software development Phase explained
In the Software development phase (which is the main phase of the whole project) – the
following Processes (tasks/ activities) will be performed:
1. Data management process, consisting of the following activities:

- Create data-table in MySQL for registered users;
- Create data-table in MySQL for users'-built circuits;
- Create data-table in MySQL for building tasks/ scenarios;
2. Graphical User Interface process, consisting of the following activities:
- Design the layout of the main screen;
- Developing Sandbox for circuit creation;
- Developing Choose_level menu
3. Web Interface development, consisting of the following activities:
- Select level functionality;
- Obtain/ display task (circuit) to be solved;
- Picking tools / create circuit function.

- Obtain feedback from system if the circuit is wrong/ correct.
4. Database access/ process, consisting of the following activities:
- User Login - transfers user's data into data table;
- Save the circuit to database functionality;
- Browse previously created projects by other users.
5. Testing process, consisting of the following activities:
- Testing the interface (GUI) of the app;
- Testing the process of creation circuit;
- Testing the recording of the designed circuit into the database.
Figure 5.1.A illustrates the Work Breakdown Structure of the Circuit Building Learning Application
5.2 Dependencies
The table below in Table 5.2.a illustrates dependencies for the Circuit Building Learning
Application. The dependencies diagram is a great method for tracking critical path items within
the schedule. It clearly depicts dependencies and interdependencies within the work packages.
As the Waterfall approach is chosen for the system development, the dependencies
generally follow the Waterfall Process workflow (Requirements -> Design -> Development ->
Testing -> Delivery). More detailed view of the dependencies (particularly task dependencies)
could be seen in detailed project schedule developed using Microsoft project 2013 and attached
to this document as Appendix B.
Table 5.2.b gives the dependences between the activities during the Software
development phase. We see that there are 17 activities (including testing phase) and the total
duration is 15 days.
Table 5.2.a illustrates the Dependencies diagram of the Circuit Building Learning Application
Table 5.2.b Dependences between activities in the Software Development phase.

Activity Duration Precedent
A -
Create data-table in MySQL for registered users 0.3 days
B Create data-table in MySQL for users'-built circuits 0.3 days -
C -
Create data-table in MySQL for building tasks/ 0.3 days
D Design the layout of the main screen 2 days -
E Developing Sandbox for circuit creation 1 day D
F Developing Choose_level menu 1 day D
G Select level functionality 1 day C
H Obtain/ display task (circuit) to be solved 1 day D, E
I Picking tools / create circuit function. 1 day D, E, F
J Obtain feedback from system if the circuit is wrong/ 1 day E, I
K User Login - transfers user's data into data table 1 day A
L Save the circuit to database functionality 2 days B, C
M Browse previously created projects by other users 1 day B, C
N Testing the logging process/ database records 0.5 day A, K
O Testing the interface (GUI) of the app 0.5 day D, E, H
P Testing the process of creation circuit 0.5 day G, H, J
Q Testing the recording of the desined circuit into the 0.5 day C
5.3 Resource Requirements
Resource graphs depicted in Figure 5.3.a is used to show the resource requirements for
the project. The view below illustrates resource stats, work and resource status for the entire
project.
Figure 5.3.a. An illustration of the Resource graphs of the Circuit Building Learning Application
5.4 Budget and Resource Requirements
MS Project 2013 tool is a project planning tool used for managing this project. The
graphs below depicted below in Figure 5.4a, 5.4b and 5.4c provides overall cost for resources
and budget. It is assumed that equipment (servers, personal computers, android gadgets) is
already in place. Thus, resources are the only cost of the project.
Figure 5.4.a Illustration of the Resource cost overview of the Circuit Building Learning Application
Figure 5.4.b illustrates the Resource allocation of the Circuit Building Learning Application
Figure 5.4.c illustrates the Budget overview of the Circuit Building Learning Application
5.5 Schedule
Detailed project schedule is developed using Microsoft Project 2013.Figure 5.5a depicts
the Microsoft project schedule used for managing this project. The schedule includes project
functions, activities, and tasks, and the required milestone dates. Project schedule will be
published together with other documents to be followed and reviewed regularly by all team
members. Project manager is responsible to monitor the project schedule, regularly update it and
input all changes.
Figure 5.5a illustrates the Project schedule for the Circuit Building Learning Application
6. Additional Components
7. Index
8. Appendices
Appendix A
Organizational Assignments
Position Individual
Project Manager SME (PM)
Project Leader
Software Lead Developer
Software Quality Control Manager
App Community Manager
Software Architect
Software Architect
Software Architect
Software Architect
8.2
Project Plan
Microsoft Project file enclosed (as .pdf document)


Project Management Plan Business Analysi

Uploaded by

Document Information

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

Project Management Plan Business Analysi

Uploaded by

Copyright:

Available Formats

Project Management Plan

Circuit-building Learning Platform

Title Printed Name Signature Date

Revision Change Record

Revision Revision Date ECO Description of Author

1.1 Product Overview

The intended audience for this document consists of:

1.2 Project Deliverables

documents in electronic format:

1.3 Evolution of the SPMP

1.4 Reference Materials

- How to Use a Breadboard. Accessed on December 6, 2014 from

1.5 Definitions and Acronyms

Table 1.5.1 Definitions

Android A Linux-based mobile phone operating system.

Application A program designed for end-users.

Breadboard The grid area where the components are placed

Circuit A combination of a power source, conduit, and

Cloud The ability to store and access data through the

Component Can also be referenced to as circuit elements.

Database A library of circuits that have been saved by

Flash Player Free software for viewing multimedia, executing

Gantt Chart Gantt charts make it easy to visualize project

Hybrid A hybrid application (hybrid app) is one that

MS Project Microsoft Project is a project management

Prototype The original model of the application, which will

Resources Resources are required to carry out the project

Sandbox Style of game in which minimal character

Tablet Internet-enabled computer that works in a

Table 1.5.2 Acronyms

GUI Graphical User Interface

ISP Internet Service Provider

OCD Operational Concept Document

RAM Random Access Memory

SME Subject Matter Expert

SQL Structured Query Language

WBS Work Breakdown Structure

B&O Bitwise & Otherwise

COTS Commercial Off The Shelf Software

iOS iPhone Operating System

SDK Software Development Kit

Web World Wide Web

Figure 2.1.A Workflow of the Waterfall Process Model

As shown in Figure 2.1.A, there will be six stages, which are:

is prepared. Hardware requirements are also determined.

Table 2.1.B Major Project Functions and Activities

Function/Activity Purpose/Description Date

Manual Signoff meets standards

Table 2.1.C Prototype Phase Diagram

2.2 Organizational Structure

Table 2.2.A Development Team Titles and Responsibilities

Project Leader 1. Performs the tasks of the Project

Software Lead Developer 1. Oversees corrections received from

Software Architect 1. Designs program code

Software Quality Control Manager 1. Checks software against documents

App Community Manager 1. Manages app community

Figure 2.2 Development Team Structure

2.3 Organization Boundaries and Interfaces

Change Control Board Approves changes to project requirements,

Client Project Manager Primary contact on the Client’s end

Configuration Management Department

Development Department Builds the solution

Project Manager Manages the budget, schedule, and all project