@article {Simula.approve.88,
	title = {The Value of Design Rationale Information},
	journal = {ACM Transactions on Software Engineering and Methodology},
	volume = {22},
	year = {2013},
	publisher = {ACM},
	abstract = {A complete and detailed Design Rationale Documentation (DRD) could support many software development activities, such as an impact analysis or a major redesign. However, a full DRD is too onerous for systematic industrial use as it is not cost-effective to write, maintain, or read. The key idea investigated in this paper is that DRD should be adopted only to the extent required to support activities particularly difficult to enact or in need of significant improvement in a particular context. The aim of this paper is to empirically investigate the possibility to customize the DRD by documenting only the information that will probably be required for executing an activity. This customization strategy relies on the hypothesis that the value of a DRD information item depends on its category (e.g. Assumptions, Related requirements, etc.) and on the activity it is meant to support. This hypothesis is investigated through two controlled experiments involving a total of seventy-five post-graduate master students as experimental subjects. The value of DRD information was shown to significantly depend on its category and, within the same category, on the activity it supports. Furthermore, our results show that, on average among activities, documenting only the information that has been required at least half of the time (i.e., the information that will probably be required in the future) generates a customized DRD containing about half the information of a full documentation. Such a significant reduction of information to document is expected to mitigate the effects of inhibitors that are currently preventing practitioners from documenting the rationale of their design decisions.},
	author = {Falessi, Davide and Briand, Lionel Claude and Cantone, Giovanni and Capilla, Rafael and Kruchten, Philippe}
}
@article {Simula.simula.213,
	title = {Decision-Making Techniques for Software Architecture Design: a Comparative Survey},
	journal = {ACM Computing Surveys},
	volume = {43},
	number = {4},
	year = {2011},
	publisher = {ACM},
	abstract = {The architecture of a software intensive system can be defined as the set of relevant design decisions that affect the qualities of the overall system functionality; therefore, architectural decisions are eventually crucial to the success of a software project. The software engineering literature describes several techniques to choose among architectural alternatives, but it gives no clear guidance on which technique is more suitable than another, and in which circumstances. As such, there is no systematic way for software engineers to choose among decision-making techniques for resolving tradeoffs in architecture design. In this paper, we provide a comparison of existing decision-making techniques, aimed to guide architects in their selection. Results show that there is no \&ldquo;best\&rdquo; decision-making technique; however, some techniques are more susceptible to specific difficulties. Hence, architects should choose a decision-making technique based on the difficulties that they wish to avoid. This paper represents a first attempt to reason on meta-decision-making, i.e., the issue of deciding how to decide.},
	doi = {10.1145/1978802.1978812 },
	author = {Falessi, Davide and Cantone, Giovanni and Kazman, Rick and Kruchten, Philippe}
}
@article {Simula.simula.209,
	title = {Applying Empirical Software Engineering to Software Architecture: Challenges and Lessons Learned},
	journal = {Empirical Software Engineering},
	volume = {15},
	number = {3},
	year = {2010},
	pages = {250-276},
	publisher = {Springer},
	abstract = {In the last 15 years, software architecture has emerged as an important software engineering field for managing the development and maintenance of large, software-intensive systems. Software architecture community has developed numerous methods, techniques, and tools to support the architecture process (analysis, design, and review). Historically, most advances in software architecture have been driven by talented people and industrial experience, but there is now a growing need to systematically gather empirical evidence about the advantages or otherwise of tools and methods rather than just rely on promotional anecdotes or rhetoric. The aim of this paper is to promote and facilitate the application of the empirical paradigm to software architecture. To this end, we describe the challenges and lessons learned when assessing software architecture research that used controlled experiments, replications, expert opinion, systematic literature reviews, observational studies, and surveys. Our research will support the emergence of a body of knowledge consisting of the more widely-accepted and well-formed software architecture theories.},
	doi = {10.1007/s10664-009-9121-0},
	author = {Falessi, Davide and Muhammad Ali {Babar} and Cantone, Giovanni and Kruchten, Philippe}
}
@techreport {Simula.simula.277,
	title = {The Value of Design Rationale Information},
	number = {2010-13},
	year = {2010},
	publisher = {Simula Research Laboratory},
	abstract = {A complete and detailed Design Rationale Documentation (DRD) could support many software development activities, such as an impact analysis or a major redesign. However, a full DRD is too onerous for systematic industrial use as it is not cost-effective to write, maintain, or read. The key idea investigated in this paper is that DRD should be adopted only to the extent required to support activities particularly difficult to enact or in need of significant improvement in a particular context. The aim of this paper is to empirically investigate the possibility to customize the DRD by documenting only the information that will probably be required for executing an activity. This customization strategy relies on the hypothesis that the value of a DRD information item depends on its category (e.g. Assumptions, Related requirements, etc.) and on the activity it is meant to support. This hypothesis is investigated through two controlled experiments involving a total of seventy-five post-graduate master students as experimental subjects. The value of DRD information was shown to significantly depend on its category and, within the same category, on the activity it supports. Furthermore, our results show that, on average among activities, documenting only the information that has been required at least half of the time (i.e., the information that will probably be required in the future) generates a customized DRD containing about half the information of a full documentation. Such a significant reduction of information to document is expected to mitigate the effects of inhibitors that are currently preventing practitioners from documenting the rationale of their design decisions.},
	author = {Falessi, Davide and Briand, Lionel and Cantone, Giovanni and Capilla, Rafael and Kruchten, Philippe}
}
@inproceedings {Simula.simula.478,
	title = {Value-Based Design Decision Rationale Documentation: a Replicated Experiment},
	journal = {Proceedings of the 3rd international workshop on Sharing and reusing architectural knowledge},
	year = {2008},
	publisher = {ACM},
	type = {Conference},
	abstract = {ABSTRACT The explicit documentation of the rationale of design decisions is a practice generally encouraged but rarely implemented in industry because of a variety of inhibitors. Known methods for Design Decisions Rationale Documentation (DDRD) are aimed to maximize the benefits for practitioners who should utilize the DDRD by imposing the burden on the developers of documenting all the potentially useful information. In our view, the adoption of a tailored DDRD, consisting only of the required set of information, would mitigate the effects of DDRD inhibitors. This paper focuses on confirming empirically the feasibility of a valuebased approach for documenting the rationale behind design decisions, and the importance of different DDRD information categories. In this context, this work describes a replicated experiment carried out at the University Rey Juan Carlos of Madrid (Spain) aimed to validate previous results from an analogous study conducted at the University of Roma Tor Vergata (Italy). Results confirm that the level of utility related to the same category of DDRD information significantly changes depending on its purpose.},
	isbn = {978-1-60558-038-8},
	author = {Falessi, Davide and Capilla, Rafael and Cantone, Giovanni},
	editor = {Avgeriou, Paris and Lago, Patricia and Kruchten, Philippe}
}
@inproceedings {Simula.simula.442,
	title = {Value-Based Design Decision Rationale Documentation: Principles and Empirical Feasibility Study},
	journal = {Seventh Working IEEE/IFIP Conference on Software Architecture},
	year = {2008},
	publisher = {IEEE},
	type = {Conference},
	abstract = {The explicit documentation of the rationale of design decisions is a practice generally encouraged, but rarely implemented in industry because of a variety of inhibitors. Methods proposed in the past for Design Decisions Rationale Documentation (DDRD) aimed to maximize benefits for the DDRD consumer by imposing on the producer of DDRD the burden to document all the potentially useful information. We propose here a compromise which consists in tailoring DDRD, based on its intended use or purpose. In our view, the adoption of a tailored DDRD, consisting only of the required set of information, would mitigate the effects of DDRD inhibitors. The aim of this paper is twofold: i) to discuss the application of Value-Based Software Engineering principles to DDRD, ii) to describe a controlled experiment to empirically analyze the feasibility of the proposed method. Results show that the level of utility related to the same category of DDRD information significantly changes depending on its purpose; such result is novel and it demonstrates the feasibility of the proposed valuebased DDRD.},
	isbn = {978-0-7695-3092-5},
	author = {Falessi, Davide and Cantone, Giovanni and Kruchten, Philippe},
	editor = {Kruchten, Philippe and Garlan, David and Woods, E{\'o}in}
}
@inproceedings {Simula.simula.444,
	title = {Do Software Architecture Design Methods Meet Architects{\textquoteright} Needs?},
	journal = {Sixth Working IEEE/IFIP Conference on Software Architecture},
	year = {2007},
	publisher = {IEEE},
	type = {Conference},
	abstract = {Several Software Architecture Design Methods (SADM) have been published, reviewed, and compared. But these surveys and comparisons are mostly centered on intrinsic elements of the design method, and they do not compare them from the perspective of the actual needs of software architects.We would like to analyze the completeness of SADM from an architect{\textquoteright}s point of view. To do so, we define nine categories of software architects{\textquoteright} needs, propose an ordinal scale for evaluating the degree to which a given SADM meets the needs, and then apply this to a small set of SADMs. The contribution of the paper is twofold: (i) to provide a different and useful frame of reference for architects to select SADM, and (ii) to suggest SADM areas of improvements. We found two answers to our question: {\textquotedblleft}do architectural design methods meet the needs of the architect?{\textquotedblright} Yes, all architect{\textquoteright}s needs are met by one or another SADM, but No, no architectural design method meets simultaneously all the needs of an architect. This approach may lead to improvements of existing SADMs.},
	isbn = {978-0-7695-2744-4},
	author = {Falessi, Davide and Cantone, Giovanni and Kruchten, Philippe},
	editor = {Paulish, Dan and Gorton, Ian and Tyree, Jeff and Soni, Dilip}
}
@inproceedings {Simula.simula.452,
	title = {Issues in Applying Empirical Software Engineering to Software Architecture},
	journal = {First European Conference on Software Architecture},
	volume = {LNCS 4758/2007},
	year = {2007},
	publisher = {Springer},
	type = {Conference},
	abstract = {Empirical software engineering focuses on the evaluation of software engineering technologies, such as processes and tools, by comparing related sets of data. It has contributed a valuable body of knowledge in several areas such as Software Economics and Software Quality, which in turn drove important advances in related tools and techniques. Unfortunately this is not (yet) the case for software architecture, where empirical studies are still few. Such a condition demands for further empirical research efforts on the topic of software architecture and suggests specific areas of improvement. In this paper we discuss several essential, innovative, and maybe provocative, questions such as: Why do we have so few applications of empirical software engineering on software architecture? Which are the main difficulties? What can we do?},
	isbn = {9783540751311},
	author = {Falessi, Davide and Kruchten, Philippe and Cantone, Giovanni},
	editor = {Carlos Enrique {Cuesta} and Marcos, Esperanza and Oquendo, Flavio}
}
