: CT059-3-2-SAT SOFTWARE ARCHICTECTURE &

Module Code
TESTING
Intake Code : UC2F1805SE
Lecturer Name :
Hand in Date : 18th Jan 2019
Tutorial No. : T2
Group No. :
Student ID Student Name
TP045823 KHALID HASSAN ABEID AWADHAN
TP044647 HU XIE
TP042457 LAU JUN HSIEN
Table of Contents
1.0 INTRODUCTION.....................................................................................................................5
1.1 Overview of Foodpanda.........................................................................................................6
1.2 Why we chose foodpanda......................................................................................................6
2.0 REQUIREMENTS....................................................................................................................7
2.1 Functional Requirements.......................................................................................................7
2.2 Non-functional Requirements................................................................................................8
3.0 ARCHITECTURE EVALUATION..........................................................................................9
3.1 What is architecture evaluation?............................................................................................9
3.2 Why evaluate Foodpanda’s software architecture?...............................................................9
3.3 When to evaluate the software architecture?.......................................................................11
3.4 How to evaluate the software architecture?.........................................................................11
3.5 Who is involved in the Evaluation?.....................................................................................11
3.6 What Are the Outputs of an Architecture Evaluation?........................................................11
4.0 CONCLUSION AND RECOMMENDATION......................................................................13
Question 2 – ATAM......................................................................................................................14
Schedule.....................................................................................................................................14
ATAM........................................................................................................................................14
Introduction................................................................................................................................14
Present business drivers.............................................................................................................15
Present architecture....................................................................................................................16
Identify architectural approaches...............................................................................................17
Generate quality attribute utility tree.........................................................................................19
Analyze architectural approaches..............................................................................................20
Brainstorm and prioritize scenarios...........................................................................................22
Analyze architectural approaches..............................................................................................23
Reporting....................................................................................................................................25
Reference.......................................................................................................................................26
Question 3 - ARID.........................................................................................................................27
Introduction of ARID....................................................................................................................27
Phase 1: Rehearsal.........................................................................................................................27
Step 1: Identify reviewers..........................................................................................................28
 Step 2: Prepare design briefing..................................................................................................28
Step 3: Prepare seed scenario.....................................................................................................31
Step 4: Prepare materials............................................................................................................31
Phase 2: Review.............................................................................................................................32
Step 5: Present ARID.................................................................................................................32
Step 6: Present design................................................................................................................34
Step 7: Brainstorming Session...................................................................................................38
Step 9: Summarize.....................................................................................................................39
Question 4 - Individual Component..............................................................................................40
KHALID HASSAN ABEID AWADHAN – TP045823...............................................................40
Software Architecture Analysis Method (SAAM) Agenda.......................................................40
Introduction and Overview........................................................................................................41
Prerequisite and Inputs of SAAM..............................................................................................41
SAAM Steps..............................................................................................................................41
Step 1: Development of Scenarios (1st Iterative).......................................................................42
Step 2: Architecture Description (1st Iterative)..........................................................................43
Visual representation..................................................................................................................44
Step 1: Development of Scenarios (2nd Iterative).......................................................................45
Step 2: Architecture Description (2nd Iterative).........................................................................46
Step 3: Classification of Scenarios.............................................................................................47
Step 4: Individual Assessment of Indirect Scenarios.................................................................48
Step 5: Assessment of Scenario Interaction...............................................................................49
Step 6: Overall Evaluation.........................................................................................................50
Conclusion.................................................................................................................................50
References..................................................................................................................................51
Xie Hu – TP044647.......................................................................................................................52
Schedule....................................................................................................................................52
Introduction..............................................................................................................................52
Steps 1: Develop Scenario........................................................................................................53
Step 2: Describe the Architecture...........................................................................................55
Step 3: Classify and Prioritise the Scenarios.........................................................................55
Step 4: Individually Evaluate Indirect Scenarios..................................................................57
 Step 5: Assess Scenario Interactions......................................................................................58
Step 6: Create the Overall Evaluation...................................................................................59
Conclusion.................................................................................................................................59
Reference......................................................................................................................................60
Lau Jun Hsien – TP042457............................................................................................................61
Schedule for SAAM...................................................................................................................61
Introduction of SAAM...............................................................................................................61
Step 1: Develop Scenario...........................................................................................................62
Step 2: Describe the architecture...............................................................................................64
Step 3: Classify and prioritize the scenarios..............................................................................65
Step 4: Individually evaluate indirect scenarios........................................................................66
Step 5: Assess scenario interactions...........................................................................................67
Step 6: Create overall evaluation...............................................................................................68
Conclusion.................................................................................................................................70
Workload Matrix...........................................................................................................................71
References......................................................................................................................................72
1.0 INTRODUCTION
Online food ordering is the process of food delivery or takeout from a local restaurant or
food cooperative through a web page or mobile application. Food delivery services aim to make
our lives easier with just a few taps. There are 2 types of online food delivery service; restaurant-
controlled and independent. Companies such as Pizza Hut and Dominos have their own websites
where customers can order food. Independent online food ordering companies, such as
Foodpanda and Grabfood, sign contracts with restaurants to handle orders from them in a
regional area. The companies also hire riders who will pick up the orders from the restaurant and
deliver them to customers.

Food delivery service is made up of multiple systems including online ordering system,
delivery system and payment system. This service allows customers to keep accounts with them
in order to make frequent ordering convenient. A customer will search for a favourite restaurant
and choose from available items and choose delivery or pick-up. Payment can be amongst others
either by credit card, PayPal or cash, with the restaurant returning a percentage to the online food
company.

The first online food order was a pizza from Pizza Hut in 1994[CITATION Huf13 \l
17417 ]. Increased smartphone penetration and the growth of the sharing economy enabled food
delivery services to receive more attention. According to [ CITATION Sam16 \l 17417 ] online
delivery accounted for about 3 percent of the 61 billion U.S. restaurant transactions as of
September 2016. The company we chose to conduct an architecture evaluation is Foodpanda.
1.1 Overview of Foodpanda
Foodpanda, which is headquartered in Berlin, is one of the food delivery marketplaces
[ CITATION Che17 \l 17417 ]. The Foodpanda group was founded by Ralf Wenzel, Rohit
Chadda, Benjamin Bauer and Felix Plog in 2012. It operates in 12 countries in Asia and Eastern
Europe. The company has partnered with over 27,095 restaurants in 193 cities and works with
over 15,733 delivery riders[CITATION Del18 \l 17417 ].

The service allows users to select from local restaurants and place orders via its mobile
applications as well as its websites [ CITATION Sam14 \l 17417 ]. It then processes and sends
orders directly to partner restaurants, which then deliver to their customers. Customers order
food by entering their postcodes on the site and browsing for food from a list of restaurants.
Restaurants receive these orders and then deliver to customers[CITATION Foo16 \l 17417 ].

1.2 Why we chose foodpanda

We decided to choose Foodpanda for our assignment topic because it has multiple
systems across multiple platforms and to that, software architecture is highly involved. The
integration of online ordering system, delivery system and payment system significantly require
an architecture evaluation.

In 2014, Foodpanda hit 5 million downloads [ CITATION Lea14 \l 17417 ]. Today,

Foodpanda has more than 10 million downloads in Google Play only[ CITATION Goo18 \l
17417 ]. With over 37,000 ratings in App Store [ CITATION App18 \l 17417 ], Foodpanda must
be the biggest food delivery service. The large customer base they have shown that Foodpanda
requires an architecture evaluation.

Problems experienced by users of Foodpanda explains why we chose it for an architecture

evaluation. The problems will be listed in the next section.

Foodpanda is a complete running system making it ready architecture evaluation. Both

the mobile application and website are working and therefore require an evaluation.
2.0 REQUIREMENTS
A successful project should have a sensible and comprehensive collection of both
functional and non-functional requirements [ CITATION Eri12 \l 17417 ].

2.1 Functional Requirements

A functional requirement defines a function of a system or its component, where a
function is described as a specification of behavior between outputs and inputs [ CITATION
Ran17 \l 17417 ].

The following use case diagram will show all the functional requirements of Foodpanda’s
software.
 Figure 1: Foodpanda's Use Case Diagram

2.2 Non-functional Requirements

Non-functional requirements, also known as quality attributes or quality requirements,
specify the criteria that can be used to judge the operation of a system. According to
[ CITATION Che13 \l 17417 ], the plan for implementing non-functional requirements is
detailed in the system architecture, because they are usually architecturally significant
requirements.

The following is a list of the quality attributes of Foodpanda’s system starting with the most
important one to the least important:
 Availability
 Usability
 Reliability
 Performance
3.0 ARCHITECTURE EVALUATION
3.1 What is architecture evaluation?
Architecture evaluation is a valuable, useful, and worthwhile instrument for managing
risks in software engineering[ CITATION Jen16 \l 17417 ].

3.2 Why evaluate Foodpanda’s software architecture?

We evaluate Foodpanda’s architecture to see if it’s the right architecture and determine
whether it will work or fail. By architecture evaluation, we can save time and money by
identifying the problem in early stages and avoiding wrong decisions. The cost increases
exponentially in the subsequent stages. A successful architect is aware of the problem to be
solved and designs an adequate solution considering given context factors. “The cost to fix an
error found during requirements or early design phases is orders of magnitudes less to correct
than error found in testing” (Desalegn Bekele, 2015).

Reviews in App Store and Google Play show users are not happy with the mobile app and
the service in general. Users complain about the location service not working properly making
ordering of meals to the nearest restaurants impossible. Waiting time for delivery is absurdly
long. Users complain to up to 3 hours of waiting for their meal to be delivered. Some users
regard the service to be ‘terrible and unprofessional”. Customer service is poor and
unsupportive. Calls are left unanswered most of the time. Orders are cancelled without notice
and reason making users to be disappointed by the company. The company also had issues
with some of the restaurants. One user stated that “The representative of Foodpanda on the
phone also requested not to order from that particular restaurant because they had issues with the
restaurant.”[CITATION App18 \l 17417 ][ CITATION Goo18 \l 17417 ]. All these negative
feedbacks and complaints show that Foodpanda’s architecture deserve to be evaluated.

According to Quora, many people are questioning why Foodpanda is down often. Some
believe that Foodpanda does not have an efficient delivery model. Others say that it’s for
marketing purposes[CITATION Quo16 \l 17417 ]. My team will conduct an architecture
evaluation to understand the problem and provide solution to it.
Figure 2: A user Review in App Store

Figure 3: A user review in Google Play

Figure 4: A user review in Google Play

Availability, usability and reliability are some of the quality attributes that Foodpanda are
having trouble with. Our group will look at the problems and provide solutions to them.

3.3 When to evaluate the software architecture?

Evaluation is done either in early or late stages. Since Foodpanda’s architecture is nailed
down, we conduct the architecture evaluation in the late stage.

3.4 How to evaluate the software architecture?

There are many methods to evaluate a software architecture, but we will focus on the three
main methods in our project. These are:

 ATAM: Architecture Tradeoff Analysis Method

 SAAM: Software Architecture Analysis Method
 ARID: Active Reviews for Intermediate Designs

These methods will be discussed later in depth and how we used them to evaluate
Foodpanda.

3.5 Who is involved in the Evaluation?

Two groups are involved in the evaluation of Foodpanda’s software architecture.

Evaluation Team - these are the people who will conduct the evaluation and perform the
analysis.

Stakeholders – these are people who have a vested interest in the architecture and the system.
The project Manager, system architect and designer are examples of stakeholders.

For our project, our group will act as both the Evaluation team and the stakeholders.

3.6 What Are the Outputs of an Architecture Evaluation?

Architecture evaluation produces a report which varies depending on the method used.
The report answers the question; Is this architecture suitable for the system for which it was
designed? (See Figure)
 Architecture evaluation also produce prioritized statement of quality attribute
requirements. Having a prioritized statement of the quality attributes serves as an excellent
documentation record to accompany the architecture and guide it through its evolution.

It also displays risks and non-risks. Risks are potentially problematic architectural decisions.
Non-risks are good decisions that rely on assumptions that are frequently implicit in the
architecture.
4.0 CONCLUSION AND RECOMMENDATION
The average architecture evaluation adds no more than a few days to the project schedule.
It is significantly important to evaluate Foodpanda’s architecture to avoid disasters such as
performance goals not met, Security goals falling, customer dissatisfaction, system that is too
hard to change, and schedules and budgets through the roof. We would recommend conducting
architecture evaluation using ATAM, SAAM and ARID to understand the architecture and
provide solutions to the problems. The following parts will look at the three techniques used to
evaluate Foodpanda’s architecture in depth.
Question 2 – ATAM

Schedule
Time Activity
8:00-9:00 Step 1: Presentation on Introduction to ATAM
9:00-10:00 Step 2: Presentation on Business Drivers
10:00-11:00 Step 3: Discuss Software Architecture
11:00-12:00 Step 4: Identify Architectural Approaches
12:00-1:30 Break
1:30-3:00 Step 5: Generate Quality Attribute Utility Tree
3:00-4:30 Step 6: Analyse Architectural Approaches
4:30-6:30 Step7: Analyse architectural approaches
6:30-7:30 Break
7:30-9:30 Step8: Analyse Architectural Approaches again
6:30-7:30 Step9: Present Result (Reporting)

ATAM
Introduction
The Architecture Trade-Off Analysis Method (ATAM) is a method for evaluating
software architectures related to quality attribute objectives. It considers a variety of quality
attributes such as modifiability, performance, reliability, and security to gain insight into whether
the full enrichment of the architecture meets its requirements. ATAM is named because it not
only reveals how an architecture meets specific quality objectives, but also provides insight into
how these quality objectives interact and how they weigh each other[ CITATION Ric13 \l
1033 ]. Meanwhile the purpose of the ATAM is to assess the consequences of architectural
decisions in light of quality attribute requirements [ CITATION Ric00 \l 1033 ].
Present business drivers
2.1 business context for system
As we mentioned on question one, Foodpanda is a mobile food delivery
marketplace which operates in 10 countries and territories. It has partnered with
over 27,095 restaurants in 193 cities and works with over 15,733 delivery riders.
2.2 Time to market
On 10 December 2016 Delivery Hero acquired Foodpanda, a company estimated
at a $3 billion valuation at that time [ CITATION Ste16 \l 1033 ].
Delivery Hero went public in a listing on the Frankfurt Stock Exchange on June
30, 2017. The listing was the largest by a European technology business in almost
two years [ CITATION Jon17 \l 1033 ].
2.3 Most important function requirements
a. To allow customers and restaurants to register
b. Customers can save their favorite restaurants
c. Customers can filter restaurants by key words
d. Customers can track orders
e. The system will estimate the delivery time based on actual conditions, such as
weather and traffic conditions.
f. Customers can use a variety of payment methods, such as visa, online
payment and third party payment.
g. Customers can give comments to restaurants and riders
Present architecture

Foodpanda uses 3-tier Client-server.

1. The Presentation Tier interacts with the user. Meanwhile, the system interacts with
IOS system and android system.
2. The Application Tier contains the business logic of the application. Foodpanda uses
multiple computer languages to achieve the logic, such as PHP, JavaScript and
HTML.
3. The Data Tier stores data. The data is hosted on cloud services. Data storage can
depend on the cloud services they have registered. SQL or MySQL is the most
common storage at the initial phase. Then software engineers move the data to the
cloud.
Identify architectural approaches
The techniques and architectural approaches used by Foodpanda can be classified into several
categories, it shows as below:

4.1 Web servers

Foodpanda uses Nginx and Apache from May of 2012 to now.

4.2 Language
Hreflang provides language technology support for Foodpanda, which tells search
engines the relationship between pages in different languages on the site based on the
county and language preference of the searcher, using this attribute to provide the
correct regional or language URL in the search results [ CITATION Luk17 \l 1033 ].

4.3 Mobile
IPhone/Mobile Compatible
Apple Mobile Web App Capable
Viewport meta

4.4 Main Program Language

4.4.1 PHP is a Server-side programming language and it is a predominant
scripting language for creating web pages [ CITATION Gri17 \l 1033 ] for
Foodpanda. A sample of PHP code as below:
 4.4.2 JavaScript is a Client-side programming language and it is a lightweight,
object-oriented, cross-platform scripting language, mainly used within
web pages [ CITATION Cal95 \l 1033 ].

The JavaScript sample

4.4.3 Hypertext Mark-up Language is used to create electronic documents that
are displayed on the World Wide Web for foodpanda. Each page contains
a series of connections to other pages, called hyperlinks. Every web page
you see on the Internet is written in a version of HTML code or other
version [ CITATION com18 \l 1033 ].

4.5 Analytics and tracking

Foodpanda uses Google Analytics to understand how users find and use apps, and
with Google Analytics, you can track the return on investment for online marketing
[ CITATION Bil17 \l 1033 ].
Generate quality attribute utility tree

The quality attribute utility tree clearly shows it contains security, reliability,
performance and availability.
 Performance
The response will be focused to discuss. The system can only process 1000
orders at most at the same time. This causes the system to close the order
function during the peak period, when the order quantity reaches 1000 copies.
On the other hand, data transmission delays are very serious. Whether it is
tracking the rider position or checking the order status, there is at least 5
minutes’ delay.
 Security
 System security is guaranteed from external stimuli or internal backups. The
safety factor has reached 99.99%.
 Reliability
Estimates of transit time are very inaccurate. Many customers complain that
the actual delivery time is much longer than the estimated time.
 Availability
External stimulus to system availability is mainly reflected in system updates.
In general, less than 5 seconds to reconnect the network is less than the
average of similar apps. However, some customers complain that app updates
sometimes fail, and main reason is that the new update is not compatible with
the old system and the latest application needs to be re-downloaded.
The system availability is still quite good in response. Network signal loss and
reconnection time is less than 5 seconds. It is less than average time of other
applications.

Analyze architectural approaches

Scenario: Process up to 1000 orders at the same time

Attribute(s): Performance
Environment: Normal operation
Stimulus: The order application exceeds 1000 at the same time
Response: The system will stop accepting order requirements
Architectural Decision Sensitivity Tradeoff Risk Nonrisk
Threads in a Processor S1 N3
Back-end service S3
ROM S4 T4
Reasoning:
 All central processing units have a thread that allows the CPU to perform
multiple operations at once. Therefore, if you want to run a very dense
number of processes, you need a CPU with a lot of threads. (S1, N3)
 A back-end server is a computer program that remains in the background or
a computer program that resides on a server in the background. Typically,
users only interface with front-end applications and rarely need to access
back-end applications. The system can better support horizontal expansion
and meet the requirements of greater traffic. If the back-end service is kept
 as stateless as possible. (S3).
 The ROM is an integral part of the computer, and the CPU can address the
memory through the data bus. Historically, there is main memory on the
computer motherboard, and the memory module is an extension of the main
memory. There is no main memory on the computer motherboard in the
future, and the CPU completely depends on the ROM. All content on the
external storage must pass through the ROM to function. ROM expansion
can improve server processing speed and processing power(S4,T4).

Threads in a
Method link
Processor
Back-end
service
Threads in a
Method link
Processor
 Scenario: Application works in 99% of time
Attribute(s): Reliability
Environment: System modification
Stimulus: System updating or components changed
Response: 99.99% of function work
Architectural Decision Sensitivity Tradeoff Risk Nonrisk
Scale-out storage S1 N13
The package format R2
Glitches R3
Reasoning:
 Scale-out storage technology is a network-attached storage (NAS) architecture in which
the capacity of a disk can be expanded as needed. If a given disk array reaches the storage
limit, another array can be added to expand the system capacity.
 The package format is a compressed file that contains the files and additional metadata
that can be found in the package. There are many formats available today.
 Sometimes components in your computer may experience a brief failure. Some of these
faults are temporary (eg, faults caused by voltage spikes or heat build-up around transient
or faulty components), and some of these faults repeat themselves with surprising
regularity. During the period of no failure, there is no obvious failure and the computer
works as usual. Staggering behaviour or crashes can occur when a fault manifests itself.
Architectural Diagram:

Update requires Update

program

check (1 sec)

Storage

Brainstorm and prioritize scenarios

In this section, all stakeholders: customers, Foodpanda staffs, Foodpanda manager,
suppliers, software developers, system architects, and project managers will meet and discuss
and vote on the system architecture.
Scenario Vote
priority
order（fr Scenario Description Disagree
Agree
om high
to low）
1 Application works in 99% of time 90% 10%
2 Process up to 1000 orders at the same time 90% 10%
3 Customers' database authorisation works 99.99% of time 80% 20%
4 Transactions are secured 99.99% of time 60% 40%
5 Data is automatically backed up each 60 minutes 70% 30%
6 system crash and then restart, application < 10 second  50% 50%
7 Update order status < 5 minutes 40% 60%
8 Estimated time error is large, the general error is more than 20 minutes    60% 40%
9 Network failure detected and reconnect < 5 second 60% 40%
10 Rider position tracking is not real-time, update rider position > 5 minutes 30% 70%
11 After updating failure, re-update< 2 minutes, re-download app < 5 minute 60% 40%

Analyze architectural approaches

It is clear to see from step 7 that the scenario 1, scenario 2, scenario 3 are considered by
most stakeholders to be the most important. The stability of the system directly affects whether
the system can operate normally. The stable operation of the system in 99.9% of time is the
consensus of all stakeholders. The ability of the system to deal orders at the same time is highly
valued by the Foodpanda manager, who wants to improve their ability to process orders. Because
this directly affects the company's effectiveness. A system throughput is usually determined by
two factors, QPS (TPS) and concurrency. Each of these two values has a relative limit. Under the
application scenario access pressure, as long as an item reaches the highest system value, the
system throughput will be limited. For example, if the pressure continues to increase, the
throughput of the system will decrease, because the system's overloaded work consumption leads
to system performance degradation. Software developers and system architects can improve QPS
(TPS) in several ways. Firstly, software developers could increase the number of concurrent
threads of tomcat and open the number of threads matching the server performance, which can
more satisfy the service request. Moreover, system architects could increase the number of
connections to the database, pre-establish the appropriate number of TCP connections. In
addition, the back-end service is as stateless as possible, which can better support horizontal
expansion and meet greater traffic requirements. On the other hand, Since the CPU is completely
dependent on the ROM. All content on the external memory must be run through the ROM.
Therefore, in ROM extension can improve server processing speed and processing power.
Furthermore, Data backup is also considered important by more than half of the
stakeholders. Due to natural disasters, viruses, power failures, and even operator accidental
operation errors can affect the normal operation of the system, and even lead to complete system
paralysis. The task and significance of data backup is that when a disaster occurs, the original
system can be restored completely, quickly, simply, and reliably by backing up the data. On the
other hand, customer data is also very important for Foodpanda, and business planning can be
adjusted in time by analyzing customer data. If you lose the customer's data, the company will
suffer great losses. Therefore, whether it is a backup of the system or a backup of customer data
is listed as one of the priority options.
Moreover, at least half of stakeholders believe that scenario 11, scenario 4, scenario 8 and
scenario 9 will be relatively important. Although the technology to automatically detect lost
networks and automatically reconnect to the network is also important for Foodpanda, there are
also many stakeholders who believe that it is not the highest priority. Because foodpanda
believes that customers should be in a relatively stable environment when making foodpanda.
Such as offices, apartments and schools. The probability of losing a network is not very large. In
addition, some employees also believe that customers can manually connect to the network to
refresh the app and will not affect the customer's intention to use the app to buy food. In terms of
app updates, stakeholders believe that minimizing app update time will give customers a better
experience.
Therefore, while not updating the update content, the update package needs to be as small
as possible. Project code redundancy could help to resolve this problem. It only relies on
maintaining good coding habits to continuously optimize or refactor your code, reduce code
duplication, and achieve code reuse. Unused code is not commented out in large sections,
variable names, method names are too long, etc. It is also an aspect. On the other hand,
Obfuscation is another option. Obfuscation not only improves the decomplication of the APK,
but also minimizes the APK. Obfuscation can remove comments and useless code and can
change Java files, variables, and method names to short names. Therefore, this can reduce the
space occupied by characters, of course, not all files can be obfuscated, which is a category of
confusion configuration.

Finally, stakeholders don’t think it is so important for scenario 10. They think that the
rider's real-time positioning technology will increase the load on the system, and the quality of
this function will not affect the stability and performance of the entire system. The customer only
needs to know how long it will take for the customer to wait. The customer will not care where
the rider is.

Reporting
In this section, the collected information from ATAM will be brought together and
presented to stakeholders. This presentation is usually in the form of an oral report with a
slide. In addition, a more complete written report provided after the ATAM can be
attached. The contents of the report should be displayed:
 The set of scenarios and their prioritization
At this part, all scenarios will be displayed and prioritized
 The utility tree
The utility tree clearly show that each scenario is summarized in that quality attribute.
 The risks discovered
While some scenarios change or additions may lead to systemic risks, these changes are
necessary. This can make the system more in line with the interests of stakeholders or
make the system more stable. Just like the package format mentioned before. Format
changes may directly cause the system to be unrecognizable However, what we need to
do is to minimize the risk while changing.
 The non-risks discovered
Some changes or additions do not lead to system risks, such as Scale-out storage.
 The sensitivity points
Like the scenario which is process up to 1000 orders at the same time, changes to it will
directly improve the efficiency of the system.
Reference
Calif. (1995, 12 04). NETSCAPE AND SUN ANNOUNCE JAVASCRIPT, THE OPEN, CROSS-
PLATFORM OBJECT SCRIPTING LANGUAGE FOR ENTERPRISE NETWORKS AND
THE INTERNET. Retrieved from archive:
https://web.archive.org/web/20070916144913/http://wp.netscape.com/newsref/pr/newsrel
ease67.html
Clements, R. K. (2000). ATAM: Method for Architecture Evaluation. Pittsburgh: Carnegie
Mellon University.
computer hope. (2018, 11 13). HTML. Retrieved from computer hope:
https://www.computerhope.com/jargon/h/html.htm
foodpanda. (n.d.). CONTACT | FOODPANDA. Retrieved from FOODPANDA:
https://www.foodpanda.com.bd/contents/contact.htm
Griffin, L. (2017). What is PHP Used For? - Uses & Advantages. Retrieved from study.com:
https://study.com/academy/lesson/what-is-php-used-for-uses-advantages.html
Harsel, L. (2017, June 30). Hreflang Attribute 101. Retrieved from SEMrush:
https://www.semrush.com/blog/hreflang-attribute-101/
O'Hear, S. (2016). Delivery Hero acquires Foodpanda as Rocket Internet shuffles online takeout
pack once again. Retrieved from TC: https://techcrunch.com/2016/12/10/delivery-hero-
captures-foodbanda/
Rick Kazman, M. K. (2013). The Architecture Tradeoff Analysis Method. Pittsburgh: Software
Engineering Institute Carnegie Mellon University.
Russell, J. (2017). Delivery Hero’s valuation surpasses $5B following successful IPO. Retrieved
from TC: https://techcrunch.com/2017/06/30/delivery-heros-valuation-surpasses-5b-
following-successful-ipo/
Su, B. (2017, May 16). What is Google Analytics, and why is it important to my business?
Retrieved from MC: https://medium.com/analytics-for-humans/what-is-google-analytics-
and-why-is-it-important-to-my-business-8c083a9f81be
Suhana Ramly, R. M. (2018). EATEE Mobile Based Food Delivery System . Johor Bahru:
Universiti Teknologi Malaysia.
Technologies, P. E. (2017, 11 27). What startups can learn from food panda success story.
Retrieved from slideshare: https://www.slideshare.net/HammadMaddy1/what-startups-
can-learn-from-food-panda-success-story
Question 3 - ARID

Introduction of ARID
Active Reviews for Intermediate Designs (ARID), is a method for reviewing preliminary
software designs (such as for a component or a subsystem) for suitability in its intended usage
context and environment. It is also a method to evaluate software architectures that combines
aspects from architecture trade off analysis method (ATAM) and software architecture analysis
method (SAAM) in a more tactical level. It is an intersection of both approaches which is
scenario-based design review techniques (ATAM and SAAM) and active design reviews
(ADRs). ADRs are an effective technique for ensuring quality, detailed design in software.
ARDs involves having the necessary reviewers to make a review on the respective tasks
meticulously as this will help to ensure having an appropriate and suitable design approach for
the respective software architecture. In conclusion, ARID is best suited for evaluating a partial
design in its infancy.

Phase 1: Rehearsal
Phase one is about the meeting between the lead proposed designer and the ARID process
facilitator. The purpose of meeting is to discuss suitable reviewer candidates for the proposed
design and preparation for Phase 2.

Day 1 Schedule

Time Activities
10:00am - 12:00pm Meeting with Designer
12:00pm - 1:00pm Break
1:00pm - 2:30pm Identify reviewer
2:30pm - 4:00pm Prepare design briefing of ARID
4:00pm-4:30pm Break
4:30pm-5:30pm Prepare seed scenarios
5:30pm-7:00pm Preparation for phase 2
7:00pm End of session
Step 1: Identify reviewers
The first step of ARID is to choose the suitable reviewers for the proposed design and to
determine the proposed design approach is suitable for our software architecture. Suitable
reviewers should be chosen for a better testing process because the reviewers are the design’s
stakeholders[CITATION Pau14 \l 17417 ] in terms of software architecture design. To that, one
of the reviewers should be one of the staffs from Foodpanda, this is because they are the one who
are currently using the system and thus they can find out the feasibility of the design by
comparing the proposed approach to their expected standard operation processes. Thus, they can
compare the proposed design to the old system in terms of efficiency and performance. Next,
software developer should also be one of the reviewers because they have the knowledge of
software development concepts that are useful for the reviewing process. Lastly, another
reviewer should be the system architect as they are in proficiency of this field. They can evaluate
the feasibility of the design and apply that with their own experience.

Step 2: Prepare design briefing

This is where the designers prepare a briefing explaining of the design. The designers
present it to the review facilitators to help identify problems and to improve before proceeding to
phase 2. This helps in many ways. First, it lets the facilitator to see the design and ask a set of
questions that the reviewers would ask, thus helping the designer to be prepared. Second, it helps
identify areas where the presentation could be improved. Then, it helps set the pace for the
presentation itself. Last but not least, it gives the designer practice in presenting the material in
phase 2. [ CITATION Pau141 \l 17417 ]

The 4+1 Architectural View Model is used during this step which consists of logical
view, development view, process view and physical view. For logical view, we choose class
diagram to represent the functionalities of the system. This is to help facilitate the understanding
of the reviewers by helping them to understand the basic functionalities of the design and make
necessary evaluations on the design.

For the second view which is the process view in the 4+1 Architectural View Model we
choose the activity diagram. Process view describes the dynamic aspects of the system,
explaining on how the system processes and communicate, and focussing on the behaviour of the
system during runtime. This will help identify the flaws and further improve the system.
Logical View – Class Diagram
Process View - Activity Diagram
Step 3: Prepare seed scenario
Set of seed scenario is prepared by designer for the viewer in this step.

Scenari Description
o
1 99.99% of user’s information is stored successfully in database
2 Foods can be added to cart 100% of run time
3 Foods and prices are sync 99.99% of run time
4 99.99% of user’s order information is stored into database after order has been
made

Step 4: Prepare materials

Participants Materials provided
Foodpanda Staffs Foodpanda’s software architecture design,
Software Developer Seed scenarios, Evaluation questionnaires
Software Architect

Before proceeding to phase 2, hardcopies of Foodpanda’s software architecture design,

seed scenarios and evaluation questionnaires are prepared and to be distributed to the reviewers.
First will be the Foodpanda’s software architecture design, it will be present to the reviewers as
to understand the flow of the whole design. The architecture design brings an overview of the
whole system design for the reviewers to evaluate.

Other than that, another material provided to the reviewers will be the seed scenarios. The
seed scenarios are samples that simulates the running of the system, providing a concept to the
reviewers which help them in the next phase for brainstorming session.

The third material provided for the reviewers is evaluation questionnaires. The
questionnaires provided includes questions for the system as to collect opinions to further
improve the system. For example, the functionalities of the system in terms of meeting the needs
and expectations of the reviewers.
Phase 2: Review
The next phase is the review phase which consist of the remaining 5 steps of ARID. The
reviewers are assembled and the main activities of the review commence.

Day 2 schedule

Time Activities
8:30am - 9:00am Presentation of ARID
9:00am – 10:00am Present design of Foodpanda architecture
10:00am – 11:00am Break
11:00am – 12:00pm Brainstorming session
12:00pm – 3:00pm Apply scenarios
3:00pm – 4:00pm Break
4:00pm – 5:00pm Summarize
5:00 pm End of session

Step 5: Present ARID

There are a total of 9 steps in ARID which classifies as Phase 1 and Phase 2 in which
Steps 1 to 4 are within Phase 1 while Steps 5 to 9 are in Phase 2. In step 1, reviewers were
identified to determine the appropriateness of the design approach for the proposed system. In
the next steps which is the preparation of design briefing, the designer gives a dry run of the
presentation to the review facilitator to improve the presentation. Step 3 will be the preparation
of seed scenarios. In this step, scenarios that acts as a sample for the reviewers in Phase 2 are
generated by the designers. Next will be the step 4, which is the preparation of materials.
Hardcopies of presentation, seed scenarios, and evaluating questionnaires are given to the
reviewers during Phase 2. The meeting is scheduled, stakeholders are invited, and steps are taken
to assure the presence of a quorum of reviewers in the meeting. This concludes the Phase 1 and
Phase 2 is proceeded.

In Phase 2, the reviewers start to review the materials prepared. Leading to Step 5 in
which the review facilitators spend at least 30 minutes to explain the steps of ARID to the
reviewers. After Step 5 is finished, Step 6 starts with the presentation of the design. In this step,
the lead designer presents an overview of the system design and walks through examples. The
goal of this step is to find out whether the design is suitable. Also, the reviewers are not
encouraged to questions nor gives suggestions about alternate designs. However, reviewers
should scribble questions that are crucial to help in the reviewing process. After that, Step 7 is
the brainstorming session in which the reviewers gather to think and give ideas for the system to
be improve and suggestion of new scenarios for using the design to solve problems they expect
to face. The voting process also occurs in Step 7. Moving on to Step 8 will be the application of
scenarios. Beginning with the scenario with the most vote, the facilitator ask the reviewers to
solve the problems as in the scenarios. The reviewers are to solve the problems as stated in the
scenario using pseudocode and more. In the last step which is Step 9 of the ARID, the facilitator
recounts the list of issues, polls the participants for their opinions regarding the efficiency of the
reviews.
Step 6: Present design
Logical View – Class Diagram
 Class diagram are chosen in logical view of 4 + 1 Architectural View Model as to
describes the attributes and operations of a class and also the constraints imposed on the system
of Foodpanda. The class diagram above shows the basic class within the system of Foodpanda.
In Food class, it consists of Food ID, Food Name, Food image, Food price, display food function
and get food details function. Food class is where the food details stored and display to the user.

Next, the Order Detail class. It consists of order ID, Food Id, Food Name, quantity of
food, food price and total price. This class shows the detail of the order made by each users, on
what food is consist of this order, quantity of food the user have ordered and made calculations
pf total price. Another class is the Delivery info class which includes of Delivery ID, Delivery
type, Delivery cost, Delivery Area ID and update Delivery info. The delivery type is where the
user chooses the delivery type in terms of vehicle used, delivery info is where the special request
by user in which the user specify either to be delivered within 1 hour or a selected time.

In the Order class, it consists of Order ID, Customer Name, Customer ID, Delivery ID,
Status of the order on whether it is delivering or not, Date and Update Delivery Info. It shows
user whenever they wish to make an order based on the products they have added into the cart.
Furthermore, the Cart class consists of Cart ID, Food ID, quantity of food, price of food, Update
Cart, Delete Cart Item and view Cart. The class is connected with Food Class and Customer
Class.

In addition, the Customer Class consists of Customer Name, Customer ID, Customer’s
Address, Customer’s Email, Credit card Info, Delivery Info, Register new account, Login, and
update user profile. It is connected with 3 other classes which is the User Class, Cart class, and
Order class. Last but not least, the User class consists of User ID, User Password and Verifying
of Login.
Process View – Activity Diagram
 The activity diagram is a flowchart to represent the flow from one activity to another
activity. The activity can be described as the operation of the system. The control flow is drawn
from one operation to another. In this case, the user first login to the system of Foodpanda, and
undergoes the verification process. If the password and the user ID is matched, the user proceeds
to the next operation and if it is not match, the user is direct back to the login page as to try
again. After the user is logged in, they can choose to search various food to place order and add
to cart and user can choose to edit their cart or his own account.

The user is direct to make payment after the desired foods are added to cart or user can
just cancel the order. User can search through the menu and if food is chosen by the user, it is
added into the cart and then user can choose either to continue shopping or just proceed to make
payment. In the payment process, the total price is calculated and shown to the user and user can
choose the options of paying by credit card or cash on delivery. In another way, user is given the
option to choose to edit the cart’s item as well as the account’s details. For editing account, user
can change their name, their password, address and more. And for editing the cart, user can
choose to add more food into the cart and also to deduct foods in the cart.
Step 7: Brainstorming Session
In step 7 of ARID, session of brainstorming and prioritization is held. the seed scenarios
by reviewers are put into a pool with others. After that, voting occurs, the most voted scenarios
are then used to test the design for suitability. Below is an example table of seed scenarios by
suggestions of the stakeholders:

No. Scenario Votes

1 User are able to log in 99.99% of the time 16
2 User’s credit card information cannot be accessed by others without 11
authorization in 99.99% of the time
3 Foods and their prices ae sync 99.99% of the time 9
4 Delivery status are real time sync 99.99% of all time 15
5 Reduce login time to under 1 minute 17
6 Minimize the chance of data redundancy to 0.01% 6
7 Maximize throughput to 1000 transactions per second 12
8 Cart item can be edit 99.99% of runtime 10
9 Credit card transactions are secured 99.99% of the time 15
10 99.99% of the system is able to accept changes 11
Step 8: Apply Scenario
-based on the top 2 scenario, search/write pseudo code
-mention the pseudo code able to run or cannot run
-whether the design is suitable for the scenario to carry out

Step 9: Summarize
-summarize all steps
-stakeholder’s feedback
-reviewer feedback etc.
Question 4 - Individual Component
KHALID HASSAN ABEID AWADHAN – TP045823

Software Architecture Analysis Method (SAAM) Agenda

Time Agenda Item
Day 1
8:00-8:30 Introduction and overview of evaluation
8:30-9:00 Overview of system being evaluated
9:00-10:00 Develop scenarios (Step 1)
10:00-10:30 Break
10:30-12:00 Architecture description (Step 2)
12:00-1:00 Lunch
1:00-2:30 Develop scenarios (Step 1)
2:30-3:00 Break
3:00-3:30 Architecture description (Step 2)
3:30-5:00 Classify and prioritize scenarios (step 3)
Day 2
8:00-10:00 Evaluating scenarios Individually (step 4)
10:00-10:30 Break
10:30-12:00 Scenario Interaction
12:00-1:00 Lunch
1:00-2:30 Overall evaluation
2:30-3:30 Break
3:30-4:00 Summarization
SAAM Agenda [ CITATION Pau02 \l 17417 ]
Introduction and Overview
Software Architecture Analysis Method (SAAM) shows how the software architecture meets
certain properties such as functionality, structure, and allocation through a method that explains
and analyses software architecture. Quality attributes like modifiability, portability, extensibility
and integrability are quickly assessed in SAAM. Quality aspects such as performance or
reliability are also assessed[CITATION Ros15 \l 17417 ].

SAAM starts with requesting stakeholders to list known scenarios that are likely to change.
Scenarios will be analysed, prioritized and mapped onto the representation of the architecture.

Prerequisite and Inputs of SAAM

 Description of the architecture
 Several scenarios describing the interaction of a user with the system
 The quality requirements that the system is intended to achieve

SAAM Steps

Fig 1: SAAM steps

 Step 1: Development of Scenarios (1st Iterative)
In developing scenarios, the challenge is to capture all major uses and users of the system, all
quality attributes and their associated level that the system must reach and most important all
foreseeable future changes to the system.

In Foodpanda, the users of the system are the customers, restaurants and drivers. Customers
order meals using the system. Restaurants receive the order through the system and prepares the
food. Drivers use the system to pick up food from the restaurant and delivers it to the customer.

Quality attributes of Foodpanda such as performance, availability, usability and reliability are
mentioned already in the previous parts. In SAAM we will focus on modifiability and robustness
of the system.

After meeting up with the stakeholders and brainstorming, the following scenarios were
obtained:

Scenario No Scenario Description

1 Implement two-factor authentication
2 The user wants to order without re-entering location
address
3 Double the size of existing database tables while
maintaining 1 second average retrieval time
Step 2: Architecture Description (1st Iterative)
In the first iterative of Foodpanda’s architecture, we look at the 3-tier architecture model and its
visual representation to get a better understanding of how the system works.

Figure 5: 3 tier architecture of Foodpanda

The following data is obtained at https://builtwith.com/foodpanda.com

Content Management System

 Atlassian Cloud

Email hosting providers

 Zoho Mail
 Google Apps for Business
 SPF
 Microsoft Azure DNS

Name Server

 Cloudflare DNS

Web Hosting Providers

 Cloudflare Hosting

SSL Certificates
  Cloudflare SSL
 Comodo Positive SSL
 Comodo SSL

Operating System and Servers

 IPv6

A detailed Technology profile is available at https://builtwith.com/detailed/foodpanda.com

Visual representation

Figure 6: Visual representation of Foodpanda service

Step 1: Development of Scenarios (2nd Iterative)
After going through the architecture description to know the visual representation of Foodpanda,
we brainstormed to develop more scenarios.

Scenario No Scenario Description

4 Improve the system’s availability from 98% to 99.999%
5 Option to pay or revise order
6 The promo code section will be filled automatically if
there is a promo code available
Step 2: Architecture Description (2nd Iterative)
In the second iterative of architecture description, we look at the code view of the MVC based
architecture of Foodpanda.

Figure 7: MVC architecture of Foodpanda

Step 3: Classification of Scenarios
We here classify the scenarios in step 1 as direct or indirect scenarios. A direct scenario is a
scenario that describes the behaviour currently supported by the system. An indirect scenario is
that sequence of events for which realization or accomplishment the architecture must suffer
minor or major changes.

The prioritization of the scenarios is based on a voting procedure to address the most important
scenarios.

Scenario Scenario Description Type Votes

Number
1 Implement two-factor authentication Indirect 18
3 Double the size of existing database tables while maintaining Indirect 16
1 second average retrieval time
4 Improve the system’s availability from 98% to 99.999% Indirect 13
5 Option to pay or revise order Indirect 8
6 The promo code section will be filled automatically if there Direct 6
is a promo code available
2 The user wants to order without re-entering location address Direct 3
Step 4: Individual Assessment of Indirect Scenarios
We selected two of the most voted indirect scenarios for individual scenarios. We checked the
elements required to change, number of changed components and effort for changes.

Scenari Scenario Direct/ Elements Number of Effort for

o Description Indirect requiring changed changes
Number change components
1 Implement two-factor Indirect Model, 3 1 person-
authentication controller, month
view
3 Double the size of Indirect Model 2 1 person-
existing database week
tables while
maintaining 1 second
average retrieval time
Step 5: Assessment of Scenario Interaction
Scenario interaction is important to highlight. Affected components need to be modified to avoid
potential problems. SAAM highlights

Figure 8: Anointed Code View of MVC-Based Architecture

Step 6: Overall Evaluation
In this last step we assign a weight to each scenario in terms of its relative importance to the
success of the system. The weighting ties back to the business goals supported by a scenario or
other criteria like costs, risks and time to market.

Scenario
No. Description Weight
1 Implement two-factor authentication 25%
3 Double the size of existing database tables while maintaining 1 20%
second average retrieval time
4 Improve the system’s availability from 98% to 99.999% 18%
5 Option to pay or revise order 15%
6 The promo code section will be filled automatically if there is a 12%
promo code available
2 The user wants to order without re-entering location address 10%

Conclusion
SAAM brings stakeholders together to discuss the architecture in a mutually
comprehensible language. It is also a good place to begin incorporating architecture evaluation
into Foodpanda. SAAM is also an easy to learn and carry out. It has many social and technical
benefits. It reveals scenarios and underlying business goals. It forces an appropriate level of
architectural documentation to be revealed. To sum it up, SAAM is a relatively simple
architecture evaluation method which can operationalize vague claims of modifiability.
References
Mary, R., 2015. Software architectural patterns from vastu and a new hybrid model for dynamic
selection of architectural style. Shodhganga, pp. 80-93.
Paul Clements, R. K. M. K., 2002. A sample SAAM Agenda. In: Evaluating Software Architectures:
Methods and Case Studies. s.l.:Pearson Education, pp. 220-221.
Xie Hu – TP044647
Schedule
Time Agenda
Introduction
08:00-08:30

08:30-09:30 Develop Scenario (Step 1)

09:30-12:30 Describe the Architecture (Step2)
12:30-14:00 Lunch Break
14:00-15:00 Classify/Prioritize Scenario (Step 3)
Individually Evaluate Indirect Scenario
15:00-17:00
(step 4)
17:00:19:00 Break
19:00-20:00 Access Scenario Interaction (Step 5)
20:00-21:00 Create the overall Evaluation (Step 6)

Introduction
Software Architecture Analysis Method (SAAM) is a methodology used to determine how
specific application quality attributes were achieved and how possible changes in the future will
affect quality attributes based on hypothetical cases studies. Common quality attributes that can
be utilized by this methodology include modifiability, robustness, portability, and extensibility
[CITATION Placeholder1 \l 1033 ].Foodpanda is a takeaway app for mobile phones. Its system
is mainly to provide an online trading platform for restaurants, food delivery services and
customers. In this section, Foodpanda's system will be analyzed through Software Architecture
Analysis Method.

Function requirement
Customer
Customers can register for an account.
Customers can browse all the restaurant information on the app.
Customers can choose information, for example (only display Malay food, restaurants
ranked high to low, choose free delivery restaurant).
Before confirming the order, the customer can leave a message to the restaurant (eg
less spicy, more soup, etc.).
Customers can track the rider's real-time location.
Customers can check the status of the order.
Customers can rate for restaurants.
Foodpanda staff
Foodpanda staff can track orders.
Foodpanda staff can manage orders.
Foodpanda staff can modify the customer's information.
Foodpanda staff can manage the rider's information.
System is a maintainer
The system regularly maintains system stability for the maintainer.
The system fixes system vulnerabilities or bugs for the maintainer when the system
fails or crashes.
The system uploads a system update package for the maintainer.
Rider
The rider can accept the confirmed order through the system.
The rider can view the details of the order.
The rider can confirm the delivery through the system.
Steps 1: Develop Scenario
Scenari Description
o
1 The system can process at least 5,000 orders at the same time
2 Improve the accuracy of the rider's position in real-time
3 Change hard disk backup to cloud storage
4 Add a minimalist interface
5 Add a third-party payment system

1. By improving server CPU performance, increasing RAM and increasing the

multi-threaded integration method, the system can effectively improve the ability
to process orders.
2. Due to the compatibility of The Global Positioning System (GPS) and the BeiDou
Navigation Satellite System (BDS)[ CITATION TIM17 \l 1033 ], the accuracy of
real-time positioning has been greatly improved. Foodpanda's system can improve
the rider's real-time positioning accuracy by installing two navigation systems.
3. Through collaboration with third-party cloud storage companies, Foodpanda
could storage its data in a pool built by virtual resources called a private cloud.
These resource pools come from enterprise-specific systems. Manually setting up
an enterprise-class private cloud is less efficient in the long-tern than using
existing software, so organizations use digital platforms such as OpenStack® to
move virtual resource pools to private clouds.
4. Create a simple user interface in digital mode to allow users to use the Foodpanda
app even under weak network conditions. For example, replacing the picture with
text or replacing the picture format, etc.
5. By being compatible with third-party payment company systems, an interface is
created to allow Foodpanda's system to jump directly into the interface of a third-
party payment system.
Step 2: Describe the Architecture
Step 3: Classify and Prioritise the Scenarios
Scenari Description Type Vote
o
1 The system can process at least 5,000 Indirec 10
orders at the same time t
2 Change hard disk backup to cloud Indirec 9
storage t
3 Add a third-party payment system Indirec 7
t
4 Add a minimalist interface Direct 7
5 Improve the accuracy of the rider's Indirec 4
position in real-time t

The ability of the system to process the order quantity will directly affect the
productivity of this app. The productivity of the app also directly affects the
company's business profits. Therefore, in order to obtain higher commercial profits,
the client decided to increase the ability to process the order quantity as the highest
priority.
On the other hand, although the purchase of cloud storage services of third-party
companies may bring about an increase in system cost, the advantages brought by
cloud storage services cannot be avoided. First of all, cloud storage is easy to expand.
It expands storage space in time based on server usage and space, so it does not affect
the use of front-end users. Second, it has a high degree of reliability and security.
Data synchronization effectively avoids the problem of loss of damage caused by
media storage data. At the same time, the disk array and tape offline backup mode are
adopted for the server to ensure the security of the cloud storage. Hence the scenario
2 is also listed as a higher priority.
Compatible with third-party payment systems makes customers more selective in
terms of payment. This is also in the interest of the company. In addition, since this
APP is highly dependent on the network, considering the weak network signal, it is
necessary to add another simple version of the interface. The minimalist interface is
to minimize or replace information that requires more traffic to load, such as images.
User interface information is described by characters and numbers.
Step 4: Individually Evaluate Indirect Scenarios
In the case of a direct scenario, the architect demonstrated how the architecture performs
the scenario. In the case of an indirect situation, the architect describes how to change the
architecture to fit the scene. For each indirect scenario, the architectural modifications
required to facilitate the solution as well as the components of the affected or new
systems and the estimated cost and effort to implement the modifications must be
determined.
Scenari Description Type Require Number of Estimated
o d Changed Effort for
Changes Components Changes
1 The system can process at Indirect CPU, RM10,000,
least 5,000 orders at the RAM, 3 10 persons,
same time Code 15 days
2 Change hard disk backup to Indirect RM2000, 5
cloud storage Database 1 persons,
a week
Step 5: Assess Scenario Interactions
When two or more scenarios are requesting changes over the same component(s) of the
architecture, they are said to interact. In this case, the affected components need to be
modified or divided into sub-components in order to avoid of the interaction of the
different scenarios.
Step 6: Create the Overall Evaluation
In the final step, the Foodpanda's system scenarios and architecture will be evaluated as a
whole. Meanwhile, it will be weighted by their expected costs, time required by the
market, change risk and other criteria.
Scenario
No Description Weight
.
1 The system can process at least 5,000 orders at the same time 30%

2 Change hard disk backup to cloud storage 25%

3 Add a third-party payment system 25%

4 Add a minimalist interface 15%

5 Improve the accuracy of the rider's position in real-time 5%

Conclusion
SAAM is a good software architecture assessment technology through SAAM.
Stakeholders have an in-depth understanding of the architecture being analyzed. In some
cases, software architecture documentation has been improved after the SAAM
evaluation session, such as the increased system processing capabilities mentioned above,
changes to system data storage methods, and increased third-party payment methods.
In addition, by enhancing the communication between stakeholders, map brainstorming
scenarios to the architecture to understand future changes in the system. As a result, areas
with high potential complexity are identified. The costs and efforts to implement the
necessary changes are also estimated.
Reference
Merritt, T. (2013, Jan 17). Software Architecture Analysis Method (SAAM). Retrieved from
DZone: https://dzone.com/articles/software-architecture-analysis
SHEN, T. (2017, DEC 08). China, US cooperates on satellite navigation to offer better GPS &
BeiDou services. Retrieved from TECHNODE: https://technode.com/2017/12/08/beidou-
gps/
Lau Jun Hsien – TP042457
Schedule for SAAM
Time Activities
10:00am – 11:00am Introduction
11:00am – 12:00pm Develop Scenario
12:00pm – 1:00pm Break
1:00pm – 2:00pm Architecture description
2:00pm – 4:00pm Classify and prioritize scenarios
4:00pm – 5:00pm Break
5:00pm – 6:00pm Individually evaluate indirect scenarios
6:00pm – 7:00pm Assess Scenario Interactions
7:00pm -8:00pm Creating overall evaluation
8:00pm End of Session

Introduction of SAAM
Software Architecture Analysis Method (SAAM) is a methodology used to determine
how specific application quality attributes were achieved and how possible changes in the future
will affect quality attributes based on hypothetical cases studies. [ CITATION Tod13 \l 17417 ]
It is a simple method which is easy to learn and to carry out with relatively small amount of
training and preparation. SAAM requires the stakeholders to develop a set of scenarios that
represent the changes of the system that will undergo in the future. The scenarios are then
prioritized and mapped onto a representation of the architecture.
Step 1: Develop Scenario
The first steep of SAAM is developing of scenarios by stakeholders. In developing
scenarios, it is crucial to capture all of the major uses of the system, and qualities of that a system
must satisfy now and the future. Thus, the scenarios are illustrated to represent task relevant to
different roles.
Functional requirement:
User:
 User can login to the system of Foodpanda
 User can register new account in Foodpanda
 User can track their delivery
 User can pay by credit card within the system
 User can add food to the cart as in an order

Foodpanda Staff:
 Staff can track orders of user
 Staff can manage orders of user

Delivery Staff:
 Staff can retrieve order delivery information from Foodpanda
 Staff can receive payment upon delivering the food

Table of scenarios:

No Scenarios
.
1 Implement two factor authentication on login system
2 Making interface more user-friendly
3 Change the data structure of an entity (eg. store date and time when order is made)
4 Change the communication infrastructure
5 Change current data storage as cloud storage

Functional View:
 These are the basic subsystem operate independently within the system of Foodpanda.
These systems are controlled by the process support component and transferring data through the
subsystems to the central data repository. In the end, the data transferred are sent to the constraint
checker to validate.
Step 2: Describe the architecture
In step 2, the architecture of the system is described by using the architectural notation
that can be easily understood by all the people involved in analysis stage. In the representation of
system architecture, system computation, data components and the relevant connections between
them must be indicated. The second iteration of code view can be shown as below:

A second iteration scenarios are developed as shown as below after the code view is shown to
the stakeholders and evaluated.

No Scenarios
.
6 Change the relationships between data items in the database (e.g., add the features of
associate related ordered foods)
7 Change the GUI toolset used to build the tool
Step 3: Classify and prioritize the scenarios
In step 3, the analysis team grouped to prioritize and classify the scenarios. The
classification of the scenarios is based on direct scenario, which the architecture may directly
support that scenario with no modification required, and indirect scenario, which changes or
modifications to the architecture is required to adapt the changes. After that, voting of
stakeholders occur to find out the most important scenario by stakeholders.

No Type Votes Scenarios

.
1 Direct 6 Implement two factor authentication on login system
2 Indirect 9 Making interface more user-friendly
3 Indirect 11 Change the data structure of an entity (eg. store date and time when
order is made)
4 Indirect 11 Change the communication infrastructure
5 Direct 10 Change current data storage as cloud storage
6 Indirect 15 Change the relationships between data items in the database (e.g., add
the features of associate related ordered foods)
7 Direct 7 Change the GUI toolset used to build the tool

Based on the votes, the scenario of changing the relationships between data items in the
database are voted the most by the stakeholders. Follow up are the two scenarios which share the
same votes of 11 which are the changing of data structure of an entity and changing of
communication structure. Next will be the changing of current data storage to cloud system
which receive 10 votes from the stakeholders follow up by making the interface more user-
friendly. The least voted scenarios are changing the GUI toolset that is used to build the tool (7
votes) and implementation of two-factors authentication (6 votes).
Step 4: Individually evaluate indirect scenarios
Step 4 is the evaluation of indirect scenarios to help estimate changes of current and for
future. The components which would need to be changed to accommodate the indirect scenarios
are also described. Thus, it can help the stakeholders to have great understanding about them.

Scenari Scenario Type Elements Number of Effort for changes

o No. Description requiring changed/added (estimate)
changes components
6 Change the Indirect View, 3 2 person - weeks
relationships controller,
between data model
items in the
database
2 Making Indirect View 1 1 person - months
interface more
user-friendly
Step 5: Assess scenario interactions
In step 5, analysis is done to generate an estimate of per-scenario effort. In additional to
that, each of the scenarios are mapped onto the architectural representations provide by the
architect s that the areas of scenario to portions of the architecture that are affected by multiple
independent scenarios as shown as below:
Step 6: Create overall evaluation
In step 6 of SAAM, overall evaluation will be created. The scenarios developed by the
stakeholders will be weighted by their anticipated cost, time needed to market, risk to change and
other criteria.

Scenario
No. Description Cost (1-7) Risk (1-7) Time (1-7)
1 Implement two factor 1 1 1
authentication on login
system
2 Making interface more user- 3 1 4
friendly
3 Change the data structure of 5 6 5
an entity (eg. store date and
time when order is made)
4 Change the communication 5 6 6
infrastructure
5 Change current data storage 7 2 2
as cloud storage
6 Change the relationships 5 4 4
between data items in the
database (e.g., add the
features of associate related
ordered foods)
7 Change the GUI toolset used 6 7 7
to build the tool
Weight

Scenario
No. Description Weight
1 Implement two factor authentication on login system 5%
2 Making interface more user-friendly 15%
3 Change the data structure of an entity (eg. store date and time when 25%
order is made)
4 Change the communication infrastructure 17%
5 Change current data storage as cloud storage 6%
6 Change the relationships between data items in the database (e.g., 13%
add the features of associate related ordered foods)
7 Change the GUI toolset used to build the tool 19%
Conclusion
Workload Matrix

No. Description Khalid Hassan Hu Xie Lau Jun Hsien Total

1 Question 1 40% 30% 30% 40% + 30% + 30%
=100%
2 Question 2 30% 40% 30% 30% + 40% + 30%
=100%
3 Question 3 30% 30% 40% 30% + 30% + 40%
=100%
4 Question 4 100% 100% 100% N/A
Signature Khalid
References
Apple, 2018. App Store. [Online]
Available at: https://itunes.apple.com/my/app/foodpanda-food-delivery/id758103884?mt=8
[Accessed 23 November 2018].
Bomkamp, S., 2016. Restaurant food delivery heating up, Chicago: The Columbian.
Chen, L., Babar, M. A. & Nuseibeh, B., 2013. Characterizing Architecturally Significant
Requirements. IEEE, 30(2), pp. 38-45.
Cheung, R., 2017. Hong Kong food delivery services put to the test. South China Morning Post.
Delivery Hero, 2018. Delivery Hero. [Online]
Available at: https://www.deliveryhero.com/brands/foodpanda/
[Accessed 22 November 2018].
Eriksson, U., 2012. Functional vs Non Functional Requirements. [Online]
Available at: https://reqtest.com/requirements-blog/functional-vs-non-functional-requirements/
[Accessed 19 November 2018].
Foodpanda, 2016. Foodpanda. [Online]
Available at: https://www.foodpanda.in/contents/how-it-works
[Accessed 14 November 2018].
Google, 2018. Google Play. [Online]
Available at: https://play.google.com/store/apps/details?
id=com.global.foodpanda.android&hl=en&showAllReviews=true
[Accessed 23 November 2018].
Huffpost, 2013. Huffpost. [Online]
Available at: https://www.huffingtonpost.com/2013/09/09/pizza-hut_n_3894981.html
[Accessed 22 November 2018].
Jens Knodel, M. N., 2016. Why Architecture Evaluation. In: Pragmatic Evaluation of Software
Architectures. 1st ed. s.l.:Springer International Publishing, p. 154.
Mary, R., 2015. Software architectural patterns from vastu and a new hybrid model for dynamic
selection of architectural style. Shodhganga, pp. 80-93.
Merritt, T., 2013. DZone. [Online]
Available at: https://dzone.com/articles/software-architecture-analysis
Paul Clements,Rick Kazman,Mark Klein, 2014. The steps of ARID. In: Evaluating software
architectures. s.l.:Addison-Wesley, p. 246.
Paul Clements,Rick Kazman,Mark Klein, 2014. The Steps of ARID. In: Evaluating Software
Architectures. 11th ed. Massachusetts: Addison-Wesley, p. 246.
Paul Clements, R. K. M. K., 2002. A sample SAAM Agenda. In: Evaluating Software
Architectures: Methods and Case Studies. s.l.:Pearson Education, pp. 220-221.
Poh, L. L., 2014. Foodpanda Hits 5 Million Downloads, Proving Food Ordering Future Lies In
Mobile. [Online]
Available at: https://vulcanpost.com/64111/foodpanda-hit-5-million-download-proving-food-
ordering-future-lies-mobile/
[Accessed 24 November 2018].
Quora, 2016. Quora. [Online]
Available at: https://www.quora.com/Why-is-Foodpanda-down-closed-so-often
[Accessed 23 November 2018].
Randall Fulton, R. V., 2017. Airborne Electronic Hardware Design Assurance: A Practitioner's
Guide to RTCA/DO-254. Washington: s.n.
Wakoba, S., 2014. Nokia Partners With Rocket Internet to Launch Hellofood/foodpanda App On
Nokia Asha, Lumia & X Family of Devices. Tech Moran, 26 February.