Soliloquy of Eloquence

After I submitted the proposal, and got the new version running, the suggestion to make it a more complete database solution using MySQL and a web interface was made.  So, while it's unusual for a product to go from 2.0 to 3.0 without going through the usual 2.1.1 and 2.3.2 (etc) stages, it's an important step in both this database's development and my professional development.

I won't be changing any of the conceptual functionality of the program, just the language it is coded in and the way our customers interact with it.  This is, obviously, a massive undertaking that will take several months.  Step one -- learn more SQL.

This semester, I'm taking GUI Development and Applied SQL courses, so once again my professional and academic life have lined up fairly well. 

So, I forgot to post this - but here is my proposal draft for my organization's change management board to consider signing off on my little extra cirricular project.  It's a zip file located here and it gives a marginally technical overview about the goals, expectations, and functionality of previous versions and future versions on LEAPH.

I used Rational Rose to create a few sequence diagrams to better illustrate the next release of LEAPH's functionality. There's more than a few of them, so I only posted the overview and Actor's, but you can find the rest here.  I still have to draw up the ER diagram using Visio and write up some use-cases; then I'll compile it all into a Systems Upgrade Proposal and submit it to my change management board and the Helpdesk personnel for their input and approval.

Psuedo CodeSchemas and Relations

During my tenure as a Systems Administrator with the National Guard, I have always been perplexed by one thing above all else: the inefficient ways in which it conducts its record keeping.  While larger organizations within DoD have become more efficient, the smaller operations (such as ours) are still finding ourselves writing fix actions and help requests in notebooks with a pen and paper.  The problems with this are far too numerous to list, so I set out to fundamentally change the way we conduct our IT support operations.

The position is called a "Communications Focal Point," which is known in corporate America as "Help desk." Prior to my installment, we had no officially designated help desk and like I mentioned before our operations were tracked by simply writing them down (legibly, if we were lucky) in notebooks with a pen and paper.  Tasks were assigned by word of mouth to whoever happened to be within shouting distance, and trend analysis was something we could not even dream of.

I set out to read the contracts, work orders, AFIs and associated guidelines from "big Air Force" and develop a comprehensive policy for the help desk operations at my place of work.  Once the policy was created and approved by management, I set out to replace the bane of my existence: the dreaded notebook. My language of choice was Visual Basic, and my management software was Microsoft Access.  Armed with only a handful of pages on Google that weren't blocked by our ISP's proxy server, a basic understanding of programming and no idea what a relational database was, I set out to teach myself how to become a Database Architect. 

My first installment (v1.0 through 1.5) have been released and are operating relatively well, but these release have been more of a working prototype and it has understandably developed a slew of annoyances, bugs, and inefficiencies as it grew in size.  The database has grown in ways that were previously inconceivable when I set out on this endeavor and the ticket management software I had hoped to develop has quickly become the main database for our IT operations.  Tracking not only the initial help desk ticket requests that I had set out to track, but it has incorporated asset tracking, daily narratives (for shift change-over), Maintenance tasking, basic project management, as well as basic data mining to enable trend analysis and manpower justification.

However, the database grew far too quickly and in far too many ways to have been properly and efficiently constructed, so the task of rebuilding it has been self-bestowed upon me.  Properly armed with the teachings of past experience, as well as a database course, I have set out to begin my first "real" professional database development.  I will be posting my progress, schemas, psuedo code, etc here so stay tuned!