CAPSTONE PROJECT

MANUAL 2019
for INFORMATION
TECHNOLOGY
DEPARTMENT
 CAPSTONE PROJECT GUIDELINES

A. Definition

B. Introduction

C. Project Areas

D. Pre-requisites

E. Capstone Project Team

F. Stages of the Capstone Project

1. Submission of Capstone Project Proposals *
2. Title Hearing *
3. Prototype Presentation *
4. Pre-Oral Defense *
5. Project Presentation & Skills Test **
6. Final Defense (Final Project)**
7. Final Submission**

G. Panel Composition

H. Duties and Responsibilities

a. The Proponents
b. Capstone Project Adviser
c. Capstone Project Instructor/Coordinator
d. Capstone Project Defense Panel

I. Capstone Project Document Format

J. Capstone Project Outline

K. References

2
 CAPSTONE PROJECT GUIDELINES

A. Definition

A Capstone Project is an undertaking appropriate to a professional field. It should significantly

address an existing problem or need. An Information Technology Capstone Project focuses on the
infrastructure, application or processes involved in introducing a Computing solution or problem.

B. Introduction

The Capstone Project is a non-classroom learning environment in which students apply the skills,
methods, and theories learned throughout their stay in the BSIT program. Capstone Project is a
major requirement in the BSIT program, and will assess if the students are ready to graduate.

Capstone Project extends two semester (IT 412L and IT 422L). Students enrolled in IT 412L
(Capstone Project 1) are required to attend an Orientation on such topics as choosing a research
topics, choosing a programming language, guidelines in writing the manuscript, title proposal
defense schedule and other related topics (e.g. number of title proposals to be presented and
groupings). Final submission of the complete system is presented in Capstone Project 2 (IT 422L).

The student is solely responsible for the preparation of the Capstone Project according to the
format and timetable prescribed by the Capstone Project Panel Committee, and within the
timetable specified in the Department Guidelines. It is the responsibility of the student’s Capstone
Project Panel Committee to judge the acceptability of the Capstone Project from all standpoints,
including writing quality, neatness, technical considerations and professional competency.

C. Project Areas

Capstone Project focuses on the infrastructure, application, or processes involved in introducing a

computing solution to a problem. Must include a comprehensive report on infrastructure
requirements and the projects implications on other existing systems (CMO 25 s2015).

Capstone Project must be useful to certain organization, institution, LGU, or other private entity. It
must be unique and have not been proposed by previous Proponents. The project should also be
feasible/attainable within two semester. Suggested areas for the computerized systems may fall
under the following category:

1. Software Development

3
 - Software Customization
 Extensions
 Plug-ins
- Information Systems Development for an actual client (with pilot testing)
- Web Applications Development (with at least Alpha Testing with Live Servers)
- Mobile Computing Systems
- Software w/ Hardware Integration

2. Multimedia Systems
- Game Development
- E-learning Systems
- Interactive Systems
- Information Kiosks

3. Network Design and Implementation and Server Farm Configuration and Management

4. IT Management
- IT Strategic Plan for sufficiently complex enterprises
- IT Security Analysis, Planning and Implementation

D. Pre-requisites

The following courses are helpful for the students in finishing the Project. Thus, the following
subjects are required before they can undergo Capstone Project.
 IT 113L (Computer Concepts and Fundamentals w/ Prod. Tools)
 IT 123(Data Structures and Algorithms)
 IT 123L (Programming II)
 IT 213 (Discrete Structures)
 IT 313 (System Analysis and Design) - for Software Development steps or life cycle
 IT 323 (Software Engineering) – for software development paradigms
 IT 313L (Database Management Systems 2) – for database application
 IT 323L (Web Applications Development) – for developing online applications
 IT 383L [IT Elective 3(Accessing the WAN)]
 IT 333L [IT Elective 1(PHP)]
 IT 343L (Multimedia Systems)
 IT 363L (Operating System Application)

Additional Subject that could help the students prepare the manuscript for the Capstone Project
are the following:
 Eng 14 (Technical Writing) - for formal articles/writing and presentation skills
 Stat 17 (Statistics and Probability) - for statistical process and treatment
 IT 333 (Accounting Principles) - for business processes

4
E. Capstone Project Team

The Capstone Project team is composed of at most three (3) members. The following are the
different roles that the proponents/researchers should play:

 Project Manager/Systems Analyst- The person with authority to manage a Capstone

Project. This includes leading the planning and the development of all Capstone Project
deliverables. The project manager is responsible for the budget, work plan and all Project
Management Procedures (scope management, issues management, risk management,
etc.). The project manager will also serve as the systems analyst who checks that all parts
of the system are coordinated.

 Programmer/Database Designer - The persons who design, write, and test computer
programs. He also ensures the quality of the software product and help find and eliminate
any bugs. He determines the functionality of every aspect of a particular application.

 Documenter/Technical Writer - A person who writes the Project study document, both the
system and the Research / Capstone Project manuscript.

F. Capstone Project Stages

The project paper has seven stages. At the end of every stage, each project paper proponent
submits specific deliverables for evaluation and acceptance by an adviser and the Capstone
Project Instructor, and in the end by a Capstone Project defense panel.

For all the stages of the project paper project, the criteria used when deliberating the defense
verdict include:

 complete and acceptable manuscript;

 a well-prepared and delivered presentation;
 a productive Question and Answer session; and
 a working Program/System including the necessary documentation/manuscript

1. Capstone Project Proposal Writing (Submission of Capstone Project Proposals)

- The Proposal Writing is catered in IT 412L (Capstone 1) subject.

- This includes shortlisting of possible title for Capstone Project. This is done in
preparation for Title Hearing. Each group are required to submit 5 possible
study/title to the Capstone Project Instructor.
- Each proposed study must be attached with at least 5 review of related literature
and 5 related studies. Make sure that sources are taken from reliable citations
using citation softwares like for example, Mendeley.
- The Capstone Project Instructor will then select 3 possible study/title. After
choosing three possible titles, a title hearing will be conducted immediately by
the Capstone Project Panel members to approve the proposed study. The only
deliverable at the end of this stage is a project proposal.

5
2. Title Hearing
- Title Hearing is catered in IT 412L (Capstone 1) subject.
- Title Hearing will be scheduled upon the completion of Capstone Project
Proposals.
- Proponents should present the following:
 Project Context
 Purpose and Description of the Project
 Objective of the Project
 Scope and Limitation of the Project
 Significance of the Project; and
 Initial design of the Project Proposals (screenshots of the proposed
project)

- Title Hearing will be scheduled on a Friday and all IT faculty will be divided into
two groups to serve as panel.
- During this stage, the Head, faculty members and Capstone Project Instructor
will deliberate and approve only one of the 3 study/title presented. Once a title is
approved, student will now be advised to choose their Capstone Project adviser.
- Students must consult their Capstone Project Instructor in choosing their
Capstone Project adviser. Advisers includes all IT Faculty available to serve a
group of students during thesis making.
- Students must choose three possible advisers
- Only the approved Capstone Project Proposal should advance to the next stage.
If none of the proposed study/title presented was approved, then, proponents
should do stage 1 again.
- Recommendation from the adviser is a prerequisite for Pre-Oral Defense

3. Prototype Presentation
- This part starts after the approved proposal. Student should now start working on
the proposed title.
- The team shall present to their adviser the 1st prototype (5% - 30%); 2nd prototype
(31% - 60%), 3rd prototype (61% - 99%) of the system/capstone project output.
- Regular meetings with the Capstone Project Adviser should be observed. Group
accomplishment report is required to check the accomplished milestone
conducted in developing the Capstone Project.
- The 1st Prototype should be presented to the Capstone Project Adviser as
scheduled.
- If the 1st Prototype reaches the required percentage, then the adviser can
recommend the group for a Pre-Oral Mock Defense.

Pre-Oral Mock Defense

- During this pre-oral mock defense, 30% from the manuscript will be checked and
an evaluation guide is stated in the Pre-Oral Mock Defense Evaluation Form.
- Manuscript includes Chapter 1, 2 and 3.

6
 - Take note that 30% of IT 412L(Capstone 1) grade comes from pre-oral mock
defense
- If the group will not show as scheduled during this defense but have stated to the
panel with valid reason, a redefense will be given.
- If the group will not show as scheduled during this defense but have stated to the
panel without valid reason, an incomplete grade will be given.
- The three possible verdicts after the pre-oral mock defense are:
 ACCEPTED
 ACCEPTED WITH REVISION
o Revisions are necessary to enhance the document
and/or software.
 NOT ACCEPTED
o Either the objectives of the study have not been met
or the proponent cheated.
- The team should take note the recommendations given by their adviser and
incorporate it in the creation of the 2nd prototype.
- Note: Students are only allowed to have a redefense only once

4. Pre-Oral Defense
- The proponents are required to submit a working or a functional system and the
complete documentation. A well prepared presentation should be presented to
the panel members with the Capstone Project adviser.
- Capstone Instructors will remind the team about the honoraria of the team panel
before the scheduled pre-oral defense
- The proponents are allowed to have the pre-oral defense if:
 the Capstone Project Adviser recommends the Capstone Project by
signing the Application for Pre-Oral Defense Form;
 the proponents secure an approval coming from the Capstone Project
Instructor/Coordinator three days before the Defense date.
 four copies of the Capstone Project Manuscript are submitted to the
Capstone Project Instructor/Coordinator three days before the actual
defense date.
- Proponents should present the following during this stage:
 Corrected Chapter 1 and Chapter 2
 Corrected Chapter 3
 2nd prototype (31% - 60%) of the Project Proposal
- If the group will not show as scheduled during this defense but have stated to the
panel with valid reason, a redefense will be given.
- If the group will not show as scheduled during this defense but have stated to the
panel without valid reason, an incomplete grade will be given.
- The team shall prepare and provide for the honoraria of the panel of examiners
immediately after the pre-oral defense.
- At the end of the Pre-Oral Defense, the Capstone Project Panel of Examiners will
deliberate and the Lead Panel will be the one to announce the verdict.

7
 - The five possible verdicts after the pre-oral defense are:
 PASSED
 CONDITIONAL PASS WITH MINOR REVISION
 CONDITIONAL PASS WITH MAJOR REVISION
Note: Revisions are necessary to enhance the document and/or
software.
The panelists are tasked to make sure that all the revisions are
made.
 REDEFENSE
Note: Students are only allowed to have a redefense only once
 FAILED
Either the objectives of the study have not been met or the proponent
cheated.
- The verdict is a unanimous decision among the three members of the Capstone
Project Defense Panel. Once issued, it is final and irrevocable.
- In case the project is NOT ACCEPTED, the proponents are allowed to redo the
project proposal or proposed a new topic.
- The Capstone Project Adviser should ensure that all recommendations for
improvement by the Panel of Examiners are incorporated in the next stage. This
may include grammar, accuracy of language, adequacy of data, project design,
methodology and appropriateness of data gathered.
- This is the last stage for Capstone Project 1. The student can proceed to take
Capstone Project 2 if they successfully completed all the requirements of
Capstone Project 1.

5. Project Presentation (Final Mock Defense)

- This is done in the second semester and the first stage in Capstone Project 2.
Recommendations from the Pre Oral defense should be complied.
- The proponents are required to submit a working or a functional system (3rd
prototype) and the revised manuscript. A well prepared presentation should be
presented to the panel members with the Capstone Project adviser.
- This stage is a pre-requisite for Final Defense.
- The proponents are allowed to have the project presentation and skills test if:
 the Capstone Project Adviser has checked the 3rd prototype and
recommends the group for presentation.
 the proponents secure an approval coming from the Capstone Project
Instructor/Coordinator three days before the presentation.
 four copies of the Revised Capstone Project Manuscript are
submitted to the Capstone Project Instructor/Coordinator three days
before the actual presentation date.
- Proponents should present the following during this stage:
 3nd prototype of the Project Proposal

8
  a corrected Capstone Project Manuscript (Chapter 1, 2, 3) ( revisions
shall be incorporated from Pre-Oral Defense) and a corrected Chapter
4 and 5 of the manuscript.
- If the group will not show as scheduled during this defense but have stated to the
panel with valid reason, a redefense will be given.
- If the group will not show as scheduled during this defense but have stated to the
panel without valid reason, an incomplete grade will be given.
- The three possible verdicts after the pre-oral mock defense are:

 ACCEPTED
 ACCEPTED WITH REVISION
o Revisions are necessary to enhance the document
and/or software.
 NOT ACCEPTED
o Either the objectives of the study have not been met
or the proponent cheated
- The Capstone Project Adviser should ensure that all recommendations for
improvement by the Panel of Examiners are incorporated for Final Defense.
- A skills test will be given to each group member to test the knowledge ability

THESIS IMPLEMENTATION TO CLIENT

- Students who have passed the Project presentation will implement its study to
its
respective clientele/end-user.
- Before the deployment, a requirement needs to be prepared like the
MOA(Memorandum of Agreement or an Memorandum of Understanding that
will be signed by both parties, the EVSU official signatory and representative
from an end-user client

6. Final Defense
- Proponents are required to present a complete and fully functional system.
Manuscript should include the last chapters which is Chapter 6 of the Capstone
Project.
- Capstone Instructors will remind the team about the honoraria of the team panel
before the scheduled pre-oral defense
- If the group will not show as scheduled during this defense but have stated to
the panel with valid reason, a redefense will be given.
- If the group will not show as scheduled during this defense but have stated to
the panel without valid reason, an incomplete grade will be given.
- The proponents are allowed to have the Final Defense if:
 the Capstone Project Adviser recommends the Capstone Project by
signing the Application for Final Defense Form

9
  the proponents secure an approval coming from the Capstone Project
Instructor/Coordinator three days before the presentation.
 final manuscript (Complete chapters)
- Proponents should present the following during this stage:
 a complete Capstone Project Manuscript
 a functional and running system
 grammar & plagiarism checker software
 note: plagiarism should not be more than 20% and grammar
must be 95% accurate
- The proponents should ensure that the complete Capstone Project Manuscript is
refined
- Take note that 30% of IT 422L(Capstone 2) grade comes from final mock
defense
- The Capstone Project Lead Panel and the adviser shall ensure that all
recommendations for improvement are incorporated in the final copy.
- One of the members of the Final Defense-Panel of Examiners maybe invited
from outside of the University if the study requires his/her expertise.
- The team shall prepare and provide for the honoraria of the panel of examiners
immediately after the pre-oral defense.
- At the end of the Final Defense, the Capstone Project Panel of Examiners will
deliberate and the Lead Panel will be the one to announce the verdict.
- The five possible verdicts after the pre-oral defense are:
 PASSED
 CONDITIONAL PASS WITH MINOR REVISION
 CONDITIONAL PASS WITH MAJOR REVISION
Note: Revisions are necessary to enhance the document and/or
software.
The panelists are tasked to make sure that all the revisions are
made.
 REDEFENSE
Note: Students are only allowed to have a redefense only once

 FAILED
Either the objectives of the study have not been met or the proponent
cheated.
- The verdict is a unanimous decision among the three members of the project
paper defense panel. Once issued, it is final and irrevocable.

7. Final Submission
- The student can only graduate within the semester if the final approved
Capstone Project is submitted to the Capstone Project Instructor/Coordinator.
- One copy of the Revised Capstone Project Manuscript together with the
Grammarian’s Certificate shall be routed to the Adviser, Panel members, and the
Lead Panel for confirmation of revisions. An Approval Sheet also may be routed
for their signatures if already amenable.

10
 - Approval Sheet is necessary prior to the FINAL Submission of the manuscript
and other deliverables.
- The following deliverables are required:
 Hard bound copy of the manuscript
 Proposal CD(with correct CD Label) which contains:
a. Final Capstone Project Manuscript (pdf copy)
filename: Capstone Project - Title
b. Final Capstone Project Manuscript (word copy)
filename: Capstone Project - Title
c. Installation / set up files/folders
d. Executable format of the running software
e. User Manual in pdf format;

G. Panel Composition

Capstone Project Panel of Examiners or the Panel Review Members are chosen based on the
following criteria:
1. Academic qualification
2. Breadth and depth of knowledge and experience in the discipline, and
3. Willingness to accept the responsibility

The panel consists of the following:

- 1 Chairman, 2 members, and may include content experts and recorder as assigned if
necessary.
- Their duties and responsibilities include the following, but not limited to:
 Chairman
- Brief the Proponents/Researchers about Pre Oral Defense, Proposal
Presentation /Skills Test and Final Defense.
- Issue the verdict. The verdict is a unanimous decision among the three
members of the Capstone Project Proposal Hearing and Oral Defense
panel. Once issued, it is final and irrevocable.
 Panel Members / Content Expert
- Validate the endorsement of the adviser. The panel serves as "Internal
Auditors", putting some form of check and control on the kinds of Capstone
Projects being approved by the Department.
- Evaluate the deliverables.
- Recommend a verdict.
- Listen and consider the request of the adviser and/or the
Proponents/Researchers.
- Nominate a Research / Capstone Project for the Outstanding Capstone
Project Award. Guidelines for the Outstanding Capstone Project Award will
be provided separately.
 During the Final Oral Defense, the end-user client or a representative will sit down to be a
part of the panel.

11
H. Duties And Responsibilities

1. The Proponents

The project paper proponent will be composed of only three members/students and have
the following responsibilities:

- Keep informed of the Capstone Project Guidelines and Policies.

- Keep informed of the schedule of activities, required deliverables and deadlines
posted by Capstone Project Instructor/Coordinator.
- Submit on time all requirements specified by the Capstone Project
Instructor/Coordinator.
- Submit on time all requirements identified by the Capstone Project defense panel
during the defense.
- Submit on time the requirements identified by the project paper adviser
throughout the duration of the project.
- Schedule regular meetings with the Capstone Project adviser throughout the
duration of the project paper. The meetings serve as a venue for the proponent
to report the progress of their work, as well as raise any issues or concerns.

2. Capstone Project Adviser

Each project paper proponents are assigned to one adviser, who should be a faculty
member of the Department of Information Technology of the College of Engineering.

The student will choose their adviser recommended by the Capstone Project Instructor
from the pool of IT faculty based on the faculty’s field of specialization or expertise.

Responsibilities

The adviser has the following responsibilities:

- Meet the proponents regularly to answer questions and help resolve

impasses and conflicts. In cases of failed attempts to resolve the issue, a
letter detailing, and justifying his/her decision must be submitted to the
Capstone Project Instructor.
- Ensure that the project paper is feasible. The Capstone Project adviser sees
to it that objectives, scope/limitations and methodology of the project are
well-defined.
- The adviser must be familiar with the topic to be able to give sound advice to
his/her advisees.
- Point out errors in the development work, in the analysis, or in the
documentation. The adviser must remind the proponent to do their work
properly.

12
 - Review thoroughly all deliverables at every stage of the project paper, to
ensure that they meet the department’s standards. The adviser may also
require his/her advisees to submit progress reports regularly.
- Recommend the proponent for a defense. The adviser should not sign the
Application for Pre-oral Defense Form or the Application for Final Defense if
he/she believes that the proponent is not yet ready for oral defense.
- Clarify points during the defense.
- Ensure that all required revisions are incorporated into the appropriate
documents and/or software.
- Keep informed of the schedule of project paper activities, required
deliverables and deadlines.
- The adviser can also request, on behalf of the proponent, for the
modification or elimination of certain revisions/requirements and defend
such requests before the final verdict is issued.
- The adviser is not expected to check the English spelling and grammar of
the project paper document.
- A faculty member assigned to be the adviser of a particular project paper
proponent would remain in that capacity for as long as he/she is a faculty
member of the Institute. If the faculty member goes on leave, he/she may
continue to serve as the adviser, or may pass the advisorship to another
faculty member.

3. The Capstone Project Instructor/Coordinator

The Capstone Project Instructor/Coordinator has the following responsibilities:
- Conduct orientation and give possible project areas at the start of the
semester to the students;
- Conduct general meetings with the students to discuss the Capstone Project
Guidelines, Policies and Requirements, and to allow the students to raise
and clarify issues;
- Select the defense panel for each Capstone Project proponents.
- Schedule project paper activities, such as the deadlines of requirements and
defense sessions.
- Post schedules, defense guidelines, requirements guidelines, and other
announcements;
- Furnish every member of the defense panel with all the necessary
documents before the defense;
- File at least one copy of the defense panel’s evaluation (including revisions)
and the Revised and Approved Requirement at every stage of the Capstone
Project paper.
- Streamline procedures.

4. Capstone Project Defense Panel

Each project paper proponent will have a project paper defense panel, which is composed
of three faculty members of the Department.

13
Responsibilities

The project paper defense panel has the following responsibilities:

- Validate the endorsement of the Capstone Project adviser.

- Knows the theoretical principles in the information technology of the topic to
be defended.
- Be punctual during the defense schedule.
- Contributes positively in the defense exercise by asking the Capstone
Project Group pertinent questions which would clarify and evaluate the
knowledge of the students in the topic of their study.
- Evaluates objectively the presentation of the students, the developed
software, and the responses made by the students.
- At all times promotes and exhibits unbiased behavior that is deemed
appropriate and consistent with any academic expertise.
- Recommend a verdict.
- Consider the requests of the Capstone Project adviser and/or the
proponent.

The lead panelist has the following responsibilities:

- Brief the proponents about the defense program during the actual defense.
- Issue the verdict. The verdict is a unanimous decision among the three
members of the project paper defense panel. Once issued, it is final and
irrevocable.

14
I. Capstone Project Document Format

Please refer to the following document formatting guidelines:

1. Paper
a. Size: 8.5 x 11
b. Orientation: Portrait (except for special diagrams)
c. Bookpaper Substance 20 (for copies to be bounded)

2. Spacing: double space

3. Indentation: 1 inch
4. Margins:
a. Top: 1 inch
b. Bottom: 1 inch
c. Left: 1.5 inches
d. Right: 1 inch
e. Header: 0.5
f. Footer: 0.5
5. Font
a. Sizes
- Chapter Headings: 14
- Sub Headings: 12
- Body Text: 12
b. Type/Style: Arial Narrow
c. Color: Black(Automatic)
6. Pagination
a. Top Right (no extra characters)
b. No page shown on first page of every chapter
7. Indention: Single Tab only
8. Sample Layout for Tables

Table <chapter.number [1…n]>:

Table Title

15
 9. Sample Layout for Figures

Figure <chapter.number [1…n]>: Figure Title

J. Capstone Project Outline

Title Page
Approval Sheet (for Final Manuscript only)
Acknowledgement (for Final Manuscript only)
Executive Summary or Abstract(for Final Manuscript only)
Table of Contents
List of Figures
List of Tables

Chapter I – Introduction
o Introduction Proper
o Project Context
o Purpose and Description of the Project
o Objectives of the Project
o Scope and Limitations of the Project
o Significance of the Project

Chapter II – Review of Related Literature and Systems

o Theoretical Background
o Related Literature
o Related Systems

Chapter III – Technical Background

o Technicality of the project
o Details of the technologies to be used
o How the project will work

Chapter IV – Methodology

16
o Environment (only for org-specific capstone project)
 Locale
 Population of the Study
 Organizational Chart/Profile
o Requirements Specifications
 Operational Feasibility
 Fishbone Diagram
 Functional Decomposition Diagram
 Technical Feasibility
 Compatibility checking (hardware / software and other technologies)
 Relevance of the technologies
 Schedule Feasibility
 Gantt Chart
 Economic Feasibility
 Budget and Cost Management
 Requirements Modeling
 Input
 Process
 Output
 Performance
 Control
 Either of the following two (2) or combined, whichever are applicable:
o Data and Process Modeling
 Context Diagram
 Data Flow Diagram
 System Flowchart
 Program Flowchart (highlights only)
o Object Modeling
 Use Case Diagram
 Class Diagram
 Sequence Diagram
 Activity Diagram
o Design
 Output and User-Interface Design
 Forms
 Reports
 Data Design
 Entity Relationship Diagram (preferably done in MS Access )
[but MS Access is discouraged as DBMS]
 Data Dictionary
 System Architecture
 Network Model
 Network Topology

17
  Security
o Development
 Software Specification
 Hardware Specification
 Program Specification
 Programming Environment
 Front End
 Back End
 Deployment Diagram
 Test Plan
o Testing
 Unit Testing
 Integration Testing
 System Testing
 Acceptance Testing (must be done after the Proposal Presentation & Skills Test)

Chapter V – Implementation Plan

o Project Implementation Checklist
o Implementation Contingency
o Infrastructure/Deployment

Chapter VI – Conclusion and Recommendations

BIBLIOGRAPHY

APPENDICES
o Relevant Source Code
o Evaluation Tool
o Sample Input / Output / Reports
o Users Guide/Manual
o Other Relevant Documents
o Acceptance sheet
o Grammarian’s Certification
o Curriculum Vitae

K. References

1. Commission on Higher Education (CHED), Republic of the Philippines. CMO 25 s2015:

Revised Policies, Standards, and Guidelines for BSCS, BSIS and BSIT programs.

2. Romana, C.L.C., Gamboa, R. S., Marcial, D. S., Gabison, G. V. D, Sioson, A. A. PSITE

Undergraduate Research and Capstone Project Manual, PSITE, 2014

18
 3. UC-CICS. Capstone Project Guideleines.

CAPSTONE PROJECT 1
TIMETABLE

MONTH DELIVERABLE SUBMIT TO DUE DATE

AUGUST Submission of Proposal Statements Capstone Project Instructor/Coordinator 3rd week of August
2nd week of
SEPTEMBER Title hearing Capstone Project Defense Panel
September
Prototype Presentation
OCTOBER 1 prototype (Pre-Oral Mock
st
Capstone Project Adviser October 18-19
Defense)
Pre-Oral Defense
NOVEMBER Capstone Project Defense Panel November 28-29
2nd prototype
DECEMBER Refinement of Capstone Project Capstone Project Adviser

CAPSTONE PROJECT 2
TIMETABLE

MONTH DELIVERABLE SUBMIT TO DUE DATE

JANUARY Refinement of Capstone Project Capstone Project Adviser

FEBRUARY Final Oral Mock Defense Capstone Project Defense Panel 2nd week of February
3rd week of February
MARCH Implementation/Deployment End-User Client
till end of March
Final Oral Defense
APRIL Capstone Project Defense Panel 1st week of April
3rd prototype
MAY Refinement of Capstone Project Capstone Project Adviser

19
 CHAPTER I-VI GUIDE

Chapter I

(Introduction Proper) The first page must contain the general view of the ICT as an
applied science focusing on the system under study vis-à-vis the technology being proposed.

An effective introduction discusses the meaningfulness of the study along while it presents
the problem or issue. Because it advocates for the need for your investigation and gives a clear
insight into your intentions, the introduction presents a background and context for your
investigation.

Project Context

(1-2 pages only) The proponent should introduce the presentation of the problem, that is,
what is the problem is all about. The proponent should describe the existing and prevailing problem
situation based on his or her experience. This scope may be global, national, or regional, and local.

The proponent should give strong justification for selecting such research problem in
his/her capacity as researcher. Being part of the organization or systems and the desire and
concern to improve the systems.

Defining your project’s context requires that you closely examine the problem statement
and then ask yourself and others the right questions. A good place to begin is to ask why the
system needed. Who will potentially benefit from the system? How does this system fit together
with other systems?
The answer to these questions will allow you to establish a context for your system in relation to
the people and systems that need to interact with it.

The researcher state a sentence or two that would show the link and relationship of the
rationale of the study to the proposed research problem.

20
 Purpose and Description of the Project

Project Description is a formally written declaration of the project and its idea and context
to explain the goals and objectives to be reached, the business need and problem to be
addressed, potentials pitfalls and challenges, approaches and execution methods, resource
estimates, people and organization involved, and other relevant information that explains the need
for project startup and aims to describe the amount of work planned for implementation.

It should primarily answer the following questions in writing the Purpose and Description
of the Project: (1) What is the function of your project? (2) What is good in your project? (3) What makes
your project unique, innovate, and relevant?

Objectives of the Project

Objectives of the Project should start with the General Objective which is very parallel to the project
title. Explode the general objective into Specific Objectives that will help realize the proposed study.

Objectives should be SMART:

S- Specific(numbers, amount; lengths, weights, scores, yields, etc.)

M- Measurable ( with standard measuring tools)
A- Attainable (can be achieved with project resources and capacities)
R- Relevant (answer real needs)
T- Time-bounded(span of time within which expected changes occurs)

Scope and Limitations of the Project

Think the project scope as a box. High-level scope defines the sides of the box and separates what
is relevant to your project from what is irrelevant. The scope refers to the work that needs to be
accomplished to deliver a products, service, or result with the specified features and functions. The scope
explains the nature, coverage, and time frame of the study.

The limitations, on the other hand, explain all that are NOT included in your project. In other words,
the scope of the project gives an overview all the deliverables(i.e. the things that your project gives/delivers),
and the tools and technologies used that will be used in the project development while the limitations of the
project are the boundaries of the project (i.e. areas/things that are out of scope).

Significance of the Project

A discussion of the significance of the study typically includes an explanation of the work’s
significance, its potential benefits and its overall impact. The significance of the study, attempts to explain to
an audience why a researcher’s work is worth performing.

21
 Stakeholders. People affected by the system may gain potential benefit and significant impact from
the project.

Chapter II

(Maximum of 4 pages). This chapter presents the theoretical background, related

literature and systems used by the proponents in order to have a clear view and knowledge in how
to develop the proposed system. A review of related literature and systems is an examination and
discussion of the literature and systems in a given area of study. It is a concise overview that has
been studied, argued, and established about a topic, and it is usually organized chronologically or
thematically.

Theoretical Background

When writing theoretical background, outline first, starting off with an anchor theory.
Supporting theories help elaborate the anchor theory. Footnoting is important which follows correct
bibliography entry. Fluidity and continuity should be observed.

Related Literature

They help or guide the researcher in searching for or selecting a better research problem
or topic. They help the investigator understand his topic for research better. They ensure that there
will be no duplication of other studies. They help and guide the researcher in locating more sources
of related information. They help the researcher in making his research design. They help and
guide the researcher in making comparison between his findings with the findings of other
researchers in similar studies with the end in view of formulating generalizations or principles which
are the contributions of the study to the fund of knowledge. Reviewed materials must not be too
few or too many. Many consider 3 to 5 related studies/projects.

Related Systems

A review of related systems serves as a proof that the system requirements used by other
systems similar to what is intended to be implemented in the capstone project are sufficient.

A review of related systems contains description of existing systems that are relevant to
the proposed capstone project. Discussion of specific features of other systems that you intend to
replicate and improve will help define what is to be expected in your project. Comparative matrix
may be more appropriate. Screenshots make the presentation believable.

Reviewed materials must not be too far few or too many. May consider 3 to 5 related
studies/projects.

Chapter III

22
 TECHNICAL BACKGROUND

(Maximum of 2 pages). This section describes the technical terms, relevant algorithms,
and possibly mathematical theorems for better understanding of the reader. It should start with a
paragraph that describes what the readers should expect in it. For capstone projects that use or
integrate existing software products, the latter should be described in sufficient detail.

Technicality of the Project

The technical part of the project should be elaborated as much as possible in layman’s
term. Technical terms (definition of terms), relevant algorithm and possibly mathematical theorems
may be included in this part. The purpose of this section is to serve as reference for technical
details used widely and importantly in the study.

It is most likely that the abbreviation and acronyms will be widely used in this section. The
first time you use abbreviation, you must write out the full form and put the succeeding paged of
the manuscript.

Details of the Technologies to be Used

If there are special hardware (e.g. computer server) and software systems(e.g. operating
systems) that are essential in the actual project implementation should be described clearly.

How the Project will Work

It is worth keeping that this section may set tone of the whole report or project. Hence, it
should be clear and understandable, possibly using different visual presentations as necessary.
This section should be written in narrative form. Aside from texts, the author may put tables,
graphs, illustrations, pictures, and other relevant information, as necessary.

Chapter IV

METHODOLOGY

Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text.

23
 Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text.

Environment

Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text.

Locale. Text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text.text text text text text text text text text text

text text text text text text text text text text.

Population of the Study. Text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text text text text.

Organizational Chart. Text text text text text text text text text text text text text text text text.

Figure 4.1: Organizational Chart of XYZ Company

Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text. Text text text text text text text text text text text text

text text text text.

Requirements Specification

24
 Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text.

Feasibility Test. Text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text text.

Operational feasibility. Text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text text text text.

Figure 4.2: Functional Decomposition Diagram of XYZ Company

Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text.

Technical feasibility. Text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text text text.

Table 4.1
SOFTWARE REQUIREMENT

Items Minimum Specification Required Specification

Table 4.2
HARDWARE REQUIREMENT

Items Minimum Specification Required Specification

25
Text text text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text. Text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text text text text text text text.

Schedule feasibility. Text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text

Table 4.3
GANTT Chart

DATE
ACTIVITIES

Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text

Economic feasibility. Text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text text text.

Table 4.4
BUDGET AND COST MANAGEMENT

Items Minimum Specification Required Specification

Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text

Requirements Modeling. Text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text text text text.

26
 Input. Text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text

 Text text text text text text text text text text text text text text text text.

 Text text text text text text text text text text text text text text text text.

 Text text text text text text text text text text text text text text text text.

Process. Text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text.

 Text text text text text text text text text text text text text text text text.

 Text text text text text text text text text text text text text text text text.

 Text text text text text text text text text text text text text text text text.

Output. Text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text.

 Text text text text text text text text text text text text text text text text.

 Text text text text text text text text text text text text text text text text.

 Text text text text text text text text text text text text text text text text.

Performance. Text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text

 Text text text text text text text text text text text text text text text text.

 Text text text text text text text text text text text text text text text text.

 Text text text text text text text text text text text text text text text text.

Control. Text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text

27
  Text text text text text text text text text text text text text text text text.

 Text text text text text text text text text text text text text text text text.

 Text text text text text text text text text text text text text text text text.

Data and Process Modeling. Text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text

Context Diagram. Text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text.

Figure 4.3: Context Diagram of XYZ System

Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text

Data Flow Diagra. Text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text

Figure 4.4: Data Flow Diagram of XYZ System

28
 Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text

System Flowchart. Text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text

Figure 4.5: System Flowchart of XYZ System

Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text

Program Flowchart. Text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text.

Figure 4.6: Program Flowchart of XYZ System

Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text

Design

29
 Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text. Text text text text text text text text text text text text text text text text text

text text .

Output and User Interface Design. Text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text text.

Forms. (User Interface)Text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text. Text text text text text text text text text text text

text text text text text text text text text text text text text text text text text text text text text text

Figure 4.7: Log-in Form of XYZ System

Text text text text text text text text text text text text text text text text text text text text text text text

text text.

Figure 4.8: Registration Form of XYZ System

30
 Text text text text text text text text text text text text text text text text text text text text text text text

text text.

Reports. (Generated Reports). Text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text.

Figure 4.9: Payroll Report of XYZ System

Text text text text text text text text text text text text text text text text text text text text text text text

text text.

Figure 4.10: Pay Slip of XYZ System

Text text text text text text text text text text text text text text text text text text text text text text text

text text.

Data Design. Text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text. Text text text text text text text text text text text text text

text text text text text text text text.

31
 Entity Relationship Diagram. Text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text. Text text text text text text text text text text

text text text text text text text text text text text.

Figure 4.11: Entity Relationship Diagram of XYZ Company

Text text text text text text text text text text text text text text text text text text text text text. Text text text

text text text text text text text text text text text text text text text text

Data Dictionary. Text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text.

Table 4.5
TABLE_DOCUMENTS

Name Type Width Index

Table 4.6
TABLE_REGISTRATION

Name Type Width Index

System Architecture. Text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text.

32
 Network Model. Text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text.

Figure 4.12: Network Model

Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text. Text text text text text text text text text text text.

Network Topology. Text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text.

Figure 4.13: Network Topology

Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text. Text text text text text text text.

Security. Text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text. Text text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text text. Text text text text text text text text

text text text text text text text text text text text text text text text text text text text text text text text.

33
Development

Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text. Text text text text text text text.

Software Specification. (Software needed in developing the system. This can be in sentence form)

Text text text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text.

Hardware Specification. (Hardware needed in developing the system. This can be in sentence

form) Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text.

Program Specification. (Application Program needed in developing the system. This can be in

sentence form) Text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text.

Programming Environment. (List of all Programming Language Used) Text text text text text text

text text text text text text text text text text text text text text text text text text text text text text text text text.

Front End. Text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text.

Back End. Text text text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text.

Deployment Diagram. (Identify the Changeover Method that you are going to use) Text text text

text text text text text text text text text text text text text text text text text text text text text text text text text

text text text.

34
 Figure 4.13: Phased Operation

Test Plan. (A Sample template is given below.. You may use this as a reference for the test plan

part) text text text text text text text text text text text text text text text. Text text text text text text text text

text text text text text text text text text text text text text text text text text text text text text text text. Text text

text text text text text text text

35
36
37
Testing

Text text text text text text text text text text text text text text text text text text text text text text text

text text text text text text text text. Text text text text text text text.

Unit Testing. (Sample Unit Test Result.. )Text text text text text text text text text text text text text

text text text text text text text text text text text text text text text text text text. Text text text text text text

text.

Integration Testing. (For Integration Testing, you may use the samnple template in below.

However, there should be more than one module to be tested.) Text text text text text text text text text text

38
text text text text text text text text text text text text text text text text text text text text text. Text text text text

text text text.

39
 System Testing. (Here, the entire system will be tested. You may just show the results gatheres

in testing the entire system)Text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text. Text text text text text text text.

40
 Acceptance Testing. Text text text text text text text text text text text text text text text text text text

text text text text text text text text text text text text text. Text text text text text text text.

41
 CHAPTER V
IMPLEMENTATION PLAN

Successful projects require detailed implementation plans. Generalized statements such as “staff
training” need further clarification in order to assign the task to an area of responsibility and to schedule it
effectively (McManus, 1989), (Maryland DBM, 2007). The implementation plan section defines the specific
requirements discussed in the methodology section. It gives detailed tasks and requirements.
The training plan identifies the type of training required for the stakeholders. A human resource
plan identifies the individuals and roles involved in the project and their responsibilities. A communications
plan describes the people who need information about the project, communicating the information, and
delivering updates, status reports, and other communications (Haughhey, 2008).
The majority of the tasks in the implementation plan focus on training development and delivery.
Different end users may have different training needs separate preparation, development, and delivery as
they are different audiences with different objectives.

42
(A sample format)
The project begins on September 22, 2008 and will finish on May 15, 2009. The project has
subcategories with dependent start dates and end dates to accommodate for upcoming tasks. There are
restrictions in place that dictate the timing of various training sessions and delivery. It is difficult to conduct
instructor training sessions during teaching periods because coordinating rooms and instructor’s timetables
is a feat in itself. This training must take place during break weeks or between semesters.
When determining the schedule, these issues became the starting points, and the necessary
preparation times worked backwards from the delivery dates. Alder (2007) discovered that when teaching
complex technical skills, the training is best if conducted within two weeks of going live to retain the new
skills.

Procedures

Discuss how the systems will be implemented. Starting on how username and password will be
acquired or the registration process, and others.

(A sample format)
The implementation plan focuses on training development and delivery, but there are some
VENDOR administrative procedures requiring attention. Students need to have usernames and passwords
assigned for them to use VENDOR. This will occur in VENDOR as a batch process. However, the
implementation plan needs procedures defining naming conventions and dissemination of the username
and password prior to the batch input.

Training Plan
The best way to teach people something is to give them the information they need to do
something they already want to do (Ra0, 1995). With this in mind, the training plans developed for end
users will give them a sense of “what’s in it for me.”
(A sample format)
Instructor training plan. Each module will contain specific learning goals and a lesson plan
(Jobert-Egou, 2003). There will be hands-on exercises for instructors to experiment with the software and
develop a good understanding of its application in CRM concepts. There is often resistance to new
technology when training instructors (Lewis, 1997). Traditionally, instructors believed that those who used
technology in the classroom did so because of their own experience with the software, not necessarily
through professional development (Price, 2003). Knowing this, the material must cater to the target
audience in its design and delivery. It must include explanations of the technology in non-technical terms. It
should be simple to understand and use step-by-step instructions and screenshots with callout balloons to
highlight the steps. Some instructors will be more adept at understanding the technology than others, so the
material needs to ensure that both types of audiences will be benefit from the training.

43
 The instructor training plan has two phases. The first phase is a discussion with instructors,
including a demonstration of VENDOR by the course leader. The instructors will receive their usernames
and passwords and self-study material two weeks prior to a one-day meeting planned during Break Week in
October. The second phase is a more formal training session with modules, exercises, and objectives. It will
take place during the Break Week in March. The delivery of the VENDOR module to students will take place
three or four weeks after this session. The course leader or VENDOR administrator will be available for
consultation at instructor’s request.
Teacher selection will be an important component of the success of the VENDOR
implementation. Proper planning will improve productivity and minimize political issues (Trepper, 1999). The
course leader will incorporate the feedback received from instructors into the course, keeping in mind the
course and lesson objectives. The implementation should have a “team” feel to it to enable insrtructors to
feel part of the process.
Student training plan. The student training plan follows standard curriculum development
procedures. The implementation will follow course objectives; include evaluation criteria, and abide by
program standards. The training will take place in Weeks 11-13, delivered by the instructors. An evaluation
of the software will occur in Week 14. The training plan for the students needs to ensure that students do
not just learn the technology itself, but that the lessons prepared reflect the concepts and theories discussed
in the preceding weeks. The VENDOR module should allow a large amount of exercises for students to
practice their skills (Oncu, Delialioglu, & Brown 2008). The evaluation will test student’s understanding of
VENDOR as it applies to CRM concepts, not the use of technology.
Human Resource Plan
State the responsibilities of all users/stakeholders
(A sample format)
Faculty responsibility. The faculty responsibility is to deliver real-world application of CRM-related
technology into the classroom. The faculty member must prepare lesson material, understand the impact of
the application on the CRM concepts, and assist students in their understanding of the application (Xachry,
2007), (Oncu, Delialoiglu, & Brown, 2008). Instructors need to communicate lesson objectives and reasons
for using the technology. The training delivered to students is different from the training the instructors
receive. Instructors need to be aware of this difference and ensure that the student-centered training takes
place. They need to provide an environment that allows students to learn the material at their own pace to
solidify the understanding. This may require different classroom management strategies to deter students
from using their computers for other purposes that may distract other students.
Administration responsibility. The administration needs to support faculty in their own learning
and understanding of the software, support the internal procedures, and give the course leader time to
develop the new material (Badua, 2008).
Support staff responsibility. Support staff should be knowledgeable about the use of VENDOR in
the CRM course, but they do not require any first-hand knowledge or specific training on the software. They
may have access to usernames and passwords as a backup in case students cannot contact their instructor
for access.
ITSC responsibility. ITSC does not have any direct responsibility for the system outside of
normal operating procedures. They are not required to support the product.

44
 Student responsibility. The student needs to understand that the application will directly affect
their ability to understand and apply CRM concepts. They need to overcome any barriers to technology
training by being open-minded (Wingard, 2000), (Constanza, 1993). By practicing the exercises in the
VENDOR module, students will develop a greater understanding of the technology and its application in
business (Oncu, Deliaglioglu, & Brown 2008).
VENDOR responsibility. VENDOR has responsibility for providing access to and support for the
implementation. They have done this already. Several instructors have administrator access to the system,
and VENDOR provided training and materials for instructor to develop instructor and student training.
VENDOR will continue to play a greater role in the course development stages of the plan, as their existing
material will create the framework and flow for the lesson plans, as well as some of the exercises. VENDOR
will provide ongoing support for administrators of the system. VENDOR will continue to communicate
technical information such as upgrades, course training offerings to the VENDOR administration or course
leader.

Chapter VI

CONCLUSION AND RECOMMENDATIONS

Aaaaaaaa’s School of Business is commited to incorporating the use of technology and software in
its courses to provide students with real-world business application of concepts. Second-year marketing
students take a Customer Relationship Management (CRM) course. Given the direct link between CRM and
technology, a project began to evaluate the viability of using a commercial software product within the
course. VENDOR was the chosen VENDOR because of the correlation between the course material and the
software, the cost of using the software, and the support the college received from VENDOR.

Conclusion

This project’s objective was to develop an implementation plan for the course leader, program
coordinator, administration, and CRM instructors to set the new expectations for incorporating VENDOR into
the program. The best approach to teaching the application effectively to students was to ensure that
instructors were well versed in the software. This project includes an instructor training plan, a student
training plan, and a communications plan to ensure that the VENDOR project is a success.

The School of Business faculty and staff would use this paper to assist in determining the viability
of software in other projects. The benefits to the organization are that it would present an effective way to
analyze the viability and suitability of a project. Currently, key personnel meet once or twice a year to
discuss a plan for change.

45
However, with individual and union contracts, it is difficult to break down a large project into smaller, more
manageable pieces in a short time frame. This project would help alleviate much of the intense work and
decrease the planning and implementation phases. In addition, a framework for project planning would allow
for clearer communication of the plan to upper management, and provide continuity if key players
responsible were no longer available for consultation or training.

A successful project would result with a framework for current and future projects, and a shared
plan for Aaaaaaaa faculty and staff. The specific project plan for VENDOR in a CRM course is a key take-
away for this project due to the implementation plan for Winter 2009.

Recommendations

Based on the findings, the following recommendations are suggested:

1. A technical person must be in charge of developing the instructor and student training material. This
person must ensure that the material is concise, provides examples and exercises and explains the
terminology is easy to understand language. Knowledge of the faculty members and their teaching styles is
ideal.
2. It is beneficial to have a central VENDOR administrator that ensures all courses using VENDOR are
able to receive information in a timely manner.
3. After subsequent implementations, testing and review would occur. The initial purpose would determine if
the system met the needs as intended. Ongoing issues or expected dates would need reviewing.
4. Using a phased approach, after the Winter 2009 implementation of VENDOR, course leaders for courses
can look at implementing VENDOR. Specifically, VENDORS’s use would be well positioned in Sales
Account Management in the Marketing program, eCRM in the E-Commerce program, and a variety of
courses in the post-grad Sales Management Certificate program.

46
 BIBLIOGRAPHY

Bowman, M., Debray, S. K., and Peterson, L. L. 1993. Reasoning about naming systems.
ACM Trans. Program. Lang. Syst. 15, 5 (Nov. 1993), 795-825. DOI=
http://doi.acm.org/10.1145/332040.161471.
Ding, W. and Marchionini, G. 1997. A study on Video Browsing Strategies. Technical Report.
University of
Maryland at College Park.
Frohlich, B. and plate, J. 2000. The cubic mouse: a new device for three-dimensional input. In
Proceedings of the SIGHCHI Conference on Human Factors in Computing Systems (The Hague,
The
Netherlands, April 01 – 06, 2000). CHI ’00. ACM Press, New York, NY, 526-531. DOI =
http://doi.acm.org./10.1145/332040.332491.
Nala, A. (1998) Teaching vocabulary: Evidence from research in Pig Latin Unpublished
manuscript,
Bringham Young University, Provo, UT.
Sanella, M. J. 1994 Consraint Satisfaction and Debugging for Interactive User Interfaces. Doctoral
Thesis.
UMI Order Number: UMI Order No. GAX95-09398., University of Washington.
Spector, A. Z. 1989. Archieving application requirements. In Distributed Systems, S. Mullender,
Ed.
Acm Press Frontier Series. ACM Press, Ney York, NY, 19-23. DOI =
http://doi.acm.org/10.1145/120417.90738
Y.T Yu, M.F. Lau, “A comparison of MC/DC, MUMCUT and several other coverage criteria for
logical
decisions”, Journal of Systems and Software, 2005, in press.

47
FNAME MNAME LNAME
Personal Data Information

Date of Birth : Age :

Place of Birth : Gender :
Civil Status : Nationality :
Father’s Name : E-mail :
Mother’s Name : Cellphone No. :
Home Address :

Educational Attainment

2017 Bachelor of Science in Information Technology

Eastern Visayas State University
Tacloban City

2013 High School Diploma

Tacloban High School
Tacloban City

2010 Elementary Diploma

Tacloban Elementary School
Tacloban City

Personal Strength

Skills
Psychomotor : Typing, Encoding
Cognitive : Training & Teaching

Awards : DOST-SEI RA 7687 Scholarship Program

BS Award (2014-2017)

Language Proficiency : English, Filipino, Waray.

Lectures/Seminars/Trainings Attended

Participant ICT Solutions for Everyday

Tacloban City, March 1, 2017

Facilitator Technology in Life

Tacloban City, January 1, 2017

48
CAPSTONE PROJECT

TEMPLATE

49
 COLLEGE OF INFORMATION AND COMPUTER

STUDIES ONLINE INFORMATION

SYSTEM
(Must be inverted pyramid form, all caps)

A Capstone Project

Presented to the

Faculty of the Department of Information Technology

College of Engineering

Eastern Visayas State University

Tacloban City

In Partial Fulfillment

of the Requirements for the Degree

Bachelor of Science in Information Technology

By

Juan D.. Dela Cruz

Peter R. Reyes

Luke S. Santos

March 2017

50
 ii

APPROVAL SHEET

The Capstone Project Study entitled COLLEGE OF INFORMATION AND COMPUTER

STUDIES ONLINE INFORMATION SYSTEM prepared and submitted by Juan D. Dela Cruz, Peter
R. Reyes, and Luke S. Santos in partial fulfillment of the requirements for the degree of
BACHELOR OF SCIENCE IN INFORMATION TECHNOLOGY has been examined and is
recommended for acceptance and approval for FINAL DEFENSE.

JAMES P. JAMES, MSIT

Adviser
=============================================================

APPROVED by the members of the Evaluation Panel on FINAL DEFENSE with a grade of
_________________.

CAPSTONE PROJECT COMMITTEE

MEMBER B. PANELIST, MSIT MEMBER B. PANELIST, MSIT

Panelist Panelist

MARIA G. DE JESUS, MSIT

Lead Panelist
============================================================
Accepted and approved in partial fulfillment of the requirements for the degree of BACHELOR

OF SCIENCE IN INFORMATION TECHNOLOGY.

ANNABELLE B. PILAPIL, Ph.D.

Dean, College of Engineering

DIANE B. REMOT, MST-CS

Head, IT Department

July 9, 2018
Date of Defense
ACKNOWLEDGEMENT

ii
 iii

This is an optional page for acknowledgments. It is a nice place to thank

the faculty, family members, and friends who have helped you reach this point in

your academic career.

The acknowledgments are personal for the student and may contain appropriate

information, written in a professional manner, that the student may wish to share

with the reader. There is no word limit, but the acknowledgments must not

exceed two pages in length. Any quotes listed in this section need to be cited;

however, use of copyrighted material in this section is discouraged.

iii
 iv

ABSTRACT

[NOTE: no indention on the first paragraph of the abstract]

Insert abstract here; it should not exceed one page. Abstract text must be

double-spaced with no paragraph breaks. The abstract for the completed

capstone project should include all the elements described for the final study.

Here are some form and style tips: (a) Limit the abstract to one typed page; (b)

maintain the scholarly language used throughout the project; (c) keep the

abstract concise, accurate, and readable; (d) use correct English; (e) ensure

each sentence adds value to the reader’s understanding of the research; and (f)

use the full name of any acronym used again in the abstract, and include the

acronym in parentheses. Do not include references or citations in the abstract.

Use numerals in the abstract, not written out numbers. For more guidance on

writing this paragraph, consult the Abstract Primer (available at

http://researchcenter.waldenu.edu/).

The last sentence of the abstract must start with the word “Keywords:” followed

by project area [select appropriate project area as written here: Software

Development, Cybersecurity, Game Development, E-Learning System,

Interactive System, Information Kiosks, Network Design and Implementation],

capstone project adviser’s full name, and up to five additional keywords that are

not included anywhere else in the abstract.

Example of last sentence: Keywords: Game Development, Prof. Juan Cruz,

multiplayer, interactive, social, educational, hobby.

iv
 v

TABLE OF CONTENTS

TITLE PAGE...........................................................................................................i

APPROVAL SHEET...............................................................................................ii

ACKNOWLEDGEMENT........................................................................................iii

ABSTRACT...........................................................................................................iv

TABLE OF CONTENTS.........................................................................................v

LIST OF TABLES................................................................................................viii

LIST OF FIGURES................................................................................................ix

CHAPTER 1: INTRODUCTION............................................................................1

Project Context..........................................................................................1

Purpose and Description of the Project......................................................1

Objectives of the Project.............................................................................1

Scope and Limitations of the Project..........................................................1

Significance of the Project.……………………………………………………….1

CHAPTER 2: REVIEW OF RELATED LITERATURE AND SYSTEMS...............2

Theoretical Background..............................................................................2

Related Literature.......................................................................................2

Related Systems.........................................................................................2

CHAPTER 3: TECHNICAL BACKGROOUND.....................................................3

Technicality of the Project.........................................................................3

Details of the Technology to be Used........................................................3

How the Project Will Work..........................................................................3

v
 vi

CHAPTER 4: METHODOLOGY...........................................................................4

Environment...............................................................................................4

Requirements Specification........................................................................4

Feasibility Test.................................................................................4

Requirements Modeling...................................................................4

Data and Process Modeling.............................................................4

Design........................................................................................................4

Output and User Interface Design..................................................4

Data Design....................................................................................4

System Architecture........................................................................4

Development..............................................................................................4

Software Specification.....................................................................4

Hardware Specification....................................................................4

Programming Environment..............................................................4

Deployment Diagram.......................................................................4

Test Plan..........................................................................................4

Testing.......................................................................................................4

Unit Testing......................................................................................4

Integration Testing...........................................................................4

Systems Testing..............................................................................4

Acceptance Testing.........................................................................4

CHAPTER 5: IMPLEMENTATION PLAN.............................................................5

CHAPTER 6: CONCLUSION AND RECOMMENDATIONS................................6

REFERENCES......................................................................................................7
vi
 vii

APPENDIX A: RELEVANT SOURCE CODE.......................................................8

APPENDIX B: EVALUATION TOOL....................................................................9

APPENDIX C: SAMPLE REPORTS (EXISTING SYSTEM)..............................10

APPENDIX D: SYSTEM GENERATED OUTPUTS...........................................11

APPENDIX E: USER’S GUIDE/MANUAL..........................................................12

APPENDIX F: ACCEPTANCE SHEET..............................................................13

APPENDIX G: GRAMMARIAN’S CERTIFICATION...........................................14

APPENDIX H: PICTURES..................................................................................15

CURRICULUM VITAE.........................................................................................16

vii
 viii

LIST OF TABLES

Table 1.1 Caption for Table 1..............................................................................................1

Table 1.2 Caption for Table 2..............................................................................................2

viii
 ix

LIST OF FIGURES

Figure 1.1 Caption for Figure 1..........................................................................................1

Figure 2.1 Caption for Figure 2..........................................................................................2

REFERENCES

ix
 x

References will be APA style.

x
 8

APPENDIX A: TITLE OF APPENDIX A

Text text text text text text text text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text text text text text text text text
text text text text text text text text text text.

11
 9

APPENDIX B: TITLE OF APPENDIX B

Text text text text text text text text text text text text text text text text text text text text text text text
text text text text text text text text text text text text text text text text text text text text text text text
text text text text text text text text text text.

12