School of Information Technology Mapua Institute of Technology

Capstone Project Guidelines and Policies

Version 2.1

These policies and guidelines were formulated with the objective of helping the BSIT students of School of IT to deliver useful capstone projects on time.

Comments and suggestions are continually welcome for the betterment of the BSIT program.

Prof. Ariel Kelly D. Balan Course Adviser Capstone Project

1. RATIONALE
The capstone project is required for candidates for graduation in a BSIT program as indicated in Section 10 of CHED CMO. 53, s. 2006 or the Revised Policies and Standards for IT Education. The capstone project is a terminal project requirement that would not only demonstrate a students comprehensive knowledge of the area of the study used but also allow them to apply concepts and methods to a specific problem in his/her area of specialization. This course is a non-classroom learning environment in which students apply the skills, methods, and theories learned throughout their stay in the School of IT. This document intends to serve as a guide for faculty and students alike in determining what are allowable standards for a capstone project in the context of undergraduate studies in IT. With the goal of adequately preparing students for their respective careers by involving them in a large project that extends over several months, the capstone project is put in place to demonstrate:

1.1 Application of Concepts a. Documentation (e.g. use of appropriate documentation tools) b. Database c. Networking d. Project management/Software Engineering e. Other technologies 1.2 Exhaustive and convincing related literature / systems a. the existence or non-existence of similar systems/theory b. needed extensions or improvements c. proper documentation tools/notations will be used

2. Projects
2.1 Categories Projects may fall under one of the following categories: a. Software Development Software customization Information Systems Development for an actual client (with pilot testing) Web Applications Development (with at least alpha testing on live servers) Mobile Computing Systems b. Multimedia Systems Game Development e-Learning Systems Interactive Systems Information Kiosks c. Network Design and Implementation and Server Farm Configuration and Management d. IT Management IT Strategic Plan for sufficiently complex enterprises IT Security Analysis, Planning and Implementation

2.2 Scope of the Work The panel and the adviser must ensure that the project is feasible/attainable within a school year if done in a part-time basis. Detailed Proposal IT200L Developmental Work IT200 -1L Final Writing IT200-2L

3. Project Stages
The entire course program officially starts upon successful defense of the project proposal and ends with the submission of an approved project document and other deliverables. The capstone project has three stages. At the end of every stage, each group submits specific deliverables for evaluation and acceptance by the adviser and panels. For all the stages of the project, the criteria used when deliberating the defense verdict include: a. complete and acceptable deliverables; b. a well-prepared and delivered presentation; and c. a productive Question and Answer session. 3.1 Pre-Proposal Pre-proposal stage results in the identification of a capstone project. This stage involves the following activities: a. identification of the problem; b. specification of the objectives of the project; and c. search of related literature. The only deliverable at the end of this stage is a concept paper. This is a pre-requisite in order for the topic to be approved by the course adviser. The concept paper should have the following two characteristics: a. It is in line with the research thrusts of the School of IT, the Institute or government; and b. The proponents understand the project and proponents know what they will do next. There is no defense at this stage. The students are encouraged to consult with the Course Adviser. 3.2 Writing and Presenting the Proposal (IT200L) The student must have an approved concept paper before starting this stage. This stage involves the following activities: a. search of related literature/related system b. conducting feasibility studies technical operational economical - Cost-Benefit Analysis c. investigation of existing solutions to the identified problem(s) d. evaluation of existing solutions

e. application of methods and theories learned to design of a solution to the problem(s) f. successful proposal defense

The deliverable at the end of this stage is an approved proposal that includes a partial project document covering Chapters 1 to 3. These chapters include the Introduction (project context, objectives, scope and limitations), Review of Literature, Methodology, and the description and initial design of the system to be developed. Proponents are eligible for proposal defense only if: a. students apply for a Proposal Defense at the Office of the Deans/Treasurers Office. Deadline for application is normally on the 7th week of the term; b. adviser recommends the proposal and signs the Application for Project Proposal Defense Form; c. three copies of the proposal are submitted to the Course Adviser at least one week before the actual defense date. Deadline for the defense is one week before final exam week; There will be four possible verdicts after the defense: a. ACCEPTED WITH NO REVISIONS. The proposal document will immediately be approved by the Panel Members. b. ACCEPTED WITH MINOR REVISIONS. Revisions are necessary but they do not have to be presented in front of all panel members. The corrected version will only be consulted to the Technical Adviser and the Lead Panel. After which the other panel members will just affix signature on the approval sheet. c. ACCEPTED WITH MAJOR REVISIONS. The revisions will be presented and checked by all panel members. If indeed necessary that another defense session maybe required by the panel in order to further clarify the objectives and scope of the project, the students must re-apply for another proposal defense. d. NOT ACCEPTED. The proposed topic can not be considered.

The verdict is a unanimous decision among the three members of the defense panel. Once issued, it is final and irrevocable. Once approved, no item may be modified or removed from the project and software objectives and scope. In very rare and extreme cases, the defense panel may allow modifications in the software objectives and scope prior to the FINAL WRITING defense. For this, the proponents must submit a letter (signed by the adviser noted by the Dean) to the defense panel explaining why there is such a need.

3.3 IT200-1L The proponents are required to enroll IT200-1L. During this stage, there are no deliverables submitted to the defense panel. However, the proponent performs the following activities: a. implementation/development of the solution identified in the Proposal b. analysis of the solution Project Milestones should be identified by the proponents and the schedule should be submitted to the Course Adviser and noted by the Technical Adviser. This is the stage where the system is implemented, tested, and the results analyzed. The possible grades of the students are as follows: A. B.

PASSED: if the project completion is 70% complete or better. FAILED: if the project development is less than 70% of the identified project scope. Thus, the students are required to re-enroll IT200-1L.

3.4 IT200-2L During this stage, the proponents perform the following activities: a. documentation of the results b. finalization of the project document c. preparation for the project final presentation The following are the deliverables required at the end of this stage: a. the complete capstone project document b. for projects involving software systems or applications: the Technical Manual; the Users Manual (If the system is immediately deployable); and the running software. The proponents are eligible for FINAL WRITING presentation/defense only if a. students are officially enrolled in IT200-2L. b. technical adviser recommends the document by signing the project document and Application for the Schedule of Final Defense Form; c. three copies of the document are submitted to the Course Adviser at least one (1) week before the actual defense date. Deadline for the defense is on the 6th weeks of the current term;

There will be four possible verdicts after the defense: a. ACCEPTED WITH NO REVISION. The proposal document will immediately be approved by the Panel Members. b. ACCEPTED WITH MINOR REVISIONS. Revisions are necessary but they do not have to be presented in front of all panel members. The corrected version will only be consulted to the Technical Adviser and the Lead Panel. After which the other panel members will just affix signature on the approval sheet. c. ACCEPTED WITH MAJOR REVISIONS. The revisions will be presented and checked by all panel members. If indeed necessary that another defense session

maybe required by the panel for further clarifications, the students must re-apply for another proposal defense. d. NOT ACCEPTED. Either the objectives of the study have not been met or the proponents cheated. The students are required to undergo the whole process of Capstone Project again. The verdict is a unanimous decision among the three members of the defense panel. Once issued, it is final and irrevocable.

4. Duties and Responsibilities

The development and defense of the capstone projects involves the following key parties: 4.1 The Project Proponents The project proponents will be composed of a maximum of three (3) student, they should have successfully passed the prerequisite courses and must be of third year standing. 4.1.1 Responsibilities The following are the responsibilities of the proponents: a. Keep informed of the Capstone Project Guidelines and Policies. b. Keep informed of the schedule of project activities, required deliverables and deadlines posted by Course Adviser. c. Submit on time all deliverables specified in this document as well as those to be specified by the Course Adviser. d. Submit on time all requirements identified by the defense panel during the defense. e. Submit on time the requirements identified by the adviser throughout the duration of the project development. f. Schedule regular meetings (at least once a month) with the adviser throughout the duration of the capstone project. The meetings serve as a venue for the proponents to report the progress of their work, as well as raise any issues or concerns. 4.2 The Technical Adviser Each group is assigned to a technical adviser, who should be a faculty member of the School of IT Department. In special cases, the adviser can come from another department of the School, provided that the selection criteria discussed in the next section is observed. 4.2.1 Selection The adviser will be chosen by the faculty handling Capstone Project course from the pool of SOIT faculty based on the following factors: a. the faculty members research area and projects; b. the advising and administrative load of the faculty 4.2.2 Responsibilities The adviser ha the following responsibilities: a. Meet the proponents regularly (at least once a month) to answer questions and help resolve impasses and conflicts. In cases of failed attempts to resolve the issue, a letter detailing, and justifying their decision must be submitted to the Course Adviser noted by the Dean.

b. Ensure that the project is feasible. The technical adviser sees to it that the objectives, scope/limitations and methodology of the project are well-defined. c. Personally conducting (or has conducted) research in parallel with the advisees on the topic. The adviser must be familiar with the topic to be able to give sound advice to his/her advisees. d. Point out errors in the development work, in the analysis, or in the documentation. The adviser must remind the proponents to do their work properly. e. Review thoroughly all deliverables at every stage of the project, to ensure that they meet the schools standards. The adviser may also require his/her project proponents to submit progress reports regularly. f. Recommend the proponent for oral defense. The adviser should not sign the document and the Application for the Schedule Proposal Defense Form and the Application for Schedule of Final Defense Form if he/she believes that the proponents are not yet ready for oral defense. g. Clarify points during the oral defense. h. Ensure that all required revisions are incorporated into the appropriate documents and/or software. i. Keep informed of the schedule of activities, required deliverables and deadlines. j. Recommend to the defense panel the nomination of project for an award. The adviser can also request, on behalf of the proponents, 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 document. A faculty member assigned to be the adviser of a particular project proponents would remain in that capacity for as long as he/she is a faculty member of the School of IT. 4.3 The Defense Panel Each group proponent will have a defense panel, which is composed of three faculty members of the School of IT. 4.3.1 Selection In special cases, a panelist may come from an external unit. The panel members are chosen by the Dean based on the following constraints: a. At least one of the panelists is a senior faculty member, whose research area is the area the project falls under, b. At least two of the panelists belong to the research area under which the project falls; and c. The composition of the defense panel must be retained, as much as possible, throughout all the stages of the capstone project. 4.3.2 Responsibilities The defense panel has the following responsibilities: a. Validate the endorsement of the technical adviser. The panel serves as internal auditors, providing a form of check and control on the kinds of project being approved by the School. b. Evaluate the deliverables. c. Recommend a verdict. d. Listen and consider the requests of the adviser and/or the proponents. e. Nominate a project for the Outstanding Capstone Project Award. Guidelines for the Outstanding Capstone Project Award will be provided separately. The lead panelist has the following responsibilities: a. Brief the proponents about the defense program during the actual defense. b. Issue the verdict. The verdict is a unanimous decision among the three members of the project defense panel. Once issued, it is final and irrevocable. 4.4 Course Adviser

The Graduate Studies Director has the following responsibilities: a. Announce research areas (at the start of the each term) to the students; b. Conduct general meetings with the students to discuss the Capstone Project Guidelines, Policies and Deliverables, and to allow the students to raise and clarify issues; c. Select a defense panel for each project proponent based on the guidelines in Section 4.3; d. Schedule project activities, such as the deadlines of deliverables and defense sessions. e. Post schedules, defense guidelines, requirements guidelines, and other announcements; f. Furnish every member of the defense panel with all the necessary documents before the defense; g. File at least one copy of the defense panels evaluation (including revisions) and the Revised and Approved Deliverables at every stage of the project. h. Streamline procedures.

5. Documents
5. 1 Format/Page Layout The general format and page layout of the document should follow the format prescribed for Mapuas institutional Thesis document. The font used for the entire document must be Times New Roman with a point size of eleven (11). Paragraphs must be double-spaced. 5.2 Capstone Project Proposal Outline and Contents Title Page Table of Contents Chapter I. Introduction Overview of the Current State of Technology This section gives the reader an overview of the specific technology or field in the international or local setting. The information regarding the technology or field should be contemporary and not based on outdated sources. Discussion must not be too technical or too detailed. This section ends with a discussion on the problems faced by or that still exist in the specific technology or field (e.g., limitations of existing software or algorithms). The problem statement would lead to the project research objectives. Objectives General Objective This section states the over-all goal that must be achieved to answer the problem. Specific Objectives This subsection is an elaboration of the general objective. It states the specific steps that must be undertaken to accomplish the general objective. These objectives must be specific, measurable, attainable, realistic, time-bounded. Each specific objective may start with to design/survey/review/analyze

Studying a particular programming language or development tool (e.g., to study Windows/ObjectOriented/Graphics/C++ programming) to accomplish the general objective is inherent in all project and, therefore, must not be included here. Scope and Limitations of the Project This section discusses the boundaries (with respect to the objectives) of the research and the constraints within which the research will be developed. Significance of the Project This section explains why research must be done in this area. It rationalizes the objective of the Research project with that of the stated problem. Avoid including here sentences such as This research will be beneficial to the proponent/department/college as this is already an inherent requirement of all capstone projects. Focus on the researchs contribution to the Computer Science field. Chapter II Review of Related Literature/Review of Related System This section discusses the features, capabilities, and limitations of existing research, algorithms, or software that are related/similar to the project. The reviewed works and software must be arranged either in chronological order, or by area (from general to specific). Observe a consistent format when presenting each of the reviewed works. Chapter III Methodology This section lists and discusses the specific steps and activities that will be performed by the proponents to accomplish the project. The discussion covers the activities from pre-proposal to Final Document Writing. This section also includes an initial discussion on the theoretical/conceptual framework to be followed. Examples of activities include inquiry, survey, research, brainstorming, canvassing, consultation, review, and interview, observe, experiment, design, test, document, etc. The methodology also includes the following information: who is responsible for the task the resource person to be contacted what will be done when and how long the activity will be done where will it be done why should be activity be done Calendar of Activities This section contains the Gantt chart showing schedule of the activities outlined in Section 3.0. Appendix A. Diagrams and other documentation tools such as Ishikawa/Fishbone Diagram Appendix B. Theoretical and/or Conceptual Framework Discusses the basic framework/foundation the project is based on. This section is normally referred to when discussing Scope and Limitations, and Research Methodology Appendix C. Important of the feasibility studies. .

. . . Appendix Z. Resource Persons For each resource person: <full name and title, e.g., Dr. Juan de la Cruz> <profession, e.g., faculty> <department, e.g., School of IT> <name of institution, e.g., Mapua Institute of Technology> <e-mail address> References (see Section 5.4)

5.3 Final Document for Capstone Project Title Page Approval Sheet Acknowledgement* Executive Summary Table of Contents List of Tables List of Figures Chapter I. Introduction 1.1 Project Context 1.2 Purpose and Description 1.3 Scope and Limitations 1.4 Significance of the Project Chapter II. Review of Related Literature/Review of Related Systems Part of the contents of this section is lifted from Chapter 2 of the Proposal. Additional materials gathered during final document Writing stages must also be included. Chapter III. Technical Background This section discusses the theories and concepts to be used in the course of designing or developing the project. Include only those concepts that you feel will be needed. DO not copy the whole source Chapter IV. Methodology Requirements Specification Analysis Design Development and Testing Chapter V. Recommendations Implementation Plan (Infrastructure/Deployment) This chapter gives an assessment of what happened in this project. It presents explanations and justifications on how the objectives of the project were met, to what extent and why some objectives were not met. This chapter also includes a discussion of possible improvements that can be made on the software, as well as future directions of the research topic in general. This serves as a springboard for projects that may be done by capstone project proponents.

Appendix A Diagrams Appendix xxx Appendix (xxx)+1 Resource Persons (follow the format in the Proposal) Appendix (xxx)+2 Personal Vitae (follow the format in the Proposal) References (see Section 5.4) TECHNICAL MANUAL (see Section 5.5)* USERS MANUAL (see Section 5.6)*

5.4 Format for References, Citations, and Quotations Reference and citation Format for the Communications of the ACM By Dr. Andy Dong The Association for Computing (2003, Mueller et al., 2003) Machinery is the pre-eminent professional body dealing in all aspects of information technology. This is a style guide for their reference and citation format. Note that there are some slight stylistic differences between the format for the magazine Communications of the ACM (per the style in EndNote) and the ACM conference proceedings reference format (per the style in the ACM conference proceedings template). This document will describe the Communications of the ACM style. In practice, adherence to a single, consistent style is satisfactory. References Section The References section appears at the end of the paper. All references appear alphabetically by the lead authors last name and are numbered consecutively. A clear header should be used to indicate the start of the References. Example: References 1. Bless, H. The Interplay of Affect and Cognition. in Forgas, J.P. ed. Feeling and Thinking: The Role of Affect in Social Cognition, Maison des Sciences de l'Homme and Cambridge University Press, Cambridge, 2000, 201-222. 2. Garcia, A.C.B. and Howard, H.C. Acquiring design knowledge through design decision justification. Artificial Intelligence for Engineering Design, Analysis and Manufacturing, 6 (1). 59-71. Citation As you write your report, you will cite your references. A citation to a reference in the body of the text is indicated by a bracketed number corresponding to the reference number in the References section. Example: During high stress periods, individuals should focus on the situation-specific tasks rather than rely on general knowledge structures. [1]

Reference Formats
GENERAL INSTRUCTIONS

A complete reference should contain the name(s) of the author(s) and/or editor(s), the title of the article, the name of the book or conference proceedings where appropriate, and bibliographic information about the article such as the name of the publisher, the city of publication, and the page numbers. The basic concept is that the reference should be sufficiently complete so that the reader could readily find the reference and can judge the authority and objectivity of the reference. All author names appear as Lastname, Initials. For example, if Andy Dong is the primary author and Alice M. Agogino is the second author, the correct appearance of the author names would be: Dong, A., and Agogino, A.M.
THIS IS THE REFERENCE FORMAT FOR A BOOK.

Authors. Title. Publisher, City of Publication, Year of Publication. Example: 1. Fogg, B.J. Persuasive technology: using computers to change what we think and do. Morgan Kaufmann Publishers, Boston, 2003.

THIS IS THE REFERENCE STYLE FOR AN ARTICLE WHICH APPEARS IN AN EDITED BOOK.

Authors. Title. in Editors Title of edited book, Publisher, City of Publication, Year of Publication, Pages. Example: 1. Fischer, G. and Nakakoji, K. Amplifying designers creativity with domain-oriented design environments. in Dartnall, T. ed. Artificial Intelligence and Creativity: An Interdisciplinary Approach, Kluwer Academic Publishers, Dordrecht, 1994, 343-364.

THIS IS THE REFERENCE STYLE FOR A JOURNAL OR MAGAZINE ARTICLE.

Authors. Title. Journal or magazine name, Volume (Issue), Pages. Example: 1. Hirsh, H., Coen, M.H., Mozer, M.C., Hasha, R. and Flanagan, J.L. Room service, AI-style. IEEE intelligent systems, 14 (2). 8-19.

THIS IS THE REFERENCE STYLE FOR A CONFERENCE PROCEEDINGS.

Authors, Title. in Title of conference, (Location of Conference, Year), Publisher, Pages. Example: 1. Leclercq, P. and Heylighen, A. 5,8 Analogies per hour: A designer's view on analogical reasoning. in 7th International Conference on Artificial Intelligence in Design, (Cambridge, UK, 2002), Kluwer Academic Publishers, 285-303.

THIS IS THE REFERENCE STYLE FOR ELECTRONIC MEDIA (ARTICLES, IMAGES, ETC.) RETRIEVED FROM THE WEB. FOLLOW THE REFERENCE FORMAT FOR A JOURNAL ARTICLE AND THEN INCLUDE INFORMATION ABOUT THE WEB SITE AND THE DATE WHEN YOU RETRIEVED THE RESOURCE. NOTE THAT THE DATE OF PUBLICATION AND THE DATE OF RETRIEVAL OF THE ARTICLE MAY NOT BE THE SAME. WHEN THERE IS NO DETERMINATE DATE OF PUBLICATION, USE (N.D.) IN THE DATE FIELD. WHERE POSSIBLE, INCLUDE THE NAME OF THE ORGANIZATION HOSTING THE WEB SITE.

Examples: In the following example, the Cornell Chronicle is a regular newsletter which is published online. Thus, we follow the journal/magazine format and include the volume and issue. Steele, B. Look, Ma, no wires! Cornell class project tests wireless networking, Cornell Chronicle, 31 (35). Retrieved February 15, 2004, from Columbia University: http://www.news.cornell.edu/Chronicle/00/5.18.00/wireless_class.html. The following Web page has no evident author, but the Revised date in the footer gives us the date of publication. MIT Project Oxygen: Overview, 2004. Retrieved March 15, 2005, from Computer Science and Artificial Intelligence Laboratory, Massachusetts Institute of Technology: http://oxygen.lcs.mit.edu/Overview.html.

FOGG, B. J. (2003) Persuasive technology : using computers to change what we think and do, Amsterdam ; Boston, Morgan Kaufmann Publishers. MUELLER, F., AGAMANOLIS, S. & PICARD, R. (2003) Exertion interfaces: sports over a distance for social bonding and fun. Proceedings of the SIGCHI conference on Human factors in computing systems. Ft. Lauderdale, Florida, USA, ACM. 5.5 Technical Manual For those using the object-oriented methodology, kindly use the following CLASS DICTIONARY FORMAT for your technical manual. For each class that you have created: CLASS SUPERCLASS PROPERTIES 1. <property name> -- <purpose and constraint> 2. 3. METHODS 1. <method name> -- <description, parameters, result type, and constraint> 2. If you are creative enough, you may want to come up with your own table format. Just make sure that you have the minimum requirements outlined above for each class. The design and implementation issues of your class methods are discussed in the Design and Implementation chapter (which can include the pseudocode). There is no pseudocode needed in your Technical Manual, nor are you required to do IPO. For each function used from an existing library, kindly explain them in your Theoretical Framework chapter. You may also choose other tools, notations and diagrams that apply best to your development methodology if object-oriented methodology is not suitable.

5.6 Users Manual All software systems are required by the SOIT to have an ONLINE HELP and a USERS MANUAL. Most of the contents of the Users Manual are based from chapter 4 of the main project document (specifically on the system functions and features). The difference lies in the manner of presentation. Chapter 4 of the main project document is oriented towards highly technical systems designer, thus it gives an overview of the major modules of the system and their interactions. On the other hand, the Users Manual is oriented towards end users, who might be nave users. Therefore, it gives a detailed step-by-step instruction on how to use each function and feature of the system. The suggested outline of the Users Manual is as follows: Title Page (see Section xxx, but add the line USERS MANUAL below the project title) Table of Contents 1.0. Introduction This section gives an overview of the system. It includes the following subsections: 1.1. System Requirements This section lists the minimum hardware and software requirements needed to properly execute the system. 1.2. Installation This subsection contains instructions on how to install the system, and the list necessary files and their respective directories.

1.3. Convention This subsection presents the convention used in the manual, e.g., text in boldface for emphasis on important concepts, text in italics are inputs from the users, etc. 2.0. Getting Started This section tarts with instructions on how to run the system, and the initial screen that will be displayed. It then explains the major components of the system, e.g., tool bars, menu options, status bar, etc. 3.0. <Module / Feature 1> Succeeding sections, from 3.0 to N-1, focus on the major modules or features of the system. Each section contains detailed instructions on how to use the particular modules, the available features and limitations of the module. : N.0. Messages This section lists all system messages error message, status message, information, and instruction message that the user may encounter while using the system. For each message, include a brief description and the possible courses of action that the user may take in response to the message. Below is a sample format: <Message Text> Description: Action:

The messages must be arranged in ascending order, and may be grouped into subsections (e.g., N.1 Error Messages, N.2 Status Messages, etc.).

6. Forms
6.1 Title Page <Title of Project>

A Capstone Project [Proposal] Presented to the Faculty of the School of Information Technology Mapua Institute of Technology In Partial Fulfilment of the Requirements for the Degree of Bachelor of Science in Information Technology

by <lastname, firstname, middle initial of proponent> <lastname, firstname, middle initial of proponent> <lastname, firstname, middle initial of proponent>

<advisers name> Faculty Adviser <date of submission>

6.2 Approval Sheet Mapua Institute of Technology School of Information Technology This is to certify that I have supervised the preparation of and read the CAPSTONE document prepared by Name of Proponent 1, Name of Proponent 2, Name of Proponent 3 entitled title of the project and that the said document has been submitted for final examination by the Oral Examination Committee. _____________________ Name of Adviser Adviser As members of the Oral Examination Committee, we certify that we have examined this CAPSTONE document, presented before the committee on date of final defense, and hereby recommended that it

be accepted as fulfillment of the practicum requirement for the degree in Bachelor of Science in Information Technology.

______________________ Name of Panel Member 1 Designation

______________________ Name of Panel Member 2 Designation ______________________ Name of Lead Panel Designation

This CAPSTONE document is hereby approved and accepted by the School of Information Technology as fulfillment of the practicum requirement for the degree in Bachelor of Science in Information Technology.

___________________ Nilda S. Eliquen Associate Dean, School of IT

7.

Proposal/Final Defense Proponents Guidelines

The Defense Procedure (normally 1 hour) 1. Limit your presentation to 30 minutes (20 minutes presentation 10 minutes for demonstration/clarifications if any) 2. Normally the presentation contains the following:

Proposal introduction objectives scope and limitation significance review of literature methodology and schedule

2 minutes 4 minutes 4 minutes 4 minutes 2 minutes 4 minutes

Final brief introduction objectives scope and limitation design and implementation analysis of results project demonstration recommendations

1 minute 2 minutes 2 minutes 5 minutes 5 minutes 5 minutes 15 minutes 5 minutes

3. The panel will ask you to step out for initial deliberation (normally 10 minutes), after which you will be motioned back for questions and answers (normally 10 minutes).

4. The panel will ask you to step out for final deliberation (normally 5 minutes), after which you will be motioned back for the final verdict and your clarification of the verdict (normally 5 minutes).