1 / 0

FIPOS: Food Industry Point Of Sale

FIPOS: Food Industry Point Of Sale. Final Project Presentation April 26, 2011. Agenda. Team Project Scope Requirements Actors Top Level Use Case Diagram System Architecture Future Capabilities Lessons Learned Project Evaluation. Our Team – Team Exception(). John Gleason

quincy
Download Presentation

FIPOS: Food Industry Point Of Sale

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. FIPOS: Food Industry Point Of Sale

    Final Project Presentation April 26, 2011
  2. Agenda Team Project Scope Requirements Actors Top Level Use Case Diagram System Architecture Future Capabilities Lessons Learned Project Evaluation
  3. Our Team – Team Exception() John Gleason Nick Mallard Kevin Hagood Michael Shrove Ashley Chafin
  4. Our Initial Idea All businesses have a need for a Point of Sale system to run efficiently. The software should be open source, so it can be modified and continually improved. This should be role based, with users having only required privileges. The system should use an external database.
  5. The Scope Evolution Initially we started out very ambitious! Initial Thoughts: One stop shop for all POS systems everywhere Customers broken down into two broad groups: Retail Industry Food Industry Main design goals: Flexible Functional
  6. The Scope Evolution (cont.) We brainstormed our initial idea and goals. … until we ran into a major problem: Our team had experience with the food industry, but NOT with the retail industry. So, we didn’t have any prior knowledge or experience to base our “customer needs” from. We developed a comprehensive set of requirements for the food industry area, but the retail industry area was bare. In the end, we did not have enough knowledge/experience on the retail side to build a good set of “customer needs.” Too many unknowns
  7. The Scope Evolution (cont.) We decided to scope down from our original idea We sorted out our “customer needs” and requirements Core Needs Things needed for the system to be functional. Nice to Have Things that were important enough, but were not core needs. Fluff Trash We prioritized the core needs and nice to have’s. Then, we tasked our iterations. Everything else was put in a possible future release.
  8. The Scope Evolution (cont.) An example of a requirement that we had to push off to our future idea list: Plug-in architecture It would allow users to add a specific set of functionality to the system Good idea, but… The added benefit was limited The implications it would have on design were too complicated for the limited time we had In the end, we removed it from our core mission and marked it for future consideration.
  9. The Scope Evolution (cont.) Having the ability to narrow down our scope prevented us from “biting off more than we could chew.” Once we started the analysis and design process, we realized our iteration tasks were not as simple as we had thought they would be. Scoping down the project gave us: Clear, unambiguous requirements More time to focus on the analysis and design of the main components of the system, rather than spreading our time over a variety of things Simple and thought out framework Which results in an easier system maintenance down the road
  10. Final Project Scope Point of sale system specifically for the food industry with a restaurant focus Focus on: Recording individual sales Managing menus Managing discounts Tracking orders Generating reports based on the POS system data Open source – most current POS systems are out dated and proprietary
  11. Final Project Scope (cont.) Data to be maintained in a database (external to POS system) The system needs to be: Reliable Fast Easy to use Role based: The view of the system will be tailored to the role of the person using the system at that time.
  12. Functional Requirements FR1: System shall authenticate a user and record “login” and “logout” times. FR2: Register and Management User’s shall be able to view, create, and modify Orders. FR3: Management User’s shall be able to void orders and manage reports, users, discounts, and menu items. FR4: Service Line User’s shall be able to view a static representation of an Order and mark an order as completed. FR5: System shall provide searching and sorting functionality for orders, discounts, menu items, and users. FR6: System shall have the ability to back up data.
  13. Non-Functional Requirements NFR1: The Database shall manage the system data. NFR2: Database shall not store authentication information in plain text. NFR3: Database shall provide an interface for manipulating system data. NFR4: System shall be accessible to all authorized users from anywhere within the restaurant intranet. NFR5: System shall be accessible from a computer with an intranet connection using a web browser. NFR6: System shall provide a role hierarchy in order to limit user privileges and keep the system secure.
  14. Actors The General User is allowed to login and logout of the system. All other roles in the system are built off this user. The Register User is allowed to Create/Modify Orders and List/Search Menu Items. The Service Line User is only allowed to list the pending orders that need to be built and mark the order completed. The Management User is allowed full reading and write access to the system. They are the only ones that can Void an order, perform a no-sale operation, and generate reports.
  15. Top Level Use Case Diagram To Backup slides (Use Cases)
  16. Top Level Architecture Our main focuses when designing the architecture: Decoupling the business, presentation, and data layers Package cohesion Reuse of common functionality Modularity Our desired result was a software architecture that successfully addresses the desired system qualities.
  17. Top Level Architecture (Revision: 70)
  18. Top Level Architecture (Revision: 103)
  19. Top Level Architecture (Revision: 105)
  20. Top Level Architecture This diagram shows the relationships between the FIPOS and the packages. The FIPOS doesn’t have a composition relationship with the packages themselves, but the manager classes within them. We realized this diagram did not show exactly what we wanted shown. See next slide.
  21. Top Level Architecture (cont.) This diagram shows the relationships between the FIPOS and the packages. It more accurately reflects the relationships to the FIPOS class.
  22. Top Level Architecture (Revision: 188)
  23. Top Level Architecture (Revision: 171)
  24. Top Level Architecture (Revision: 180)
  25. Top Level Architecture (Revision: 215)
  26. User Package Evolution (1st Iteration) Initial idea: role based system Roles: General User Register User Service Line User Management User We had a difficult time, at first, designing the role of the system.
  27. User Package Evolution (2nd Iteration) Realization of 1st Iteration Design: We did not like how the system would have to go through the users to perform tasks. New Design: We decided on one user class with a Role attribute. Role attribute is an enumeration. We think this is a much better design. The User class is more cohesive and decoupled from the rest of the system.
  28. Future Capabilities Below is a list of possible future capabilities that did not make our iteration schedule: Plug-in Framework for more specialized menu items Restaurants may develop their own plug-ins for specific menu items. Capabilities for retail customers Example: Barcode lookup, Item bar-coding, etc. More user defined roles Example: Inventory User Making the menu items and menu more flexible to the user Inventory system
  29. Lessons Learned Start small Start simple Do not be afraid to just let go We designed, designed, and designed. Eventually, having to let go some old designs for improved ones. Abstraction is your friend Abstraction allowed us to work top down, giving clarity and consistency as we worked. Abstraction helped the team to not feel overwhelmed.
  30. Project Evaluation Accomplished our revised idea Created a Point of Sale system to be used in the restaurant industry System architecture revised but not radically changed Met or exceeded goals at each iteration Clearer, more concise use cases and diagrams Refined actor roles and responsibilities Designed a good foundation architecture Further analysis and design is still possible and needed!
  31. Questions?

  32. Backup Slides

    Use Case Diagrams and Package Level Class Diagrams
  33. Activation Use Case (UCD-1) The Authentication use case is made up of the following sub-use cases: User Login User Logout Actors: General User
  34. Manage Users Use Case (UCD-2) The Manage Users use case is made up of the following sub-use cases: View User List Create User View User Delete User Modify User Search User Actors: Management User
  35. Manage Store Data Use Case (UCD-4) The Manage Discounts use case is made up of the following sub-use cases: Create Modify Remove Apply The Manage Store Data use case is made up of the following sub-use cases: Set Sales Tax Search View Sort
  36. Mange Order Use Case (UCD-5) The Manage Orders use case is made up of the following sub-use cases: Create Order View Order Mark Completed Order Modify Order Search Orders Actors: Register User Service Line User Management User
  37. Manage Reports Use Case (UCD-6) The Manage Reports use case is made up of the following sub-use cases: View Reports Create Reports Print Reports Save Reports Actors: Management User
  38. Manage Register Use Case (UCD-7) The Manage Orders use case is made up of the following sub-use cases: No-Sale Operation Backup Register Data Actors: Register User Management User Back to Main Presentation
  39. Menu Items Package
  40. Report Package
  41. Discount Package
  42. Order Package
  43. User Package
More Related