This project uses systems engineering principles for the system-level development and design of Pepsi soda vending machine. We apply UML to the visual modeling of the system functionality and structure.
TABLE OF CONTENTS
Each day millions of coins and bills are poured into coin-operated devices. Automatic merchandising is one of today's fastest growing industries. Every day nearly 7 out of 10 people will get some product from the devices. Vending machine, coin-operated, has the greatest diversification of vending such like snack machine, Coke vending machine, snack and soda combination vending machines, bulk candy vending machines, and other specialty vending machines, medical vending, cigarette vending, phone card machines, even disposable panty vending machine.
The purpose of this project is to demonstrate systems engineering processes concerned with the step-by-step system development of Pepsi soda vending machine system, from identification of system requirements through to specification of all components and sub-systems to be designed. We will examine Pepsi soda vending machine through system-level development and design along with UML and, further, explore alternative system design whose objectives vary through the design space bounded by constraints
This case study will evolve as follows:
Approach
The systems engineering approach is used in order to determine system
structure and system behavior from user/system requirements. Once they are determined, the system logical
design is obtained.
Goals and Scenarios for Initial Use Case Modeling
Elicitation of goals and scenarios are very important phase in designing the vending machine system. This is the very first place where system requirements are generated. Once the elicitation of goals and scenarios are done, the following use case modeling is performed. This will help identify systems requirements for the vending machine.
Goal 1. The Soda Vending Machine must allow a customer buy a soda.
Scenario 1.1. When a customer feels thirsty, a customer goes to a soda vending machine to get a soda with money.
Scenario 1.2. A customer checks the availability and the price of a soda he or she wants to buy.
Scenario 1.3. A customer inserts either $1 bill or coins.
Scenario 1.4. The soda vending machine will display the amount of money deposited.
Scenario 1.5. A customer makes a selection for a soda.
Scenario 1.6. A customer gets a soda from the soda vending machine.
Scenario 1.7. A customer will get the change if there is the difference.
Scenario 1.8. A customer leaves after he or she gets a soda.
Goal 2. The Soda Vending Machine must allow a supplier to restock sodas and change.
Scenario 2.1. With fixed period of time, a supplier goes to the soda vending machine to restock sodas and change.
Scenario 2.2. The supplier exposes the inside of the soda vending machine by unlocking the lock.
Scenario 2.3. The supplier restocks both sodas and change according to sales.
Scenario 2.4. The supplier secures the soda vending machine after restocking.
Goal 3. The Soda Vending Machine must allow a supplier to collect the accumulated money from the soda vending machine.
Scenario 3.1. With fixed period of time, a supplier goes to the soda vending machine to collect the accumulated money.
Scenario 3.2. The supplier exposes the inside of the soda vending machine by unlocking the lock.
Scenario 3.3. The supplier collects the accumulated money.
Scenario 3.4. The supplier secures the soda vending machine after collecting the money.
Initial Use Case Modeling
The Unified Modeling Language (UML) is a tool used to illustrate how systems work. It is be very useful in describing a system visually and diagramming components, interactions, and relationships. The development of initial use case models is required to identify overall system requirements through elicitation of goals and scenarios. In initial step, a use case describes a single goal and all possible scenarios that can happen in system usage.
The purpose of the initial use case modeling is to provide high-level framework and traceability for the system functionality, expected performance, and system requirements. In this case study several use cases will be expanded to cover detailed functionality of the soda vending machine.
Identify Actors
In the initial use case of the soda vending machine the actors are as follows:
|
|
Customer. | A person who buys a soda from the soda vending machine. |
Supplier. | A person who a soda company hired to restock sodas and change to a soda vending machine with a contract. Also, the person collects the money accumulated in the soda vending machine. |
Power Source. | A soda vending machine will be connected to AC/DC power source of a building. |
Soda. | A product that is provided for a customer. |
Money. | The money that is needed to get soda by a customer, i.e., $1 bill or coins. |
Change. | Coins needed to return the difference after delivering the soda product. Also it is needed to restock by a supplier. |
System Boundary
System boundary is about what things are inside the system and what are outside the system. It is defined by identifying the actors and the use cases. The system boundary of the soda vending machine is defined by the machine itself that has an interface which receives information from external system and delivers the proper outputs. A customer, a supplier, money, and power sources are all external systems.
Baseline (Textual) Initial Use Cases with Activity Diagrams
In this section baseline use cases are described and activity diagrams are presented to make up the initial use cases.
Use Case (1): Buy Soda.
Figure 1. Activity diagram for "Customer buys a Soda with Money."
Use Case 2: Restock Soda and Coins.
Figure 2. Activity diagram for "Supplier restocks Sodas and Change."
Use Case 3: Collect Money.
Figure 3. Activity diagram for "Supplier collects Money from Machine."
Initial Use Case Diagram
Figure 4. Initial Use Cases Diagram of Pepsi Soda Vending Machine
Expanded Use Case Modeling
Before developing detailed design, some of expanded use cases are needed to provide a level of specification consistent with design details that will appear in the initial logical and physical design.
Elicitation of Goals and Scenarios
Goal 1. The Soda Vending Machine must show its availability.
Scenario 1.1. When a customer presses a selection button for a soda before he or she inserts money, the soda vending machine shows the price of the soda he or she wants to buy.
Scenario 1.2. If any soda selected is out of stock, the soda vending machine displays “Sold Out” message.
Goal 2. The Soda Vending Machine must provide a cool soda.
Scenario 2.1. At power on, the soda vending machine will make sodas cool automatically.
Goal 3. The machine must allow a customer to deposit money.
Scenario 3.1. A customer inserts money to the bill or coin acceptor.
Scenario 3.2. If the money inserted can be scanned successfully, the soda vending machine will accept the money.
Scenario 3.3. If the money inserted can not be scanned successfully, the soda vending machine will reject the money.
Scenario 3.4. If a customer changes his mind not to buy a soda, he or she will press “Return” button at any time to get the money deposited back.
Goal 4. The machine must allow a customer to deposit $1 bill.
Scenario 4.1. When the bill receiver is operating normally, it flashes to a customer.
Scenario 4.2. If the bill receiver is not working, it will not flash.
Scenario 4.3. When the bill receiver is not operating, it will automatically reject the $ 1 bill if a customer tries to insert.
Scenario 4.4. A customer inserts $1 bill to the bill receiver.
Scenario 4.5. If the $1 bill inserted can be scanned successfully, the bill receiver will accept the money.
Scenario 4.6. If the money inserted cannot be scanned successfully, the bill receiver will reject the money.
Goal 5. The machine must allow a customer to deposit coins.
Scenario 5.1. If the soda vending machine does not have enough change, it will show a signal, “Use Exact Change.”
Scenario 5.2. A customer inserts coins to the coin receiver.
Scenario 5.3. The coin receiver will accept only nickel, dime, and quarter.
Scenario 5.5. If the coins inserted can be scanned successfully, the coin receiver will accept the coins.
Scenario 5.6. If the coins inserted can not be scanned successfully, the coins receiver will reject the coins.
Goal 6. The machine must allow a customer to make a selection for the soda he or she wants to buy.
Scenario 6.1. A customer presses the selection button for the soda he or she wants to buy.
Scenario 6.2. If the soda selected is sold out, the soda vending machine will display “Sold Out” message.
Goal 7. The Soda Vending Machine must deliver a soda product through the dispenser window.
Scenario 7.1. After the selections, the soda vending machine will deliver a soda product.
Scenario 7.2. After the delivery, a customer will pick up the soda product through the dispenser.
Goal 8. The Soda Vending Machine must return the change if there is any difference through the change window.
Scenario 8.1. After the selections, the money is stored into the money repository.
Scenario 8.2. If there is any difference, the soda vending machine will return the change.
Scenario 8.3. A customer picks up the change through the change window.
Goal 9. The Soda Vending Machine must allow a supplier to restock sodas and change.
Scenario 9.1. A supplier unlocks the soda vending machine.
Scenario 9.2. A supplier pulls open the front of the soda vending machine.
Scenario 9.3. A supplier checks the current amount of the stock and change.
Scenario 9.4. If there is need to restock sodas and change, a supplier restocks sodas and change.
Goal 10. The Soda Vending Machine must allow a supplier to secure the front of the soda vending machine.
Scenario 10.1. After restocking, a supplier closes the front of the soda vending machine.
Scenario 10.2. A supplier secures the soda vending machine.
Scenario 10.3. A supplier leaves.
Expanded Use Case Modeling
Baseline (Textual) Use Cases with Activity Diagrams
In this section baseline use cases are described and activity diagrams are presented to make up the expanded use cases.
Use Case 1: Check Availability and Price of a Soda.
Figure 5. Activity Diagram for "Check Availability and Price of a Soda."
Use Case 2: Decide Type of Payment.
Figure 6. Activity Diagram for "Decide type of Payment."
Use Case 3: Use $1 Bill.
Figure 7. Activity Diagram for "Use $1 Bill."
Use Case 4: Use Coins.
Figure 8. Activity Diagram for "Use coins."
Use Case 5: Make a Selection for a Soda.
Figure 9. Activity Diagram for "Make a Selection for a Soda."
Use Case 6: Get Soda.
Figure 10. Activity Diagram for "Get Soda."
Use Case 7: Get Change.
Figure 11. Activity Diagram for "Get Change."
Use Case 8: Expose Inside of the Machine.
Figure 12. Activity Diagram for "Expose Inside of the Machine."
Use Case 9: Secure the Machine.
Figure 13. Activity Diagram for "Secure the Machine."
Expanded Use Case Diagram
The expanded use case diagram is as follows:
Figure 14. Expanded Use Cases Diagram of Pepsi Soda Vending Machine
Organization of Use Cases
At this point the use cases for the soda vending machine system are identified and defined. It is important from system behavior modeling perspective to organize the use cases first so that we can get a very high level relationship between use cases.
Figure 15. Organized Use Case Diagram
Generation of System Requirements
The development of both initial and expanded use case models was required to identify system requirements through elicitation of goals and scenarios.
The requirements for the Pepsi soda vending machine are as follows:
1. Performance Requirements
1.1. The soda vending machine shall dispense the right soda for a selection.
1.2. The soda vending machine shall return the right change.
1.3. The soda vending machine shall scan both $1 bill and coins.
1.4. The soda vending machine shall return exact amount of money if a customer presses a return button at any time.
2. Human Factors Requirements
2.1. The selection buttons shall be placed at distance where two adjacent selection buttons cannot to be pressed by one finger.
2.2. The change dispense window shall prevent coins from coming out of the window.
2.3. The dispenser of the soda vending machine shall be located within arm’s reach.
2.4. The soda dispense window shall keep a soda from coming out of the window.
2.5. The bill or coin acceptor shall be placed within arm’s reach.
2.6. The soda vending machine shall have rack for restocking soda.
2.7. The soda vending machine shall have rack for restocking coins.
3. User Interface Requirements
3.1. After money is deposited, the amount of money shall be displayed on display window.
3.2. When a selection button for a soda is pressed, the soda vending machine shall display either the price of the soda selected or "Sold Out" message on display window.
3.3. After a soda is dispensed, the difference shall be displayed on display window.
3.4. The bill acceptor of the soda vending machine shall blink if it is working.
3.5. The selection buttons shall show the product information of a soda.
3.6. The information of available coin that a customer can use shall be presented near the coin acceptor on the front of the soda vending machine.
3.7. The information that a customer can use only $1bill shall be presented near the bill acceptor on the front of the soda vending machine.
3.8. The soda vending machine shall have a set of selection buttons for soda.
4. Functional Requirements
4.1. The soda vending machine shall show the price of a soda selected when a customer pushes a selection button.
4.2. If the soda vending machine does not have a soda for selection, it shall display "Sold Out" message when a customer presses a selection button.
4.3. If the soda vending machine has less than 35 cents of change, it shall display "Use Exact Change" message.
4.4. The soda vending machine shall scan $1 bill with sensor.
4.5. The soda vending machine shall scan only nickel, dime, and quarter with sensor.
4.6. The soda vending machine shall reject both $1 bill and coins if the scanned data is different from the default data.
4.7. The soda vending machine shall memorize the scanned data of money.
4.8. The soda vending machine shall show the amount of money deposited.
4.8. The soda vending machine shall show the amount of money deposited. 4.9 The soda vending machine shall calculate the difference if the amount of money deposited is greater than the price data of a soda.
4.10. The soda vending machine shall show the remaining difference if the amount of money deposited is greater than the price data of a soda.
4.11. The soda vending machine shall store the money deposited after selection is made.
4.12. The soda vending machine shall return the difference if the amount of money deposited is greater than the price data of a soda.
4.13. The soda vending machine shall make sodas in stock cool.
4.14. The bill acceptor of the soda vending machine shall blink a light to show that it is working.
4.15. The soda vending machine shall not accept money any longer after the amount of money deposited excesses $1.
4.16. The bill and coin acceptor shall reject money if it fails to scan.
4.17. The soda vending machine shall be capable of checking the remaining stock of soda.
5. Security Requirements
5.1. The soda vending machine shall be unlocked only a supplier.
5.2. The soda vending machine shall be secured only by a supplier.
5.3. The soda vending machine shall not be broken by vandal.
5.4. The money storage box shall have a different security device.
We use statechart diagram to show the system behavior. First, high level statechart diagram is given to show the overall system behavior, and then detailed statechart diagrams are used to show more specific system behavior.
Behavior (Availability Displayed State)
Figure 16. Statechart diagram for "Overall System Behavior."
Detailed System Behavior (Availability Displayed State)
Figure 17. Activity diagram for "Availability Displayed State."
Detailed System Behavior (Ready State)
Figure 18. Activity diagram for "Ready State."
Detailed System Behavior (Collected/Restocked State)
Figure 19. Activity diagram for "Collected/Restocked State."
Detailed System Behavior (Deposited State)
Figure 20. Activity diagram for "Deposited State."
Detailed System Behavior (Dispensed State)
Figure 21. Activity diagram for "Dispensed State."
Detailed System Behavior (Selected State)
Figure 21. Activity diagram for "Selected State."
Here are the key components and subsystems that are needed for the system structure are identified.
Component Definition
High-Level System Structure
Figure 22. Simplified Model of System Structure.
Low-Level System Structure
Figure 23. Simplified Model of System Structure.
This section describes the logical design phase of Pepsi soda vending machine system. At this phase, high-level decisions about component usage and integration, based on the conceptual design, are made. Use cases are used to construct a logical model of the vending machine. At the close of this process, a logical design will have been developed, which is the basis for the physical design phase of Pepsi soda vending machine.
Figure 24. Schematic of Logical Design.
The goal of the logical phase is to convert the functions that were defined in system behavior model into an abstract model that identifies the cooperating logical components that support. The resulting logical design does not identify specific technologies. Instead, the objective of this phase is to analyze and understand the functionality before making any technology commitments.
The things needed in the creation of a logical design are the objects (the components) that will provide the required functionality, the behaviors, and relationships that each object (component) has.
Use Case/Component Task Interaction Matrix
The following matrix provides traceability from use cases to system components that implement these requirements. It shows why each system-level component is required.
Use Cases Requirement |
Buy Soda |
Restock Soda & Change |
Collect Money |
Secure the Machine |
Expose Inside of the Machine |
|||||
Check Availability & Price of Soda |
Decide Type of Payment |
Make Selection for a Soda |
Get Soda |
Get Change |
||||||
Use $1 Bill |
Use Coins |
|||||||||
Power System |
X |
X |
X |
X |
X |
X |
X |
X |
|
|
User Interface System |
X |
X |
X |
X |
X |
X |
|
|
|
|
Coin/Bill Processing System |
|
X |
X |
X |
|
X |
X |
X |
|
|
Main Processor |
X |
X |
X |
X |
X |
X |
X |
X |
|
|
Soda Dispense System |
X |
|
|
X |
X |
|
X |
|
|
|
Security System |
|
|
|
|
|
|
X |
X |
X |
X |
Cooling System |
|
|
|
|
X |
|
|
|
|
|
The following traceability matrix shows how use cases trace to groups of requirements and how individual requirements have been taken into account in the system-level design.
Use Cases Requirement |
|||||||||||
Performance |
|
|
|
X |
X |
|
|
|
|
|
|
|
|
|
|
X |
X |
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
||
|
X |
X |
X |
|
X |
|
|
|
|
||
Human Factors |
X |
|
|
X |
|
|
|
|
|
|
|
|
|
|
|
|
X |
|
|
|
|
||
|
|
|
|
X |
|
|
|
|
|
||
|
|
|
|
X |
|
|
|
|
|
||
|
X |
X |
|
|
|
|
|
|
|
||
|
|
|
|
|
|
X |
|
|
|
||
|
|
|
|
|
|
X |
X |
|
|
||
User Interface |
|
X |
X |
|
|
|
|
|
|
|
|
X |
|
|
X |
|
|
|
|
|
|
||
|
|
|
X |
|
X |
|
|
|
|
||
|
X |
|
|
|
|
|
|
|
|
||
X |
|
|
X |
|
|
|
|
|
|
||
|
|
X |
|
|
|
|
|
|
|
||
|
X |
|
|
|
|
|
|
|
|
||
X |
|
|
X |
|
|
|
|
|
|
||
Functional |
X |
|
|
X |
|
|
|
|
|
|
|
X |
|
|
X |
|
|
|
|
|
|
||
|
|
X |
|
|
|
|
|
|
|
||
|
X |
|
|
|
|
|
|
|
|
||
|
|
X |
|
|
|
|
|
|
|
||
|
X |
X |
|
|
|
|
|
|
|
||
|
X |
X |
X |
X |
X |
|
|
|
|
||
|
X |
X |
X |
X |
X |
|
|
|
|
||
|
|
|
X |
X |
|
|
|
|
|
||
|
|
|
X |
X |
|
|
|
|
|
||
|
|
|
X |
|
|
|
|
|
|
||
|
|
|
X |
X |
X |
|
|
|
|
||
|
|
|
|
X |
|
|
|
|
|
||
|
X |
|
|
|
|
|
|
|
|
||
|
X |
X |
|
|
X |
|
|
|
|
||
|
X |
X |
|
|
X |
|
|
|
|
||
X |
|
|
X |
|
|
X |
|
|
|
||
Security |
|
|
|
|
|
|
|
|
|
X |
|
|
|
|
|
|
|
|
|
X |
|
||
|
|
|
|
|
|
|
|
X |
|
||
|
|
|
|
|
|
|
X |
|
|
Since Soda Vending Machine is a profit-making tool of a supplier, the design strategy is to include the system’s functionality features that may yield high revenue with low cost. Thus the measurements of system effectiveness are mainly related to two categories, which are “preference” of the consumer and/or supplier, and “cost”.
Decision Criteria
Followings are possible contributions to the “preference”:
Followings are sub-categories of Cost
To enable consistent and rational decision making, we will use pair-wise comparison method to evaluate the above subjective and non-quantifiable criteria.
For the case using pair-wise comparison method, a good number of alternatives to generate are three because three alternatives can neatly represent both ends and the middle of a continuum or spectrum of potential solutions. One alternative represents the low end of the spectrum. Low-end solutions are the most conservative in terms of the effort, cost, and technology involved in developing a system. This strategy provides nothing but all the required functionality.
Another alternative represents the high end of the spectrum. High-end alternatives go beyond simply providing minimum required functionality and focus instead on systems that contain many extra features it may be desired. Functionality, not cost, is the primary focus of high-end alternatives. A high-end alternative will provide some desired features using advanced technologies, which often allow the system to expand to meet future requirements. Finally the third alternative lies between the extremes of the low-end and high-end systems. Such alternatives combine the frugality of low-end alternatives with the focus on functionality of high-end alternatives. Midrange alternatives represent compromise solutions. There are certainly other possible solutions that exist outside of these three alternatives. Defining the bottom, middle, and top possibilities allows drawing bounds around what can be reasonably done.
Our three Design alternatives are as follows:
Alternatives |
Design Options |
Alternative A (Low end) |
Accept coins only (No Bill Acceptor) |
Alternative B (Midrange) |
Accept coins and bill |
Alternative C (High end) |
Accept coins, bill and credit card Audio direction/feedback Integration with web system |
The analytic hierarchy process (AHP) is a good way to display and compare the design alternatives with non-quantifiable multi-criteria, which is used to arrive at a ratio-scale cardinal ranking of alternatives for multi-attribute decision problems. AHP is especially suitable for complex decisions which involve the comparison of decision elements which are difficult to quantify. It is based on the assumption that when faced with a complex decision the natural human reaction is to cluster the decision elements according to their common characteristics. It involves building a hierarchy (Ranking) of decision elements and then making comparisons between each possible pair in each cluster (as a matrix). This gives a weighting for each element within a cluster (or level of the hierarchy) and also a consistency ratio (useful for checking the consistency of the data).
The principle of the AHP relies on the pairwise comparison. This comparison is carried out using a scale from 1 to 9 as follows:
Scale | Interpretation |
1 | Equally preferred |
2 | Equally to moderately preferred |
3 | Moderately preferred |
4 | Moderately to Strongly preferred |
5 | Strongly preferred |
6 | Strongly to Very Strongly preferred |
7 | Very Strongly preferred |
8 | Very to Extremely Strongly preferred |
9 | Extremely preferred |
It is necessary to know if one has been consistent in one's pairwise comparisons in order to accept the result of this process. The parameter that is used to determine if an acceptable selection has been made is the Consistency Ratio.
Pairwise comparison of Decision Criteria
The results of the pairwise comparison for decision criteria are shown in the following table. Also, confidence ratio (CR) is calculated.
|
Flexibility |
Ease-of-Use |
Reliability |
Tracking |
Fixed Cost |
Variable Cost |
Weight |
Flexibility |
1 |
5 |
4 |
5 |
2 |
3 |
0.38 |
Ease-of-Use |
1/5 |
1 |
1/2 |
1 |
1/4 |
1/3 |
0.06 |
Reliability |
1/4 |
2 |
1 |
2 |
1/3 |
1/2 |
0.10 |
Tracking |
1/5 |
1 |
1/2 |
1 |
1/4 |
1/3 |
0.06 |
Fixed Cost |
1/2 |
4 |
3 |
4 |
1 |
2 |
0.25 |
Variable Cost |
1/3 |
3 |
2 |
3 |
1/2 |
1 |
0.16 |
|
2.48 |
16.00 |
11.00 |
16.00 |
4.33 |
7.17 |
1.00 |
Confidence Ratio (CR) = 0.0130
Comparing Alternatives for each Criterion
We now compare the three alternatives with respect to each of the decision criteria. The results of the comparison of alternatives for each criterion are shown in the following table. Also, confidence ratio (CR) for each criterion is calculated.
Flexibility |
Alt. A (Low-End) |
Alt. B (Mid Range) |
Alt. C (High-End) |
Weight |
Alt. A (Low-End) |
1 |
1/7 |
1/8 |
0.06 |
Alt. B (Mid Range) |
7 |
1 |
1/2 |
0.35 |
Alt. C (High-End) |
8 |
2 |
1 |
0.58 |
|
16.00 |
3.14 |
1.63 |
1.00 |
Confidence Ratio (CR) = 0.030
Ease-of-Use |
Alt. A (Low-End) |
Alt. B (Mid Range) |
Alt. C (High-End) |
Weight |
Alt. A (Low-End) |
1 |
1 |
1/2 |
0.25 |
Alt. B (Mid Range) |
1 |
1 |
1/2 |
0.25 |
Alt. C (High-End) |
2 |
2 |
1 |
0.50 |
|
4.00 |
4.00 |
2.00 |
1.00 |
Confidence Ratio (CR) = 0.000
Reliability |
Alt. A (Low-End) |
Alt. B (Mid Range) |
Alt. C (High-End) |
Weight |
Alt. A (Low-End) |
1 |
2 |
3 |
0.52 |
Alt. B (Mid Range) |
1/2 |
1 |
3 |
0.33 |
Alt. C (High-End) |
1/3 |
1/3 |
1 |
0.14 |
|
1.83 |
3.33 |
7.00 |
1.00 |
Confidence Ratio (CR) = 0.046
Tracking |
Alt. A (Low-End) |
Alt. B (Mid Range) |
Alt. C (High-End) |
Weight |
Alt. A (Low-End) |
1 |
1 |
1/3 |
0.20 |
Alt. B (Mid Range) |
1 |
1 |
1/3 |
0.20 |
Alt. C (High-End) |
3 |
3 |
1 |
0.60 |
|
5.0 |
5.0 |
1.67 |
1.00 |
Confidence Ratio (CR) = 0.000
Fixed Cost |
Alt. A (Low-End) |
Alt. B (Mid Range) |
Alt. C (High-End) |
Weight |
Alt. A (Low-End) |
1 |
2 |
5 |
0.57 |
Alt. B (Mid Range) |
1/2 |
1 |
4 |
0.33 |
Alt. C (High-End) |
1/5 |
1/4 |
1 |
0.10 |
|
1.70 |
3.25 |
10.00 |
1.00 |
Confidence Ratio (CR) = 0.021
Variable Cost |
Alt. A (Low-End) |
Alt. B (Mid Range) |
Alt. C (High-End) |
Weight |
Alt. A (Low-End) |
1 |
2 |
6 |
0.58 |
Alt. B (Mid Range) |
1/2 |
1 |
5 |
0.34 |
Alt. C (High-End) |
1/6 |
1/5 |
1 |
0.08 |
|
1.67 |
3.20 |
12.00 |
1.00 |
Confidence Ratio (CR) = 0.025
Grand weight of the three alternatives is shown in the following table.
|
Flexibility |
Ease-of-Use |
Reliability |
Tracking |
Fixed Cost |
Variable Cost |
Weight |
|
|
|
|
|
|
|
|
Alt. A (Low-End) |
0.06 |
0.25 |
0.52 |
0.20 |
0.57 |
0.58 |
0.33 |
Alt. B (Mid Range) |
0.35 |
0.25 |
0.33 |
0.20 |
0.33 |
0.34 |
0.33 |
Alt. C (High-End) |
0.58 |
0.50 |
0.14 |
0.60 |
0.10 |
0.08 |
0.34 |
The table above shows the best of the three options having the highest value is alternative C. However the differences among the numerical value of grand weights are merely small so we can conclude that there is no meaningful difference of priority among the three alternatives.
Alternative A and B have same weight even though alternative B offers much higher flexibility with bill acceptor. That is because alternative A has relatively more preference in the following three criteria: reliability and fixed and variable cost.
Advantages and Disadvantages of Ranking
The ranking approach to deriving criterion weights is attractive due to its simplicity. In practice, however, the number of criteria limits the practicality of using ranking. The larger the number of criteria the more difficult it is to arrive at a reliable ranking. One limit for the number of criteria, derived from psychometrics, is 7+-2. This means that on average humans are capable of discriminating, at the maximum, among 9 different entities (nine different importance levels that can be assigned ranks). This limitation can be overcome by using hierarchical ranking schemes. Another limitation of ranking is the lack of its theoretical foundations.
Advantages and Disadvantages of Ranking
Rating is easy to understand by using the analogy of
distributing a fixed amount of money, on the priority basis, across a set of
objectives represented by evaluation criteria. However, rating, similarly to
ranking, lacks theoretical foundations and its practicality is limited to a
small number of criteria. The approach may be misused if the DM does not pay
attention to the definition of criteria and ranges of criterion values.
Advantages and Disadvantages of Pairwise Comparisons
Pairwise comparison, in contrast to ranking and rating, has a solid theoretical foundation based on ratio-scale judgments about pairs of criteria and the properties of reciprocal matrix of pairwise comparisons. The advantage of this technique is that information can be used from handbooks, regression output, or decision makers/experts can be asked to rank-order individual factors. The disadvantage of pairwise comparison is a large number of judgements that must be made when the number of criteria is large.
Developed by Jeon, Kwan Yong and Chun, Duk-hi, May 2002.
Reformatted and slightly modified by Mark Austin, September 2002
Copyright © 2002, Jeon, Kwan Yong, Chun, Duk-hi,
and Mark Austin. University of Maryland.