Group Assignment 1
Group Assignment 1
Group Assignment 1
Table of Contents
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
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.
*
Login *
Chef
Menu <<extends>>
*
<<extends>> <<extends>> Add food detail
Payment <<extends>>
*
View total Payment
customer
<<extends>>Order Menu
*
cashier <<extends>>
Make Order
View order
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.
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)
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.
Introduction
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.
Steps Phases
1 Describe the SCRAM
Presentation
2 Present Business Drivers
3 Identify Architectural
4 Analyze Architectural Problems Investigating &
5 Solution on architectural problems analyzing
6 Generate quality attribute utility tree
7 Brainstorm and Prioritize Scenarios
Testing & Evaluating
8 Evaluate Architectural
9 Present Results Reporting
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.
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.
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.
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.
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.
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.
Introduction
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.
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.
Input:
- 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.
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:
Output:
- Cashier only prints one receipt after customer payment in order to limit the use of the paper.
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)
new development
environment.
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)
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)
Conclusion
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
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.
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.
ARID include the 9 step and evaluate the design. Each step and phase will be explained in
detail.
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.
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.
Conclusion
Reference
W. Pree, 2000. “Architecture analysis: – The SAAM”, Carnegie Mellon University, 2012