WEB BASED INVENTORY
Hastings/Hernandez/Miller/Wollenburg
Software Engineering Associates
http://jttab.net/inventory/Inventory/Covina_Inventory.html
Software Project Management Plan
09-09-2009
1
Table of Contents
1.0 INTRODUCTION
1.1 PROJECT SCOPE
1.2 MAJOR SOFTWARE FUNCTIONS
1.3 PERFORMANCE/BEHAVIOR ISSUES
1.4 MANAGEMENT AND TECHNICAL CONSTRAINTS
2.0 PROBLEM DEFINITION
2.1 HISTORICAL DATA USED FOR ESTIMATES
2.2 ESTIMATION TECHNIQUES APPLIED AND RESULTS
2.2.1 Estimation Technique m
2.2.2 Estimate for Technique m
2.3 RECONCILED ESTIMATE
2.4 PROJECT RESOURCES
3.0 RISK MANAGEMENT
3.1 PROJECT RISKS
3.2 RISK TABLE
3.3 OVERVIEW OF RISK MITIGATION, MONITORING, MANAGEMENT
4.0 PROJECT SCHEDULE
4.1 PROJECT TASK SET (DELIVERABLES)
4.2 FUNCTIONAL DECOMPOSITION
4.3 TIMELINE CHART
5.0 STAFF ORGANIZATION
5.1 TEAM STRUCTURE
5.2 MANAGEMENT REPORTING AND COMMUNICATION
2
1.0 Introduction
WBI provides schools, churches and businesses with an easy-to-use, portable and fullyfeatured web-based management system. These customers require a web based asset
management tracking system that uses a graphical interface and is available to any
user with a network connection. This will allow customers to see the data they need in
real time, from anywhere, all they need is an internet connection. Most inventories are
based in text-based spreadsheets.
The WBI Project will provide the end user with a point and click access to inventory
data. This enables users to minimize the time spent looking for inventory and maximize
customer service levels. The WBI will be an interactive map of the premises of the
client. The user will be able to click on a specific building and then room or other
specific location and be able to retrieve data about the hardware in that location. Client
will accept finished project when all available data is inputted and accessible via point
and click.
1.1 Project Scope
The WBI will be an application that resides on an intranet or internet based web
server, which will allow for the input of maps, asset information, and user access
controls to graphically display corporate asset inventory data on any computer
used by company employees. The customer will be allotted the ability to read,
write, and control database information based on their access privileges. This
project will result a working application, but be narrowed down to a single
location (classroom) in order to satisfy the requirements of APU.
1.2 Major Software Functions
The software will be HTML coded, and designed to run on multiple platforms (i.e.
Windows, Linux, Unix, Mac OS X). The ultimate goal will be to allow for the
integration of a variety of database applications, however, we are going to begin
with the use of Oracle for testing and development purposes.
1.3 Performance/Behavior Issues
No special requirements for performance or behavior are anticipated at this time.
3
1.4 Management and Technical Constraints
Being that this will be a part time project, as the design team cannot dedicate a
full time work schedule to the development of this software, and the remote
locations of all team members, this project is going to require strict management
and control of ongoing project operations. The WBI team has determined and
utilized a primary meeting place to hold status meetings and discuss any issues.
2.0 Project Estimates
2.1 Historical Data Used for Estimates
Other than the teams combined experience on similar projects, there is no
historical data available to estimate the time and cost of this project.
2.2 Estimation Techniques Applied and Results
A weighted formula based on 3 variables (see sub-section 2.2.1) will be utilized
to calculate time estimates. Four factors will be considered in the estimation:
Project size and scope, IT resources, prior experience with similar projects, and
applicable constraints.
2.2.1 Estimation Technique m
The 3 variables that will be used in the calculation are: best-case estimate
(B), probable-case estimate (P), and worst-case estimate (W) calculated
as (B+4P+W)/6.
2.2.2 Estimate for Technique m
B = 500 hrs., P = 1000 hrs., W = 1500 hrs.
Therefore m = 1000 hrs. or 41.7 person-days
Salaries: None (Time)
Hardware resource costs = None (Borrowed hardware)
Insurance (backup) funding = N/A
4
2.3 Reconciled Estimate
Total Estimated Cost = $0
Estimated Time to Complete = 41.7 person-days
2.4 Project Resources
4 part time development team members
4 independent workstations
1 Web Server
Access to school asset information
Oracle database software
Internet
3.0 Risk Management
3.1 Project Risks
Schedule: The schedule will be constrained and success-oriented, and the
highest priority will be placed on meeting schedule to allow for early fielding of
the system. Many of the tasks that would typically be done sequentially will have
to be done in parallel.
Funding: Limited to no funding is available, so we plan to make maximum use of
funding by multiple tasking of project engineers, and using volunteers as quality
assurance, lab technicians, and network administrators.
Technical Issues: The software must be able to integrate easily into an existing
IT environment, so we must plan to test on various platforms with different types
of network configurations to ensure compatibility.
5
3.2 Risk Table
Risks
Category
Probability
Impact
Schedule
Fixed
10%
2
Funding
Constrained
20%
3
Technical Issues
Flexible
70%
1
Impact Values:
1 - Catastrophic
2 - Critical
3 - Marginal
3.3 Overview of Risk Mitigation, Monitoring, Management
Risk: Schedule

Mitigation
Failing to meet the deadlines established by the team in order to complete
this project on time will result in a failing grade for the team project.

Monitoring
In order to ensure project timeliness, monthly checkpoints have been
established for each team member to maintain productivity.

Management
If a team member is falling short of their deadlines, all team members
should investigate to help get back on track.
6
Risk: Funding

Mitigation
Being that we are using free software, and utilizing hardware at our
workplaces, funding should not be an issue. However, if the team cannot
produce the needed equipment or software, it could result in an
incomplete project and missed deadlines.

Monitoring
Each team member is responsible for acquiring their own tools necessary
to complete their section of the project.

Management
If a team member has trouble acquiring a needed resource, other team
members will assist in the acquisition.
Risk: Technical Issues

Mitigation
Any technical failure that arises can cause the entire project to collapse.
This is by far the most critical threat to the successful completion of the
WBI project.

Monitoring
All code will be backed up on a minimum of 2 separate devices, and each
team member will have a copy of code. Backup resources are readily
available in the event of system failures.

Management
In the event of a technical issue, WBI team members are able to recover
from backups, or replace failed hardware in a timely manner.
7
4.0 Project Schedule
4.1 Project Task Set
The project deliverables, as designated by the program director, are as follows:
1. Project Requirements Document (PRD)
2. Project Specification Document (PSD)
3. Software Project Management Plan (SPMP)
4. Software Design Document (SDD)
5. Acceptance Test Plan (ATP)
6. Software Operator's Manual (SOM)
7. Project Legacy Document (PLD)
8. Source Code
9. All Documentation (bound)
4.2 Functional Decomposition
Deliverable
Requirements
PRD
Level-0 DFD - Context Diagram - Prototype
PSD
Level-1 DFD - Structure Chart/Entity Relationship Diagram
SPMP
Production Schedule - Gantt Chart
SDD
Hierarchical Dataflow Diagram - Revised Structure
Chart/Entity Relationship Diagram - Graphical User
Interface & Pseudo Code
ATP
Functional, Performance, Stress, and Structural Test Data
SOM
Flow Chart - Interactive Programming Environment Programming Language - Functionality
PLD
Expectations - Actual Events - Lessons Learned
Source
Code
Copy of Source Code
All Docs
Submit Final Project in Bound Folder
8
4.3 Timeline Chart
5.0 Staff Organization
5.1 Team Structure
Jeremy Miller: High-Level Program Architect
Robert Hernandez: HTML Programmer
Paul Wollenburg: Database Programmer
Mike Hastings: Documentation Specialist
5.2 Management Reporting and Communication
The team has a designated meeting place to discuss progress, critical issues, or
concerns. Primary method of communication will be via email, and on-campus
communication.
9