Introducing The Project
Let’s get down to it.
At The Company, there are many buildings spread throughout the area. Each building has various pieces of IT equipment used by the workers of each building. Being a “good” company, they know that things break, so each building “keeps” a spare inventory of equipment.
(spare tire…get it?)
“Keeps” because some buildings keep Access DBs for their own building. Others circulate an Excel sheet. Others don’t use any mechanism. So if your laptop breaks down, there is no centralized way to know if
- There is a spare laptop in your building
- There is a cache of spare laptops in the building 5 miles away
- You need to create a purchase order and buy a new one
- A building is running dangerously low on spare equipment and needs to stock up
Enter The Project. Imagine a system like this:
You: Dear computer, do we have any spare laptops here in Building A?
The Project: Why yes there is. There are 5 Dells and 1 HP in Room 291.
You: Thanks! I’m going to take the Dell with serial number OTIE8185194G.
The Project: Noted. Have fun.
You: By the way, how many Padres hats are in the building five miles down the road?
The Project: There are 17 spare hats in that building.
Someone else: Dear computer, how many spare laptops are here in Building B?
The Project: None!
Someone else: Oh no! Do we have any in Building A?
The Project: Yes, there are 4 Dells and 1 HP in Room 291 there.
Someone else: Great, I’ll make a call…
To spare you the details of a month of requirements elicitation and negotiation, the first release of The Project consisted of these pieces of functionality:
- Add Equipment
- Edit Equipment
- Search for Equipment
- View Building Equipment At A Glance
- View Equipment Type At A Glance
- View Equipment Type Details
- Switch Building
- Select Building (upon login)
- Add Equipment From External System
- View Equipment History
- Scan Network-reachable Equipment & Produce Report
There were different pre-determined types of equipment we knew would be tracked. These would be the “Equipment Types” alluded to above. To protect the innocent, The Project tracked PCs, Hats, Textbooks, DVDs, Jerseys, and General (anything else). Each type, save General, had specific attributes built into The Project.
Reporting for the first release was delegated to users, who it was assumed would have some kind of read-only access to the data.
To add to the fun, I was a software developer hired for a part of The Company that was not technically allowed to develop software. So the first constraint:
- Software engineer / project manager must keep a low profile within The Company
- Due to constraint #1, The Project must not run its own server of any kind because Corporate will promptly shut it down.
- The project must be completed before May 2008 by a part-time developer.
- Microsoft products only.
This ended up affecting communication, user meetings, and scheduling. The next constraint:
This ruled out a web-based solution. It almost ruled out using a DBMS other than Access! More on that in the next post. Next:
Yeah, this was because of me. That’s when I left. And I was going to school full-time, which made me a part-time worker. Finally:
The next post on The Project will review the architecture I went with, along with the amazing fact that I had to present an architecture comparison to get approval for a SQL Server (!).