Project Plan: Inventory and Attendance System With Barcode

Project Plan
BECARIOS DE SANTO TOMAS
INVENTORY AND ATTENDANCE SYSTEM

WITH BARCODE
Document Revision #: 3
Date of Issue: October 21, 2016
Project Manager/Group Members:

Gala, Katrine Grace Z.
Delgado, Luhvie Chyrriel T.
Gabriel, Patrick Lance E.
Juachon, Jean Philip L.
Keh, Anthony B.
Kinol, Carlos Lewis O.
Rodriguez, Jaroed Paolo A.
San Juan, Johannes Paul V.
Yabut, Eric John V.
Approval Signatures
_______________________________
Prepared by: Katrine Grace Gala
Table of Contents
1.
............
Project Overview...........................................................................................................................
1.1. . .Purpose, Scope, and Objectives.....................................................................................................
1.2. . .Assumptions, Constraints and Risks..............................................................................................
1.3. . .Project Deliverables.......................................................................................................................
1.4. . .Schedule and Budget Summary.....................................................................................................
Schedule Summary..................................................................................................................................
Organisation
Becarios De Santo Tomas
President
Approved by
Hazel Reyes & Marc
Sanchez
Software Engineering 2
October 21, 2016
Version
3
Page 2
1.5. . .Evolution of the Plan......................................................................................................................

1.6. . .References......................................................................................................................................
1.7. . .Definitions and Acronyms..............................................................................................................
2.
Project Organization............................................................................................................
2.1. . .External Interfaces..........................................................................................................................
2.2. . .Internal Structure..........................................................................................................................
2.3. . .Roles and Responsibilities............................................................................................................
3.
Managerial Process Plans..................................................................................................

3.1. . .Start-up Plan.................................................................................................................................
3.1.1. Estimates..........................................................................................................................................
3.1.2. Staffing.............................................................................................................................................
3.1.3. Resource Acquisition........................................................................................................................
3.1.4. Project Staff Training........................................................................................................................
3.2. . .Work Plan.....................................................................................................................................

3.2.1. Work Breakdown Structure..............................................................................................................
3.2.2. Schedule Allocation..........................................................................................................................
3.2.3. Resource Allocation..........................................................................................................................
3.2.4. Budget Allocation.............................................................................................................................
3.3. . .Project Tracking Plan...................................................................................................................

3.3.1. Requirements Management..............................................................................................................
3.3.2. Schedule Control..............................................................................................................................
3.3.3. Budget Control.................................................................................................................................
3.3.4. Quality Control.................................................................................................................................
3.3.5. Reporting..........................................................................................................................................
3.3.6. Project Metrics.................................................................................................................................
3.4. . .Risk Management Plan.................................................................................................................

3.5. . .Project Closeout Plan...................................................................................................................
4.
Technical Process Plans......................................................................................................

4.1. . .Process Model..............................................................................................................................
4.2. . .Methods, Tools, and Techniques..................................................................................................
4.3. . .Infrastructure................................................................................................................................
4.4. . .Product Acceptance......................................................................................................................
5.
Supporting Process Plans...................................................................................................
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page 3
5.1. . .Configuration Management..........................................................................................................

5.2. . .Verification and Validation...........................................................................................................
5.3. . .Documentation.............................................................................................................................
5.4. . .Quality Assurance........................................................................................................................
5.5. . .Reviews and Audits......................................................................................................................
5.6. . .Problem Resolution......................................................................................................................
5.7. . .Subcontractor Management..........................................................................................................
5.8. . .Process Improvement...................................................................................................................
6.
Additional Plans..................................................................................................................
7.
Project Evolution................................................................................................................
7.1. . .Project support and maintenance..................................................................................................
7.2. . .Follow-up projects........................................................................................................................
Annex A.......................................................................................................................................
Annex B.......................................................................................................................................
Annex C.......................................................................................................................................
Annex D.......................................................................................................................................
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page 4
Document Change Control

This section provides control for the development and distribution of revisions
to the Project Charter up to the point of approval. The Project Charter does
not change throughout the project life cycle, but rather is developed at the
beginning of the project (immediately following project initiation approval,
and in the earliest stages of project planning). The Project Charter provides
an ongoing reference for all project stakeholders. The table below includes
the revision number (defined within your Documentation Plan Outline), the
date of update/issue, the author responsible for the changes, and a brief
description of the context and/or scope of the changes in that revision.
Revision
Number
Date of
Issue
Author(s)
Brief Description of
Change
March 8,
2016
Gala, Katrine Grace

Z.
Title of project
changed.
Delgado, Luhvie
Chyrriel T.
Project Overview
has been revised for
better wording.
Project Organization
has been added
with system
interface.
Managerial Process
Plans has been
revised with Use
Case Points and
budget allocation
has been changed
with additional cost.
Technical Process
plans has been
added with Rational
Unified Process
diagram.
Supporting Process
Plans has been
revised with more
detailed description.
Escultura, Yvette D.
Gabriel, Patrick
Lance E.
Juachon, Jean Philip
L.
Kinol, Carlos Lewis
O.
Rodriguez, Jaroed
Paolo A.
San Juan, Johannes
Paul V.
Yabut, Eric John V.
March 29,
2016
October
21, 2016
Revision of Project
Deliverables
Revision and recalculation of Use

Case Points
Gala, Katrine Grace

Z.
Revision of using QR
code to Barcode 128
Delgado, Luhvie
Chyrriel T.
Revision of title
Revision of
scheduling
Gabriel, Patrick
Lance E.

L.
Revision of Roles
and Responsibilities
Kinol, Carlos Lewis

O.
Addition of client
coordinator
Final revisions for

user acceptance
phase
Same authors
Keh, Anthony B.
Rodriguez, Jaroed
Paolo A.
San Juan, Johannes
Paul V.
Yabut, Eric John V.
Project Plan
Inventory and Attendance System with Barcode
1. Project Overview
1.1 Purpose, Scope, and Objectives
Purpose
The purpose of this Information Systems (IS) project is to design
and create an inventory system for the Becarios De Santo Tomas, included
in this project is to also create a database for the Barcode system of their
attendance. First of all, we can make the organization have a better and
productive work or project. Implementing a system makes the work of the
people involved easier in a way that manual work is reduced. The most
important aspect of the system to be implemented is to get the precise
data, reduce the office supplies, and improve the productivity time of the
members.
Scope
The coverage of this project involves the creation of an inventory
system for the Honesty Store accompanied by a database for the Barcode
attendance system of the organization.
The following are included in the scope of the project:
- Computerized inventory system
- Training the members of the organization with the nature of the
inventory system
- Deployment and implementation of the system in the
organization
- Creating a database for the organizations Barcode attendance
system.
Objectives
Our project aims to create a user-friendly system and updating the
system from manual to automated. It intends to reduce the work time in
creating a manual inventory. This also helps in protecting the confidential
data in the inventory. An objective is also to give the organization their
needed database for their Barcode attendance system. Lastly, it will lessen
the use of paper while doing the inventory. Other office supplies expense
will be reduced therefore it aims to reduce cost.
1.2 Assumptions, Constraints and Risks

Assumptions
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page 1
Project Plan
Number
The organizations members have their own personal laptops to be

used in the proposed system
The members can easily adapt to the inventory system
The database will be good enough for their Barcode system
All the members of the organization are willing to be trained in
using the inventory system.
Category
Constraints
Technology
The technology used for the documentation

is the laptop of each member. Each member
is required to bring his or her laptop.
Budget
The budget used for the project is only from

each members daily/weekly/monthly
allowance
Quality
The inventory system and Attendance

database should achieve the scopes and
objectives and enhance the productivity of
the organization
Materials or
Resources(Data)
All data can only be validated by the

organizations President. However, the
resources where money involved are
validated by the organizations auditor.
Schedule
The meetings are only done on days where
the members are free and are able to be with
each other.(School days, sometimes
weekends)
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page 2
Project Plan
Number
Category
Risks
Data loss or data corruption may
occur if the laptop crashed or an
infection of virus happens
Technology
Budget
The budget is only limited to each

members allowance
Quality
Errors in the system or database may

occur and may be hard to use by the
end user.
Materials or
Resources(Data)
Some needed information may not be

displayed in the system.
Other members are not available

during the times of meeting because
they have different sections or
schedule. Very risky during SDLC.
Schedule
1.3 Project Deliverables

1. Computerized Inventory System
The Computerized Inventory System is a system that is aimed to make

the manual work of inventory in the organization to be reduced and to
have a more accurate data recording.
The Computerized Inventory System will have a database that will

keep all the records of the items that they have and the user can add or
reduce the numbers of items.
2. Database for Barcode attendance system
The organization has a Barcode but they dont have an attendance

system yet. They intend to use the Barcode for the attendance system
that will be made by our team.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page 3
Project Plan
3. Proposal Project Plan
Our group will be providing a project plan with a feasibility study for
the proposal of the new system.
4. Software Requirements Specification
The deliverable is intended to provide the technological requirements

for the proposed system.
5. Software Test Plan

The deliverable provides what the organization needs for testing of
the new system and provides if the testing would be successful and
other necessary changes.
6. Software Design Document
Our group will be providing the design document for the groups
programmers to base their coding from. The document will state how
the software system will satisfy the clients requirements and
constraints.
7. Training of members
Our group will train selected members so that they can use the system
effectively.
The training of the selected members will start after the system has
been made.
8. Testing of the system
Some members of our group will be testing the system during and after
the programming of the system.
Our group should be assured that the systems are 100 percent
operational before delivering it to our client.
1.4 Schedule and Budget Summary

Schedule Summary
Month
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
Task
October 21, 2016
Version
3
Page 4
Project Plan
January
1.
Identifying and assigning roles.
2.
Preparation of documents for
client choosing.
February
March
3.
Choosing a client
4.
Client background review.
5.
Client meeting.
1.
SWOT Analysis
2.
Feasibility Study
3.
Feasibility Study revision
4.
Project proposal
5.
Project Plan
1.
Project Plan Revision
2.
System Request Specifications
3.
revision
April
May
4.
Design Revision
1.
Test Plan
2.
Test Plan revision
3.
Presentation
1.
Final Revisions
2.
Approval of Client
3.
Coding
June
1. Coding
July
1. Coding
August
1.
Coding
September
1.
Coding
2.
Testing and maintaining the
system
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page 5
Project Plan
October
1.
Coding
2.
Testing and maintaining the
system
3.
Implementing and evaluating the
system
Budget Summary
Amount
Direct Cost
1,000.00
Hosting Subscription
2,500.00
Total Amount
3,500.00
1.5 Evolution of the Plan

At the start of the project, the project manager will assign the
tasks that will be divided among the group members. There will
be a deadline for each deliverable and it will be checked and
revised as the project progresses. The updates will be
disseminated to the members and will be improving their earlier
version of task. Scheduled and unscheduled updates to the plan
will be produced by dividing the tasks to each member.
1.6 References
Our group will be producing an inventory system and an
attendance system and while producing the deliverables, we are
using books and online references to improve our work. Below is
a list of references that weve used for the project.
Plan document versioning, content approval, and check-out
controls in SharePoint 2013. (2014, April 09). Retrieved February
25, 2016, from https://technet.microsoft.com/enus/library/cc262378.aspx
Project Plan Template. (2003, December 16). Retrieved February
25, 2016, from https://www.tbs-sct.gc.ca/hgw-cgf/oversightsurveillance/itpm-itgp/pm-gp/emf-cag/project-projet/projectprojet02-eng.asp
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page 6
Project Plan
Rosenblatt, H. J. (2013). Understanding Systems Analysis and

Design. Pasig City, Philippines: Cengage Learning Asia Pte.
The Issue Resolution Process in Software Project Management.
(2013, July 13). Retrieved February 25, 2016, from
http://www.brighthubpm.com/methods-strategies/6941-issueresolution-in-software-project-management/
Qualitative Risk Analysis and Assessment. (n.d.). Retrieved March
06, 2016, from http://www.project-managementskills.com/qualitative-risk-analysis.html
Project Estimation with Use Case Points. (2005, March 22).
Retrieved March 06, 2016, from
http://www.codeproject.com/Articles/9913/Project-Estimationwith-Use-Case-Points
Software Cost Estimation With Use Case Points. (2007, February).
Retrieved March 06, 2016, from
http://tynerblain.com/blog/2007/02/13/software-cost-estimationucp-2/
Cottrell, W. (2004, May 26). Standards, compliance, and Rational
Unified Process, Part I: Integrating RUP and the PMBOK. Retrieved
March 06, 2016, from
http://www.ibm.com/developerworks/rational/library/4763.html
Christensson, P. (2006). RUP Definition. Retrieved 2016, Mar 7,
from http://techterms.com
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page 7
Project Plan
1.7 Definitions and Acronyms

End user = a person or user using the system or database created by the
programmer.
Database = collection of information or data
Data = something used to give information
SDLC = Systems Development Life Cycle
System = a set of principles or procedures according to which something
is done; an organized scheme or method.
Code = computing program instructions
IS = Information Systems
Automated = automatic operation
XAMPP- X (any of four different operating systems), Apache, MySQL,
PHP and Perl.
UST University of Santo Tomas
UCP Use Case Points
ECF Environmental Complexity Factors
TCF Technical Complexity Factors
UUCW Unadjusted Use Case Weight
UAW Unadjusted Actor Weight
PF Productivity Factor
UCP Use Case Point
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page 8
Project Plan
2. Project Organization
2.1 External Interfaces
Figure 1: System Interface Diagram

The diagram shows how the proposed system will be gathering their
data from. Using the wireless Barcode scanning application for Android
application that the organization has been using and their current registration
database, the proposed system will use this information for archiving and
data accessibility. For the inventory feature, the manual data that the
organization has been using with MS Excel will be gathered for backup with
the proposed system.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page 9
Project Plan
The organization has given the team their organizational chart based
from the 2014 Constitution which defines the relation of each
department and officers that becomes the basis from which the
officers and department may be connected with the systems and how
will it be affecting the organizational structure.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
10
Project Plan
2.2 Internal Structure
The project manager heads the line of authority. The team is

divided in four subgroups: Project Management team, the
Operational/ Research and Development team, the Technical team,
and the Marketing team.
2.3 Roles and Responsibilities

The major work activities are the project management, creation
of the inventory and attendance systems, marketing, budgeting, and
documentation. The project management is focused on developing
the project plan, assigning tasks, and establishing a project schedule.
The creation of the systems includes designing the interface,
programming, testing, maintenance and support, and enhancement
of the systems. The marketing is composed of attracting scholars in
the organization and advertisement of the Honesty Store. The
budgeting includes finance and accounting. And lastly, the
documentation includes research and development and finalizing the
requirements documentation.
The organization has four teams: the Project Management team,
the Operational/ Research and Development team, the Technical
team, and lastly, the Marketing team. The Project Management team
develops the Project Plan, acquires project resources, and leads
meetings; the team also oversees project tasks and report project
status. The Operational/Research and Development team is
responsible for implementing various research methodologies to help
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
11
Project Plan
gain understanding of user needs and behaviors; the team performs

the testing, analyzes and reports results, and makes
recommendations. In addition, they develop and maintain
requirements documentation, post project, and finalizes requirements
documentations. The Technical Development team is responsible for
the set-up and maintenance of the inventory and attendance
systems; the members should be skilled in developing accessible
content and features. And lastly, the Marketing team focuses on
developing inbound and outbound strategies for gaining exposure
and attracting intended students to the organization.
Team members may be able to cover multiple roles or there may
be a sub-team focused on a particular area. Resource allocation
depends on the level of expertise team members have, the scope of
the project, and budget available. Assigned roles are given to each
member of the team for them to fulfil specific functions from the
project plan. The following are the assignment of each member:
Role
Responsibility
Project Manager
Develops Project Plan, acquires project resources,

and leads meetings. Oversees project tasks and
report project status.
Co-Project Manager
Takes over whenever the Project Manager is not

available. Ensures that tasks assigned to the
members are done correctly.
Business Analyst
Responsible for implementing various research

methodologies to help gain understanding of user
needs and behaviors. Performs the testing, analyzes
and reports results, and makes recommendations.
Systems Analyst
Uses computers and related systems to design new

IT solutions
Programmer
Write and maintain the computer program or the

system that will be generated
Systems/Interface Designer
Focused on creating consistent and predictable

interface layouts. Responsible for contributing to
the wireframes, prototypes, and navigational
elements.
Document Controllers
Develops and maintains requirements
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
12
Project Plan
documentation. Post project, finalize requirements

documentation and archive as appropriate
Quality Assurance
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
Ensures that the system is well-developed and take

notes of the mistakes and to avoid further problems
in the system creation
October 21, 2016
Version
3
Page
13
Project Plan
3. Managerial Process Plans

3.1 Start-up Plan
3.1.1 Estimates
Resource Requirement
The primary resources for this system are printers,
laptops and software such as NetBeans, XAMPP and electrical
utilities. These resources will be the primary key to starting the
system and processing the intended function of it.
Schedule
Activity
Week No.
Identify and assign roles of each member
1st week
Preparation of necessary letters consents and

other documents
mid 1st week
Choose a company/organization
1st week
Make a company background review and

preparation for client meeting
1st 2nd week
Client meeting
2nd week
SWOT Analysis
3rd week
SWOT Analysis
4th week
Revision / Feasibility Study

Feasibility Study revision / Project Plan
5th week
Project Plan revision
6th week
Project plan revision / System Request

Specifications
7th week
System Request Specifications revision /

Presentation of Project Plan
8th week
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
14
Project Plan
Software Design
9th 10th week
Software Design revision / Test Plan

11th week 12th week
Test Plan revision
13th week
Project Presentation
14th week
Final revision of Documentations
15th week
Approval of System Design
16th week
System Development / Coding of System
17th -37th week
Testing and Quality Assurance of System
34th - 37th week
Implementing and Evaluating the system
38th - 40th week
Final Revision of System
41st 43rd week
Documentation
44th -45th week
Team meeting for Oral Defense/Presentation
Mid 45th week
Adjustment Allocation (for delayed activities)
46th-48th week
After much deliberation about the working time for the

system, it is estimated that the system would take at least 45
weeks and in case of delays and unexpected interruptions, it
might take up a year. With the use of Use Case points, it is
estimated that the system can be completed within 48 weeks.
See Annex D for the calculations. The schedules are divided
according to their relevance on the system. The more
important ones are given more time than the adjustments. The
less important ones are given a short week of working time.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
15
Project Plan
Use Case Points

Technical Complexity Factors
Calculated
Factor
(weight*percei
ved
complexity)>
Technic
al
Factor
Descripti
on
Weig
ht
Perceive
d
Complexi
ty
T1
Distributed
System
T2
Performan
ce
T3
End User
Efficiency
T4
Complex
internal
Processing
0.5
0.5
T5
T6
T7
T8
T9
T10
T11
T12
T13
Reusability
Easy to
install
Easy to
use
Portable
Easy to
change
Concurrent
Special
security
features
Provides
direct
access for
third
parties
Special
user
training
facilities
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
16
Project Plan
are
required
Total
Factor
19
Environmental Complexity Factors
Environmen
tal Factor
E1
E2
E3
E4
E5
E6
E7
E8
Descriptio
n
Familiarity
with UML
Application
Experience
Object
Oriented
Experience
Lead
analyst
capability
Motivation
Stable
Requiremen
ts
Part-time
workers
Difficult
Programmi
ng
language
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
Weig
ht
Perceiv
ed
Impact
Calculated
Factor
(weight*percei
ved
complexity)
1.5
4.5
0.5
0.5
1.5
-1
Total
Factor
20
October 21, 2016
Version
3
Page
17
Project Plan
Unadjusted Use Case Points

Use Case
Type
Description
Simple
A simple
user
interfaces
that includes
3
transactions.
(Project
Team)
More
elaborate
interfaces
with 4 to 7
transactions
(Butil and
Becarios De
Santo
Tomas)
More
complex
user
processing
with more
than 7
transactions
(Members of
the
organization)
Average
Complex
Weight
Number of
Use Cases
Result
45
10
20
15
45
Total UUCW
110
Unadjusted Actor Weight

Actor Type
Descriptio
n
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
Weight
Number of
Actors
Result
October 21, 2016
Version
3
Page
18
Project Plan
Simple
Average
Complex
The Actor
represents
another
system with
a defined
API (Project
Team)
The Actor
represents
another
system
interacting
through a
protocol,
like TCP/IP
(Butil and
Becarios De
Santo
Tomas)
The Actor is
a person
interacting
via an
interface.
(Members of
the
organization
)
Total UAW
22
Cost
Supplies (bond papers, filing folders, ink for the printer)
for documentations and data gathering will cost at estimate of
P 1,000. The team would not be responsible for any hardware
tools and equipments that the company would like to replace.
The team suggests that the company has their Internet
connection and has their browser, Google Chrome, and a free
Barcode scanner mobile application for the proposed systems.
3.1.2 Staffing
Data Gatherers (2-3 persons from the project team)

To conduct surveys, gather the information and statistics that is
needed
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
19
Project Plan
Documentation Team (3-5 persons both from organization and

project team)
To document all manual procedures and is responsible for
printing the hard copies that are required
System Analyst (1-2 persons)
To gather information, analyze, make a suggestion or proposal
as to the best course of action and evaluate the efficiency
Quality Assurance (2-3 persons)
To ensure that the encoded program is working properly and
provides its needed service
User- Acceptance Testing (1-3 persons from the company, 2-3
persons from the project team)
To ensure that the created systems met the objectives and
satisfied the given requirements of the client
Programmers (2-4 persons)
To create and develop the system
Financial Team (2-4 persons)
To monitor if the project is being carried out within the
allocated budget and is responsible for the finances and
breakdown of expenses
System Designers (1-2 person)
To design a system which is more effective and efficient for the
clients to use that is proposed by the system analyst that will be
developed later on by the programmers.
3.1.3 Resource Acquisition

The resources needed for completion of the project are the
following:
1. Time
It is acquired by following the schedule and being
on time for deadlines.
2. Budget
It is acquired through the money given to the team
members to finish each task.
3. Skills
It is acquired from the skills and other learned
practices of different courses from the members of the team.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
20
Project Plan
4. Hardware
Each team member has laptop, with all the needed
software and operating system installed for the project.
5. Software
Every team member has Microsoft Office Word
installed for typing required documents. Additionally, it is
suggested that all team members must install any
development tools needed for executing the project.
3.1.4 Project Staff Training

All the assigned organizations members that would be handling
the system must be oriented and trained under technological
training and technology based seminars by which their skills will
both be enhanced and applied. The necessary trainings must
tackle the needed knowledge for the system.
The team should also be knowledgeable of technological
experiences such as programming coding. The skills will be
applied for the development of the project.
3.2 Work Plan

3.2.1 Work Breakdown Structure
Task ID
Task Description
Data gathering
1.1
Building a team
1.2
Choosing a client
1.3
Meeting the company
1.4
Task assigning to members
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
21
Project Plan
Analysis
2.1
SWOT analysis
2.2
Work Plan
2.3
Brainstorming
2.4
Feasibility Study
2.5
Project Proposal Plan
2.6
2.7
Software Design
2.8
Test Plan
Preparation
3.1
Determine Applications Needed
3.2
Brainstorming for Design
3.3
Submit to Company for Approval
3.4
Final Revisions
Creation
4.1
Coding the System
4.2
Testing
4.3
Debugging
4.4
Final Revision
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
22
Project Plan
Documentation and Submission
5.1
Compilation of Documented Files
5.2
Creation of Powerpoint presentation with Revisions
5.3
Meeting before the defense
5.4
Project Defense
3.2.2 Schedule Allocation

Activities
Assigning of
Roles
Document
Preparations
Coding of
Choosing
Testing
Client
Company
Background
Coding
Review
Testing
Client
Implementing
Meeting
Revisions of
SWOT
system
Analysis
Final
Feasibility
Documentatio
Study
ns
Project
Plan
Defense
System
Requirements
Specifications
Software
Design
January
2
3
July
2
3
October
2
3
February
2
3
September
1
2
3
December
2
3
Group Activity
August
4
November
2
3
March
2
3
Group Meeting
Coding
April
2
3
1
Test Plan
Presentation
Final
Revisions
Organisation
Approval
Becarios
De Santo Tomas
President
Approved by
Coding
Hazel Reyes & Marc
Sanchez
Testing /
Implementation
May
2
3
June
2
3
October 21, 2016
Version
3
Page
23
Project Plan
PERT Chart for Schedule Allocation
3.2.3 Resource Allocation

The group to develop a Computerized Inventory and Barcode
Attendance system for Becarios de Santo Tomas is composed of
Information Systems students of University of Santo Tomas. The
elected project manager assigned roles and responsibilities for
each group member. Shown below:
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
24
Project Plan
Data
Gatherin
g
Databas
e
Creation
System
Programmin
g
Syste
m
Testin
g
Softwar
e
Design
Quality
Assuranc
e
Busines
s
Analyst
Project
Manager:
Gala,
Katrine
Grace
Business
Analyst:
Delgado,
Luhvie
Chyrriel T.,
Gabriel,
Patrick
Lance
Systems
Analyst:
Juachon,
Jean Philip
Document
Controller:
Escultura,
Yvette
Programmer
: San Juan,
Johannes
Software
Tester:
Rodriguez,
Jaroed
System
Designer:
Kinol,
Carlos
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
25
Project Plan
Members
Role
Responsibilities
Gala, Katrine Grace
Project Manager /
Programmer /
Systems Analyst
Supervises the entire team of their tasks and provides

the information systems needed for the client.
Ensures that requirements and goals of the team are
met with feasibility.
Business Analyst
Analyzes the clients needs and documents

requirements for changes and provide a project plan
for implementing for effective and practical solutions
Co-Project
Manager /
Systems Analyst
Assists the project Manager in additional tasks.

Provides and designs systems in response to the
clients needs and ensures that the solutions provided
by the teams benefits the client in the most effective
way
Escultura, Yvette
Document
Controller
Responsible for filing, storing, and providing soft

copies and hard copies of all the documents. Ensures
that the documents and deliverables are well-written
and provides assurances that the data are accurate.
Business
Analyst /
Document
Controller
Provides the client projects to translate their needs

into new and technical solutions. Analyzing and
documenting the requirements for the clients needs.
Tracks the deliverables and ensures that formatting
Delgado, Luhvie
Chyrriel
Gabriel, Patrick
Lance
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
26
Project Plan
was done correctly.
System
Designer /
Programmer
Creates detailed documentations to indicate different

components to be used in the systems. Coordinates
with programmers to ensure functionality and
performance of the system.
Programmer /
Software Tester
Codes and provides troubleshooting for the programs

used in the systems. Provides the weaknesses of the
programs that would be recommended to be
developed in the future.
Kinol, Carlos
System Designer
Builds a comprehensive system to hand in to the

programmers and system analysts. Communicates to
the developers to ensure the design specifications.
Yabut, Eric
Document
Controller /
Programmer
Responsible for documentation and for developing

the systems.
Client
Coordinates with the team for their needs and

provides the team with their information that would
be used for the systems.
San Juan, Johannes
Rodriguez, Jaroed
Hazel Reyes & Ruth

Castillo
(Becarios De Santo
Tomas)
3.2.4 Budget Allocation

Direct Cost
Documentation (inclusive of printing and office supplies)
Total Direct Cost
1,000.00
Software Tool Cost

Hosting Subscription
Total Software Tool Cost
2,500.00
Total Cost
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
3,500.00
October 21, 2016
Version
3
Page
27
Project Plan
3.3 Project Tracking Plan

3.3.1 Requirements Management
In order to make proper change proposals for the project,
each member are bound to communicate either via email or
text. Social Networking Service (SNS) sites are also a big
help in communicating. Its a necessity for the team to
communicate in terms of the changes to make the project a
success. The team leader deliberates the ideas to the
members for a unanimous decision over the task. After
deliberating the pros and cons of the changes about the
project and after agreeing to one decision, the team starts
on working over the changes as well as posting the changes
in the Change Control Board.
3.3.2 Schedule Control
The project has already earned four major works namely,
SWOT Analysis, Problem Identification, Project Plan and
Meeting with the Client. While the planned and emergency
meeting will be considered as minor work. The team already
has a track of progress by following the schedule and this
means that no further corrective actions are needed.
However, if some progressive action failed then some
changes might be made with the schedule.
3.3.3 Budget Control
Two factors must be considered when it comes to controlling
the budget. First, the quality of the product should be given
attention to avoid any waste for the budget. Second, the
control on overspending of the organization should be
looked upon to have full control of the budget and provide
maximum use of the allocated budget.
3.3.4 Quality Control
Quality control is made to check the projects quality and
modules are produced to assure effectiveness of the project.
Each module is also checked to see if links to other modules
are functional and accurate. Quality control processes
include debugging of source codes, testing of systems
process the check if it gets the desired results, and a User
Acceptance Test done by the client to check if he/she is
satisfied with the project. Defining how the quality target
can be measured is with the use of the Shewhart cycle. The
Shewhart cycle uses four steps: plan, do, check and act.
With the implementation of the cycle, the project team must
state their desired goals and how they can be achieved.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
28
Project Plan
These goals must be implemented and the project team

must check the production to make sure its meeting the
standards set and corrections must be acted upon by the
project team. The Product Managers task is to check
whether final output expectations are met and if it
compromises with the norms of a quality product.
3.3.5 Reporting
Reports are needed as documented proofs and as well as to
show the progress of the project. Reports are needed to
track whether the project is doing well and if it is being
processed according to plan. There are a lot of reports
needed to track down the project. Progress reporting issues
the regular progress report for budget, schedule and scope.
Project status report should include the scope, schedule,
cost, risks, and quality to highlight anything specific that
should be brought to the attention. Gantt chart is also used
for scheduling and budgeting, reporting, presenting,
communicating project plans and progress by coordinating
the specific tasks in a project in a graphical illustration.
The team had a client meeting to gather the data and
information that are necessary for the documents and
reports before scheduling a meeting for the group. After
planning, the members will make a Powerpoint presentation
to explain and elaborate the plan and expected output.
3.3.6 Project Metrics
Here are some project metrics to be considered:
project time/duration expected time to finish the proposed system in

allocated time
cost of the project the team will be using free software as much as the
team could possibly can to create the proposed system
ability to meet project specifications the team should accomplish what
the organization wants to see and should reach the requirements and
functionality
quality standards the team aims to have a assured quality system for the
organization
possible errors the members are held responsible for the system errors
and should be able to quickly resolve whatever issue the system may occur
efforts of the team the efforts of the team will be taken for consideration
and must be applied for the time of development of the project
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
29
Project Plan
3.4 Risk Management Plan

Table below shows the probable problems and risks that could be
the source of threat and hindrance for the successful development of the
system. The risks are leveled from high, moderate, to low. The criteria for
the risk factors are impact on the project, frequency with the project, and
overall risk level.
Description
Miscommunications
within the team
Client is less likely

to be approached or
asked for a meeting
Members do not
have time to train
for the new system
Delayed
submissions of
documentations or
tasks
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
Impact on
the project
Frequency
with the
project
High
Moderate
High
Moderate
High
Low
High
High
Overall
Risk
Level
Mitigation Plan
Members should
High
always have open
communication
with the project
manager and other
co-members.
Their schedule
should be said
beforehand to
ensure task
delegation will be
on time.
High
The team should
find a clients
representative to
have their
communications
when in need.
Provide training
Moderat sessions for the
e
members that will
handle the system.
Moderate A timetable
should be made
and members
should be aware
of their tasks and
October 21, 2016
Version
3
Page
30
Project Plan
deadlines
Unsuccessful
program
High
Medium
High
Technological issues
Medium
High
Low
Errors in
documentation
Medium
High
Medium
Incorrect record of
information
Medium
Low
Medium
Low stability in
system performance
High
Medium
High
10
Handlers of the
system lack of
awareness of the
new system
High
Low
Low
11
Rejection of
proposed system
High
Medium
High
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
Quality assurance
should be a
priority in testing
and evaluating.
Ensure that the
organization is
aware of what
technology they
would need.
Document
controllers should
be more careful
with proofreading
the deliverables.
Handlers should
be well-aware of
the information
they are inputting
to decrease the
risk.
The team should
focus on the
performance of
the system in
development.
The team should
provide the
organization a
time for training
for the handlers.
The team must
achieve all
possible needs of
the organization
with cost-effective
solutions to
convince the
October 21, 2016
Version
3
Page
31
Project Plan
organization.
12
Incomplete
requirements in the
system
Medium
Low
Medium
13
Members
availability to
handle the system
Medium
Low
Low
14
Budget or financial
problems by the
organization
Low
Low
Low
15
Possible errors in
output of the system
during deployment
stage
Medium
Medium
Medium
16
Change of client
officers during
development
Low
High
Low
17
Informal work
systems of the
organization that
may cause low basis
of necessary
evidences
Low
Low
Low
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
The team must

collect
information from
the organization
that they need for
the proposed
system.
The organization
should work for a
schedule of the
members as
handlers.
The organization
must include the
cost of the system
as part of their
audit.
The team must
have a quality
assured system to
avoid the risk and
to provide a
quality system for
the organization.
The team must
stay
communicated
with the
organization and
must work
harmoniously
with the new
officers.
The team must
communicate with
the organization
and observe
closely to have
appropriate and
October 21, 2016
Version
3
Page
32
Project Plan
accurate
estimations for
evidences.
Low Level - indicates that the risk could be easily solved by the team and
could less likely impact on the teams progress for the project
Moderate Level - shows that the risk could probably affect the team and
would have a quite hard time of solving
High Level - risk indicates the risk could affect greatly to the project and
would take time to solve and must be given attention to avoid any threats
that would be a source of unsuccessful project.
Likelihood
5
4
3
2
1
1
Impact
High
Level
Moderate
Level
Low
Level
Figure 1. Risk Management Matrix
3.5 Project Closeout Plan

The proposed system by the team for Becarios de Santo Tomas has
created a Closeout Plan for the system. It includes the following:
1. If the proposed system gets to be approved by the organization, the
program should also be explored and learned by other members of the
organization to be able to understand the functions and have an
increase of work flexibility.
2. The information of the organization will be archived only for the sake of
the creation of the project and for further recommendations.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
33
Project Plan
3. Both parties, the organization and the team, should have a healthy
relationship even after the system has been deployed.
4. The deployment of the system will be issued when the organization
approves of the system. The system will be given fully functional to the
organization and the domain will be theirs to use.
5. For actual testing of the system, members would be allowed to explore
the system and be given enough training and instruction for the
system.
6. Integration testing will also be implemented with the handling
members of the organization for them to familiarize with the functions
of the system.
7. The data conversion will be using the parallel conversion wherein the
old system will still be functional when the new system is deployed
until the new system will be fully functional and the old system isnt
anymore to be in use.
The lessons learned by the team with the project include the following:
The members should be open with their ideas and suggestion for
further data gathering. Members should also provide their time and
effort in doing their tasks.
Scheduling should be provided for each member for them to be

aware of their deadlines to avoid procrastination and error in
documentation. Also, being on-time is very crucial to the project.
Members should be cooperative and should communicate with the

project head in case of any questions to avoid errors in their tasks
and also to improve their knowledge when in need of help.
Recovery Plan
A recovery plan is needed to make sure that the provided data and data
that will be gathered in the future is protected and secured. Also the
plan is to make sure of the systems ability to work functionally.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
34
Project Plan
4. Technical Process Plans

4.1 Process Model
The following are the relationships among major project work activities and
supporting processes:
Initiation
Data review
Designing
Testing
Implementation
Finding a client
Problem analysis
Prototyping and
Coding
Testing the
prototype of the
program
Training of the
members who will
be in charge for the
system
Making 4
subgroups
Data gathering
Revising the
prototype
Testing final
system
Final touch ups for

the system
Identifying the
problem
Making of
deliverables
Making the final

touches
Training how to
troubleshoot their
system
Figure 1. Rational Unified Process Diagram
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
35
Project Plan
According to Christensson, P. of techterm.com, Rational Unified Process (RUP)

has four phases defined below:
1. Inception - The idea for the project is stated. The development team determines if
the project is worth pursuing and what resources will be needed.
2. Elaboration - The project's architecture and required resources are further
evaluated. Developers consider possible applications of the software and costs
associated with the development.
3. Construction - The project is developed and completed. The software is designed,
written, and tested.
4. Transition - The software is released to the public. Final adjustments or updates
are made based on feedback from end users.
Projects need to be done:
List of attendees (members) in their organization.
The person handling the system in their organization.
Equipment used in the organization with their corresponding

specifications.
List of inventories.
Documents approval matrix.
Required approvals within the duration of the project:
Documents needed Project manager

Design of the system Client
Design of the program Client
Milestones achieved so far in the project development:
1. Approval of Concept
2. Successful search for client
4.2 Methods, Tools, and Techniques
In our proposal, we identified their problem using the fishbone
analysis or also known as Ishikawa diagram to know what the
group will encounter in the project. Problem stratification is also
made for the proposal.
Our group went to the organizations office to interview some of
their team heads and to observe their working procedure. We
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
36
Project Plan
then discovered what are the problems and the needs of the
organization.
The CBA was also used to list down the hardware, software and
other cost in their organization.
Data collection is stated below:
Tools
Techniques
Questionnaire
Questioning: Written, Oral
Observation
Interviewing: On site observation
test
Program testing
SWOT / Fishbone Analysis
Cause and effect
Problem Identification/stratification
Analysis of the organization work

system and environment
4.3 Infrastructure
The group will use software like Netbeans/Notepad++ to build
the interface and XAMPP and MySQL to develop the database for
the system project. There is also a wireless Barcode scanning
application for Android for the Barcode identification for the
attendance system. The system will require internet access since
it is an Internet-Based system. The interface will be initiated by
the system designer but is subject for approval of the whole
group and also with the client. The workstation of the group will
be the University of Santo Tomas. The testing and the
implementation of design will be performed by the group.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
37
Project Plan
Figure 1. Infrastracture model of the proposed

system.
4.4 Product Acceptance

This system will help the user to speed up their works without
hassle. The interface will be appropriate for the client and it will
be just simple and easy to learn so that they can perform their
jobs faster. The information will be secured but at the same time
the data will be accessible to the user whenever it is needed.
Once the group reaches this phase of development the output
will be presented to the user for any modifications needed to
satisfy their needs. But before this the system will undergo series
of test to ensure the quality of output it will provide the client and
also to reduce the chances of major debugging and changes on
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
38
Project Plan
the system. The group will present the system with the step by
step process of how to use the system properly where the group
can also include training for the users and reduce their difficulty
or adjustment on the new system.
Figure 1. Flow diagram for the user acceptance testing.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
39
Project Plan
5. Supporting Process Plans

5.1 Configuration Management
The method of project's configuration management plan is based on the
guidelines specified in Plan Document Versioning in SharePoint 2013.
The said plan document versioning has three versioning options:
1. No versioning Specifies that no earlier versions of documents will be made.

When no versioning is used, the earlier documents will replaced by the new one,
therefore the earlier documents cannot be retrieved. Only use this option when the
change is very minimal or unimportant.
2. Create major versions Specifies that there are saved documents already. The
versions are retained by a simple versioning scheme (such as 1,2,3). With major
versioning, version histories are available, so whenever there are unnoticed
mistakes, there will always be a backup of the earlier version. Use this option
when you do not want to compare the document with the draft.
3. Create major and minor (draft) versions specifies that previously saved
documents are present. However, with major and minor versioning, there could be
possible variation within a single version. It can be retained using a major and
minor versioning scheme (such as 1.0, 1.1, 1.2). Versions ending in .0 are the
major versions, and versions ending in non-zero are the minor. In major and
minor versioning, the difference between the published content that is published
and the draft that not yet published can be compared.
5.2 Verification and Validation
The software controllers will be the one handling the trial of the
system, if it meets the expectations in the process. Verification
of the software will be done and monitored at the same time to
check if the construction is in the right track and so with some of
its attributes. As for the validation, our controllers will assess the
system for its effectiveness and accuracy of constructing.
5.3 Documentation
The project documentation will be in a documented process
flows for every transaction made.
Some of the information is provided by president of the
organization and it will be used for generating and reviewing the
project documentation. Also, transactions from the
organization's auditor are needed. The standard for each
document is also necessary, to ensure the consistence of the
document. The documents shall be given by the company since
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
40
Project Plan
this will be used for company requirements and the deliverables

needed for the project. The document shall be the current plan
of the development team, and the due dates shall be based from
what the organization assigned to the team.
The coding of the program will also be documented. It will be
documented by the means of a JavaDoc and the source code
itself, with comments included
5.4 Quality Assurance

To satisfy the client, the team guarantee a good standard of
every procedure the team do. The team is constantly consulting
for efficiencies of procedures the team do, and always meet for
validations. To ensure best quality of work, the team decided to
divide the whole group into 2 subgroups excluding the project
manager who leads the team to their work, project manager do
assure that the work of the subgroups will meet his/her
expectations. The team do assure to meet the accomplishment
time, or deadline. As the project manager disseminates the work
to the subgroups, the team immediately go to work and proceed
with the tasks given or agreed. The team also considers changes
in the project where the whole team agreed, to avoid some
hindrances for making the next step or task that will be given.
The team also assures that the system we will create will be
tested before implemented to assure the efficiency and
effectiveness of it, thus the team will also provide some
maintenance for the system, to secure its efficiency and
effectiveness to the client.
5.5 Reviews and Audits

The team holds a project review weekly to check if everything is
moving great or if there are problems present. The project
manager explains and assigns the tasks that have been
rendered to every member to assure time efficiency. Audit trail
reports will always be archived to ensure the accuracy of
transactions, and for future references. The project review also
includes the recap about the budget management to know if it is
still enough.
5.6 Problem Resolution

Having a problem with the software project management is a
reality. But thankfully there is software now that can fix software
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
41
Project Plan
problems which will be useful for maintaining the system that

the team will be developing.
The team also needs to secure a simplification of the project
about the correct execution for the client. Because the client
may find some requirements confusing, considering that it will
be the first time having a system for their inventories. While in
the progress of executing the project, the team may see that the
system will not be effective for some of the requirements, So the
team will prepare some alternatives for this kind of scenarios.
5.7 Subcontractor Management

A webhosting subscription will be subcontracted for an entire
year of the development of the proposed system.
5.8 Process Improvement

The system that the team will be creating will be an
improvement to the clients record of inventory; it will be faster
for them to record and provide a backup file for their inventories.
The team will also help the client on recording of attendance,
even if some of the members of the organization will be late, it
still better to record their attendance. To this whole project, the
teams main goal is to improve their productivity time, to help
the members on saving time more for their studies, because
members are scholars and are not consistent in attending the
organization. The team believes it will be much less work for the
members of the organization when the system is implemented.
The coding for the system will be improved for the advancement
of their work system. The members aim for the complete
functionality of the system.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
42
Project Plan
6. Additional Plans
Plans for safety, privacy and security requirements
The system will require username and password
There is limitation and restriction in the data
User Training Plans
All the members and officers of inventory department of the organization are
required to be trained.
The essential type of training is technical and technology training.
The purpose of the training is to inform and educate the members of the
technological aspects of the work such as using the device available for the
Barcode.
It will be implemented through lectures and training.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
43
Project Plan
7. Project Evolution
7.1 Project support and maintenance
The team shall be providing support and maintenance within the
development of the system and deployment. A user manual will
be provided upon a request of the client. The team will train
members of the organization to be part of help support for the
maintenance of the system. The team will ultimately detect
issues before they become evident to provide further issues.
7.2 Follow-up projects

The proposed project is only intended for the use of the
organization. However, the team suggests that the system could
be used also for other organizations if interested. A better and
much elaborate database could also be a factor for a follow-up
project.
Currently, the proposed system is used for Becarios de Santo
Tomas as it is needed by the organization and requested
formally by the officers.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
44
Project Plan
Annex A
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
45
Project Plan
Annex B
Inventory records of the store
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
46
Project Plan
Annex C
Implemented Barcodes for the organizations members.
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
47
Project Plan
Annex D
Use Case Points Calculations
TCF = 0.6 + (.01*Total Factor)
TCF = 0.79
ECF = 1.4 + (-0.03*Total Factor)
ECF = 0.8
UUCP = UUCW + UAW
UUCP = 132
Estimated work hours = 10 hours per week
Productivity Factor (PF) = 20
UCP = TCP * ECF * UUCP * PF
UCP = 1668.48
Total weeks of completion = UCP / (10 hours * 9 members)
Total = 18.53 ~ 19 weeks
Organisation
President
Approved by
Hazel Reyes & Marc
Sanchez
October 21, 2016
Version
3
Page
48

Project Plan: Inventory and Attendance System With Barcode

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Project Plan: Inventory and Attendance System With Barcode

Hochgeladen von

Copyright:

Verfügbare Formate

Project Plan

BECARIOS DE SANTO TOMAS

INVENTORY AND ATTENDANCE SYSTEM

Project Manager/Group Members:

October 21, 2016

1.5. . .Evolution of the Plan......................................................................................................................

Managerial Process Plans..................................................................................................

3.2. . .Work Plan.....................................................................................................................................

3.3. . .Project Tracking Plan...................................................................................................................

3.4. . .Risk Management Plan.................................................................................................................

Technical Process Plans......................................................................................................

Supporting Process Plans...................................................................................................

October 21, 2016

5.1. . .Configuration Management..........................................................................................................

October 21, 2016

Document Change Control

Gala, Katrine Grace

Revision and recalculation of Use

Gala, Katrine Grace

Juachon, Jean Philip

Kinol, Carlos Lewis

Final revisions for

Inventory and Attendance System with Barcode

1.2 Assumptions, Constraints and Risks

October 21, 2016

Inventory and Attendance System with Barcode

The organizations members have their own personal laptops to be

The technology used for the documentation

The budget used for the project is only from

The inventory system and Attendance

All data can only be validated by the

October 21, 2016

Inventory and Attendance System with Barcode

The budget is only limited to each

Errors in the system or database may

Some needed information may not be

Other members are not available

1.3 Project Deliverables

The Computerized Inventory System is a system that is aimed to make

The Computerized Inventory System will have a database that will

2. Database for Barcode attendance system

The organization has a Barcode but they dont have an attendance

October 21, 2016

Inventory and Attendance System with Barcode

3. Proposal Project Plan

4. Software Requirements Specification

The deliverable is intended to provide the technological requirements

5. Software Test Plan

8. Testing of the system

1.4 Schedule and Budget Summary

October 21, 2016

Inventory and Attendance System with Barcode

Identifying and assigning roles.

Client background review.

Feasibility Study revision

Project Plan Revision

System Request Specifications

Test Plan revision

October 21, 2016

Inventory and Attendance System with Barcode

1.5 Evolution of the Plan

October 21, 2016

Inventory and Attendance System with Barcode