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.
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
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
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
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.
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.