Republic of the Philippines

President Ramon Magsaysay State University

(formerly Ramon Magsaysay Technological University)
San Marcelino Campus
San Marcelino, Zambales

College/Department College of Communication and Information Technology

Course Code THS 102
Course Title CS Thesis Writing
Place of the Course on Major
the Program
Semester & Academic First Semester, AY 2021 – 2022
Year

Introduction
WRITING THE DESIGN AND METHODOLOGY
In writing IT and IS capstone projects, CHED suggests that the methodology, results and
discussion be written under one title. However, the authors humbly suggest that the results and
discussion be provided under a separate chapter. Nonetheless, the following discussion will
guide the students what to write the design and methodology regardless of the capstone project
template they are using.
Intended Learning Outcomes
At the end of this module, the student is expected to:
- apply the appropriate method(s) in his research/ capstone project undertakings;
- determine information requirements;
- plan how to gather data considering time constraints;
- enumerate the software features of the proposed system software;
- describe in detail how the software will be designed; formulate the conceptual design,
IPO diagram, systems architecture, etc, of the proposed system;
- recall the different standards used in the software design and development;
- identify the most appropriate standard(s) to be applied in software designs; and
- outline the procedures in designing and developing the proposed system.
Discussion
The Methodology
Irny Suzila Ishak and Rose Alinda Alias (2005) defines methodology as a systematic,
theoretical analysis of the methods applied to a field of study that comprises the theoretical
analysis of the body of methods and principles associated with a branch of knowledge. Typically,
it encompasses concepts such as paradigm, theoretical model, phases and quantitative or
qualitative techniques.
A methodology does not set out to provide solutions – it is, therefore, not the same thing
as a method. Instead, it offers the theoretical underpinning for understanding which method, set
Module 4 - Page 1 of 15
of methods or so call “best practices” can be applied to specific case, for example, to calculate a
specific result.
The Methodology is the general research strategy that outlines the way in which a
research project is to be undertaken and, am 1 among other thin.gs, identifies the methods to be
used in it. These methods, described in -4 • the methodology, define w a specific result is to the
means and modes of data collection, or sometimes how a specific result is to be calculated.
In writing the methodology, the students are expected to apply there be calculated."
competencies gained in the courses "Application Development and Emerging Technologies'', -
systems Analysis and Design", among others. Thus, before designing the proposed systems the
proponent must first determine information requirements. Hence, under methodology is the
subsection, requirement analysis.
Demo
In the research entitled "iBantay: An Interactive Cross Platform imDemo methodology
proper (without other components) reads in part: Mobile Application For Open Government Data
Access'', the
METHODOLOGY
The study uses the new form of software development methodology known as the agile
methodology. This attempts to develop the system incrementally by building a series of
prototypes and constantly adjusting them to user requirements. It emphasizes continuous
feedback, and each incremental step is affected by what was learned in the prior steps of
development."
The authors would like to emphasize that in writing DESIGN AND METHODOLOGY,
students should NOT be required to choose from among the research methods we discussed
under Chapter 1 of this book, unless necessary. This is because thesis and capstone project
writing in computing is a culminating activity that generates an output useful in the development
of solutions. In so doing, what is involved is the integration and application of computing
knowledge. Simply stated, design and methodology in computing involves design of solution,
not just mere data collection. Thus, if at all, the students will gather data as in the case of an IT
and IS capstone project, the data gathered shall be used as input to the system design and
development. The data gathered cannot be used as basis where conclusions of study may be
drawn. This is to distinguish computing thesis/ capstone project from thesis in social sciences,
education and feasibility studies.
In the CHED's template for IT / IS Capstone project, there is an implied message that
capstone project always involves the descriptive method. This is because of the requirements
analysis and documentation which focuses on the present and prevailing condition of the
organization under study.
Be that as it may, our thesis / capstone project template must be flexible considering the
wide range of computing topics and the rapid and fast development of the field of computing.
Thus, if there is an additional method other than the descriptive method, we suggest that the
students / proponents expressly mentioned it at the beginning paragraph of the "design and
methodology". In this case, the research entitled, "An Alternative Prototype for Improving

Module 4 - Page 2 of 15
Windows' Method of Data Transmission for Copying and Moving Files" will serve as a good
example, thus:
Demo
METHODOLOGY
This study had undergone prototyping and experimental method. The prototype had to be
reviewed, redesigned and implemented before it undergoes an experimental test with our existing
Windows 7 default file transfer utility. The following subsections describe the concept and
designs of the prototype and how the experiment was conducted.
Beginning with the end in mind, please recall the part of the CHED's suggested template
for Methodology. Notice that under the IT and IS Capstone Project, CHED provides for specific
subsections for Methodology. However, as we stated at the beginning of this chapter, we
recommend, that Results and Discussion be included in Chapter IV.
CS Thesis (Foundations of CS Thesis (Software IT / IS Capstone Project
Computer Science) Development)

Proposed Solution to the Design and the Methodology  Methodology, Results and
Problem Discussion
 Requirement Analysis
 Requirements
Documentation
 Design of Software,
Systems, Product and/or
Processes
 Development and Testing,
where applicable
 Description of the
Prototype, where
applicable
 Implementation Plan
(lnfastructure/
Deployment) where
needed
 Implementation results,
where Applicable

Thus, out tour of discussions will initially cover the following topics. Thus, our tour of
 Requirement Analysis
 Requirements Documentation Systems, Product and/
 Design of Software, or Processes
 Development and Testing, where applicable. where Description of the Prototype,
applicable. Implementation Plan (Infrastructure / Deployment) where needed
 Implementation results, where applicable

Module 4 - Page 3 of 15
 As can be perceived from the above, the CHED's template itself, prepared by experts in
the IT industry and in the academe, reveals that in writing Chapter III (Design and
Methodology), there can be NO FIXED TEMPLATE. Notice that we highlight the phrase,
"where applicable", meaning to say, it may be or may not be necessary. There is MORE
FLEXIBILITY in writing Computer Science theses. So, do not be surprised if CHED did not
provide subsections for Design and Methodology for Computer Science involving software
development as well as for the Proposed Solution to the Problem involving foundations of
Computer Science.
Requirement Analysis
At the outset, the student-proponent should bear in mind that the proposed system or
software must pro p organization. Thus, the proponent must first with regard to the specific
organization under study. At this phase, the p who are proponent(s) needs to know the details of
the current system function: who (the people involved), what the business activity), where (the
environment in which the work takes), when (the timing), and how (how the current procedures
are performed) of the business or organization under study. The proponent must know and
analyze why the business uses the current system. There may be good reasons why the
organization is using the current methods, and these should be considered when designing the
proposed system.
The programmer, systems analyst, or software engineer, no matter how brilliant they are,
cannot design the software which will serve as computing solutions addressing the needs of a
particular organization unless they familiarized themselves how such organization perform their
business. So, if the student-proponent want to design a system that will automatically prepare
class schedules as well as faculty loads for a particular University, he needs to inter-vie the right
people and be knowledgeable on how to prepare class schedules an faculty teaching loads
without conflicts in room scheduling before he can be a to design programs that will accomplish
the same. After determining information requirements and the proponent strongly believes that
improvement may be done, he may propose the same to the organization under study. In order to
impress upon reader and most of all to the members of the panel of examiners that the
proponent(s) has already determine information requirements, a data flow diagram, should be
provided under this section as well as the organization's operational framework.
Demo
The following is a part of the Requirement Analysis of the capstone project'" entitled,
"An Online Payroll System with R3 Report Generator of SSS Employee Monitoring for Edcar
Manpower Services.

Module 4 - Page 4 of 15
 Edcar Manpower Services manages their salary of their employee through time card and
manually computing their salary_ After computing the salary. they also manually deduct benefits
like SSS and PAG-IBIG. Then the secretary submits the payroll to the company. Employees can
see their salary by going to the company. The reports of contribution on benefits are then
submitted to their respected offices.
The authors strongly suggest that a data flow diagram (DFD) be provided instead of the
flow which was depicted by the above figure.

Requirements Documentation
In some schools, Functional Requirements instead of requirement documentation is being
adopted. Thus, in the research entitled, Developing an Automated Student Academic Record

Module 4 - Page 5 of 15
Management with Business Intelligence Approach51 Prof. Maria Dara C. Saquin of DMC
College Foundation and Dr. Dave E. Marcial of Siliman University uses "functional
requirements" instead of "requirement documentation."
The following discussion will guide the students what to write under requirement
documentation or functional requirements. These terms are just the same. However, in this text,
we will be using requirement documentation.
Before the commencement of software design, requirement documentation must be
provided. This is a legal requirement in a real-life situation. Recall that one of the student
outcomes / program outcomes being fully addressed by this course is the "ability to recognize the
legal, social, ethical and professional issues involved in the utilization of computer technology
and be guided by the adoption of appropriate professional, ethical and legal practices." This
requirement documentation is NOT required in a computer science thesis involving foundation
of computer science.
In real life application, the requirement documentation establishes the basis for agreement
between the customers/client and the developers/programmers on what the software product is to
do. In capstone projects, this is the bases of the panel of examiners as well as the adviser(s) in
determining whether the prototype developed by the students will be accepted unconditionally,
accepted condition(s) or rejected.
Under this section, all software features are enumerated in details by providing story
board showing how the software would look like if the same was already designed and coded.
Requirements document states what the software will do. It does not state how the software will
do it. This is because requirement documentation is written both for the programmers and the
client. Hence, customers or clients can understand the requirements documentation if the
programmer / proponent will provide WHAT the software will do. Therefore, the requirements
documentation does not include database schemas, normalization of tables, system architectures,
descriptions of communication layers - in short, no statements of design of any sort. The answer
to the question "HOW the software will do" or statement of design shall be addressed under
results and discussion.
Berezon (1994) provides a good example; it is a requirement for a word processing
application to be able to open an existing file. It is a design issue whether to build a customized
file selection tool or use a platform- standard file selection tool. The requirements document
brings the following additional benefits:
 the customers can see early on if their needs will be met
 the developers can estimate the effort involved in creating the application
 the development project leader has a basis for a project plan
 the quality assurance people have a basis for testing the application
Obviously, the proponent will need data gathering tools in preparing his requirements
analysis and documentation.
The following is a part of the Requirement Documentation of the capstone projects
entitled, 'An Online Payroll System with R3 Report Generator of SSS and Employee Monitoring
for Edcar Manpower Services."

Module 4 - Page 6 of 15
Demo
REQUIREMENT DOCUMENTATION
Project In-Scope and-Out-Scope
In-scope
 Account Module
This module will utilize an employee management that makes adding, editing and
deleting of employees. The system also shows details of the employee such as "active", and
"inactive", among others.
- Payroll Module
This module will create a reliable and accurate payroll system that will generate
report based on different primary keys such as employee, dates, etc. The report may include
at the option of the users the following SSS contributions, PhilHealth, Union dues,
PAGIBIG, Loan payment, among others.
- File Archive Mode
This module will provide a data file archive that allows backing up of files and data
records that can be exported from the database.
Design of Software, Systems, Product and/or Processes
Simply stated, under Design of Software, System" Product and/or Processes, the
proponents shall describe in detail how he will design the proposed system in accordance with
standards. The authors, in order to simplify the distinction between between Computer Science
theses and IT/IS the distinction the proponent(s) shall describe in detail how he Will in
accordance with standards. The authors, in order to simplify strongly suggests Capstone projects
that the "Design and Methodology" provided by CHED for Computer Science involving
software development and "Design of Software, Systems, Product and/ or Processes" provided
by CHED for IT/IS capstone projects should. be given the same name, say, Design and
Methodology. The only difference is- that, the requirement analysis and requirement
documentation shall not be required for computer science theses regardless of the topic. As to the
contents of the Design and Methodology in computer science, focus should be given on the
technical ' aspects of the software to be developed in a way that demonstrates comprehension of
the tradeoffs involved in design choices. For Design of Software, Systems, Product and/or
Processes focus should be given on how the requirements analysis, has been complied with
especially those possible trade and documentation have been under various constraints. - offs
presented within the given requirements. In this manner, graduate attributes or program
outcomes or student outcomes of each program will be properly addressed.
So, a responsible thesis or capstone project adviser or panelists may require the
proponents to include in this Chapter, among others, conceptual design, data models, systems
architecture, and block diagrams. This is because most of the time, students are good in giving
the characteristics of an imagined software in its finished form only to realize, during thesis II or
Module 4 - Page 7 of 15
capstone project II, that he had no idea how to design the code to arrive at the desired results.
The conceptual design, Input Process Output (IPO) Diagram and systems architecture will show
that the students have an idea on how to identify, formulate and solve computing problems.

In a thesis entitled, "Flip: A Word Formation Android Game Utilizing Speech Recognition
Using Google Speech API Dem and Pocket sphinx with Two Player Time-Attack Mode via
Bluetooth" parts of the design methodology reads:
"After the purpose and specifications of the application are determined, the development
team will design or employ a plan for the computing solution. This includes low-level
component and algorithm implementation issues as well as the architectural view.
In this stage, the preparation of the logical design, the physical design and the user
interface design will be carried out. 'There is also the functional and non-functional requirements
which will be transformed into diagrams and charts.
The system architecture of Flip is shown in Figure 2. The architecture is divided into two
parts: the online and offline versions. The proposed application will accept user inputs through
the use of microphone for accepting speech input; accelerometer device for the jumbling of
letters to see them in a different way; and touch screen for the navigation through the game. For
accepting speech inputs, the Google Speech API will be utilized for the online version while the
of version makes use of Pocketsphinx, an open-source library recognition. The audio and video
cards are used for the output processes aided by the ADT Plugin.
The random picking of words from the database will be done by the Fisher-Yates
Algorithm because the application requires different set of words every game session without
repetition.

Module 4 - Page 8 of 15
 Aside from the System Architecture an Input Process Output (IPO) chart may be
provided if applicable.
The figure on the page is a sample Input Process Output (IPO) chart involving the same
thesis title.

Module 4 - Page 9 of 15
 The Input Process Output (IPO) diagram of “Flip. A voice-activated word formation
android game” is shown on Figure 1. In order to conceptualize the idea of this study, the
researchers make use of the related studies and related literatures for further knowledge about
the study itself.

Development and Testing

Most thesis and capstone project advisers and examiners had an opinion that this
subsection "Development and Testing" may be incorporated in the subsection "Design of
Software, Systems, Product and/or Processes." We also subscribed to that opinion. However,
since we introduced in this text the relevance of requiring computing students to:
apply mathematical foundations, algorithmic principles, and computer science theory in
the modeling and design of computer-based systems in a way that demonstrates
comprehension of the tradeoffs involved in design choices (Computer Science)
Module 4 - Page 10 of 15
 or
design information systems in terms of general quality attributes and possible trade- offs
presented within the given requirements (Information Systems)
or
design computer-based systems, processes, components, or programs to meet desired
needs and requirements under various constraints (Information Technology & BSEMC);
The authors therefore strongly suggest that the standards to be used in software
development as well as how it will be tested should be included under this subsection. This will
enable computing students to comply with international standards.
After all, higher educational institutions envision their graduates to be globally
competitive few years after graduation. In Chapter III, under the subtitle "Development and
Testing", standards to be used and tradeoffs involved in the design choices shall be discussed in
synopsis only because the detailed discussion of its actual application and how the researchers or
designers finally come up with the final design shall be discussed in Chapter IV - Results and
Discussion.
Illustration of making mention of Standards and Tradeoffs involved.
"In designing, developing and evaluating the proposed Scheduling Expert System, the
proponents shall be using the ISO 9126-1 software quality model. ISO 9126 is an international
standard for the evaluation of software. It identifies 6 main quality characteristics, namely: 1)
Functionality; 2) Reliability; 3) Usability; 4) Efficiency; 5) Maintainability and 6). Portability."
Thus, in order to ensure that the software conforms with the standard, it should be
evaluated by IT Experts. Therefore, the data analysis plan should be included under this
subsection. The following is an example of a data analysis plan.
In the dissertation entitled, "Towards e-Governance and Bridging the Digital Divide: A
study on the Acceptability of Multipurpose Community Information and Telecenter (MCIT)
Prototype by Barangays in selected Municipalities", the data analysis plan was written in this
wise:
The actual application and results of this evaluation shall be discussed lengthily in
Chapter IV - Results and Discussion
Standards and tradeoffs will be discussed in the next chapter.
The Implementation Plan
The implementation Plan describes how the information system will be deployed,
installed and transitioned into an operational system. The plan overview of the system, a brief
description of the major tasks involved in the implementation, the overall resources needed to
support the implementation effort such as hardware, software. facilities, materials, and
personnel), and any site-specific implementation requirements.'
For practical reason, although an implementation plan is relevant in real applications, it
would be impractical for the students to include in the scope of their capstone project, the
implementation of the software product which they have developed, unless, the implementation
Module 4 - Page 11 of 15
is the main objective of the capstone project. This is possible if the software had been developed
and the main objective is to effectively integrate IT-based solutions into the user environment
and/or to deploy and use tools and techniques necessary for IS practice.
Nevertheless, it is under the discretion of the students and his adviser whether or not to
include the implementation plan in the scope of his project. If the capstone project already
involves design, development and evaluation of computing solution, the implementation plan
may not be required.
In the work entitled "Mindoro State College of Agriculture and Technology Online
Student Information and Fine Monitoring System Using Radio Frequency Identification Card
Technology"" the summarized version of the implementation plan reads:
3.9.4 Implementation Plan
The developed system will be sent to MinSCAT right away after the revision to present it
once more to the expected users. If the institution wants to adopt the system, the researchers will
hand over the system together with its documentation. It will serve as aguide to the
administrator who will be assigned for the system's update and maintenance. There Would be a
letter of agreement that the system will be handed over to the institution freely and the
researchers is no longer responsible for its update and maintenance. If the system Will be below.
implemented, the researchers will conduct several strategies. Those strategies are presented
below.

Table 5 Implementation Plan

STRATEGY ACTIVITIES PERSONS DURATION
INVOLVED
Approval from the
Letters for the Researchers
MinSCAT 1 Day
Administrator Administrator
Administrator
Installation of the
system and required Researchers
Systems Installation 5 Hours
software and Administrator
hardware
Administrator
Flyers
Students
Information Administrator
Posters 1 Day
Distribution Student
Administrator
Manuals
Student
Hands on Training Administrator
3 Day Training 1 Day
and Lectures Officers and Students

Computer Science Thesis Covering Computer Science Foundation

In Computer Science thesis dealing with Computer Science foundation, requirement
analysis and documentation is not applicable because these research problems do not deal with
business organizations. Instead, Chapter III of a thesis dealing with Computer Science
foundation must include under Chapter III a portion which contains the Proposed Solution to the
Module 4 - Page 12 of 15
Problem. Recall that a thesis is a technical report on a systematic investigation of a problem that
can be solved using Computing. It may include a solution, an approximate partial solution, a
scientific investigation, or the development of results leading to the solution of the problem.
Hence, the proposed solution to the problem outlines your proponent's solution to the specific
problem described in Chapter 1. The solution may be an original solution, absolute solution,
partial solution, an extension to, an improvement of, or even a disproof of someone else's theory,
solution or method.
To the mind of the authors, the absence of specific subsection of "DESIGN AND
METHODOLOGY" as well as that of "PROPOSED SOLUTION TO THE PROBLEM" for
Computer Science theses is an indication that HEIs are very much at liberty to include what they
think is appropriate.
In a Computer Science thesis entitled, "A FRAMEWORK DESIGN AND
INSTANTIATION METHOD ABSTRACT" by Marcus Fontoura (1998), the problem
description and the proposed solution was presented in this wise:
PROBLEM DESCRIPTION
There are various application areas that are not established yet and for which new ideas
and models are presently under development and evaluation. These are domains in which the
possibility of rapidly building new applications is essential and strategic from a practical point
of view. Examples of application domains that can he classified in this category include Web-
based Education, electronic commerce, biology, and financial market.
An interesting strategy for developing new applications for these domains is the
development of object-oriented application frameworks. Frameworks can reduce the costs of
developing applications since it allows designers and implementers to reuse their previous
experience with problem solving at the design and code levels. Prior research has shown that
high levels of software reuse can be achieved through the use of. object-oriented frameworks. An
object-oriented framework captures the common aspects of a family of applications, which can
be seen as a domain theory.
Although object-oriented software development has experienced the benefits of using
frameworks, a thorough understanding of how to identify, design, implement, and change them
to meet evolving requirement needs is still object of research. Techniques such as design
patterns, meta-object protocol, refactoring, and class reorganization have been proposed to
support framework development acid cope with some of the challenges.
Therefore, framework development is vent expensive not only because of the intrinsic
difficulty related to capturing the domain theory but also because of the lack of appropriate
methods and techniques to support framework specification and design.
PROPOSED SOLUTION
This dissertation proposes a new method for object-oriented framework design and
instantiation.
In Roberts and Johnson (1997) states that "Developing reusable frameworks cannot
occur by simply sitting down and thinking about the problem domain. No one has the insight to
come up with the proper abstractions." They propose the development of concrete examples in
Module 4 - Page 13 of 15
order to understand the domain. The design strategy presented here is quite framework from the
analysis of these viewpoints. similar, analyzing concrete applications as viewpoints of a domain
and deriving the final framework from the analysis of these viewpoints.
The approach to framework design is based on the idea that any design can be divided
into two parts: the kernel sub-system design and the hot-spot sub-system design. The kernel sub-
system design is common to all the applications that the framework may generate, and the hot-
spot sub-system design describes the different characteristics of each application that can be
supported by the framework. The hot-spot sub-system uses the method and the information
provided by the kernel sub-system and may extend it.
The kernel structure is defined by analyzing the viewpoints design representations to
produce a resulting design representation that reflects a structure that 15 common to all chosen
viewpoints. This part of the design approach is based on a domain-dependent semantic analysis
of the design diagrams to elicit the common features of the framework design structure, and is
formally described in this dissertation.
The elements that are not in the kernel are the ones that vary for each application, and
depend on the use of the framework. These elements define the framework hot-spots that must he
adapted to each related application. We defined new relationship in object-oriented design,
called the hot-spot relationship, to specify all the hot-spots in the system.
The semantics of this new relationship is given by the design patterns essentials. This
implies that the hotspot relationship is in fact a meta-relationship that is implemented through a
design pattern that is generated taking into account the hot-spot flexibility requirements. The
hot-spot cards guide this generation process, providing a systematic way for generating design
patterns based on flexibility properties.
The most common way to instantiate a framework is to inherit from some abstract classes
defined in the framework hierarchy and write the code that is called by the framework itself
However, it is not always easy to identify which code and where it should be written since
frameworks class hierarchies can be very complex, especially for non-expert users.
Therefore, the "common" instantiation process is not always the ideal way to describe a
particular application. This happens because of several facts:
1. The language used to build and use the framework is a wide spectrum
language, where it is not always easy to express the user intentions;
2. The complexity of framework class hierarchies and the difficulty of finding the
points where the code should be written, that are the framework hot-spots or flexible
points.
The instantiation method proposes a different process, where a particular application is
described by domain specific languages (DSLs) that are designed precisely for the framework
domain. In this way, the technique basic idea is to capture domain concepts in a DSL, which will
help the framework user to build code in an easier way, without worrying about implementation
decisions and remaining focused on the problem domain. The specification written in the DSL is
translated to the framework instantiation code through the use of transformational systems.

Module 4 - Page 14 of 15
Activity
A. In computer science theses, requirement analysis is a primordial requirement. Please
explain why do not agree.
Exercises
B. . Please formulate your Input Process Output (IPO) diagram and give explanation.
Reflection
C. In a capstone project under requirement documentation, the report should contain
how the program works. Please explain why you do not agree.

*** Disclaimer: We do not take ownership of any Intellectual Property that is included in this
module. All rights belong to their rightful owner. Books, Websites and other learning materials
referred to this module is properly cited in the references section at every module. ***

Suggested Readings, Resources and Additional Resources

 Charlemagne Garcia Laviña, Renelina Delmo Mañabo, Gloria Dela Cruz Hernandez, Fe
Larwa Hablanida, Alice Maldonado Lacorte, Jonalyn Gaza – Ebron. Outcomes-based
Practical Guide to Thesis and Capstone Project Writing in Computing. Mindshapers Co.,
Inc. 2016.

Prepared by

ACE RYAN A. LABAMPA

Module 4 - Page 15 of 15