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 Ling Chung Ming Tan Chun Wei Yap Yan Heng ID TP020369 TP019608 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
Q1 System and Architecture: - Introduction - System Background - WHO, WHY - Conclusion Q2 SCRAM - Introduction
Ling Chung Ming
Tan Chun Wei
Yap Yan Heng
33%
33%
34%
25% - Steps and phases of SCRAM - Conclusion Q3 SAAM: - Introduction - Steps of SAAM - Conclusion Q4 ARID: - Introduction 25% - Phases of ARID - Conclusion 50%
25%
50%
25%
25%
50%
25%
Page 3
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.
Page 4
System Background
Restaurant Ordering System is to improve restaurant quality and efficiency. Order system helps restaurant to save time and resources because it doesnt need paper to order food, and staff doesnt keep pass the order paper for kitchen. At peak hours, customers order selected directly by staffs 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
Page 5
restaurant owner can reduce the expenses on manpower. Diagram below is shows that the use case of the system.
Restaurant Order System

* Login
* Menu <<extends>> <<extends>> Add food detail Chef
<<extends>>
Delete Food detail Admin
Update food Detail
Payment <<extends>> *
View total Payment
customer
<<extends>> Order Menu cashier Make Order <<extends>>
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
Page 6
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)
Page 7
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.
Page 8
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 nonfunctional 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.
Page 9
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.
Page 10
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 businesss 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
Page 11
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 1 2 3 4 5 6 7 8 9 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 Present Results
Phases Presentation
Investigating & analyzing
Testing & Evaluating Reporting
Page 12
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 systems 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 systems availability and security. High availability and high security is the most central to the systems success. High availability of systems 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
Page 13
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 systems 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.
Page 14
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 stakeholders interests. Utility tree is the most critical to the systems su ccess, 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 stakeholders requirements or idea on the system. Example, stakeholders expected the system efficiency but system is focus on quality and standard.
Page 15
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.
Page 16
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.
Page 17
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.
Page 18
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 Customer Cashier Administrator Chief Maintainer Marketing
Interest Use the system to make an order without waiter. Receive the payment and select the payment method. Log in to access the system and change the content of the system. Update the status for the availability of item. Maintain the usability of the system. Design an advertising and promotion on main page of the interface.
Scenario Number 1 2 3 4 5 6
Scenario Description To make an order directly to the system by input. To check the item and total amount of the order. To change the order within a period. To update the status for the availability of item. To change the payment method of the bill. To port to another operating system.
Page 19
7 8 9 10
To increase the respond speed without affecting operation of system. To increase capacity of the database. To make minor modifications to the user interface. 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)
Restaurant Ordering System
Input
Menu
Payment
Output
Order
Check out
Bill
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.
Page 20
- 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,
Page 21
redesigning relations among elements, or everything in the between. Indirect scenarios are the most critical drivers for the subsequent activities. (W. Pree, 2000)
Scenario Scenario Description Number 1 2 3 4 5 6 7 8 9 10 To make an order directly to the system by input. To check the item and total amount of the order. To change the order within a period. To update the status for the availability of item. To change the payment method of the bill. To port to another operating system. To increase the respond speed without affecting operation of system. To increase capacity of the database. To make minor modifications to the user interface. Integrate with a new development environment
Type
Direct Direct Direct Direct Direct Indirect Indirect Indirect Indirect 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 systems 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
To port to another operating system.
Indirect
4 or All
A major re-develop may be necessary.
30 work days 12 work
To increase the respond
Indirect
Change the
Page 22
speed without affecting operation of system.
implementation according the order steps.
days
To increase capacity of the database.
Indirect
To change the bigger database managing.
3 work days 5 work days
To make minor modifications to the user interface.
Indirect
This will require changes the components which are input and menu.
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 Input
Description The input of the system such as Admin log in and Customer place an order.
Interactive 6, 9
Change 2
Menu
The interfaces of the menu which are include item list and price.
6, 7, 9, 10
Page 23
Payment
Contain information about the order and method of the payment.
Output
The output of the system such as bill details and receipt.
6, 10
Database
Storage of the system.
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 To port to another operating system.
Change 2
Modification A major re-develop may be necessary.
Important 3
To increase the respond speed without affecting operation of system.
Change the implementation according the order steps.
To increase capacity of the database.
To change the bigger database managing.
To make minor modifications to the user interface.
This will require changes the components which are input and menu.
10
Integrate with a new development environment
This requires changes which connects the new development environment.
Page 24
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.
Page 25
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 designs 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.
Page 26
ARID Phases
Phase 1: Pre-meeting Step 1: Identify Reviewers Category Name of Stakeholder Software Engineer Developer Software Architect Responsibility Solve problem and ensure that solution meets all of the constraints of the system. Design of the architecture of the
architecture of the hardware environment. Log in to access the system and change the content of the system. Receive the payment and select the payment method. Update the status for the availability of item. Use the system to make an order without help of waiter.
Administrator
Cashier Client Chief Customer
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.
Page 27
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 wont 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 dont 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
Page 28
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.
Page 29
Reviewer makes extensive use of the example that was handed out as part of the designers 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 programs 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.
Page 30
Conclusion
Page 31
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-intermediatedesigns-ppt-d143773351 [Accessed on 20 Oct 2012]
Page 32

SAT

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAT

Uploaded by

Copyright:

Available Formats

Group Assignment 1

Software Architecture & Testing

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

Work Breakdown Structure

Ling Chung Ming

Tan Chun Wei

Yap Yan Heng

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

Q1 System and Architecture

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

Restaurant Order System

* Menu <<extends>> <<extends>> Add food detail Chef

Delete Food detail Admin

Update food Detail

View total Payment

<<extends>> Order Menu cashier Make Order <<extends>>

Software Architecture & Testing

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

Why choose to evaluate the system?

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

Q2 Stakeholder Consensus Realisation Analysis Method (SCRAM)

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

Investigating & analyzing

Testing & Evaluating Reporting

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

Software Architecture & Testing

Software Architecture & Testing

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

Q3 Software Architecture Analysis Method (SAAM)

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

Stakeholder Customer Cashier Administrator Chief Maintainer Marketing

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

Restaurant Ordering System

Software Architecture & Testing

- Customer can change the order within a period.

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

To port to another operating system.

A major re-develop may be necessary.

30 work days 12 work

To increase the respond

ASIA PACIFIC UNIVERSITY COLLEGE OF TECHNOLOGY & INNOVATION

Software Architecture & Testing

speed without affecting operation of system.