Bringing It Together Robbie Robot Shop
Introduction
Robbie Robot Shop (RRS) is a fledgling start up in the exciting field of robotics. They are seeking bright young programmers to build a custom solution for defining new robot products using their growing patented line of modular components, tracking customers and the robots they buy, rewarding their sales people well enough to keep them motivated, and otherwise taking care of business.
Your job is to win this project from RRS by producing a proposal package, including a prototype that wows and other creative and persuasive artifacts that prove you know your stuff. You have exactly 6 weeks to deliver RRS Manager (Prototype) v1.0 with your proposal package, at first featuring a glorious text menu or command line interface (CLI), and then finally a thoroughly compelling Graphical User Interface (GUI).
Overview
Robbie Robot Shop assembles their robots from 5 different components - a torso, head, arm(s), locomotor, and battery(ies). A Product Manager (PM) defines new robot models from these components, assigns a product name and price, writes up a brief sales description, and approves the result. The robot then appears at their Point Of Sale (POS) systems so that their Sales Associates (SA) can arrange for their Beloved Customers (BC) to order them, as well as on their web store so that BCs can order them direct. The Pointy-haired Boss (PB) will need to track profit margins, sales, and such from the robot product lines to ensure the business is profitable.
Requirements
The Product Owner has identified the needs of each of the actors that will interact with the system, and has assembled these into a prioritized Product Backlog in the Scrum spreadsheet, which is included in this set of Requirements by reference.
Product Manager (PM)
The PM needs to be able to create new instances of robot components in the system. For each component, they need to specify a name, part number, type (torso, head, arm, locomotor, or battery), weight, cost, and a brief description. In addition, some types of components need additional data: each torso may have from 1 to 3 battery compartments, each locomotor should specify a maximum speed (in MPH) and power consumed when operating (in watts), each arm should specify power consumed when operating (in watts), and each battery should specify the energy it contains (in kilowatt hours).
The PM needs to be able to define new robot models by selecting one or more of each type of robot component. Only one component of each type may be added, except that up to 2 arms and as many batteries as will fit into the selected torso may be attached. For each robot model, the PM also needs to define a model name, model number, and price. They will want to know the total cost of all components when setting the price to ensure adequate profit for each model.
Beloved Customer (BC)
A BC needs to be able to browse the catalog of robots, with pictures (eventually - not expected on the command line version), prices, shipping costs, and description at the POS terminal and (eventually) on the web store. Each customer will also need to view their orders and their outstanding bill.
Sales Associate (SA)
A Sales Associate (SA) needs to order robot models for Beloved Customers and present a bill of sale listing the order number, date of sale, customer name, robot(s) ordered, and price (subtotal, shipping, tax, and total). Each Sales Associate would like a sales report for the sales they personally completed with which to lobby for a raise.
Pointed-haired Boss (PB)
The Boss needs to know overall shop metrics, such as the profit margin on each robot and how many were sold, a complete list of orders during a specified period, and sales for each Sales Associate with which to approve or deny requests for raises.
Process
Each developer will continue to follow the simplified Scrum process, but with a complete Product (or Feature) Backlog that covers the full anticipated scope of the project.
As before, the developer is free to negotiate changes to the Product Backlog features and priority with the Product Owner (the Boss). An approved change order is still required.
You must provide your own updated UML models and design your own menus - that's basic requirement of the project. An incomplete UML class diagram is provided, but you must provide a complete diagram yourself. Update your UML design before you start coding - that's just good OO!
However, you must use FLTK 1.3.x to implement your GUI. You may also consider third party libraries that have been approved in advance by the Product Owner in writing.
Whether the project is individual or team-based, the product baseline should be built frequently - at least once per day - and all of the automated tests run to identify any breakage that needs to be added to the Sprint Backlog of tasks, prioritized, and addressed.
Deliverables
Each developer or team is required to use the git version management system, and may optionally use GitHub. An archive of the current, stable git repository with commit history or a GitHub link with access granted to the Product Owner and grader, representing that sprint's deliverable-ready milestones, must be delivered to Blackboard every week.
Each developer or team is required to maintain and work from the Product Backlog and (for each sprint) the Sprint Backlog, using the Scrum spreadsheet provided.
Each developer or team is required to maintain and work from a UML design, updated as the project progresses. These will include at a minimum a class diagram and use case diagram, and eventually a state diagram when the associated feature is implemented.
The proposal package will include:
1. Archive of the local git repository or link to the Github repository, showing all code commits in source code form.
2. The Scrum spreadsheet representing the total project
3. Supporting UML diagrams including at a minimum a use case diagram, class diagram, and state diagram that accurately reflects the code, with additional consideration given for other useful supporting diagrams.