The DevEvent sensor data type represents developer "behavioral events", such as the action of invoking the compiler, or opening a file for editing, or running a unit test, and so forth. In many cases, DevEvents are generated along with other sensor data that might provide additional details about the context surrounding the event. For example, a DevEvent might indicate that the developer invoked unit tests, but the UnitTest sensor data would give more detailed information about what tests were invoked and what the results were.
Table 25.11, “DevEvent SDT attributes” documents the required fields for this sensor data type.
Table 25.11. DevEvent SDT attributes
| Attribute | Description |
|---|---|
| tstamp | The UTC time at which this data was collected. |
| tool | A string indicating the tool that collected this data, such as "DependencyFinder". |
| path | A file or directory path associated with this event. Examples: "c:/svn/hackyApp_Zorro/build.xml", and "/usr/local/johnson/foo". A "path" value is important in Hackystat so that this event can be associated with a Workspace, and thus with a Project. Note that the empty string "" can also be an acceptable path value for a tool that wishes to indicate that a developer behavior has occurred but there is no known path to associate with the behavior. Hackystat will provide analyses that capture these "workspace-less" events as a way of understanding the limitations of the Workspace->Project representation scheme. In addition, a future direction for Hackystat is Project Membership Expressions (http://www.mail-archive.com/hackystat-dev-l@hawaii.edu/msg01644.html), which will create new ways to associate sensor data with Projects. Supporting path-less DevEvents will be an important goal of this research. |
| type | A specification of the top-level "type" of this development event. The initial set of top-level DevEvent types include: "Refactor", "Edit", "Compile", "Execute", "Test", "Build", and "Debug". (This list can be expanded). One standard optional property is "subtype", which enables a subclassification of these top-level types. For example, the "Edit" type can have a subtype property called "StateChange". It is also possible to provide additional properties called "subsubtype", "subsubsubtype" etc. to further subclassify the type of DevEvent. (In practice, we have not yet seen anything further than "subsubtype".) Each type/subtype combination can have any number of additional properties associated with it to provide additional contextual information about the event. |
DevEvent sensor data will be used in a number of different contexts.
First, it is being used to develop a new, alternative approach to assessing the time spent by developers. Prior to DevEvent, the only automatically generated abstraction related to effort was Active Time. Active Time is based upon the "State Change" event generated as part of the Activity SDT, and attempts to record only the amount of time spent actively editing files associated with a project. This tends to significantly under-report developer effort. The DevEvent SDT will generate events based upon a much broader set of developer behaviors, resulting in a proxy for developer effort closer in magnitude to the true effort level.
Second, DevEvent sensor data will be applied to workflow modeling. By gathering together this and other sensor data, heuristics will be applied in an attempt to assess the "logical" activity that the developer is engaged in, and from this generate a workflow model.
Finally, DevEvent data will also be used to support the Zorro project, which attempts to recognize instances of test-driven design.