CMSC 435 : Class Project Mission Statements

Class Project Mission Statements
Fall 2013

DIY Terp Tech

TerpTech will present modestly tech-savvy Terps with a uniform data model and programming environment for creating event-driven applications intended to simplify many of the tasks in students' daily lives. For DIY-minded Terps who are interested in creating some custom tool for automating tasks today, this task can be considerable, since the absence of an API or data sources means everything would be created from scratch. TerpTech will roll up likely data and populate the programming environment with an appropropriate scripting notation to control effectors which the DIY-er can quickly configure to control more of their world.

Much of the student data - such as schedules, grades, meal plan status or course assignment - we would reasonably hope could someday be obtained from authoritative sources on campus. However we have no realistic near-term prospect of gaining such direct access to DOIT, so among our programming tasks will be creation of efficient tools for a student to scrape these data from the traditional sources. However, one of our explicit goals for the project would be to make it easier for DOIT to provide such data in the future. We do this by creating a successful prototype which would reduce the risk of their considering such a path later. Of course, in the spirit of prototyping, another of our explicit goals will be to get a strong working sense of what data are useful for such efforts and which simply aren't worth the effort.

DIY TerpTech will be visible to our customers as a general API on one of a reasonable selection of platforms, which would be under control of the user. The API would allow management of a data dashboard, also under the user's control, whether locally or in a personal cloudspace. (Making DIY TerpTech compatible with OwnCloud is a reasonable choice, but would be something to be worked out in the coming process.) The API would be populated with a reasonable assortment of components that would let the dashboard be populated with data relevant to the DIYer's needs. Similarly, the API would provide components which are effectors, to translate effects into external apps, displays or devices (and, in the other direction, admit the capture of external device events and map them into the data dash where they may trigger other event rules.) The API would provide an event-based language for scripting or configuring the desired apps and automation devices. (Yes! We want this to be able to control gizmos!)

The DYI TerpTech application should be readily installable on the user's platform and come pre-populated with example apps to help the user get going. These driving apps should trigger 'gee wiz!' reactions from users, and should be crafted to both inspire more innovation and serve as exemplars for users to craft their own apps.

Terp Tasker

Terp Tasker presents users with a personal task management system that lets them model their preferences for work flow, then supports their day-to-day activities according to that model. The system should thus assist each user map tasks to time in order to get best productivity. It would do this by recognizing constraints and preferences, and present (possibly by an adaptive method once the user's actual activities become known and can be compared with an original schedule) recommendations for specific use of time under those constraints.

In many respects, the Terp Tasker goals are spiritually similar to what would be found in David Allen's "Getting Things Done" approach, but with the automation assistance and integration with project support. However, there is an added dimension to Terp Tasker, and that is capture of a full 'paper trail' of artifacts that the user might identify to one or another of his projects. Meetings, phone calls, files or other documents and more are often connected with a task area or project, and when the user takes that task up (during some 'work time' or review), it is reasonable that the full log of artifacts be made available to give full context. The intent is to reduce the cost of mental 'context switch' in moving between tasks, and to assist in accounting for time. (After all, how can you know where to improve your handling of tasks or even bill for your time as a consultant if you don't know where your time goes? And the same question applies to the adaptive and advisory features.) Thus, Terp Tasker is as much a data capture and instrumentation tool as it is manager.

The Terp Tasker project should deliver the planning tool; a tasteful suite of adapters and synchronizers to assist in its both effecting and receiving data from calendars, mail systems and document managers; and all support materials to use this with a personal cloud service.

The Fine Print

Once task assignments are made to class teams, obviously the first step is to clarify what is the problem being solved and what it is you will do for the 'customer.' We need to reach an agreement on what that will be. The first milepost will be to get a detailed project plan drafted and approved - the "green light" to move forward. The clearer the picture, the stronger can be our agreements and the easier will be your build. But ... that takes longer, and now is not a great time to run the clock. This will be a balancing act. Figure it out.

The project plan (a graded assignment) will describe the architecture of your system, describe main functionality of major components (not all pieces - this is not a detailed design specification), describe the process and timetable you think will get you to a win condition, and basically contain any information which would be needed to convince the boss that your plan is realistic and has a good likelihood of bringing success. The plan will also contain - and this is important - a clear description of an independent validation exercise that, when conducted and passed according to criteria in the plan, will make it clear to all that your project has done what we agreed on. Don't game it to be trivial or small - I won't buy it. Don't make it fuzzy and grand - I might buy it! In any case, we all need to agree on what this is. (And as we go on, we will surely be talking a lot about what criteria make for a sound validation exercise.)

Your first plan submission to me, when you choose to do it, is the one for grade. I may or may not green light it, but you need the green light to move forward on your plan. You can submit as many iterations of your plan as needed to get the green light, but we want to reach that agreement. You can do this on your own schedule! But remember, the semester clock is ticking.

Once we have a plan, just go do it. Easy, right? We hope so. In any case, I will want to see a structured walk through of your project - call it an alpha release - by a date we agree on (likely in your plan, above). Details on what to submit and review will come later, but I would like for it to be a point where we can all sit down together as a team to do a detailed review of the technology under the hood. This walk through will also be for grade.

Then you just need to do the final validation exercise, as agreed in the plan. This may involve other users, independent reviews or demonstrations, and more. Just do it, and roll up the results as part of a report in your final deliverable. (What all goes into that final deliverable? Whatever is the manifest we agree on in the plan, naturally.)

We will presume the validation exercises should be going on the week prior to the final hard deadline, but otherwise the only hard deadline for projects is going to be 12:29PM on 5 December. (That last week before end of semester will be used for some measurement and costing exercises on your project, using artfacts you'll draft soon but don't know about yet. We need to make sure you get a taste of software engineering, not just development. In any event, I suspect yours will be a happier life for not having the 435 class project overlap the last week of the semester when it is crunch time in many other classes.)