PROJECT PLAN – TSHIRT KO!

(INVENTORY AND WEBSITE SYSTEM) 1/21/14

WORK BREAKDOWN STRUCTURE

Task ID Task Name Duration (days) Discrepancy Status

1 Design Phase 45 Open

1.1 Development database design document 10 Open

1.1.1 Staging database design 15 Open

1.2 Development rejects-handling design document 5 Open

1.2.1 Rejects-handling engine design 10 Open

1.3 Develop inventory design document 5 Open

1.3.1 Universe design 5 Open

1.4 Develop inventory design part 1 7 Open

1.5 Develop application design 7 Open

1.6 Exact, transform, load (ETL) design document 3 Open

1.6.1 Data export utility design 3 Open

1.7 Website design document 20 Open

1.7.1 Web entry application UI design 20 Open

1.7.2 Web entry application UI design sign-off 2 Open

1.7.3 Web entry forms and database model validation 12 Open

1.8 Functional requirements document 10 Open

1.8.1 Application Design 10 Open

1.8.1.1 User Authentication 5 Open

1.8.1.2 Troubleshooting 7 Open

1.8.1.3 Search for discrepancies 5 Open

 RISK ASSESSMENT

Risk #1: The development of this system likely will be

delayed considerably because of time constraints.

Likelihood of risk: Low probability of risk

Potential Impact on the project: This risk likely will increase the time to complete
programming tasks by 23%.

Ways to address this risk:

The project team will try to manage their time well and plan the activities for the project
ahead of time. The team will set specific timeframes so that we could do well our project. This
can be attained through long range planning before the project starts.

Risk #2: The development of this system likely will be

slowed slightly because project team members have no
longer used to program with Microsoft Access.

Likelihood of risk: Medium probability of risk

Potential Impact on the project: This risk likely will increase the time to complete
programming tasks by 48%.

Ways to address this risk:

The project team will try to remember everything they’ve studied or encountered in
Microsoft Access. They will try to learn from tutorials and ask for expert’s assistance.
Risk #3: The project team will incur additional unexpected
development costs due to human and technical
limitations/flaw.

Likelihood of risk: Low probability of risk

Potential Impact on the project: This risk likely will increase the time to complete
programming tasks by 12%.

Ways to address this risk:

The project team will try to develop the system with utmost due care and professional
competence to try and avoid unnecessary inaccuracies and errors.
 FUNCTIONAL REQUIREMENT

Functional Description Example

Requirement

Process- A process the system must  The system must allow registered customers to
oriented perform; a process the system see/view their own order history for the past year.
must do  The system must check incoming customer orders
for inventory availability.
 The system should allow customers to view and
place an order for the products/services available
from the company.
Information- Information the system must  The system must retain customer order history for
oriented contain. the past year.
 The system must include real-time inventory levels
in the storage.

NONFUNCTIONAL REQUIREMENT

Nonfunctional Description Examples

Requirement

Operational The physical and technical
environments in which the
system will operate
Perform The speedy capacity, and
reliability of the system
Security Who has authorized access to
the system under what
circumstances
Cultural and Cultural and political factors
Political and legal requirements that
affect the system
 The system can run on personal computers
 The system should be able to integrate with the
existing inventory system.
 The system should be able to work on any Web
browser.
 Any interaction between the user and the system has
no time limit.
 The system should be available for use 24 hours per
day, 365 days per day.
 The system supports 100-200 simultaneous users at
the same time anytime.
 Only the project sponsor/manager can see personal
records essential to the business.
 The system includes all available antiviruses for any
kinds of software threats.
 Personal information is protected in compliance with
the Data Protection Act.
 PROJECT STANDARDS

Types of Standards Examples

Documentation Standards The date and project name should appear as a header on all
documentation.

Font size and style of all documents must be 12 and Times New Roman
respectively.

Font color black.

All headers must be bold-faced and font size is 14

Document margin must be 1” on all sides.

All deliverables should be added to the project portfolio and recorded in

its table of contents.

Coding Standards All modules of code should include a header that lists the programmer,
last date of update, and a short description of the purpose of the code.

Proper ERD must be used as a guide for Microsoft Access programming.

On average, every query should include one line of comments for every
five line code.

Procedural Standards Record actual task progress in the work plan at the beginning of every
session.

Report to project update meeting on Tuesdays and Thursdays at 4:10 PM

– 5:40 P.M.

All changes to a requirements document must be approved by the

company manager.

Specification requirement Name of the program to be created

standards
Description of the program’s purpose

Business rules that must be incorporated into the program

Due date
User interface design
standards Labels will appear in boldface text, center-aligned, appropriate font

The tab order of the screen will move from the top left of the bottom right.

Accelerators keys will be provided for all updatable fields.

REPORTING STRUCTURE

Project Manager
(Jan Yu)

Functional Lead Technical Lead

(Jose Ostique) (Riz Cuison)