Final Year Project Report Guidebook

2022-2023

DEPARTMENT OF SOFTWARE ENGINEERING

Sir Syed University of Engineering and Technology

i
Chapter 1

Introduction
Your introduction is mostly written for non-specialists, and it should include following
sections:

1.1 Overview
Your overview is the first part of the introduction of your FYP reports. It explains the
immediate context of the problem you want to solve, tells the reader why the project area is
important and identifies your motivation for solving the problem. “Problem Statement”

1.2 Problem statement

 What problem does your software solve?
 Why are you developing this system?
 Does the same system already exist? If yes, how will a re-implementation aid your
learning?

1.3 Objectives
Your objectives are what you want to accomplish in this project or your purpose for doing the
project. In this section, you need to state in general terms how you plan to accomplish your
goals.

• What do you plan to discover or prove?

• What kind of problem are you working on?

• Why are you working on this problem?

• If the problem was assigned, why do you think your advisor assigned this particular
problem; what are you supposed to learn from working on it?

• What should readers know or understand when they are finished reading your report?

1.4 System Features

• The most important feature of the project is that user will be able to interact with the
...

• One of the key features will be the tracking of all the moves made by the user through ...

1
 • Eye tracking sensor helps to monitor the ...

• Voice recognition will provide more control to the users....

• An interactive virtual environment with realistic graphics will ....

1.5 Project scope

Provide a short description of the software being specified and its purpose. You might provide
a high-level summary of the major features the software contains or the significant functions
that it performs.
According to the Project Management Institute, a strong project scope statement has several
key characteristics. It should:
 Define the boundaries of the project.
 Define the business need and the expected outcome of the project.
 Identify constraints that limit a project team’s options for developing a solution.
 List assumptions regarding decisions outside the project team’s control.
 Identify business processes impacted by the project.
 Identify internal and external entities with which the project team will interface.

1.6 Chapter Summary

This section should contain a summary of your current chapter.

2
Chapter 2

Literature Review
The SSUET SED requires that you include a Literature Survey or Critical Review in the final
reports.

NOTE: For this section, paragraph is needed and the below points are just for their
guidance.

The value of a Literature Survey

1. It shows that you not only understand what you have done, but you understand what
others have done related to your subject - the broader context. If you can tell people
about what research has already been done and what methods already exist, then your
readers will think that at least you are interested in your topic, have some self-initiative
and are informed and up-to-date [1].

2. It shows that you are intelligent enough to evaluate the quality of the other work done
on the subject, i.e., it shows that you are capable of thinking critically [2] and identifying
strengths and weakness [3].

3. It gives you opportunity to tell how your project is related to previous work done by
others on the subject.

4. It tells the reader if you are simply going to duplicate others’ work for the sake of gaining
a better understanding, improve upon others’ work [3, 4] or perhaps combine the
methodology of two or more existing approaches to solving a problem.

Tips for Writing a Literature Survey

1. BE A HUNTER! Go online [5] and search for articles, books and papers related to your
subject. Be creative and persistent in your keyword search until you hunt down good
references or examples.

2. Ask your advisor for recommendations (but don’t totally rely only on these!) When you
read some literature that you think is useful and related, first record the citation on your
list of references, using the IEEE Citation Style [6].

3. When you read some literature that is not very useful, do not include it on your list of
references. More references [7] do not mean a better list of references. Useless
references only confuse a careful reader and make you lose credibility.

4. In each document, identify the approach(es)/method(s) [8] for solving problem(s), and
compare this/these with what you already know.

3
5. Identify which approaches and/or methods you will use and omit in your FYP [9].

6. After you feel satisfied that you know all or most of the existing approaches/methods,
for each one:

• List out all the approaches/methods, [10] in a logical sequence (perhaps in

chronological order), including both those you will use and those you will omit
• For each approach/method:
– Describe how it works and what its components are
– Tell what kinds of problems it is good at solving
– Tell what kinds of problems it is poor or limited at solving
– Mention other strengths and/or weakness of each approach
– Tell if you will use or omit the approach for your FYP and why or why not

4
Chapter 3

Design

For Design, think about visualization of design:

• What does the system look like?

• What are the hardware and software components, and how do they relate to each other?

• What kinds of functions can different kinds of users perform and in what sequence can
or should they perform them?

• What does the data look like that is used for input, and do you need to do anything to it
before processing it?

• What does the output information look (or sound) like? (If you have a lot of screen shots,
it might be best to put them in an appendix.)

• What elements of the user interface (UI) make it user-friendly and/or facilitate a good
user experience (UX)?

• Include System Block Diagram if applicable.

• Include Modular System Block Diagram if applicable.

3.1 Design methodology and Software Process Model

Explain and justify the choice of design methodology being followed. Design methodologies
may include Structured Design, Function Oriented Design, Object Oriented Design, Level
Oriented Design etc. Also explain which process model you are following and why?

3.2 Architectural design / Design Patterns

 Develop a modular program structure and explain the relationships between the
modules to achieve the complete functionality of the system. This is a high-level
overview of how the system’s modules collaborate with each other in order to achieve
the desired functionality.
 Don’t go into too much detail about the individual subsystems. The main purpose is to
gain a general understanding of how and why the system was decomposed, and how
the individual parts work together.

5
  Provide a diagram showing the major subsystems and their connections. Use a simple
Line and Box Diagram for simpler systems and detailed diagrams (MVC, Client-Server,
Layered, Multi-tiered) for complex systems.

3.3 Process flow/Representation

 Provide a representation of the flow of major processes of your system in the form of
an activity diagram.
 Do not create activity diagrams for login or signup unless they involve significant
complexity.
 Only include major processes.

3.4 Design models [along with descriptions]

The applicable models may include:
 Class Diagram
 Sequence Diagram
 State Transition Diagram
 Data Flow Diagram

You should be clear about all the concepts used in your diagrams for example for class diagram
you should know about aggregation, composition, and inheritance/generalization. Also ensure
visibility of all diagrams.
Class diagram and associated models shall only be necessary for object-oriented approach. In
case of procedural, create a DFD. Data flow diagram should be extended to 2-3 levels. It should
clearly list all processes, their sources/sinks and data stores.
Note: System design should be complete in all aspects. Create any/all diagrams if you need to.
A DFD can also be supplemented by a State Transition Diagram depending on the nature of the
project.

3.5 Data design

Explain how the information domain of your system is transformed into data structures.
Describe how the major data or system entities are stored, processed and organized. List any
databases or data storage items.

6
3.6 Data dictionary
Alphabetically list the system entities or major data along with their types and descriptions. If
you provided a functional description, list all the functions and function parameters. If you
provided an OO description, list the objects and its attributes, methods and method
parameters.

3.7 Chapter Summary

7
Chapter 4

System Development

For Implementation, think about HOW you did it and HOW you
applied your software engineering skills

• What data, coding tools, development kits, IDE, libraries and APIs did you use, and where
did you get them?

• How did you set up the server (if your system has one)?

• How did you build your database, and how is it updated?

• What important steps did you follow as you built the system, performed experiments or
recorded data?

• What cool or creative ideas did you come up with?

• What were the most difficult parts of building the system or solving your problem, why
were they difficult and what steps did you take to try to overcome them?

• What assistance did you seek from your advisor or other knowledgeable people?

8
Chapter 5

Testing

Software testing is the process of evaluating and verifying that a software product or
application does what it is supposed to do. The benefits of testing include preventing bugs,
reducing development costs and improving performance.

5.1 MANUAL TESTING

The purpose of Manual Testing is to identify the bugs, issues, and defects in the software
application. Manual software testing is the most primitive technique of all testing types and it
helps to find critical bugs in the software application.
Once the system has been successfully developed, testing has to be performed to ensure that
the system is working as intended. This is also to check that the system meets the requirements
stated earlier. Besides that, system testing will help in finding the errors that may be hidden
from the user.

5.1.1 Unit Testing

Unit testing is a type of software testing where individual units or components of a software
are tested. The purpose is to validate that each unit of the software code performs as expected.
A unit may be an individual function, method, procedure, module, or object.
Template for unit testing:
Unit testing 1: [Title e.g. Changing Username]
Test Case ID Enter a unique numeric identifier. E.g. Test Case 01
Test Case Name Describe objective of your Test case.
e.g. To check whether user can update their Username.
Test Priority Medium
Hardware Any hardware used in the project
Required: e.g. A Computer device with Internet facility

Software Any Software used in the project

Required: e.g. A Web Browser preferably (Chrome, Firefox and IE
latest versions), mobile platform etc.
Duration: Date (when you test the app)
Pre-condition 1. User is logged in to application interface.
2. User has active internet connection.

Test ID Test Test Test data Expected Actual Status

Description Step Result Result (Pass/Fail)
(If
different

9
 from
expected)
1 User types in Step1: Alphabets: Characters Pass
new open abcdefg the user is
username in URL Numbers:00000 typing
text box Step2:… Special should
Characters: appear in the
#$%^&#@ text box
2 User presses A prompt Pass
‘confirm’ informs the
button user their
username
has been
successfully
updated.
Test Case Status: Pass

5.1.2 Integration Testing

Testing of all integrated modules to verify the combined functionality after integration is
termed as Integration Testing.
Template for integration testing:
No Test Case Test Data Expected Actual Result Status
Result (If different (Pass/Fail)
from
expected)
1. Login as supervisor Username: Login - Pass
L001 successful
Password: and the FYP
1234 Committee
page with its
navigation
bar is loaded
and in the
view profile
page
2. Upload student record - File - Pass
for Project 1 successfully
uploaded and
return to the
upload page.
Student
records are
updated.
3. View supervising student - The list of The Fail
supervisees application
shown on the does not
screen. respond, and
list is not
shown.

10
 Test Case Status: Fail

5.2 AUTOMATION TESTING

Automation testing is a form of software testing that compares the actual result to the intended
result. This can be accomplished using test scripts or other automated testing tool. Automating
repeated processes and other testing duties that are difficult to complete manually is what test
automation is for.
Following Automation test strategy should be kept in mind to ensure that your software testing
is successful:
1. Decide what Test Cases to Automate
2. Select the Right Automated Testing Tool
3. Divide your Automated Testing Efforts
4. Create Good, Quality Test Data
5. Create Automated Tests that are Resistant to Changes in the UI
Tools that can be used for automation testing are Selenium, Appium, Test Complete, Test
Studio, Silk Test etc.
Following information should be mentioned if automation testing is done in your project:
No Name of tools Test Modules Test Script Framework Test
Description Automated reference. Used (if any) Report
(for each
tested web
form/page)

Class,
1 a) Selenium Method, Unittest/
(Webdriver Login Page Automating Constructor, Pytest/
or IDE) OR as Username file name or Testng/ Pass
b) Selenium supervisor and any script Junit/
with password reference POM/
Python/Java
for login BDD
OR
c) Cypress.io
OR Mention Class, Unittest/
d) Any Other Page name Automating Method, Pytest/
Automation i.e. Upload field Constructor, Testng/ Fail
2 Tool Registration file name or Junit/
page etc. any script POM/
reference BDD

Attach Automation Scripts here with test Report.

11
Chapter 6
Performance Evaluation
To study about the capacity of our application, we performed some experiments by examining
....

• Narrate your findings

• The best way to use the results section is to show the most relevant information in the
form of graphs, figures and tables.

• Be sure to include negative results - writing a results section without them not only
invalidate it, but it is extremely bad science. The negative results, and how you handle
them, often gives you the makings of a great discussion section, so do not be afraid to
highlight them.

Comparison of different datasets are shown in Table 6.1 and 6.2

Table 6.1: Comparison of different datasets

Dataset Precision Accuracy Recall TNR
TUM 0.625 0.8854 0.6666 0.9259
UCF 0.7 .8 0.7 1
TUH 0.9 0.95 0.9 1
Table 6.2: Quality Measures
Dataset Precision Accuracy Recall TNR
UCF S H A H
UCF E E N A
TUH N O O R

12
 Figure 6.1: Summarization of ...

(a) Subfigures (b) Another (c) Another Comparison

Figure 6.2: Comparison is done in ....

13
Chapter 7

Business Model
Developing a successful software product, business model requires a strategic approach that
takes into consideration various factors, including market demand, competition, revenue
streams, and scalability. The step-by-step guide for creating an internationally recognized
software product business model that can be effectively integrated into your final year project
report:
7.1 Market Research
 Identify a Niche:
o Determine a specific niche or problem your software product aims to solve.
o Analyze market trends and identify potential gaps or underserved areas.
 Business Clients
o Identify the business clients who will use the systems.
 Competitor Analysis:
o Research existing solutions in the market.
o Identify their strengths, weaknesses, opportunities, and threats (SWOT analysis).

7.2 Unique Value Proposition (UVP)

 Define UVP:
o Clearly articulate the unique value your software product brings to users.
o Highlight what sets your product apart from competitors.

7.3 Target Audience

 Customer Segmentation:
o Identify and define your target audience.
o Understand their needs, preferences, and pain points.
 User Personas:
o Create detailed user personas to guide product development and marketing strategies.

7.4 Monetization Strategy

 Revenue Streams:
o Explore different revenue models (subscription, freemium, one-time purchase).
o Consider partnerships, licensing, or affiliate programs.

7.5 Scalability and Internationalization

 Scalability Plan:
o Design the software architecture to handle growth.
o Consider cloud services and scalability frameworks.
 Internationalization:
o Ensure your software can be easily adapted to different languages and cultural contexts.
o Plan for global marketing and support strategies.

7.6 Marketing and Branding

 Brand Identity:
o Develop a strong and memorable brand identity.
o Consistent branding across all channels.

14
  Marketing Channels:
o Utilize digital marketing, social media, and content marketing.
o Consider influencer partnerships and community building.

7.7 Propose Business Plan

7.8 Integration with Final Year Project

 Project Alignment:
o Clearly demonstrate how your final year project aligns with the business model.
o Showcase how your project addresses market needs.
 Implementation Details:
o Provide technical details on how the software product was developed.
o Discuss challenges faced and innovative solutions implemented.
 Market Experience:
o Discuss any real-world testing, user feedback, or iterations made based on market
experience.

7.9 Future Roadmap

 Future Development:
o Outline a roadmap for future product development.
o Incorporate emerging technologies and industry trends.
 Adaptability:
o Showcase the adaptability of your business model to changing market conditions.

7.10 Financial Projections

15
  Financial Modeling:
o Provide realistic financial projections, including revenue, expenses, and profit margins.
o Consider a break-even analysis and return on investment (ROI).

7.11 Legal Considerations

 Intellectual Property:
o Discuss any patents, trademarks, or copyrights associated with the software.
o Address legal considerations for international markets.

By following these steps, you can create a comprehensive business model that not only
positions your software product for international recognition but also integrates effectively
with your final year project report, showcasing a blend of theoretical knowledge and practical
market experience.

Example for the Propose Business Plan

 Example : Online Parking Payment

16
Chapter 8

Future Directions and Conclusion

In this section, you summarize the major technical accomplishments of the project and suggest
areas for future research and analysis. Focus on:

• The key things you did and learned

• Problems not addressed in your report

• Questions that were not answered in your report

• What techniques or algorithms or tools might be useful for further development?

The Conclusions section doesn’t need to be long. One page may be enough.

17
Appendix A-User Manual
User Manual is a technical communication document intended to give assistance to people
using a particular system. Sample is given below.

Getting Started
Learning about ....

Using Samsung Gear VR

1. Press the Phone Lock key to release the latch and raise it upwards.

2. In a single motion, carefully insert the mobile device (face down) at an angle and insert
the Gear VR connector (1) into the mobile device’s MicroUSB port. This process is similar
to installing the mobile device into a standard charging port. Ensure that the connector
is fully inserted into the mobile device’s multipurpose jack.
Once securely connected, carefully push the opposite end of the mobile device downwards (2)
until the Phone Lock latch snaps onto the mobile device and holds it in place against the lenses.

3. After connecting the mobile device and the Gear VR, you can wear the Gear VR.

Basic Navigation and Selection

Moving the On-Screen Pointer

18
 Making a Selection

Control Configuration

Activities PS4 Buttons

Fire PS4 Square

Reload PS4 Cross

Interact/Pickup/Drop Objects PS4 Cross

Back PS4 Triangle

Appendix B- Software Requirement

Specification (SRS)
Attach your Current/Revised SRS Document.

Appendix C – Dissemination Activity

Detail of Conference
• Details of Conference in which paper got accepted.

• A student must have a minimum of 1 research paper published/accepted for publication

in an International Conference of repute.

• Only those publication(s) related to the project work will be counted in which the
student’s name is that of the 1st, 2nd, 3rd and 4th author and supervisor as 5th author
and clearly mention student affiliation with Sir Syed University of Engineering &
Technology. Other than this, no other author is allowed in that research paper. FYPC is
the final authority on determining whether the research publication meets the
prescribed standards and requirements.

19
 • Attached your paper.

• Attached your pictures of the event.

Details of Competition
• Details of Competition in which you have applied (if any).

• Attached your pictures of the event.

Appendix D- Marketing/ Promotional

Material

Poster
Figure 8.1 shows the poster of the project.

Figure 8.1: Poster of TITLE

20
 Appendix A

Standee
Figure 8.2 shows the standee of the project.

Figure 8.2: Standee of TITLE

21
 Appendix A

Brochure
Figure 8.3 shows the front side of the brochure.

Figure 8.3: Brochure of Title of Project - Front

Figure 8.4 shows the back side of the brochure.

22
 Appendix A

Figure 8.4: Brochure of Title - Back

23
References
[1] Hao Xia , Yanyou Qiao, Jun Jian and Yuanfei Chang, “Using Smart Phone Sensors to Detect Transportation
Modes,” Sensors 2014, Available: http://dx.doi.org/10.3390/s141120843
[2] Ozlem Durmaz Incel, Mustafa Kose and Cem Ersoy, “A Review and Taxonomy of Activity Recognition on
Mobile Phones,” BioNanoSci. (2013) 3: 145. Available: http://dx.doi.org/10.1007/s12668-013-0088-3
[3] Muhammad Shoaib, Hans Scholten and P. J. M. Havinga, “Towards Physical Activity Recognition Using
Smartphone Sensors,” 2013 IEEE 10th International Conference on Ubiquitous Intelligence and Computing
and 2013 IEEE 10th International Conference on Autonomic and Trusted Computing, Vietri sul Mere, 2013,
pp. 80-87. Available: http://dx.doi.org/10.1109/UIC-ATC.2013.43
[4] Wanmin Wu, Sanjoy Dasgupta, Ernesto E. Ramirez, Carlyn Peterson and Gregory J. Norman, “Classification
Accuracies of Physical Activities Using Smartphone Motion Sensors,” in Journal of Medical Internet
Research, 2012. Available:http://dl.acm.org/citation.cfm?id=2071458
[5] Wolfgang Hu¨rst and Matthias Helder, “Mobile 3D Graphics and Virtual Reality Interaction,” in ACE ’11
Proceedings of the 8th International Conference on Advances in Computer Entertainment Technology (ACM
New York, 2011), Article No. 28. Available:http://dx.doi.org/10.2196/jmir.2208
[6] Takeo Kanade, “First-person, inside-out vision,” Keynote speech, Proceedings of 2009 IEEE Computer Vision
and Pattern Recognition Workshops: 1st Workshop on Egocentric Vision (CVPR’09), 2009.
[7] Akihiro Tsukada, Motoki Shino, Michael Devyver and Takeo Kanade, “Illumination-Free Gaze Estimation
Method for First-Person Vision Wearable Device,” 2011 IEEE International Conference on Computer Vision
Workshops (ICCV Workshops), Barcelona, 2011, pp. 2084-2091. Available:
http://dx.doi.org/10.1109/ICCVW.2011.6130505
[8] Narc´ıs Pares and David Altimira, “Analyzing the Adequacy of Interaction Paradigms in Artificial Reality
Experiences,” Human-Computer Interaction, Vol. 28, March, 2013.
[9] Mi Zhang and Alexander A. Sawchuk, “USC-HAD: a daily activity dataset for ubiquitous activity recognition
using wearable sensors,” in UbiComp ’12 Proceedings of the 2012 ACM Conference on Ubiquitous Computing
(ACM New York, 2012), pp. 1036-1043. Available: http://dl.acm.org/citation.cfm?id=2370438
[10] Felicity Allen, Eliathamby Ambikairajah, Nigel H Lovell and Branko G Celler, “Classification of a known
sequence of motions and postures from accelerometry data using adapted Gaussian mixture models”
Physiological Measurement, Vol. 27, 2006. Available: http://dx.doi.org/10.1088/0967-3334/27/10/001