The technical evaluation considers the data collected in the baseline projects, in particular focusing on a specific set of metrics that were measured in the design artefacts and directly in the code. The technical analysis focused on assessing the degree of connection between objects (component internal cohesion) and between components (coupling between components).
We found that in general the coupling values were lower than the cohesion values for the components, a confirm to the initial expectations and a clear improved modularity of the system. The analysis of the coupling indicators evidenced a lower coupling towards the presentation layer and a stronger coupling towards the persistence layer of the systems. This can be due to the fact that the reuse efforts were much more focused on business rules reuse than on graphical interface reuse.
The experimental results showed that it is not always true that components directly lead to increased cohesion and decreased inter-component coupling. This general statement is a general consideration but it depends on specific situations.

Business

A comparison of the measured data against the estimated effort for a 'traditional' development showed that the total effort employed for the two projects (if we do not consider the effort spent for the development of the reusable components) is less that the estimated one.
Adding to the effort spent for the baseline projects the work required to develop the reusable components, we found that the component-based approach incremented the total effort we employed in the baseline compared with the estimated one (by about 14% and 7% respectively for the two systems).
With the figures we measured, we can foresee that a third reuse of the two components will result in a positive balance concerning these two projects: the return on the investment is reached when we reuse three times the reusable components (considering only the effort data).
A positive result comes up from the consideration of the time to market related to the baseline projects: we released the first version of the baseline systems with an appreciable reduction of the time to market. However, we have to consider that in the experiment we made the time required to develop the two reusable components did not delay the two baseline projects.

Qualitative

We conducted a final review with the people involved in the rpoject and we obtained these considerations:

- developers emphasised that the component-based approach and the different perspective it requires directly translate into a better structuring of the software application

- the experiment showed that the new approach led to an improved readability of the project documentation: hiding specific implementation mechanisms into components boundaries and describing interactions through public interfaces simplify the reading activity and this, in turn, leverages the understandability of the information

- the adoption of a component perspective fostered the application of documentation and coding standards, and this is very important aspect for augmenting understandability

- it seems that the component approach and the impact it has on the software development process allows lowering the effort required to maintain the system

- adopting a component perspective allows to simplify the relationships and the collaboration between developers