Mark Bauer Final Presentation for Senior Engineering Project Spring 2023

1. SE494-Final Presentation
Genfare Code Configurator
Group 4
Stanley Chang, David Rodriguez,
Mark Bauer, Seonggeun Cho
1

2. Team Introduction
Stanley Chang Mark Bauer
David Rodriguez Seonggeun Cho
2

3. Overview 1. Project Introduction
2. Analysis of Current Configurator
3. Solution Research
4. Proposed Solution
5. Project Development Goals
6. Final Deliverable
7. Unit/Efficiency Testing
8. Conclusion & Recommendations
3

4. Project Introduction
What does Genfare do?
Project focus
Challenge & Opportunity
Fare solution in public
transportation
Rework their main
product’s software
configurator
Legacy feature
Improvement upon original
Problem Statement
Problem: complexity → human error
Context: Rework time is 3x the initial development time
Scope: improve current tool/create a new tool
Goal: provide a tool that is easier to use → improve work efficiency &
reduce human error
Economic Impact
Reduce overall development cost
Reduce project development time
Improve customer satisfaction
4

5. Analysis of Current Configurator
Workflow
Setting file
Edit individual setting
- Name
- On/Off
Setting file
Setting1=0xA023
Setting2=”Hello world”
Setting1-0x8000 = ON
Setting1-0x4000 = OFF
….
Setting2=”Hello world”
Example Display
Setting1
● Setting1-0x8000 = ON
● Setting1-0x4000 = OFF
● ….
Setting2
● Setting2 =”Hello world”
Farebox
Interpretation
Not inside the scope
5

6. Example of UI Display
User Navigation
Select a category (green)
Edit individual setting (red)
OR
Edit category setting (orange)
Save by pressing save (purple)
6

7. Identified Problems: Usage Complexity
Why is it complicated?
Meaningless categories
How do we solve it?
Recategorize settings
Setting file SW architecture
Setting file only
stores name and
state
No separation
between database
and codebase
Root cause
Settings hardcoded based upon customers
needs in a chronological order
Figure 1. Unorganized
categories
Figure 3. Setting file components
Figure 2. Current file structure
7

8. Solution Research
Why are we building a new tool
Current tool issues:
● GUI and data are hard-coded
(need to change the program)
○ Cannot separate backend
○ Same as rebuilding from
scratch
● Re-categorize setting data
● Separate setting data from GUI
● Output backward compatibility
Research Goals
Specific goals:
● Categories should be meaningful to the user
● Categories should be mutually exclusive and complete with each other
● Abstraction - Each level of categories should have fewer entries than
present levels (57 - category level, 16 - base level)
Methodology:
● Statistical Analysis
● User interviews
Data Recategorization
Architecture for tool must:
● Maintain current data schema at base level
● Allow addition of data attributes (categories)
● Separate backend from frontend to allow independent development
Software Architecture
8

9. Proposed Solution
3-level Tree Structure
● Component (18 entries)
○ Component Behavior (average: 3)
■ Individual settings (average: 13)
N-Layer Architecture
Data Recategorization
Comparison to original goal
√ meaningful categories
√ mutually exclusive & complete
√ abstraction - fewer entries on average*
Original: 57 + 16 = 72 entries
New: 18+3+13 = 34 entries
* some categories have more than 20 individual settings, but
some settings are grouped & displayed as a single entry in the UI 9

10. Project Development Process
Tool should be able to:
● Utilize GUI to edit individual settings
● Create new projects and load existing projects
● Display settings in treeview using current
categorization
Minimum viable product definition:
● Implement frontend GUI
● Implement backend data schema
● Reimplement file comparison tool
● Reimplementing specific UI element (multiple
choice)
Development Milestones:
● Settings validator / error handler
○ Model option flag dependencies
● Cloud file storage
Possible Future Features:
● Unit Testing
○ Test fundamental features
○ Load/Save/Display
● Efficiency Testing
○ Time trials to configure settings
○ Prevalence of errors
Testing
10

11. Final Deliverable
What can it do currently?
● Read data from GFI.ini file
○ Setting name
○ Setting optionflag
○ Setting state
● Data structure for storing configuration setting
information
○ Setting categories
○ Setting descriptions
● Settings Configuration Screen
○ Treeview displays setting categories
○ Checkbox displays individual settings
11

12. Unit/Efficiency Testing
● Loads input files properly?
○ Load sample files from client, ensure settings
display properly
● Saves files properly?
○ Configure settings to match sample client
files, check if saved outputs are the same
● Displays GUI elements properly?
○ Press all buttons, interact with all elements,
and monitor output
● Reliability
○ Prevent memory leaks -> Valgrind
● Proposed method:
○ Random subjects configure settings on old
tool or new tool, time trials and error rate
analysis, compare results
● Problem:
○ Client could not provide enough test subjects
● Solution:
○ Waive efficiency tests, client was satisfied
with product, justified by internal economic
analysis, determined further testing to be
unnecessary
12
Unit Testing: Efficiency Testing:

13. Conclusion &
Recommendations
13
In the end, this project delivered:
1. A functionally complete tool that can be a
replacement for the current code configurator
2. Systematic workflow that reduces future
product development time by automating UI
configuration of the software
Upon the completion of current project, here’s a few
recommendations:
1. Expanding upon the configuration UI file to a
database for product development.
2. Implementing error reporting feature by creating
a relational database

14. Thank you
14

15. Appendix #1: Statistical analysis on setting use
frequency and use correlation between settings
Research Questions
How many of the settings are being actively used?
What settings are being actively used in the final product?
What kind of categories can we put settings into?
How are the settings related to each other?
Available information
40 final project setting files
● ~900 individual settings
● On / Off
Available Statistics
Occurrence - The number of times a specific setting is used
Correlation - The number of times a specific setting is used
when another setting is used
As shown in the graph above, 80.4% of the option flag settings are used
0%-10% of the time in the 40 GFI.INI files that were sampled. This shows
that there are a good amount of option flag settings that can be
categorized as redundant.
This also suggests that the correlation findings are inconclusive
because over 80% of the data points are going to be indeterminate (how
do you compare 0% against any other occurrence probability)
Analysis
15

16. Appendix #2: Data Categorization Tradeoff Analysis
Reorganization priority (in order of importance):
● Categories should be meaningful to the user
● Categories should be mutually exclusive and complete with each other
● Each level of categories should have fewer entries than present levels (57 - category level, 16 - base level)
Categorization Status Reasoning Failed criteria
Use frequency Rejected 80% of the entries are only used 0-
10% the time, cannot have even
categorization
Each level of categories should have fewer entries than
present
User preference
(hardware)
Rejected Meaningful, but base-level has 30-40
entries on average
Each level of categories should have fewer entries than
present
Statistical
correlation based
on use frequency
Rejected The correlation results has an
absolute error up to 60%, may lead to
bad categories
Categories should be meaningful to the user
User preference
(functionality)
Rejected Logistically impossible to finish within
project time-frame 16