Research Mission Statement

The CodeBlues Project intends to explore the construction phase of a software development endeavour, extracting data from tools that support the activities composing this phase, to provide scientific basis for new tools and techniques to improve awareness, performance, and control upon such activities.

Research Context

This projects assumes that many companies have only the basic infra-estructure for software development, that is, the infra-structure that supports software construction. We believe that companies that do not have such minimal requirements are either very small companies, with just a few developers, or should strive to implement the infra-structure. It is composed by the following components:

• a software development environment, like Eclipse, Delphi or Visual Studio;
• a version control system, like CVS, SubVersion or similar;
• a bug tracking software, like Gemini or BugZilla.

We don't discourage having using more resources and tools, such as management suites, requirements elicitation tools, communication related tools and portals, test case generation and registration tools, and so on. We believe that companies should become as organized as possible to earn the benefits from such tools (specially requirement and test related tools, which we believe are the most important of those listed above), but we acknowledge the fact that most software companies work with no more than the bricks and mortar required to build software. So, we intend to do research that bring benefits to such companies.

Processes are also not discouraged, but we also believe that processes are paramount in projects with repeating activities, where there is enough knowledge about the concepts and abstractions underpinning the software under construction that major design decisions can be taken beforehand. Therefore, software development is closer to a repeatable process that should be documented and followed by the book. Again, we do not discourage processes if a software company works in such a scenario. However, we acknowledge that many companies develop software that is not yet as commoditized as this, whose abstraction and their relations are not precisely known from the start and where design decisions upon such elements can change the way the software is developed. Thus, in their less burocratic and less documented way, companies living in this scenario may still search for awareness about the software that they develop. Such we seek by exploiting the messages embedded in the data residing in these companies' basic construction tools.

Major industrial problems that we are looking after include:

• Software project information exchange: addressing software improvement in a scientific way requires observation and the Nature, by itself, does not develop software very often. The usual academical environment also do no ressemble the average industrial context in such a perfection that laboratorial projects can provide the basis for observation. So, software engineering research depends on industrial data. However, this is a fine edge, since publishing information may expose a company to its competitors. So, we are addressing ways to collect software related information that do not compromise the competitive edge of software development companies;
  
  
• Dealing with software fragility: long living software projects usually suffer from fragility due to continuous development - as they build new functionality upon a system, developers may introduce errors to previously working software. We intend to address this problem by supporting the test team to identify which parts of the system are more subject to fragility and which test cases should be run again;
  
  
• Construction based management: it has been overstressed that you cannot control what you cannot measure, and that measures that are not based on a standard scale and measurement process cannot be trusted and are rendered useless. So, companies invest in following documented software projects in order to be aware of their performance and improve their planning. We view software processes as a set of behaviors that breed from the company and project ecology. So, processes cannot be enforced, at least in environments that deal with problems that we not previously addressed. Thus, measurement should be possible and should guide project management, even in and enviroment that does not follow a strict process. We assume the premisses stated above and explore data stored in construction related tools to provide information for project awareness and control.
  
  

Domains of Interest

The domains of interest of this research group include, but are not limited to, the following topics:

• Software design and construction techniques;
• Software design and construction measurement;
• Usage and visualization of data from version controle systems;
• Usage and visualization of data from request handling tools;
• Software release planning.

We definitively need support from software companies to run this project. Without real data there is little we can do. So, companies that would allow us to look into their CVS and error reporting data are very, very welcome.