SAMWise Requirements Document
Product Concept Statement
SAMWise is a tool for communicating I.T. system maintenance events to users of Banner, Scholar, Virginia Tech’s network, web, and other important services. Events are viewed on a web calendar based on the open source Bedework. Current events may also be viewed on computing.vt.edu’s Status Update window, and by subscription email, RSS feed, or Twitter. Event creators log in to a web form via CAS, and select date, time, and system maintenance descriptions based on their work roles. These descriptions are then translated to terms meaningful to calendar subscribers. For example, a database administrator might post an event about maintenance on “PROD, FPRD, RPRD, VPRD, LTPROD,” which would be translated as “Hokie SPA and Faculty Access will be unavailable on Sunday.” SAMWise can also be used to post notifications of unplanned system outages.
System Analysis
To understand the business objectives and the workflow of SAMWise users, we visited event creators and subscribers in their normal work environments. We also met with the users of the current system, which is a hodgepodge of two web calendars, seven Listserv lists, and four status notification locations. The SAMS committee meets on the second Wednesday of each month, and has representation from each I.T. functional area. The SAMS committee chooses maintenance dates that minimize conflict and inconvenience to users, and this is a big improvement over the “anything goes” process, but advertising a maintenance event is still a challenge. Event posters need a web form that is simple to use, simple to change, and communicates event information in a form that users understand. While we interviewed Richard Quintin, for example, he received three phone messages and two visitors. When he is posting an event, he should not have to consider what Listserv lists the end users of his databases are subscribed to. If an emergency occurs, someone other than three authorized 4Help staff should have the ability to post notifications, and users should have an expectation of timely and accurate system status messages.
In short, system administrators should be able to fill out a notification form for planned or emergency maintenance that uses their own work context language, and trust that this information will be conveyed to people who care about the event, and event subscribers should be able to choose the form and content of these notifications.
The constraints on the system are that it be built with existing and/or open source tools, and that it not take an inordinate amount of developer time.
Early Prototype
Susan Feng and Nicole Dimond, I.T. interns, have collaborated to develop a “low fidelity” prototype. Susan has installed an instance of Bedework, and by looking at the forms and categories available there, Nicole has designed some paper prototypes which are being used to gather feedback from representative event posters and subscribers. Our interview with Hashim Durrani gave us the idea that we may be able to customize the event posting form according the ED group membership information that is delivered with the user’s CAS login. Hashim also helped us consider the perspective of Hokie SPA and MyVT users, and how they might want to be notified about events. Since we are using paper prototypes, it is easy to design posting and subscriber forms to try out on other users so that we can gather usability information in parallel with our investigation of the complexities of CAS and ED groups.
High Fidelity Prototype and Demo
When we have gathered enough data to design the poster and subscriber forms and CAS strategy, we will develop benchmark tasks which reflect the workflow for each of the user classes. We will write basic user instructions, and begin testing with a prototype web site which gives the appearance of functionality even if it doesn’t really work. We will then ask willing participants to help us test, and incorporate the test results into design improvements.
Formative Evaluation
Assuming we haven’t encountered a technical roadblock or resource depletion, we will build the application and conduct more testing. Then we will write a cost-importance table to prioritize fixes for problems discovered in the evaluations. We will also develop a maintenance plan, which we think will mean periodic updates to Bedework, the underlying web server and database, and updates to group memberships. Project leads can then decide if the utility of SAMWise is worth the cost.
First draft: 26 July 2012
Kimberley Homer, Operations Manager, SETI Quality Assurance & Verification