-
Notifications
You must be signed in to change notification settings - Fork 2
Project Proposal
System to manage the print request queue for Xavier University's MakerSpace.
This project's goal is to replace the current 3D-print order queuing process for the Maker Space in the Library. The upgrade was suggested by a staff member and requested by the manager. The intent of the project is to replace a manual process with an intuitive interface that ties in intuitively with the current workflow.
The current process involves a web form hosted by Xavier, file storage in Google Drive, and staff processing of user-made requests.
Thus, the scope will be bound to: a school-hosted web form, a priority queue for managing requests, a GUI for interacting with the queue, API for interacting with the queue, and staff authentication possibly tied in with Xavier's network.
The scope does not include the remote starting of 3-D print machines, nor other devices and software in the Maker Space. It will be limited to the queuing process and associated tasks.
The new system must include the following:
- Ability to allow internal users to access the application without downloading any software
- Ability to hold some amount of downloadable 3-D print files
- Ability to automatically store and delete request data
- Ability to enqueuer a request upon submission of web form
- Ability to send email with status updates to requester once job completes
- Ability to interact via a web GUI
- Ability to retain data in case of system reboot
We'll aim for incremental roll-outs for each deliverable and "install" towards the final deliverables.
- Queue system (application and database)
- Web-based GUI for staff
- Archive of historical requests (maybe excluding the 3-D print files)
- Hosting for queue
The 3-D print request queue in the MakerSpace. Part of Xavier's Library website.
Create an application and database that together work as a queue.
The application can be in any language, Java is a good contender because of its platform independence. C++ is another contender because we've already written software for a queue and are familiar with the algorithm.
The "Database" could be Google Drive, or could be any flavor of SQL compatible with our server, such as MySQL, or MariaDB. It must be built such that multiple users can access and change it at the same, which rules out SQLite.
Host said queue on a server.
This could be part of Xavier's network with Cerebro, or maybe through a raspberry pi running at the MakerSpace, or even a specialized domain/website (the latter would likely be more complex funding and security-wise).
Develop ways to interact with live queue.
We could develop a form of API that the server would handle to interact with the application. We could also tie the GUI directly to the application. That said, this is a good chance to learn about RESTful API's and modularize the design.
We should expect to hit failure at each stage in development and be prepared for changes in design, implementation, and to a lesser extent, the specifications.
Following the advice of Frederick Brooks in the Mythical Man-Month, we should spend:
- 1/3 - planning
- 1/6 - coding
- 1/4 - unit testing (debugging)
- 1/4 - integration testing (debugging)
If that is agreeable, then we can align that roughly with the scheduled deadlines of the course. We can also follow the test-driven approach so long as it ties in with our AGILE/Waterfall hybrid course timeline.
Let's aim on getting the core functionality of the queue and database such that it works on a *NIX machine first, and then expand to the hosting available to us, as that will inevitably create its own complications.
The GUI can be developed concurrently so long as the interfaces are well-defined and constant.