Software Project Management Plan

Project Manager: Steve Rodriguez

Assistant Project Manager: Sagar Patel
Team: Phillip Nahhas
Adrian Bautista

Software Project Management Plan 1

1. Overview 3
1.1 Project Summary 3
1.1.1 Purpose, Scope and Objective 3
1.1.2 Assumptions and Constraints 3
1.1.3 Project Deliverables 3
1.1.4 Schedule and Budget summaries 3
1.2 Evolution of the Plan 4
2. References 4
3. Definitions 4
4. Project Organization 5
4.1 External Interfaces 5
 4.2 Internal Structure 5
4.3 Roles and Responsibilities 5
5. Managerial Process Plans 5
5.1 Start-up Plan 5
5.1.1 Estimation Plan 5
5.1.2 Staffing Plan 5
5.1.3 Resource acquisition Plan 5
5.1.4 Project Staff Training Plan 5
5.2 Work Plan 6
5.2.1 Work activities 6
5.2.2 Schedule Allocation 6
5.2.3 Resource Allocation 6
5.2.4 Budget Allocation 6
5.3 Control Plan 6
5.3.1 Requirements Control Plan 6
5.3.2 Schedule Control Plan 6
5.3.3 Budget Control Plan 7
5.3.4 Quality Control Plan 7
5.3.5 Reporting Plan 7
5.3.6 Metrics Collection Plan 7
5.4 Risk Management Plan 7
5.5 Close-out Plan 8
6. Technical Process Plan 8
6.1 Process model 8
6.2 Methods, Tools and Techniques 8
6.3 Infrastructure Plan 8
6.4 Product Acceptance Plan 8
7. Supporting Process Plans 8
7.1 Configuration Management Plan 8
7.2 Verification and validation plan 8
7.3 Documentation Plan 8
7.4 Quality Assurance Plan 8
7.5 Reviews and audits 9
7.6 Problem resolution plan 9
7.7 Subcontractor management plan 9
7.8 Process improvement plan 9
8. Additional Plans 9
1. Overview

1.1 Project Summary

The Software Project Management Plan will layout the details of the management plan
that will be followed in order to develop the Umvelt mobile application. It includes the
development cycle, organization, specific roles, projected timelines and testing protocols.

1.1.1 Purpose, Scope and Objective

The Software Project Management Plan(SPMP) will relay all the details regarding the
development plan and the development cycle. It will assign each member roles and duties
regarding the development, and how and what methods they will use in order to finish their
tasks. It will also assign deadlines so that project will developed on time. It will follow the
specifications declared in the most current version of the SRS that was signed by the client. The
first prototype will contain the UI design. It will be able to navigate through different pages,
contain the logo and the remaining texts according to the client.

1.1.2 Assumptions and Constraints

The list of all the assumptions and constraints
● Team members will attend all meetings
● Team members will meet all the deadlines
● Team members will follow the requirements specified in SRS
● The application is being designed to only run on Android devices of 15 or above API
● The application will only support Google Maps for now
● Team members will work on the project outside the class to finish it on time

1.1.3 Project Deliverables

This project will deliver the following items
● Working Executable Application
● SRS, SPMP, SQAP, Design, Test Plan, Documented Source Code, and Maintenance
Manual

1.1.4 Schedule and Budget summaries

There is no budget given for this application. Therefore this is the plan we came up with for this
project. According to class guidelines the first prototype will be delivered in Week 7 and the
second prototype will be delivered by the final day of the class.
1.2 Evolution of the Plan
The management team met with the client on Date[ENTER DATE HERE], and discussed the
expectations of the applications and its functionality. While deciding on the functionality of the
final prototype we kept in mind the requirements of the client, the amount of time we had to
create said functionality. After which we consulted with the UI/UX designer and got the designs
we needed for the logo, and other aesthetics. After which we came up with the requirements of
both prototypes. We made sure that the client is up to date and knows what is happening in the
project.

2. References
Android Studio
https://developer.android.com/index.html

Google Maps API

https://developers.google.com/maps/

IEEE SRS Template

http://www.cse.msu.edu

3. Definitions
CSUSB: ​California State University of San Bernardino
Mobile App: ​Mobile Application - Application operating on small device
UI: ​User Interface - the means by which a user and system interact
GUI: ​Graphical User Interface - method used to mediate relations between user and device
through visual representations and text.
FQ: ​Frequency - Duration in which a wave repeats
AMP:​Amplitude -Height of a wave
VB: ​Vibration - Alternating forces to produce a wave
4. Project Organization

4.1 External Interfaces

Dr. Concepcion (CEO) - Monitors performance of the development team and provides guidance
to the project managers.

Steve Rodriguez (Project Manager) - Fosters communication between the client and the team.
Uses communication resources such as email and basecamp to communicate between the
different groups associated to the development team.

Sagar Patel (Assistant Project Manager) - Monitors team progress in accomplishing

development goals and manages documentation resources. In the case of Project Manager
absence, can take over duties and responsibilities associated with the Project Manager.
Adam Ruppert (Client) - Communicates to Project manager the requirements of the mobile app
and gives feedback on presented prototypes.

Program Team- Codes the required objects and combines the illustrations from the Design
Team into the working prototypes.

Design Team - Illustrates the required graphics used in the mobile app.

Server Team - Process requests for server support relating to the mobile app.

QA Team - Evaluates prototypes as they are made available and tests for worst case scenarios.

4.2 Internal Structure

The project manager and assistant project manager work together to facilitate progress in
completing the prototypes.

4.3 Roles and Responsibilities

Steve Rodriguez (Project Manager) - Communicates to the team what the client desires in the
mobile app.

Sagar Patel (Assistant Project Manager) - Works with PM to complete prototype development.

Adrian Bautista(Software Engineer) - Builds UI components and Implements designs from

Design Team.

Phillip Nahhas(Software Engineer) - Builds Google Maps API call foundation to meet project
goals.

Michelle Munoz (Design Team) - Provides Illustrations and design consulting to the
development team.
5. Managerial Process Plans

5.1 Start-up Plan

5.1.1 Estimation Plan

● Discuss with the client all the specifications for the application.
● Research all the technologies required to meet those expectations
● Figure out how much could be accomplished in the given time
● Create guidelines for working prototypes 1 and 2.
● Create estimated deadlines and task completions deadlines to create these prototypes
on time

5.1.2 Staffing Plan

The project staff was selected by the professor and the TA’s by looking at the survey that each
member had filled out in the first week of the class. There have been new members since then
as two members left the group.

5.1.3 Resource acquisition Plan

All the software required for this project is free. However, there might be a few charges for
Google Maps API, and the one time fee for Google Play store that allows the client to publish
their application into the Google App Store. There are also workstations available in the Jack
Brown computer Labs that have all the software needed by each of the group members.

5.1.4 Project Staff Training Plan

All the group members will complete the tutorials given the first three weeks of the class. After
finishing those labs each member of the group will work to learn additional technologies that
they might need in order to finish the project.

5.2 Work Plan

5.2.1 Work activities

Work Units:
● UI/UX Development Prototype 1:​ The first prototype will contain a working UI/UX which
would be developed by Steve Rodriguez, and Adrian Bautista.
● Google Maps Integration: ​The google maps integrations will be done by Sagar Patel,
and Phillip Nahhas.
● Prototype 2:​ In this version of the application, the first Prototype will be integrated with
Google Maps, and receive data from that application. The application will also be able to
 use the tutorial screen where pressing an arrow button will relay a vibration pattern for
that instruction. The entire team will work on it.
● Documentation: ​All members will make sure that all the code that they write is properly
documented.

5.2.2 Schedule Allocation

Schedule:

2/5/18 2/9/18 Prototype #1 Development

2/12/18 2/16/18 Prototype #1 Development

and testing

2/19/18 2/20/18 Final testing of Prototype #1

2/21/18 Delivery of Prototype #1

2/22/18 2/23/28 Prototype #2 Development

2/26/18 3/2/18 Prototype #2 Development

3/5/18 3/9/18 Prototype #2 Development

3/12/18 3/16/18 Prototype #2 Testing

3/19/18 Delivery of Prototype #2

5.2.3 Resource Allocation

Each member has access to the same resources all the other members. The resources include
Android Studio, and the workstations available for all the students in Jack Brown.

5.2.4 Budget Allocation

No budget has been allocated for this project.

5.3 Control Plan

5.3.1 Requirements Control Plan

Each member of the group is required to attend the meetings in the class. Also each member is
required to document their code, follow the guidelines decided in the SRS and meet each
deadline as well. Any unexpected issues, technical difficulties or requests by the clients will be
assessed by the Managing team and decided upon.
5.3.2 Schedule Control Plan
Aside from the regular class meeting time, the team might be required to meet outside the class
as well in order to finish and deliver the product on time. Managers will make sure that each
member is completing their tasks and on time. The managing team will keep a constant eye on
the progress of the project and make sure that everything is completed by the deadline. The
Project Manager and the Assistant Project Manager will keep each other up to date on the
progress of the project.

5.3.3 Budget Control Plan

There is no budget allocated to the Umvelt team. However, we will make sure that the project is
efficient enough so that it doesn’t overtax the budget.

5.3.4 Quality Control Plan

The managing and the developing team will constantly perform a quality check on the software
at least once a week to make sure that the project meets all the expectations. Also the client will
be present during the development of the application and therefore will be informed of the
quality of the application.

5.3.5 Reporting Plan

The managing team will notify Dr Concepcion of the bi weekly meetings. The project manager
will generally send him the attendance of the group members and make sure that the
application is up to date.

5.3.6 Metrics Collection Plan

The managing team will make sure that each week every developer completes their tasks so
that the project is on track and progressing as expected. The managing team will make sure
that the code is efficient, and meeting all the standards.

5.4 Risk Management Plan

Development
● The team will meet regularly to make sure that the production is not stopped at one
particular point.
● There will be scheduled deadlines that everyone will be following to make sure the
project is not delayed
● Each team member will be kept up to date, and inform managing team of any changes
or difficulties that might affect their ability to complete the task they are given on time.
Project Failure
● If the technology does not exist or is not viable the managing team will discuss with the
client and make sure that there is another route that will result in a satisfactory outcome
for the client.
Server Failure
There is no server in this stage of the production.

5.5 Close-out Plan

The team will submit all the deliverables on to the bitbucket repository, along with a
maintenance manual. The team will also present their application on the finals day.

6. Technical Process Plan

6.1 Process model

Agile Software development

6.2 Methods, Tools and Techniques

Method: Incremental Development Model
Tools: Android Studio, Dia, Bitbucket
Techniques: Regular meetings with the client.
6.3 Infrastructure Plan
There is no need for a infrastructure plan at the moment, since there will be no server used by
the application for now.

6.4 Product Acceptance Plan

The client will be kept in loop throughout the development. After which the Q&A team will test
the application and make sure that the prototypes are working and acceptable.

7. Supporting Process Plans

7.1 Configuration Management Plan

We are using bitbucket for the configuration. It will contain all the changes made to the code
and, will allow for a smoother configuration.

7.2 Verification and validation plan

Verification and validation is done through periodic testing of the mobile app. Any bugs or errors
that are found are documented and reported through basecamp.

7.3 Documentation Plan

The managing team will prepare the SRS and SPMP. The development team will write the
documentation for design and architecture.

7.4 Quality Assurance Plan

The Q&A team will make sure of the quality of the application.

7.5 Reviews and audits

During development and testing phases, every member of the development team will test and
report any deficiencies in the mobile app. Design flaws or bugs will be reported and documented
for immediate fix or future review.

7.6 Problem resolution plan

Each member of the development team will keep the managing team members up to date on
any issues that they might encounter. Afterwards the managing team will decide on how to
handle those issues and make sure that the project is completed. They will also make any
changes necessary to make sure that the project runs as smoothly and as efficiently as
possible.
7.7 Subcontractor management plan
We have no subcontractors.

7.8 Process improvement plan

In order to improve the process and development of the software, it is crucial to write a good
Documentation of the source code that they will be provided. There are features that cannot be
implemented in the given time at the moment, and therefore have been pushed back to the next
stage of development. Writing quality code now, documenting it and creating a good
maintenance manual will help the future development team to make all the changes that they
think are necessary. We also made sure that the client was kept up to date on these features,
and so he will also be able to help the future development team figure out what to do next.