Colin Potts

Georgia Tech, School of Interactive Computing

Portrait of the artist with teapots
How to get me
Where to get me
by email potts@cc.gatech.edu
by phone (+1) (404) 894-5551
by foot Tech Square Research Building, Room 339
by mail School of Interactive Computing
Georgia Institute of Technology
Technology Square Research Building, 85 5th Street,
Atlanta, GA, 30332-0760
by fax (+1) (404) 894-0673

Feature evolution and clustering

Background and objectives. Software is often said to consist of features, but what are features? As scientists, how do we identify and measure properties of features? What is feature "bloat"? When does an application suffer from it? And can we predict its onset? How do features evolve and interact? What happens when applications merge or fragment? When we complain that an application is really many applications in one package, can our intuitions be borne out by analysis? My interests are in using objective analyses of externally visible evidence to identify features and feature clusters, track their evolution and benefit/burden profiles, and develop metrics for feature integrity.

Approach.

  1. Pick a product or service that has an established history and has historical documentation or available previous versions.
  2. Develop or use theoretical models for identifying and profiling features. Examples of such models include
  3. Trace the existence of features/ontology concepts across versions or variants of the application.
  4. Reduce the analysis either quantitatively (e.g. what is the proportion of core benefits to defensive benefits in different versions) or qualitatively (e.g. by graph-theoretic analysis of the ontology graph to identify centers and peripheral elements)
  5. Correlate the reduced data with evidence of user preferences and use patterns (e.g. what are the footprints of usage scenarios over the features identified and profiled?)

What this Tells Us.

These analyses tell us about the evolutionary dynamics of systems in use: the types of features that we can anticipate being required in later versions of systems, those that fall into disuse, those that get incorporated from satellite products, those that are spun off into secondary applications. We can approach the subjective perception that some applications are "bloated" by doing more than simply asking users for their opinions or just counting menu items, and instead get a picture of whether an application is just getting bigger as it grows or whether it is becoming conceptually misshapen.

Example publications.