Professional Documents
Culture Documents
Capstone Project MANUAL 2019: For Information Technology Department
Capstone Project MANUAL 2019: For Information Technology Department
MANUAL 2019
for INFORMATION
TECHNOLOGY
DEPARTMENT
CAPSTONE PROJECT GUIDELINES
A. Definition
B. Introduction
C. Project Areas
D. Pre-requisites
G. Panel Composition
K. References
2
CAPSTONE PROJECT GUIDELINES
A. Definition
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 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:
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.
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:
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.
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.
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
- 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
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:
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
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.
13
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
15
9. Sample Layout for Figures
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 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)
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
18
3. UC-CICS. Capstone Project Guideleines.
CAPSTONE PROJECT 1
TIMETABLE
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
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 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.
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).
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
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.
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.
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.
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
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
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.
Text text text text text text text text text text text text text text text text text text text text text text text
text 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.
Text text text text text text text text text text text text 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
Table 4.2
HARDWARE REQUIREMENT
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
Text text text text text text text text text 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.
Text text text text text text text text text 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
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
Text text text text text text text text text 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.
Text text text text text text text text text 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
Text text text text text text text text text text text text text text text text text text text text text text text
text text.
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.
Text text text text text text text text text text text text text text text text text text text text text text text
text text.
Text 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
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.
Text text text text text text text text text text text text text text text text 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
Table 4.6
TABLE_REGISTRATION
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.
Text text text text text text text text text text text text text text text text text text 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.
Text text text text text text text text text text text text text text 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
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
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
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
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
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
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
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
Educational Attainment
Personal Strength
Skills
Psychomotor : Typing, Encoding
Cognitive : Training & Teaching
Lectures/Seminars/Trainings Attended
48
CAPSTONE PROJECT
TEMPLATE
49
COLLEGE OF INFORMATION AND COMPUTER
SYSTEM
(Must be inverted pyramid form, all caps)
A Capstone Project
Presented to the
College of Engineering
Tacloban City
In Partial Fulfillment
By
Peter R. Reyes
Luke S. Santos
March 2017
50
ii
APPROVAL SHEET
APPROVED by the members of the Evaluation Panel on FINAL DEFENSE with a grade of
_________________.
July 9, 2018
Date of Defense
ACKNOWLEDGEMENT
ii
iii
the faculty, family members, and friends who have helped you reach this point in
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;
iii
iv
ABSTRACT
Insert abstract here; it should not exceed one page. Abstract text must be
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
Use numerals in the abstract, not written out numbers. For more guidance on
http://researchcenter.waldenu.edu/).
The last sentence of the abstract must start with the word “Keywords:” followed
capstone project adviser’s full name, and up to five additional keywords that are
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
Theoretical Background..............................................................................2
Related Literature.......................................................................................2
Related Systems.........................................................................................2
CHAPTER 4: METHODOLOGY...........................................................................4
Environment...............................................................................................4
Requirements Specification........................................................................4
Feasibility Test.................................................................................4
Requirements Modeling...................................................................4
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
REFERENCES......................................................................................................7
vi
vii
APPENDIX H: PICTURES..................................................................................15
CURRICULUM VITAE.........................................................................................16
vii
viii
LIST OF TABLES
viii
ix
LIST OF FIGURES
REFERENCES
ix
x
x
8
Text text text text text text text text text text text text text text text text text text text text text text text
text text text text text text text text text 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
Text text text text text text text text text text text text text text text text text text text text text text text
text text text text text text text text text 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