We describe the TuVista system, a service for viewing near-live sports content consisting of a multimedia editing/bundling station, a cloud-hosted metadata server, and a set of mobile clients. We begin by introducing TuVista I, a proof of concept experience prototype implemented quickly as a probe to understand multimedia needs at a live sporting event. After discussing the results of an initial field trial at Estadio Azteca in Mexico City, we describe the improvements in TuVista II to address the issues identified. These include rapid editing of multiple live video streams, push notifications of new content over XMPP, and an optimized metadata workflow for the content producer that reduced content publication time from fifteen minutes to less than 30 seconds. We conclude with a discussion of rapid prototyping and field deployments as a way to quickly identify user needs.

Software Engineers frequently need to locate and understand the code that implements a specific user feature of a large system. This paper reports on a study by Motorola Inc. and the Software Engineering Research Center to see if industrial tools currently in use at the company could be adapted for feature understanding

Software engineers who maintain and enhance large systems often encounter the feature location problem: where in the many thousands of lines of code is a particular user feature implemented? Several methods of addressing the problem have been proposed, most of which involve tracing the execution of the system and analyzing the traces. Some supporting academic tools are available. However, companies that depend on the successful evolution of large systems are more likely to use new methods if they are supported by industrial-strength tools of known reliability. This article describes a study performed with Motorola, Inc. to see whether there were any pitfalls in using Metrowerks CodeTEST and Klocwork inSight for feature location on message-passing software similar to systems that Motorola maintains. These two tools were combined with TraceGraph, an academic trace comparison tool. The study identified two main problems. First, some ‘glue’ code and workarounds were needed to get CodeTEST to generate a trace for an interval of time in which the feature was operating. Second, getting information out of TraceGraph and into inSight was needlessly complicated for a user. However, with a moderate amount of work, the tool combination was effective in locating, understanding and documenting features. Study participants completed these steps in typically 3–4 hours per feature, studying only a few hundred lines out of a 200 000 line system. An ongoing project with Motorola is focused on improving tool integration with the hope of making feature location common practice at Motorola. Copyright © 2006 John Wiley & Sons, Ltd.