Patrick Day (mail) – Paul Fisher (mail) – Monica Hirst (mail) – Brian Murphy (mail)
The MITRE identification and point-of-presence system (renamed AWEsome wall) is a product that identifies nearby employees and displays personalized information in the form of a dashboard. The dashboard allows the user customize their experience by selecting from a list of gadgets to use. Gadgets range from the personal, like digital photo frames, to the productive, like to-do lists. The system is intended to be implemented in temporary offices, known as hotel offices, with the goal of making these generic offices feel homey and comfortable to work in.
The gadget are implemented using OpenSocial, a web API based on the Google Gadget framework. This system supports the use of pre-existing MITRE gadgets as well as specialized AWEsome wall gadgets. The gadgets aim to be “ambient” and allow the employee to quickly gather the information they need with little to no interaction with the wall.
The system will include several hardware elements. Hotel office users are currently identified by a smartcard reader in the room. Also, an office wall will be the host of an interactive whiteboard which will be displayed via projector.
For our development process, we created our own process. It was influenced by the Open Unified Process (OpenUP). It applies iterative and incremental approaches within a structured lifecycle.
As mentioned above discussing the Open Unified Process, we broke down our schedule into four blocks. The first two phases (Inception and Discovery) consumed the first ten weeks of the project. The final ten weeks were consumed by the construction and transition phases, more heavily so on the construction phase. These four phases are our major milestones. The two week iterations in these phases were also minor milestones.
Two gadgets were designated to be developed each increment, with two team members dedicated to each gadget. This included initial design and wireframe phases, with an expected prototype at the end of that two week cycle. The planned schedule in its entirety is below:
| Date | Item Name |
|---|---|
| 1/6/2011 | Project Plan Delivery |
| 1/8/2011 | SRS Delivery |
| 1/9/2011 | Inception Phase Complete |
| 1/25/2011 | Customer Visit |
| In Person Requirements Walkthrough | |
| 1/26/2011 | Architecture Document Delivery |
| 2/5/2011 | Interim Presentation Draft |
| 2/18/2011 | Test Plan Due |
| Discovery Phase Complete | |
| 3/8/2011 | Customer Visit |
| 3/18/2011 | Awards and Achievements Gadget Due |
| While You Were Out Gadget Due | |
| 3/31/2011 | Customer Demo |
| 4/1/2011 | OSEC Modifications Due |
| Weather Gadget Due | |
| 4/15/2011 | Whiteboard Gadget Due |
| Photo Frame Development Due | |
| Calendar Gadget due | |
| 4/20/2011 | Project Poster Due |
| 4/29/2011 | Traffic Gadget Due |
| Virtual Window Gadget Due | |
| Construction Phase Complete | |
| Solution Delivered | |
| Project Poster Day | |
| 4/30/2011 | Final Presentation Draft |
| 5/5/2011 | Deliver Final Presentation |
| 5/13/2011 | Transition Phase Complete |
| 5/14/2011 | Technical Report Due |
There was some slippage in our schedule. This was attributed to requirements changes early in the spring quarter. The customer wanted the container development to take over as compared to delivering individual gadgets. Without a stable and unique container, we were told the project would not succeed inside MITRE. We were able to negotiate with our customer and drop the calendar gadget as a deliverable. MITRE stressed that they have people inside who have built gadgets on this platform and can deliver these gadgets later. The main thing was delivering the “whole package”.
Because of these changes, our Awards and Achievements and While You Were Out gadgets required a schedule delay. We had begun developing these gadgets prior to the requirements change, and a redesign was necessary to meet the new needs of the container. The gadgets that followed stuck very close to their delivery schedule.
We benefitted from MITRE resources as the project progressed. This helped us stay on schedule as well as ahead of schedule on some items. Since MITRE’s OpenSocial Container was fairly new to the open source community, there was little documentation when we ran into errors. MITRE’s internal development team was very helpful and speedy in helping us when we ran into trouble. Notably, Jesse Ciancetta and Matt Franklin were vital to the container’s success. One item to note was that without the personal connection with both Jesse and Matt, we would have never been able to deliver the product we did. The documentation in the OpenSocial community was insufficient for our needs. Also the help of John Ursino in poster creation gave us some extra time to focus on development.
Our design was driven heavily on the requirement that the user must have the same experience no matter where they are connecting from. Obviously, a web based model was optimal. There are major components to our architecture:
We chose the OpenSocial design as it was pre-defined by the OpenSocial framework. All components (gadget server, Apache Shindig, OSEC), were hosted on our project server. We used Shindig to host the OpenSocial Enterprise Container, as well as hosting our gadget configurations. When adding a gadget to the container, a valid URL pointing to the gadget specifications are required.
We considered alternatives for gadget hosting, but in the end found this structure was vital for ensuring successful integration with MITRE’s infrastructure. They already had an OpenSocial environment deployed and running gadgets. We considered alternatives for OSEC, such as Partuza, a gadget rendering container in PHP, however MITRE’s written OSEC (released to the open source community), provided additional security features such as Single-Sign-On (SSO), as well as greater stability.
The AWEsome wall client represents the physical machine in the hotel office. This is the host for a variety of services and clients.
First and foremost, the OpenSocial client lives on this client. This is what the user sees and interacts with on the wall. This client was placed on the physical machine as compared to a standalone display, since we have the benefit of domain authentication on the machine, which allows us to utilize Single-Sign-On (SSO). This was the most obvious solution, since the OpenSocial client lives within a browser. We considered having the client on a standalone machine in the room, however authentication became a concern. Also, the client is then protected when a user locks their computer.
The picture loading service also lives on this machine. This was due to the fact that the digital picture frame connects to a folder of a machine on its wireless network. This allows the frame to be tied to the physical machine in the room, regardless of who is logged in. When a user logs in, we can populate a static folder with that user’s photos, and have them appear on the frame. We considered a variety of solutions for delivering photos to the user’s desktop; however in the end this seemed to be the most practical solution. Kodak offers a service to upload photos to the frame via e-mail, however in our case this solution would be too slow, as it took about five minutes for a single image to be delivered to the frame. In trying to deliver a user’s entire photo album this would be impractical.
Finally, the Mimio capture and interaction services exist on this client. Since this drives the interaction with the OpenSocial client, these two components must exist on the same machine. We considered alternatives to Mimio, such as SMART interactive touch systems, and touch LCD systems. The benefit of Mimio is its portability. The Mimio sensor can be mounted to a whiteboard and calibrated within minutes. This could allow customization by the user as to where the sensor is placed.
The physical picture frame does not have many constraints. We need it to map to a folder on a computer, which must be on the same network the frame is connected to. This requires the physical frame and the AWEsome wall client to be on the same network. We considered a few other frames; however this hardware was supplied by the client and provided all the functionality we needed.
The identification sensor is able to identify a user based on their badge. This sensor is not required to be connected to a computer, so it can be broken into its own category. The sensor client is the physical sensor device. This is where the user taps their badge to be identified. That code is then sent via TCP to the sensor identification server. The server then determines who has tapped their badge by converting the badge ID to an associated person.
This component was not completely integrated into the project. MITRE is working to grant domain authentication upon inserting their badge into a card reader. Our expected deliverable is a service that identifies a person based on the badge ID that was swiped on the reader. This was done over a TCP connection. We encountered hardware failure within the last few weeks in the project. However, we were able to deliver the badge identification service and PIN authorization process. Without functioning hardware we could not successfully demo the login process at the end of the project. With functional hardware our implementation will meet MITRE’s needs.
We considered a variety of identification solutions in the discovery phase of the project. Items included RFID, RuBEE, and facial recognition. However, as this component of the project became overshadowed by the AWEsome wall and photo frame, we did not have time to explore all of these identification solutions, as they would consume the bulk of our development time.
For our process metrics, we were able to observe many statistics provided to us by Trac, our time tracking tool, as well as Handshake, the collaborative environment with our sponsor. In Trac, we monitored the tasks per increment:
These results were able to help us identify how high our level of effort was on the project. Being able to monitor the hours worked per iteration allowed us to see how hard we were working on those goals.
Additionally, we were able to monitor our handshake metrics:
These Handshake metrics helped us see how often we were interacting with our sponsor outside of our team meetings. At one point our discussion metrics declined a little, hinting we should be interacting with our sponsor more. Upon applying this observation, we saw our requirements gathering complete faster than we would have expected without the additional interaction between meetings
For our product metrics, we initially targeted many metrics around our sensor identification time and success rate. However, as the project progressed, this metric was not as important, as the sponsor approved identification via Single-Sign-On (SSO), which does not require the sensor. However, we did target the following metrics:
Looking back upon what was planned initially during our discovery and inception phases, our delivered product mutated a bit during our construction. Our sponsor heavily urged that they did not want the AWEsome wall to resemble a portal, similar to iGoogle. Since MITRE already has a similar portal structure established internally, this wall had to have a unique look to it. Early in our second quarter of work, we shifted our schedule from primarily gadget development towards modifying the gadget container to have a custom, ambient feel with the hotel office.
Unplanned features that were added were focused around the gadget container. Building the layout of the container to not be a portal gave us some additional requirements. Also, having multiple views for each gadget was unforeseen. For example, our weather gadget took on an “ambient” view when in a small mode, and then took on a more detailed view when full screened. The biggest part of the gadget development was when specific information is delivered to the user, and what view that should fall into.
Planned features that are missing include the calendar gadget and domain authentication with the badge reader. As mentioned above, we restructured our schedule to accommodate gadget container modifications. The badge reader change was due to exploration results within MITRE, determining this would be out of our reach in the time we had for this project. Our sponsor approved the schedule change, and was ok with removing gadgets from the schedule.
Overall, we see this project as a success. We delivered a functional hotel environment, where users can create a custom office feel that will travel with them when they change office locations daily.
We feel that we could have been more proactive in our requirements gathering phase. When the project began, it was very open-ended. A major piece of it was brainstorm and research based. This delayed our development until spring quarter. If we were able to begin development earlier, we could have had more time for additional gadget development.
In terms of process, we feel the modified version of the Open Unified Process met our needs well. It gave us the flexibility Scrum could not, since Scrum would have required daily standup meetings. As college students, this seemed like an unattainable requirement. Also, task monitoring in Trac allowed us to see what we were required to deliver for that iteration, which was very helpful.
Our sponsor interaction was vital to moving this project to a final product. As mentioned earlier, there were no major requirements set when the project began. Narrowing down the sponsor’s ideas into a final, unified idea took some time. With only having one hour of face-to-face time a week, Handshake was vital to progressing the project ideas into a product.
Although the delivered product was not what was initially described in the project proposal by the customer, we feel we successfully elicited new requirements, adapted to requirements change, and delivered a working product the customer wanted.