SAT

Group Assignment 1

Module code: CT059-3.5-2-SAT

Module Name: Software Architecture & Testing

Hand in Date: 23 Oct 2012

Lecturer Name: NURSAFURAA BINTI ABDUL MAJID

Intake: UC2F1201SE

Name ID

Ling Chung Ming TP020369

Tan Chun Wei TP019608

Yap Yan Heng TP020452

Software Architecture & Testing

Table of Contents

Work Breakdown Structure...................................................................................................................3

Q1 System and Architecture..................................................................................................................4

Introduction.......................................................................................................................................4

System Background...........................................................................................................................5

Who is involved?...............................................................................................................................8

Why choose to evaluate the system?..................................................................................................9

Conclusion.......................................................................................................................................10

Q2 Stakeholder Consensus Realisation Analysis Method (SCRAM).....................................................11

Introduction.....................................................................................................................................11

Phases of SCRAM...........................................................................................................................12

Conclusion.......................................................................................................................................17

Q3 Software Architecture Analysis Method (SAAM)...........................................................................18

Introduction.....................................................................................................................................18

Steps in SAAM................................................................................................................................19

Conclusion.......................................................................................................................................25

Q4 Active Reviews for Intermediate Design (ARID).............................................................................26

Introduction.....................................................................................................................................26

ARID Phases...................................................................................................................................27

Conclusion.......................................................................................................................................31

Reference............................................................................................................................................32

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION Page 2


Work Breakdown Structure

Work Description Ling Chung Ming

Tan Chun Wei

Yap Yan Heng

Q1 System and Architecture:

- Introduction

- System Background

- WHO, WHY

- Conclusion

33% 33% 34%

Q2 SCRAM”

- Introduction

- Steps and phases of SCRAM

- Conclusion

25% 25% 50%

Q3 SAAM:

- Introduction

- Steps of SAAM

- Conclusion

50% 25% 25%

Q4 ARID:

- Introduction

- Phases of ARID

- Conclusion

25% 50% 25%



Q1 System and Architecture

Introduction

Nowadays, most of the restaurants are still using the manual ordering system. The

existing system relies on large numbers of manpower to handle customer reservation, inquiry,

ordering food, placing order and payment. This method is kind of wasting of time and energy

especially during at peak hour. Some more there may be cause a misunderstanding between

the customer and waiter during the ordering.

Therefore, the research has been selecting the Restaurant Ordering System to evaluate

the architecture. The Restaurant Ordering System developed with Graphical User Interface

(GUI) using a Microsoft Visual Studio 2008 and Microsoft Office Access 2007 for the

database. It is requiring customer to order via touch screen device that placed on each table in

the restaurant. Customers are able to view the menu, price and make an order directly using

the system. Then, their order will be sent to the database in restaurant and will be view on the

computer screen at the kitchen for food preparation.

The following report will evaluate architecture of the Restaurant Ordering System

using SCRAM, SAAM and ARID method.



System Background

Restaurant Ordering System is to improve restaurant quality and efficiency. Order

system helps restaurant to save time and resources because it doesn’t need paper to order

food, and staff doesn’t keep pass the order paper for kitchen. At peak hours, customer’s order

selected directly by staff’s device, it can save customer lunch time. Whole order system is

connected by wireless local area network. Wireless local area network without any wired

cable to connect with device, device can sent data to the router through Wi-Fi connection.

The system will use some device to implement on it such LCD Touch Screen, router and a

touch screen machine. Diagram below is the work flow of the Restaurant Ordering System.

(M. Z. H. Noor, 2012) In order to make the system work, first customer need to select the

item by LCD touch screen, after food selected can press send data to router. Router will

transmit the received data to kitchen LCD screen and counter touch screen machine. Kitchen

cook the meal by referring LCD screen order, data will also transmit to counter touch screen

machine, it is for counter to calculate the bill and print receipt.

In this system, it gives a lot more benefit to both restaurant owner and customers. The

system will improve all the lack from the previous systems. Customer can directly make an

order from the system and misunderstanding between customers and waiters can be reduced

to minimal. Moreover, it also will improve the data collection since order make by the

customer is directly sent to the database. It will reduce time waiting by the customer and



restaurant owner can reduce the expenses on manpower. Diagram below is shows that the use

case of the system.

The Restaurant Ordering System contains components such as login, home page

menu, menu order, item list and payment. The login is requiring the password for user to

enter the system. In this system, only the admin can log in the system and change the

password anytime for the security purpose. In home page menu, it is a main page which is the

user see. This page is showing a restaurant banner, picture and information for promotion

purposes. In the menu order, this is a most important page of the system. It is showing a

menu pictures, names and prices. Customers has to choose their desired menu by clicking the

on the button which is contain the menu picture. Customer can see their selected menu on the



table beside this tab. Meanwhile the total price is automatically calculated every time

customer chooses their order. However customer can remove their unwanted menu by

clicking remove button below the table. If they satisfied with their order they must clicked the

confirm button below the table. This order then sent to the database for data collection and

food preparation. In the payment function, the cashier is not going to print the receipts in

order to limit the use of the paper. (M. Z. H. Noor, 2012)



Who is involved?

The objective of the selection process is to ensure that people with the right skills and

relevance to the project are assigned to support the effort effectively. There are two groups of

people involved in an architecture evaluation.

Evaluation team

The evaluation team conducts the actual evaluation and documents all findings. The team

members and their precise roles will be defined later, but for now simply realize that they

represent one of the classes of participants.

Examples like the evaluation team in this system are Programmer and Project Leader.

Stakeholders

Stakeholders are the people who have specific architectural concerns and a vested interest in

the resulting system. Most of the architectural requirements were specified by these

stakeholders, so that their participation in the evaluation is critical.

Examples the stakeholder in Restaurant Order System are Testers, Managers, Customers and

Users.



Why choose to evaluate the system?

The architecture review resulting in the delivery of better systems. The systems are

always released with performance issues, security risks, and availability problems as a result

of inappropriate architectures. The architectures were defined early in the project life cycle,

but the resulting flaws were discovered much later. The most significant benefit of evaluation

is to reassure that stakeholders that the candidate architecture is capable of supporting the

current and future business objectives; specifically, it can meet its functional and non-

functional requirements. (Rick Kazman, 1996)

Restaurant order system is needed to ready for an architecture evaluation to archive

those qualities attribute. The quality attributes of a system such as performance, availability,

extensibility, and security are a direct result of its architecture; therefore, quality cannot be

introduced easily to your system late in the game. An evaluation of the architecture while it is

still a candidate specification can reduce project risk greatly. The software architecture is

presented to the end user with use case diagram which can helps end user to understanding

their responsibility easily.



Conclusion

In this report, the Restaurant Ordering System has been designed to replace the

manual system. The system is benefit for both customer and restaurant staff. Since the system

can replaced a lot of manual process, the owner of the restaurant can reduce the number of

manpower and reduce the cost of monthly expenses. In another side, the system will reduce

the time waiting and misunderstanding can be reduced to minimal for customer. This is really

important thing during peak hour to make sure the customer satisfy with the service. The

system is implementing in a very attracting Graphical User Interface (GUI). So, the system

can be easily used by customer without any programming knowledge. As a conclusion, the

system is very suitable in a real-time to give more benefit to the business.



Q2 Stakeholder Consensus Realisation Analysis Method

(SCRAM)

Introduction

SCRAM is a new method created by referring the ATAM method. SCRAM is a

method that reveals the architecture problems to be solving by quality solution and

architecture satisfies particular quality goals. It provide insight into how analyze problems

and prioritize scenarios. It is a structured method for analyze and evaluate the architecture.

The SCRAM method can analyze direct to the problems of the architecture and produce a

solution to solve the problems. Generate quality utility tree to understand quality attributes

requirements and brainstorming scenarios to get information or idea from the entire group of

stakeholders. Architecture is a main thing in a business’s technological system, because it is

motivated by a set of functional and quality goals.

The following of the steps of SCRAM are:

1. Describe the SCRAM

2. Present business drivers

3. Identify architectural

4. Analyze architectural problems

5. Solution on architectural problems

6. Generate quality attribute utility tree

7. Brainstorm and prioritize scenarios

8. Evaluate architectural

9. Present results



Phases of SCRAM

SCRAM has divided into four phases of running breakdown structure such as

presentation, investigating & analyzing, testing & evaluating and reporting. Presentation

phase is involving describe SCRAM and present business drivers, purpose is explain

SCRAM running steps and system background and importance to stakeholders. The second

phase is investigating and analyzing, it is analyze any problems will occur system and

identify the potential of the system. Besides, it will proceed to generate attribute utility tree

for investigate system operate.

In addition, third phase is testing and evaluating to allow stakeholders to understand

the prototype outcome and evaluate the system performance. From this phase, it can be

collected more additional ideas for system as references. As for last phase is reporting;

reporting is the final results of system facing problems, some parts affect on business, extra

parts added, system functional and so on. The below table is listing the four phases divided in

SCRAM.

Steps Phases

1 Describe the SCRAMPresentation

2 Present Business Drivers

3 Identify Architectural

Investigating &

analyzing

4 Analyze Architectural Problems

5 Solution on architectural problems

6 Generate quality attribute utility tree

7 Brainstorm and Prioritize ScenariosTesting & Evaluating

8 Evaluate Architectural

9 Present Results Reporting



1. Describe the SCRAM

SCRAM a new method solves those architecture problems revealed. There have 8

steps on SCRAM method such as describe the SCRAM, present business drivers, identify

architectural, analyze architectural problems, solution on architectural problems, generate

quality attribute utility tree, brainstorm and prioritize scenarios, evaluate architectural and

present results. SCRAM is critical solve problems in architecture, analyze problems and

generate an idea through brainstorm. Generate an attribute utility tree for the architecture, and

evaluate architectural.

In this part, SCRAM will use on reveals restaurant order system and describe to the

assembled stakeholders. Everyone will understand the process of steps and will follow the

work. Firstly, it will briefly explain the SCRAM steps, identify restaurant order system

reliability and usability after that analyze system problems and solve it. Generate a utility tree

about the system, brainstorm scenarios based on the generated utility tree. Last, evaluation

team will evaluate the system and with results.

2. Present Business Drivers

SCRAM describes the system’s business drivers and important requirements. It

describes how the business drivers running on the restaurant. There have two most important

for business drivers are functional requirements and quality attributes requirements.

Functional requirements is representative the whole system main purpose, without functional

system will not be develop, so it must require to know what the system function needs.

Besides, quality attribute requirements are about system’s availability and security. High

availability and high security is the most central to the system’s success. High availability of

system’s feature will be recovered within one minute if any failures occur and without any

hanging problem. High security is the protective or secure of the system must be very strong.

System should has hard defends to prevent any person hack into system and destroy it.

The system needs to be understood by all stakeholders for evaluation the system

quality. The system will be present the overview from a business perspective. Example, the

system functional will be useful on restaurant business or system will increase the restaurant

business amount. The system will be helping the restaurant business achieve their goal or

target itself. System must achieve high availability and high security; it does ensure the



restaurant business will not decrease by using the system. High availability in system is

mentioning on the system will not have much failure, even system failure it will also be

recovered within one minute or less. High security is mentioning system security firewall will

be strong enough to protect it.

3. Identify Architectural

Identify the architecture running style, observe the architecture and find out problems

during identification. It is to identify the architecture reliability and usability. Reliability is

define the system can perform smoothly without any error or failure. It is a serious problem if

the system will always occur error or not responding during working time, it may cause a lot

of troubles for user. Usability is the ease of use and learnability of a system, system should

have an instruction or some guideline for user to starting run program in begin.

Identify the restaurant order system reliability and usability. The performance of a

system must be running smoothly, it could not hang or automatically shut down during

business hour. If the problem occurs, it will cause the restaurant out of sequence; staff will

busy on taking order manually and send the confirmed order to kitchen manually. System is

ease of use and learnability, there have an instruction book and guideline on system,

instruction will list out the use of function clearly and understandable.

4. Analyze Architectural Problems

Analyze architectural problems is analyze what will problems bring to architecture.

Analyst will analyze what are the system’s problems and how does the system problems

created. Before develop a prefect system, it should been analyze few times to ensure

problems does not occur. Analyze the system problems starting point to prevent similar

problems occur.

In analyze problems; evaluation team will analyze any problems of system will cause

restaurant business decrease such as calculating amount, printing receipt, login failure and so.

List down all the problems and create a solution to solve all those problems.

5. Solution on Architectural Problems

Solution is to solve problems occur in system. The system will not proceed to develop

stage if without solution to settle problems. The solution is generated completely solve

system problems; it is help the future system in further planning and design.



The solution of solving the problems based on analyze steps, problems will affect

system perform therefore generate a solution to solve all the problems on system and make it

become perfect will help a lots on restaurant business.

6. Generate Quality Attribute Utility Tree

A quality attribute utility tree will build by identify, prioritize, and refine the most

important quality attribute goal. Utility trees provide a top-down mechanism for directly and

efficiently translating the business drivers of a system in to concrete quality attribute

scenarios. Utility tree is a diagram that sketch like a tree; it is listing system attribute specific

requirements. In a utility tree will have quality attribute, scenarios, describe architecture,

level of quality goals. The quality attribute in utility tree comprise modifiability, portability,

security, reliability, functionality, performance, availability, conceptual integrity, variability

and so on. Scenarios are used to understand quality attribute requirements and represent

stakeholder’s interests.

Utility tree is the most critical to the system’s success, the output of the utility tree

generation process is a prioritization of specific quality attribute and scenarios of the system.

The quality attribute is meaning the system flow and feature, voted the level of quality goals

to specific it standard and describe scenarios of system quality attribute.

7. Brainstorm and Prioritize Scenarios

The purpose of utility tree is used to understand how architecture handled the quality

attribute architectural. Brainstorm scenarios are to take idea from larger stakeholder

community. Brainstorm scenarios perform well in larger groups, creating an atmosphere in

which the ideas and thoughts of one person stimulate others to think more and have more idea

generate. Prioritized list of brainstormed scenarios is compared with those generated by the

utility tree exercise.

Generate a set of scenarios for discussion and brainstorm with stakeholders. A larger

group of stakeholders gathered to participate in SCRAM brainstorm and prioritize scenarios

steps for brainstorming the scenarios of system, stakeholders could give their brainstorming

idea of system expected or any modification part. From the brainstorming part, evaluation

team can understand the stakeholder’s requirements or idea on the system. Example,

stakeholders expected the system efficiency but system is focus on quality and standard.



8. Evaluate Architectural

The architectural will be evaluated after those previous steps of SCRAM. The

evaluation team will evaluate how strong of the architecture and how well of the architecture

will be perform on that business. The best time to evaluate the architecture is before the

system start to develop because it needs many aspects of the assessment to prevent develops a

bad and useless system.

Evaluation team will evaluate the system after the previous steps of identify, analyze

problems, solution and so on. Based on the previous steps information, evaluation team will

evaluate the system strengthens on restaurant business such as restaurant business turnover,

business efficiency and business quality. The order system must be fulfilling restaurant

requirements.

9. Present Results

Based upon the information collected from the steps of SCRAM method such as

scenarios, utility tree, analyze problem, evaluate and so on. The SCRAM team presents the

findings to the assembled stakeholders and writes a report.

The results of collected information and details from SCRAM method will be

summarized and presented back to the stakeholders about the order system.



Conclusion

SCRAM is a new method that created by referring ATAM method. From SCRAM it

can analyze the problems of architecture and identify the architecture to enhance the system

become perfectly. It can communicate with stakeholders for presenting the system and allow

them to evaluate it. After implement SCRAM method on develop a system, it will be

perfectly develop a system to help restaurant business increase day by day. In future, this

method will be very useful for other developer to know how to generate a good system by

following the SCRAM steps.



Q3 Software Architecture Analysis Method (SAAM)

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 cases studies. SAAM is one of the earliest

software architecture evaluation methods and is the foundation of many existing scenario

based methods that are used today. Many of its activities are in some way represented in

other methods. SAAM can be used to evaluate a single architecture or to compare different

alternative designs. In practice SAAM has proven useful for quickly assessing many quality

attributes such as modifiability, flexibility and maintainability. (Rick Kazman, 1996)

Diagram above shows that the steps of SAAM and the dependency relationships between

those stages. (Rick Kazman, 1996) The 6 steps of SAAM evaluation will explain more details

in the following report.



Steps in SAAM

The method consists of six main steps, which typically are preceded by a short

overview of the general business context and required functionality of the system.

Steps 1 – Develop Scenario

The set of scenarios used in the analysis of software architecture should represent the

kinds of activities that the system must support and the kinds of changes that will be made to

the system in the future as expected or foreseen. In developing these scenarios, it must

capture all important uses of the system from all stakeholders and users of the system in

concern of all quality attributes that the system is to satisfy. Thus, scenarios will represent

tasks relevant to different stakeholders such as customer, cashier, marketing, administrator

and maintainer. (Mugurel T. Ionita, 2012)

Stakeholder Interest

Customer Use the system to make an order without waiter.

Cashier Receive the payment and select the payment method.

Administrator Log in to access the system and change the content of the system.

Chief Update the status for the availability of item.

Maintainer Maintain the usability of the system.

Marketing Design an advertising and promotion on main page of the interface.

Scenario Number Scenario Description

1 To make an order directly to the system by input.

2 To check the item and total amount of the order.

3 To change the order within a period.

4 To update the status for the availability of item.

5 To change the payment method of the bill.

6 To port to another operating system.

7 To increase the respond speed without affecting operation of system.



8 To increase capacity of the database.

9 To make minor modifications to the user interface.

10 Integrate with a new development environment

Step 2 – Describe the Architecture

The candidate architecture or architectures should be described in a syntactic

architectural notation that is well-understood by the parties involved in the analysis. These

architectural descriptions need to indicate the system computation and data components, as

well as all component relationships, sometimes called connectors. (Mugurel T. Ionita, 2012)

There are major 4 components:

Input:

- Administration needs to log in to access the system.

- Customer makes an order via touch screen device that placed on each table in the restaurant.

- Customers are able to view the menu and price before make an order.



- Customer can change the order within a period.

Menu:

- Customer order will be sent to the database in restaurant and will be view on the computer

screen at the kitchen for food preparation.

- The total price is automatically calculated every time customer chooses their order.

- Chief can update the status for the availability of the certain item.

Payment:

- Cashier can check the item that customer order.

- Cashier can change the payment method of the bill.

- Customer can choose the payment method.

Output:

- Cashier only prints one receipt after customer payment in order to limit the use of the paper.

Step 3 – Classify and Prioritise the Scenarios

There are two classes of scenarios. Direct scenarios are those that can be executed by

the system without modification. Indirect scenarios are those that require modifications to the

system. Indirect scenarios cannot be directly supported by the current architecture. Achieving

them result in some modifications, such as adding one or multiple components, removing an

indirect layer, updating a module with a more suitable one, changing or enhancing interface,



redesigning relations among elements, or everything in the between. Indirect scenarios are the

most critical drivers for the subsequent activities. (W. Pree, 2000)

Scenari

o

Number

Scenario Description Type

1 To make an order directly to the system by input. Direct

2 To check the item and total amount of the order. Direct

3 To change the order within a period. Direct

4 To update the status for the availability of item. Direct

5 To change the payment method of the bill. Direct

6 To port to another operating system. Indirect

7 To increase the respond speed without affecting operation of system. Indirect

8 To increase capacity of the database. Indirect

9 To make minor modifications to the user interface. Indirect

10 Integrate with a new development environment Indirect

Step 4 – Individually evaluate Indirect Scenarios

The direct/indirect classification is a first indication of the fitness of architecture with

respect to satisfying a set of scenarios. In case of an indirect scenario the architect describes

how the architecture would need to be changed to accommodate the scenario. For each

indirect scenario there must be identified the architectural modifications needed to facilitate

that scenario together with the impacted and/or new system’s components and the estimated

cost and effort to implement the modification. The detailed explanation should contain the

range within which the modification is performed, the number of elements in this range and

the estimated work amount. (W. Pree, 2000)

Scenario

Number

Scenario Description Type Change Modification Estimated

Work

6 To port to another operating

system.

Indirect 4 or All A major re-develop

may be necessary.

30 work

days

7 To increase the respond Indirect 1 Change the 12 work



speed without affecting

operation of system.

implementation

according the order

steps.

days

8 To increase capacity of the

database.

Indirect 1 To change the bigger

database managing.

3 work

days

9 To make minor

modifications to the user

interface.

Indirect 2 This will require

changes the

components which are

input and menu.

5 work

days

10 Integrate with a new

development environment

Indirect 1 or 2 This requires changes

which connects the

new development

environment.

15 work

days

Step 5 – Assess Scenario Interactions

When two or more scenarios are requesting changes over the same components 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. Scenario interaction is an important consideration because it exposes the allocation

of functionality to the product's design. In a very explicit way it is capable of showing which

modules of the system are involved in tasks of different nature. (Mugurel T. Ionita, 2012)

Module Description Interactive Change

Input The input of the system such

as Admin log in and

Customer place an order.

6, 9 2

Menu The interfaces of the menu

which are include item list

and price.

6, 7, 9, 10 4



Payment Contain information about

the order and method of the

payment.

6 1

Output The output of the system such

as bill details and receipt.

6, 10 2

Database Storage of the system. 8 1

Step 6 – Create the Overall Evaluation

Finally a weight is assigned 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, time to market, and so on. Based on this scenario weighting

can be proposed an overall ranking if multiple architecture are compared. Alternatives for the

most suitable architecture can be proposed, covering the direct scenarios and requiring least

changes in supporting the indirect scenarios. (Mugurel T. Ionita, 2012)

Scenario

Number

Scenario Description Change Modification Important

6 To port to another operating

system.

2 A major re-develop may

be necessary.

3

7 To increase the respond

speed without affecting

operation of system.

4 Change the

implementation

according the order steps.

1

8 To increase capacity of the

database.

1 To change the bigger

database managing.

4

9 To make minor

modifications to the user

interface.

2 This will require changes

the components which

are input and menu.

2

10 Integrate with a new

development environment

1 This requires changes

which connects the new

development

environment.

5



Conclusion

As a conclusion, the SAAM method is good for stakeholders’ in-depth understanding

about the architecture being analyzed. In some cases, after a SAAM evaluation session the

software architecture documentation is improved. Besides that, it also enhanced

communication among the stakeholders. Future work also can directly relate with this

analysis regards the integration of the scenario-based techniques requirements discipline.



Q4 Active Reviews for Intermediate Design (ARID)

Introduction

The Active Review for Intermediate Deign combines the philosophy of ADR with

scenario-based methods like ATAM or SAAM. ARID is a method for evaluating small

component of partial architectures in the early or conceptual phases. Designs of partial

architectures are architectural in nature, they are small component that represent the step of

the full architecture. AIRD aims to validate the suitability of the small component being

proposed with respect to other parts of the architecture. ARID is motivated by the fact that if

the architectural small components are inappropriate, then the entire architecture can be

undermined. Hence, reviewing a small component in its early prerelease stage provides

valuable early insights into the design’s viability and allows for timely discovery of errors,

inconsistencies, or inadequacies.

This small component of this project is customer order system, this subsystem will

help customer easier to order food with more efficient way of the restaurant to take order

from customers. There are 2 phases and 9 steps in ARID evaluation which will be explained

in detail later.



ARID Phases

Phase 1: Pre-meeting

Step 1: Identify Reviewers

Category Name of Stakeholder Responsibility

Developer

Software EngineerSolve problem and ensure that solution

meets all of the constraints of the system.

Software ArchitectDesign of the architecture of the

architecture of the hardware environment.

Client

AdministratorLog in to access the system and change the

content of the system.

CashierReceive the payment and select the

payment method.

ChiefUpdate the status for the availability of

item.

Customer Use the system to make an order without

help of waiter.

Step 2: Prepare Design Presentation

In the case of our design prepare of ARID, this consisted of a one hour presentation

that explained how the customer use the system to make order, and then presented why

customer must use this new method to make order food. The goal is to present the design in

sufficient detail so that knowledgeable audience member could use the design. In the first

Phase, the software engineers or software architecture dry run of the presentation to the

review, which are the helpful reasons of the system, example, and more explanation of food

detail in system, can avoid accidently received wrong order from customer. Lastly, let the

reviews to have chance to ask question related about the Order food System and designer will

answer to the question.



Step 3: Prepare Seed Scenarios

The Ordering part of the system is the most important part of the system. This is the

subsystem that will be used by the customer to make order for their food. In the subsystem, it

includes set Menu food of picture, name, and price and food detail. The food detail is

description of what is the content of the food. Customer can review their selected choices.

Meanwhile the total price is automatically calculated every time customer confirms their

order. However, if the customer can remove their unwanted choice by clicking remove

button. If customer satisfied with the order, they must click confirm button to precede the

order process.

Performance, performance of the system is very important to satisfy the customer.

The order system will respond every process within a second. Customer won’t be worry

about the system will be crush or delay their order food time.

Maintainability, the system is always automatically backup the latest data that insert

into the database. The data which would be backups is the catalogue of the Food menu. If the

system suddenly is crush, the restaurant don’t need to manually insert the food detail because

the system is prepared automatically backup.

Reliability, the system will operate every time the restaurant is on services. Customer

can always enjoy the services every time they visit the restaurant. The crushing of the system

is very minimal because the system does not involve in huge of databases.

Step 4: Prepare for the review meeting

Copies of the presentation, seed scenarios, and review agenda are produced for

distribution to the reviewers during the main review meeting. The meeting is

scheduled, reviewers are invited, and steps are taken to assure the presence of a

quorum of reviewer at the meeting.

Phase 2: Review meeting

Step 5: Present ARID method

A meeting will be held between designer and the reviewer consists of 30 minutes

explaining the steps of ARID to the participants. The designer will explain the phase of the



ARID include the 9 step and evaluate the design. Each step and phase will be explained in

detail.

Step 6: Present design

The designer of the system presents the one hour overview presentation and walk

through the examples. During this time, a ground rule is that no questions concerning

implementation or rationale are allowed, and also no suggestion is needed about the alternate

design during the presentation. The goal is to see if the design is usable, not to find out why

things were done certain way, or to learn about the implementation secrets behind the

interfaces. Questions are allowed to ask about related to unclear explained by designer.

During this time, the scribe captures each question or each instance where the

designer indicated that some sort of resource was on its way but not yet available. The

resulting list is summarized to show potential issues that the designer should address could be

considered complete and ready for production. The list of issues will be capture on a

whiteboard for everyone to see, and the designer made sure that all the reviewers understood

each issue and agreed with its wording before the presentation continued.

Step 7: Brainstorm and prioritize scenarios

The Designer allow the reviewer suggest scenarios for using the design to solve

problems they expect to face. During brainstorming, the entire seed scenario will put into the

pool with all others. Reviewers might suggest that two scenarios are version of the same

scenario or that one subsumes another and should be merged. After that, voting occurs. The

reviewer can vote to any scenario they wish. After the voting is satisfied, then the design will

then be used to ‘test’ for usability. After voting is complete, it is important to make the point

that the reviewer has just defined what it mean for the design to be usable, if it performs well

under the adopted scenarios, then it must be agreed that the design has passed the review.

Step 8: perform review

Beginning with the scenario that received most votes, the designer asks the reviewer

to jointly craft code that uses the design services to solve the problem posed by the scenario.



Reviewer makes extensive use of the example that was handed out as part of the designer’s

presentation. The voted scenario will be tested after that. The pseudo code will be create uses

the design services to solve the problem posed by the scenario. The step by step will be

explained how the design is word and how the data flow is process or transfer to other

subsystem of the system. It took the group about one hour to finish the review.

During this time, a ground rule is that the designer is not allowed to help or gives

hints. In the exercise, the designer was tasked with the UML model on a direct-display

projector, so the when participants had question about a program’s interface or interactions,

he could quickly take us to the specification where the question could be answered.

However, the group became stuck or began to go off in wrong direction, and then the

designer will stop the proceedings. Each time this happen, the designer asked the scribe to

record as an issue where and why stalled, as this would indicate an area where the design

were insufficient to allow a non-expect to proceed.

Step 9: Present conclusion

At the end, the list of issues is recounted, the participants are polled for their opinions

regarding the efficacy of the review exercise, and they are thanked profusely for their

participation.



Conclusion



Reference

Rick Kazman, 1996. “Scenario-Based Analysis of Software Architecture”, IEEE Software,

November 1996.

M. Z. H. Noor, 2012. “The Development of Self-service Restaurant Ordering System”,

Control and System Graduate Research Colloquium, 2012

Mugurel T. Ionita, 2012. “Scenario-Based Software Architecture Evaluation Methods: An

Overview”, Department of Mathematics and Computing Science, 2012

W. Pree, 2000. “Architecture analysis: – The SAAM”, Carnegie Mellon University, 2012

Ebookbrowse. Retrieve on website: http://ebookbrowse.com/active-reviews-for-intermediate-

designs-ppt-d143773351 [Accessed on 20 Oct 2012]


http://ebookbrowse.com/active-reviews-for-intermediate-designs-ppt-d143773351

http://ebookbrowse.com/active-reviews-for-intermediate-designs-ppt-d143773351

SAT

Documents

lcd touch

work breakdown

touch screen

software architecture

make minor

bigger database

present business

clicking remove