A practical framework for re-factoring a software architecture with agile approaches.

From Master Projects
Jump to: navigation, search


has title::Improving software evolvability by exploiting change history and software metrics
status: finished
Master: project within::Software Engineering
Student name: student name::Antonio Cappiello
Dates
Start start date:=2012/01/23
End end date:=2012/08/08
Supervision
Supervisor: Hans van Vliet
Second supervisor: Joost Huizinga
Second reader: has second reader::Ivica Crnkovic
Company: has company::WoodWing Software
Thesis: has thesis::Media:Thesis.pdf
Poster: has poster::Media:Posternaam.pdf

Signature supervisor



..................................

Abstract

The design phase is a fundamental step of the development process of a software product. It defines the architecture of the software, which plays an important role as vehicle of communication among the stakeholders, dictates the organizational structure of the company and embodies the most relevant design decision.

WoodWing Software has noticed during the years an increasing gap between its initial software architecture and its software product. This gap has been caused mainly because it has dedicated less and less time to the design phase during the releases. This has resulted in a messed up architecture that is not very useful in supporting the maintenance of the current software product, as well as any future additions to the software product.

Their original development methodology has been a sort of the classical waterfall model 10 years, with iterations approximately every year for new releases. In the last 2 years, they have switched to a more agile approach that is a result of the scrum and extreme programming methodology customized to their need.

By now this switch has improved the development process making the “development spring” shorter and reducing the scope of the work, but they still have not had the time to reduce the gap between the documented architecture and the real product. Moreover, the architecture of the real product is neither that flexible to be adapted to new updates, neither that formally consolidated to have a clear vision of the whole product.

They would like to find a risk-limiting way for re-factoring the whole software, which can be considered the classical example of a “spaghetti-product”, in order to make the future maintenance process more affordable either from a practical perspective or from the financial point of view.