Isolating and Predicting Risks in Architectural Design

Failure to manage risks often causes budget and schedule problems in software projects. Software architectures are difficult to change at later stages and determine software quality attributes such as maintainability. Error-proneness and change propagation risks occur in software that is difficult to maintain. If risks can be isolated into architecture subsets called risk containers, practitioners could prioritise mitigations towards the riskiest containers to increase the chances of project success. Some existing software architecture analysis techniques attribute maintainability risks to architecture subsets, but previous research fails to consider which kinds of architecture subsets are risk isolating (risk inducing architecture elements are not shared with other containers). Furthermore, the architecture description standard does not include guidance for describing risks. This thesis addresses those knowledge gaps. Three types of risk container are extracted from the architectural designs of four software projects and metrics are used to determine which container type is the most risk isolating. Design Rule Containers are the most effective container type because they have very strong and significant correlations between design metrics and implementation change propagation, moderate or stronger correlations between design metrics and implementation error-proneness, but crucially they overlap less than Resource and Use Case Containers which means they are more risk isolating. An experiment demonstrates that participants were able to locate more error-inducing architecture flaws using smaller container diagrams, than when using a larger overall diagram. An architecture risk model based on the international standards for architecture description and risk management is synthesised from the output architecture analysis techniques, including risk containers, so that the isolated risks can be communicated. Surveyed practitioners consider the model to be more applicable to waterfall software development than agile and prefer the model to textual risk descriptions due to the fidelity, rigour, and traceability supported by the model