6. CONCLUSION
Software design is inherently complex to study for the following
reasons:
• The activity boundaries between requirements, design and
implementation phases can be fuzzy because of the
presence of continuous implicit design activities;
• Design artifacts are often not implemented as designed,
and some implemented artifacts have not been explicitly
designed;
• There is a wide variability of constraints regarding the
nature of the application, the team’s experience and the
project parameters.
For these reasons, this case study will have limited generalization.
Data values are only indicative of one very specific case.
However, it is believed that studies like this one are important
because they shed light on an essential process which might not
differ fundamentally from project to project. Many processes and
frameworks present some form of design activities.
This study explores the impact of the design artifacts through the
analysis of quantitative data like class size and complexity, as well
as qualitative data like class concerns and coupling. Data were
captured from a project realized by a team of five senior students
as part of their degree capstone project. The resulting software
product was of good external quality, and has been integrated into
the participating industry’s software environment. The project was
successful and all the milestones were achieved on schedule. One
of these was to deliver and present the design of the product
before the implementation iterations began.
Our main finding is that software pre-implementation artifacts,
unlike traditional engineering artifacts, are not only a plan to
follow, but are also a mean to facilitate the sharing of the project
understanding and of the resulting mental model of each of the
teammates. Most important, it represents the understanding of the
team members at the time the design was realized. This
understanding will evolve with the developer progresses into the