Research

Initially we focused on the problem of providing a definition of COTS [ICCBSS2002] since the items that people address when they use the term COTS product span over a very wide range.

The we tried to classify [ECSQ2002] and characterize [SEKE2002i] products for the purpose of selection.

Evaluation of COTS requires defining attributes and assigning values to them, we investigated the extent to which they can be reused across several evaluations [ICCBSS2003] and then we defined taxonomies of COTS products to drive the reuse of attributes and methods [ICCBSS2004].

We recognized the importance of defining a process for the development of COTS-based system including also software architecture as a fundamental asset [PROSIM2003.pdf] [MPEC2003].

We also conducted empirical studies, first on a small scale identifying a set of research hypotheses against common belief [Software2004].
Then in cooperation with NTNU and Fraunhofer-IESE we permed a large scale investiation across Europe. [ICCBSS2005] [Profes2005] [Metrics2005] [TSE2008] [IEEE Software 2008]

I prepared a selected list of literature on this topic: COTSLiterature.pdf (need to be updated).

Design patterns

Design patterns are widely recognized as important software development methods. Their use as software understanding tools, though generally acknowledged has been scarcely explored. Patterns are most useful in understanding software when they are well documented. Sometimes they are described separately from code as design comments. Nevertheless they hold a strong relationship to the source code and thus they should be documented at the source level too. Unfortunately there is no agreement on how to document pattern use.

We look for a structured approach to document pattern use in the Java language. Our solution is based on the standard Javadoc tool and it is able to generate HTML documentation. The approach has been implemented and tested with software that use pattern.

First we investigated the benefits in terms of maintenance effort and accuracy by replicating a previous experiment. [ICSM2002]

Then we focuse on how the cognitive process is affected by the presence of patter-specific documentation [IWPC2004]

Test-Driven Development

We conducted an experiments with a small system and unexperienced programmers. No direct clear effect of using TDD on quality or productivity could be observed. What we revealed was a significant larger amount of tests written by subjects using TDD. Also we observed an effect of lower quality threshold that increases with the number of tests (i.e. the more test you write the higher quality your code will be) independently of subjects skill or other factors - in agreement with common sense.

Working with: Hakan Erdogmus and Marizio Morisio

UML stereotypes

We found a surprising reverse effect of experience on the usefullness: the more experienced the developers the smaller the usefulness of the notation. In practice the complexity of the notation does not help in finding more quickly and esily information that is available alternatively in the source code. This result has been found for relatively small projects, so no empirically based statement can be made for large system. Though I suspect it will hold also there.

Working with: Filippo Ricca, Massimiliano Di Penta, Paolo Tonella, Mariano Ceccato

Table-based acceptance tests

We conducted a series of empirical studies to investigate a few research questions:

• Do Fit tables help in understanding a software system?
• What is the usefulness of Fit tables in maintenance tasks?
• Does the executability of Fit tables help?

This represents the latest entry in my research interests. I attended the very interesting Summer School on Software Architecture and I'm investigating the relationships of this discipline with the other topics of interest.

How can we describe the architecture of a software system?
A number of UML profiles are emerging which are addressed ad architectural descriptions, a common architectural represenation is being sought.

Which are the quality requirements we can estimate based on a software architecture?
Maintainability, performance and integration effort/problems are among the basic properties addressed in the state-of-the-art research.

What the industry do? What they would like to do? What they are interested in doing once realized it's feasible?

The idea of a continuous process that leads from specification to the development of the deployable system is not new. Many of the modern development methods make an extensive use of models to describe software artifacts. Model-based development is the result of the merge of those two ideas and their extensiont further into the realm of the deployed system.

MBD uses models in a seamless way in all the phases of a system; in particular they are used to:

• capture the problem-domain abstractions;
• build an high-level description of the system;
• support the operational phase of the system.

The Software-Implemented Hardware Fault Tolerance (SIHFT) is based on a set of source code transformation rules. This approach hardens a program against transient memory errors by introducing software redundancy.

The adoption of SIHFT techniques allows the implementation of dependable systems without incurring in the high costs coming from designing custom hardware or using hardware redundancy.