TWiki> SEOC Web>SEOCProject (29 Oct 2010, Main.s1032283)EditAttach

SEOC Group Project

Please add any relevant comments about the SEOC Group Project.

  • Question: does the number of students in each team affect the workload expected?
Small teams (of 2/3 people) require less coordination effort than Large teams (up to 5 people). Note that the SEOC deliverables are assessed not on quantity, but on quality criteria - Check the marking scheme http://www.inf.ed.ac.uk/teaching/courses/seoc/2010_2011/coursework/

Questions on the P&G Requirements

  • Question: "Ensures that the status of deliveries is up-to-date and visible at all times" - What should the "Status of Deliveries" include? Should it be visible to both P&G and customers
The first question is concerned with the "Status of Deliveries". The "status of deliveries" implies that deliveries (as well as orders) could be in a different state, which should me monitored throughout the process supported by the system. For instance, deliveries could be "ongoing" (meaning that deliveries are currently being despatched) or "completed" (meaning that the the goods have been delivered to the Customer delivery Points. Note that these are just sample states, the states depend on the way you interpret the requirements. Moreover, there could be some states that concern not just the deliveries, but the orders too.
The second question concerns who can view the deliveries' states, hence, what Actors can access particular system functionalities (use cases). It could be the case that Customers are able to view the states of the deliveries for their orders. However, this functionality should be further specified for P&G. For instance, P&G is able to view more information (e.g., track, exact position, etc.) than the customer. Therefore, the same functionality can be available to both Customers and P&G employees, but with different outcomes (that is, showing different set of information concerning the deliveries). Another difference i s that P&G employees should be able to access information about all deliveries.
  • Question: What if the delivery plan created by users is not a good one? Should it be cancelled?
It depends on the interpretation of the delivery planning process. It is possible to assume that the customers select a specific delivery plan (e.g., a specific order, for a specific date and a specific delivery point), which then needs to be "approved/accepted" by P&G by providing an order number. If the specific order/delivery plan is not feasible by P&G for any reason, P&G could just refuse the order/delivery plan, or propose an alternative one (which then needs to be accepted by the customer).
  • Question: "Can accept orders and plan from a minimum of 24hrs and a maximum of 7 days before delivery" - What does this requirement mean? Does it mean that from order to end of delivery can only take the time from 24hours to 7days?
Yes, it means that any order can be delivered not before 24hrs (a similar, but different requirement, is next day delivery) and not later than in 7 days. In other words, if the order has been accepted on a specific date D, the delivery can append or be requested in the period [D+1;D+7]. It is not possible to plan any delivery outside this time window.

-- Main.mfelici - 24 Sep 2010

Questions relevant to Deliveries and Plants teams as posted by a Delivery team membre:

  • Question: "Does Delivery need to account for the wagons traveling between the Plants and DC's?"
Whether Delivery/Plants or both deal with wagons on different parts of the journey between the production points and the customer is a matter which you need to discuss with your colleagues from Plants. There is no exact answer as the requirements from P&G can be interpreted in different ways and you need to make assumptions on how P&G does this and find a solution which you consider more reasonable and efficient. You could either consider that Plants will handle its wagons for the part of the journey between the production point and the DC and Deliveries for the part of the journey between DC and CDP or you could consider that Deliveries is responsible of all the transportation and needs to send a wagon to Plants each time new stock must be acquired. I have taken out the option that Plants would be responsible of the whole journey, as I consider that Deliveries, who are "delivering" products, should deal with at least part of the transportation, but I think any solution is ok as long as you make it be reasonable within your system. You need to discuss with the people from Plants about this and not make any assumptions on their behalf. On making your decision, think about time efficiency for the customer, customer satisfaction, the fact that you must load the wagons efficiently for each journey (or part of journey) (more about this in point 3), rationality of your idea as implemented within a business.
  • Question: "In efforts to determine the time it will take for products to be shipped, should Delivery teams be manually calculating the distance between the provided addresses for plants, DC's and CDP's ?"
Should Deliveries know the location of the plants on the map? So would your team need to store this information so that the whole time calculation be calculated by you- not "manually", but automatically by your code. Or would your team only calculate the time on matters it knows- the DC's locations and customer's location given in the order, and ask Plants for the rest which it would then sum up? Consider these two options and think again about efficiency, reliability- the data from Plants could change as a plant could be changing location or new plants could be built for example, time- indeed, your idea would be quicker. Again, you must also discuss this with the Plants team. And importantly, think about the stock which is available in your DC- you might not need to get products from plants after all, so you must also take this into consideration.
  • Question: "How many palettes can be loaded onto a wagon? If more than 1, do wagons need to be loaded with more than 1 palette in order to ship?"
There is no rule on this in the requirements, but you must be efficient in the way you ship things so that more orders could be shipped and more customers be satisfied. If you only send one palette in each wagon, thus the wagon is almost empty, there are not a great number of orders you could satisfy at one time, whereas a more efficient management of such things would be better for the customer and more profitable for the company. If you look at the Sample data provided on the site for the group project, you will see that a product has an associated number of products per palette field, then you have the size of a palette in the P&G requirements specification and the volume and capacity of a wagon as a field in the Sample data for wagons. Thinking about this, you must calculate how many palettes and which products to send in each wagon so that orders are to be satisfied as quickly as possible. Going back to points 1 and 2, if you as Deliveries decide to deal with wagons, you probably need to consider this too when calculating a time for making the delivery for the customer.
  • Question: "Is it appropriate to assume that each CDP is associated with a DC (i.e., the closest one)?"
Think about stock levels. What if a DC which is further away from the customer has the stock of products he needs readily available? And also think about where plants are. What if bringing products from a plant which is further away but can produce the products quicker and bring them to a DC which is again further away that the closest DC takes less to bring the product to the customer overall. You need to consider all this calculation and not assume that the closest DC will always be the one transited on the way from the plant to the customer.

-- Cristina Alexandru - 11 Oct 2010

Questions about usecases:

  • Question: "Most of our use cases include the Login use case, e.g. Select Products includes Browse Products which includes Login. We are wondering if we need to connect each of these to the User actor, or can we just link to an end of the chain?"
You link a use case to an actor if the action represented by that use case can be done directly by the actor. In the case of the log in action, an actor would normally be able to log in even if he does not start browsing products yet, so in this case the log in use case would be linked directly to the actor. In case you restrict the user from browsing products until he logs in or you allow him to choose to browse products but when doing this option you first require him to log in, the log in use case is also linked with browse products as an include coming from browse products to log in. So it is all a matter of how you think of the options given to the user. So, to sum up, if a user has an action represented by a use case as available right from the start, you link him with the use case. If this action is only required once he does some other action represented by another use case, you only link the two use cases with include and don't link the user with the use case in discussion. If both occur, like in the case in which you allow the user to both log in right from the start and choose to browse products, after which you require him first to log in, you both link the user with the use case (log in), and also link the two use cases with include (browse products and log in).

-- Cristina Alexandru - 17 Oct 2010

Questions about class diagrams:

  • Question: "Also, do we need to deal with creating new / discontinuing products or do we just assume we have a static product list?"
In what concerns products, as I probably told you at the tutorial, your separate teams' class diagrams will need to include each class at most once, and the other teams will use abstract classes or interfaces representing the classes which they would use from other teams at integration. In case of the products class, Plants are normally responsible of the products as they are the ones producing them, so Plants will have the Products class in their class diagram, while you and Deliveries will have an abstract class for products. Given the sample data provided on your assignment page on the website (look at this sample data, as it gives you clues as to the attributes you must have), you have some products there as designed by P&G. Plants would therefore create those products. They could also create more products if they choose to by simply using the Products class's constructor. Anyhow, you should not worry about the products and allow them to make this decision, you only treat products as an abstract class.

-- Cristina Alexandru - 17 Oct 2010

NetBeans Support

Question: "How can I connect to the CVS repository from within NetBeans?"

  1. Choose Team > CVS > Checkout from the main menu. The Checkout wizard opens. (See image below.)
  2. In the CVS Root field, enter: :ext:<username>@cvs.inf.ed.ac.uk:/disk/cvs/<seoc??> (where <username> is the DICE username and <seoc??> is the repository name to connect to).
  3. Select 'Use Internal SSH' then type in your DICE password.
  4. Optionally select the Remember Password checkbox so that you aren't prompted for the password during each repository access.
  5. Click Next and carry on with the wizard. When the wizard completes, it allows you to open any NetBeans projects existing in the repository in the IDE.

    netbeans-cvs.png

Question: "How can I import my NetBeans project into the CVS repository?"

To import a NetBeans project into a CVS repository, first select the project in the Projects window, then choose Team > CVS > Import into Repository. The two-step wizard guides you through the process.
Topic attachments
I Attachment Action Size Date Who Comment
docdoc srs_template-1-2.doc manage 54.5 K 05 Oct 2010 - 12:29 Main.s1056938 IEEE System Requirements Specifications template
Topic revision: r8 - 29 Oct 2010 - 00:15:55 - Main.s1032283
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies