Reason Chosen: it is important that this assumption be part of our problem solution as one of the key issues that the problem solution must address is that of transportation costs.
How it affects the model: In the model, assuming that each car used has fixed operating cost allows us incorporate it if the delivery vehicle is needed to make the trip.
Real World Application: There is an additional cost for each delivery vehicle that we decide to use in the delivery process.
Reason Chosen: this assumption has been added to prevent more than one delivery vehicle from visiting a given customer (in this case, even if the physical customer is the same individual, separate orders are considered separate customers).
How it affects the model: This assumption is reflected in the model by the constraint that indicates that only one entering arc to a customer node may be used in a feasible solution to the network problem.
Real World Application: In a real world situation, It is clear that it is not feasible for a product such as pizzas to be divided up into fractions for delivery. It is important to realize that in most cases a customer would expect their whole order to be delivered to them at one time. Additionally, it should not even be a consideration in most cases, as it will probably be more efficient to ship an entire order to a customer in one car than in separate cars – it would just mean that more than one car would have to visit the same customer, increasing operating expenses. Thus, there is no real compromise in terms of real world application in the solution to this problem.
Reason Chosen: The node demands must be determined in some artificial way, as the problem being assessing is, essentially a theoretical one at present. The most appropriate way is to examine past trends of demand and include any other criteria that might possibly affect the model.
How it affects the model: The node demands indicated in the model were arrived at by careful assessment of the aforementioned factors. These customer demands should be typical of customer demands that would be present if the delivery business were to be implemented in reality.
Real World Application: In reality, the customer demands for pizza will generally fall within a given range, with some exceptions. Some factors to include in calculating the expected requirements of a customer node are:
Reason Chosen: Since vehicles do not presently exist for pizza transportation, it is convenient for inclusion in our problem to simply assume one typical value for the capacity of a delivery vehicle.
How it affects the model: For our model, the constraints that represent the arc capacities on all the arcs can all be the same.
Real World Application: It may be true that by assuming a fixed value for transport vehicle capacity, there are compromises made. By taking the average expected vehicle capacity, however, general conclusions that have application to reality can be drawn. In order to simplify the model in question and avoid guessing different possible vehicle capacities with respect to customer orders, a fixed capacity has been assumed with little loss to real world applicability.
Reason Chosen: The assessment of traffic conditions would require some type of dynamic updating to any model chosen based upon projected time which is beyond the scope of this project.
How it affects the model: This assumption allows all of the arc costs in the network to be fixed at a value based upon distance and other transportation factors. In short, one value can be decided for each arc.
Real World Application: This assumption does reduce the application of the model to real world situations, but to compensate, the arc costs can be calculated by average transportation times, weather conditions, road speed limits, time of day and average traffic level. The difficulty for any kind of dynamic model is very high and would not necessarily give the model more accuracy. Using fixed arc costs based upon the factors noted should give an accurate indication of the time involved.
Reason Chosen: It is beyond the scope of our model to account for the situation in which delivery becomes infeasible. For the average case, it is assumed that delivery will run relatively smoothly and no breakdowns will occur en route to a customer.
How it affects the model: The model created to solve this problem is one that has a feasible and optimal solution. If the case where it is impossible to deliver to a customer were examined, then a network that was infeasible would have to be examined. Without a feasible or optimal solution, it is doubtful that much information would be gained from such a model.
Real World Application: In the real world, it is always possible that a vehicle breakdown or accident occurs. Such occurrences should be in the small minority of deliveries, and by not including the possibility of an accident, the value of the model is not degraded significantly.
Reason Chosen: A continuous model can be made by repeating the solving of a model that addresses one typical "iteration" of the delivery system. The actual implementation of a continuous delivery system is beyond the scope of this project.
How it affects the model: The model, when solved, shows the optimal solution of the delivery problem. Given one set of customers and a given number of delivery vehicles, the model determines the optimal paths for the vehicles. The model is static and can only represent one iteration of the delivery process. More iterations would be required to represent a dynamic model with virtually all factors changing on a regular basis.
Real World Application: A more useful model would be a continuous one in which a test case over a period of time was taken into account. The single example in this presentations model, however should serve as a basis for any future work on the problem and should give a good indication of the time involved in delivery and how the factors that have been identified affect the solution to the problem.
Reason Chosen: Any customer demand greater than the capacity of a delivery vehicle would be taken in stages. In addition, such deliveries should be in the minority.
How it affects the model: This assumption can actually be taken account for in the model used. Instead of using the actual demand of a customer as a node demand, the demand can be split into separate demands and made into different nodes or the problem can be reiterated to deal with the unfulfilled node demand at a later time (in the next delivery iteration).
Real World Application: There should be few time in which the shop receives requests for more pizzas than will fit into one delivery vehicle. Thus there is little loss of application in making this assumption.