Login | Register
My pages Projects Community openCollabNet

Project home

2020-03-13: This site is going to be decommissioned and shut down very soon. Please copy and archive any data you wish to keep ASAP

If you were registered and logged in, you could join this project.

Summary Efficiency and agility analysis for Java projects
Categories scm, construction, process
License Apache License
Owner(s) bannerman

Message from the owner(s)

I have placed initial versions of the software and web pages on the site. I now want to get people using the toolset and generating data. I'd also like to get some people with XSL skills to help me transform experimental results into HTML pages that project teams can look at.

jeanda stands for "Java Efficiency and Agility Analysis". It is a set of ant tasks and supporting Java code which are intended to be inserted into project builds. When inserted, it compares the .class files in the build fileset with previous builds, with the help of BCEL.

It is intended to be fast, relatively space efficient, and non-intrusive - if successful in these respects, then it will not inhibit project builds. And, as long as it does not hinder project builds, then it has the capability to provide useful raw experimental data from a variety of Java development projects.


This is the primary goal of the jeanda project - to gather raw experimental data from a variety of Java development projects. We believe this data is important because:

  • With it, we can estimate the relative efficiency and agility of each project that built a product.
  • By classifying each project team according to the process(es) they followed to create their products, we can relate process(es) to relative efficiency and agility.
  • We, the software development community, can use these relationships to help us make decisions when choosing processes (or parts of processes) to execute when building software products.

Hence, a secondary goal of this project is publication (of summaries) of:

  • the raw data;
  • the estimates of efficiency and agility;
  • the classification of projects (with respect to processes);
  • the relationship between processes and efficiency and agility.


Why should we estimate efficiency and agility based on the compiled software product. The short answer is that it's the only artifact that we know will be generated. The longer answer is:

  • There are so many variabilities in software development - so many tools, artifacts, skill levels, processes, etc... - these variabilities make it very difficult to form meaningful relationships from processes to measures like efficiency and agility.
  • There is one common thing across all software development - we generate software products.
  • By taking a black-box approach, we can analyze the changes between two versions of a product.
  • By analyzing the changes between the the last version of a product (in an iteration) and the first version of a product (in the same iteration), we can estimate the "output." By summing the changes for all of the intermediate builds, we can estimate the "input." Then, our estimate for efficiency is the output divided by the input (efficiency = output/input).
  • Using the same analyses as we use for estimating efficiency, we can estimate agility. Agility, by definition here, means the amount of change (relatively) per time.

Lines of Code (LOC) revisited?

Finally, why is this different than measuring lines of code? Although measuring lines of code can provide some insight, it was easy to exploit. The main difference between that approach and our approach is that there are two competing measures: efficiency and agility.

If a development team tries to "game" the system by changing a lot of code in a short amount of time, it will increase their agility estimate. That's good. However, it will also decrease their efficiency estimate (assuming the changes will be replaced and/or removed over time). That's bad.

Similarly, if a development team tries to "game" the system by witholding their changes until later in the iteration, it will increase their efficiency estimate. That's good. However, it will also decrease their agility estimate (because they're changing less of the system less often). That's bad.

Thus, these estimates should provide a decent counter-balance for one another.

Related resources

  • The jeanda product supports the mission of this project by providing tasks and code to analyze different versions of Java software builds.
  • The ant project provides Java developers with scripting tasks and is commonly used to build software products from their source code.
  • The Bytecode Engineering Library is a project which models Java bytecode. It is used in this project to help with the comparison of Java classes and methods.