OVERVIEW
SUMMARY
The Key Tracker allows the Facilities Keys Office to manage their key inventory. The existing key tracking application, which was developed 15 years ago, currently resides on an old VAX and Ingres database. We have been asked to migrate it to a web-based application with an Oracle database.
GOALS
- Migrate the application while the existing environment is still stable
- Create a user-friendly interface that makes it easy for the Keys Office to get their job done
TEAM
Programmer: Joshua Dale
DBA: Peter Maloof
CUSTOMERS
The Keys Office.
TECHNICAL
SVN LOCATION
svn+ssh://svn.mit.edu/pmdashboard
DEVELOPMENT ENVIRONMENT
PHP 5.2
Cake 1.1.15.x (the latest stable, non 1.2 version)
Oracle - whatever version Ops currently recommends
Apache - whatever version Ops currently recommends
FUNCTIONALITY
The functionality will match the current system. Functionality is fully described in the Key System User Guide printout. Most user actions are CRUD - create, read, update, or delete records. Functionality includes:
- CRUD a key
- CRUD room information
- CRUD key holder information
- CRUD department information
- assign keys
- transfer keys from one holder to another
- keyoholder returns key
- keyholder loses key
- show key inventory
- show rooms and keys brief list
- show key inventory
- show key holders and their keys
- show keys assigned to key holders
- show report list
- run reports
We need more information about reports. The user guide names nine reports, but doesn't give a detailed description of what they show. We may be able to copy the SQL from the existing system.
PROJECT PLAN
This will be an agile-flavored project, using several short iterations with visible results at the end of each. The order of iterations may change.
Iterations:
... in progress ...
1. Hello, World!
GOAL: set up environment, make sure all the pieces are in place ( dev environment, server, databases, apache configured correctly, svn)
DELIVERABLES: Deploy a simple Cake-generated page to server. Page should do something to confirm it can connect to database.
2. Models and simple controllers: the CRUDS
GOAL: create the building blocks so there's something to work with and see on the screen; get some momentum with Cake; rough out the UI and page flow
DELIVERABLES: plain, rough HTML pages for CRUD'ing keys, people, departments, locations. Unit tests.
User stories:
- CRUD a key
- CRUD room information
- CRUD key holder information
- CRUD department information
3. Assign key, transfer key, lost key
GOAL: Add non-CRUD business logic, change multiple objects with a single action
DELIVERABLES: a means to assign and transfer keys. Unit tests.
User stories:
- assign keys
- transfer keys from one holder to another
- keyoholder returns key
- keyholder loses key
4. UI work
GOAL: Make it look nice so the user WANTS to use it; develop a visual style to use through the application.
DELIVERABLES: a look that's not out-of-the-box plain Cake HTML; a start page that lets the user navigate functionality, with placeholders for upcoming functionality
?? We should visit the Keys Office for a test drive, get some feedback on the UI
5. Show inventory, etc.
GOAL: develop a search/select page
DELIVERABLES: all the "show X" pages. Unit tests.
- show key inventory
- show rooms and keys brief list
- show key inventory
- show key holders and their keys
- show keys assigned to key holders
6. Reports
GOAL: implement one report. Discover hidden requirements about formats, etc.
DELIVERABLES: run one report. Subsequent reports will use same code, different SQL, so it's not critical to implement all of them right now. Unit tests.
- select a report to run
- run a report
7. Test and Launch
GOAL: migrate application from old database to new database, go live!
DELIVERABLES: live, working website
8. Wrap-up
GOAL: Hand project back over to ZINC. Document anything needed for another developer to maintain the application.
DELIVERABLES: final updates to project notebook - anything we'll need to know to maintain the project. Required intern summary