Workshop TwinPeaks 2013 – Author Index |
Contents -
Abstracts -
Authors
|
| Bellomo, Stephany |
TwinPeaks '13: "Understanding the Role of ..."
Understanding the Role of Constraints on Architecturally Significant Requirements
Neil A. Ernst, Ipek Ozkaya, Robert L. Nord, Julien Delange, Stephany Bellomo, and Ian Gorton (SEI, USA) A key constraint on software development is reliance on tools, which we define as COTS products, software services, languages, frameworks and platforms. These tools may have significant architectural impacts that are not obvious when the requirements are elicited, tools selected, and architecture sketched out. In this paper, we report on a case study we conducted to identify architecturally significant requirements (ASRs) that were impacted by tool selection. We identified ASRs in an existing health IT project, CONNECT, and also identified the constraints on the project that were tool-related. We produce a mapping showing how the architectural risks identified in the initial architectural analysis were impacted by the tool choices made. We produce metrics showing how much time has been consumed when implementing ASRs that involve working around/with these constraints and the risks associated with them. 
@InProceedings{TwinPeaks13p9,
author = {Neil A. Ernst and Ipek Ozkaya and Robert L. Nord and Julien Delange and Stephany Bellomo and Ian Gorton},
title = {Understanding the Role of Constraints on Architecturally Significant Requirements},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {9--14},
doi = {},
year = {2013},
}
|
|
| Carvalho, Julia |
TwinPeaks '13: "A Domain-Centric Approach ..."
A Domain-Centric Approach for Recommending Architectural Tactics to Satisfy Quality Concerns
Mehdi Mirakhorli, Julia Carvalho, Jane Cleland-Huang, and Patrick Mäder (DePaul University, USA; Harvard University, USA; TU Ilmenau, Germany) Architectural tactics such as heartbeat, resource pooling, and scheduling, offer proven solutions for systematically increasing the reliability, security, performance, and other critical characteristics of a software system. Current literature on architectural tactics advocates a requirements-driven approach for deciding when and where tactics should be used in order to address specific quality concerns. In this paper we explore a domain-driven approach by building predictor models which capture relationships between topical domain concepts and the use of specific architectural tactics. Based on an extensive analysis of over 1000 open source systems, we identify significant correlations between domain topics and architectural tactics, and use this information to construct a predictor for generating tactic-related recommendations. Our approach is validated through a series of experiments which demonstrate the ability to generate package level recommendations. It is also illustrated through a worked example of package-level recommendations in the OfBiz Neogia system.
@InProceedings{TwinPeaks13p1,
author = {Mehdi Mirakhorli and Julia Carvalho and Jane Cleland-Huang and Patrick Mäder},
title = {A Domain-Centric Approach for Recommending Architectural Tactics to Satisfy Quality Concerns},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {1--8},
doi = {},
year = {2013},
}
|
|
| Cleland-Huang, Jane |
TwinPeaks '13: "A Domain-Centric Approach ..."
A Domain-Centric Approach for Recommending Architectural Tactics to Satisfy Quality Concerns
Mehdi Mirakhorli, Julia Carvalho, Jane Cleland-Huang, and Patrick Mäder (DePaul University, USA; Harvard University, USA; TU Ilmenau, Germany) Architectural tactics such as heartbeat, resource pooling, and scheduling, offer proven solutions for systematically increasing the reliability, security, performance, and other critical characteristics of a software system. Current literature on architectural tactics advocates a requirements-driven approach for deciding when and where tactics should be used in order to address specific quality concerns. In this paper we explore a domain-driven approach by building predictor models which capture relationships between topical domain concepts and the use of specific architectural tactics. Based on an extensive analysis of over 1000 open source systems, we identify significant correlations between domain topics and architectural tactics, and use this information to construct a predictor for generating tactic-related recommendations. Our approach is validated through a series of experiments which demonstrate the ability to generate package level recommendations. It is also illustrated through a worked example of package-level recommendations in the OfBiz Neogia system.
@InProceedings{TwinPeaks13p1,
author = {Mehdi Mirakhorli and Julia Carvalho and Jane Cleland-Huang and Patrick Mäder},
title = {A Domain-Centric Approach for Recommending Architectural Tactics to Satisfy Quality Concerns},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {1--8},
doi = {},
year = {2013},
}
|
|
| Delange, Julien |
TwinPeaks '13: "Understanding the Role of ..."
Understanding the Role of Constraints on Architecturally Significant Requirements
Neil A. Ernst, Ipek Ozkaya, Robert L. Nord, Julien Delange, Stephany Bellomo, and Ian Gorton (SEI, USA) A key constraint on software development is reliance on tools, which we define as COTS products, software services, languages, frameworks and platforms. These tools may have significant architectural impacts that are not obvious when the requirements are elicited, tools selected, and architecture sketched out. In this paper, we report on a case study we conducted to identify architecturally significant requirements (ASRs) that were impacted by tool selection. We identified ASRs in an existing health IT project, CONNECT, and also identified the constraints on the project that were tool-related. We produce a mapping showing how the architectural risks identified in the initial architectural analysis were impacted by the tool choices made. We produce metrics showing how much time has been consumed when implementing ASRs that involve working around/with these constraints and the risks associated with them.
@InProceedings{TwinPeaks13p9,
author = {Neil A. Ernst and Ipek Ozkaya and Robert L. Nord and Julien Delange and Stephany Bellomo and Ian Gorton},
title = {Understanding the Role of Constraints on Architecturally Significant Requirements},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {9--14},
doi = {},
year = {2013},
}
|
|
| Ernst, Neil A. |
TwinPeaks '13: "Understanding the Role of ..."
Understanding the Role of Constraints on Architecturally Significant Requirements
Neil A. Ernst, Ipek Ozkaya, Robert L. Nord, Julien Delange, Stephany Bellomo, and Ian Gorton (SEI, USA) A key constraint on software development is reliance on tools, which we define as COTS products, software services, languages, frameworks and platforms. These tools may have significant architectural impacts that are not obvious when the requirements are elicited, tools selected, and architecture sketched out. In this paper, we report on a case study we conducted to identify architecturally significant requirements (ASRs) that were impacted by tool selection. We identified ASRs in an existing health IT project, CONNECT, and also identified the constraints on the project that were tool-related. We produce a mapping showing how the architectural risks identified in the initial architectural analysis were impacted by the tool choices made. We produce metrics showing how much time has been consumed when implementing ASRs that involve working around/with these constraints and the risks associated with them.
@InProceedings{TwinPeaks13p9,
author = {Neil A. Ernst and Ipek Ozkaya and Robert L. Nord and Julien Delange and Stephany Bellomo and Ian Gorton},
title = {Understanding the Role of Constraints on Architecturally Significant Requirements},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {9--14},
doi = {},
year = {2013},
}
|
|
| Gorton, Ian |
TwinPeaks '13: "Understanding the Role of ..."
Understanding the Role of Constraints on Architecturally Significant Requirements
Neil A. Ernst, Ipek Ozkaya, Robert L. Nord, Julien Delange, Stephany Bellomo, and Ian Gorton (SEI, USA) A key constraint on software development is reliance on tools, which we define as COTS products, software services, languages, frameworks and platforms. These tools may have significant architectural impacts that are not obvious when the requirements are elicited, tools selected, and architecture sketched out. In this paper, we report on a case study we conducted to identify architecturally significant requirements (ASRs) that were impacted by tool selection. We identified ASRs in an existing health IT project, CONNECT, and also identified the constraints on the project that were tool-related. We produce a mapping showing how the architectural risks identified in the initial architectural analysis were impacted by the tool choices made. We produce metrics showing how much time has been consumed when implementing ASRs that involve working around/with these constraints and the risks associated with them.
@InProceedings{TwinPeaks13p9,
author = {Neil A. Ernst and Ipek Ozkaya and Robert L. Nord and Julien Delange and Stephany Bellomo and Ian Gorton},
title = {Understanding the Role of Constraints on Architecturally Significant Requirements},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {9--14},
doi = {},
year = {2013},
}
|
|
| Hesse, Tom-Michael |
TwinPeaks '13: "Supporting the Collaborative ..."
Supporting the Collaborative Development of Requirements and Architecture Documentation
Tom-Michael Hesse and Barbara Paech (University of Heidelberg, Germany) In most software projects, particular requirements significantly drive the design of the software architecture by forcing architectural decisions to be made. As requirements and architecture are refined iteratively, their extensions and improvements need to be aligned continuously. Much research has been conducted to identify such requirements and their impact on architecture. However, it remains a problem how to collaboratively document such requirements and architectural knowledge under development. In particular, knowledge of architectural decisions such as assumptions or alternatives for the system erodes over time and can even vaporize completely. A major reason is the inability to easily manage informality and complexity of knowledge when performing both requirements engineering and architecture design. Therefore, we propose a documentation model for decisions supporting the intertwined documentation of related requirements and architecture knowledge. It provides documentation elements, which are common to both disciplines. In order to support refinement in documentation, knowledge can be iteratively accumulated at different levels of granularity. So the model fits to the twin peaks model of requirements and architecture. In consequence, the comprehension and collaboration between requirements engineers and system architects is improved by negotiating and refining the same documentation together in an ongoing process. We apply our approach to an example in order to demonstrate that it is applicable and useful for managing architectural decision knowledge in relation to the grounding requirements.
@InProceedings{TwinPeaks13p22,
author = {Tom-Michael Hesse and Barbara Paech},
title = {Supporting the Collaborative Development of Requirements and Architecture Documentation},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {22--26},
doi = {},
year = {2013},
}
|
|
| Lucena, Leonardo |
TwinPeaks '13: "STREAM-AP: A Process to Systematize ..."
STREAM-AP: A Process to Systematize Architectural Patterns Choice Based on NFR
Fábio Silva, Marcia Lucena, and Leonardo Lucena (UFRN, Brasil; IFRN, Brasil) The importance of non-functional requirements for computer systems is increasing. Satisfying these requirements require special attention to the software architecture, once an unsuitable archi-tecture introduces greater complexity in addition to the intrinsic complexity of the system. Some studies have shown that, despite requirements engineering and software architecture activities act on different aspects of development, they must be performed iteratively and intertwined to produce satisfactory software systems. The STREAM process presents a systematic approach to reduce the gap between requirements and architecture development, emphasizing the functional requirements, being the non-functional ones used in an ad hoc way. However, non-functional requirements typically influence the system as a whole. This paper presents a process to improve STREAM in making the choice of architectural patterns from non-functional requirements, in order to guide the refinement of an architectural solution.
@InProceedings{TwinPeaks13p27,
author = {Fábio Silva and Marcia Lucena and Leonardo Lucena},
title = {STREAM-AP: A Process to Systematize Architectural Patterns Choice Based on NFR},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {27--34},
doi = {},
year = {2013},
}
|
|
| Lucena, Marcia |
TwinPeaks '13: "STREAM-AP: A Process to Systematize ..."
STREAM-AP: A Process to Systematize Architectural Patterns Choice Based on NFR
Fábio Silva, Marcia Lucena, and Leonardo Lucena (UFRN, Brasil; IFRN, Brasil) The importance of non-functional requirements for computer systems is increasing. Satisfying these requirements require special attention to the software architecture, once an unsuitable archi-tecture introduces greater complexity in addition to the intrinsic complexity of the system. Some studies have shown that, despite requirements engineering and software architecture activities act on different aspects of development, they must be performed iteratively and intertwined to produce satisfactory software systems. The STREAM process presents a systematic approach to reduce the gap between requirements and architecture development, emphasizing the functional requirements, being the non-functional ones used in an ad hoc way. However, non-functional requirements typically influence the system as a whole. This paper presents a process to improve STREAM in making the choice of architectural patterns from non-functional requirements, in order to guide the refinement of an architectural solution.
@InProceedings{TwinPeaks13p27,
author = {Fábio Silva and Marcia Lucena and Leonardo Lucena},
title = {STREAM-AP: A Process to Systematize Architectural Patterns Choice Based on NFR},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {27--34},
doi = {},
year = {2013},
}
|
|
| Mäder, Patrick |
TwinPeaks '13: "A Domain-Centric Approach ..."
A Domain-Centric Approach for Recommending Architectural Tactics to Satisfy Quality Concerns
Mehdi Mirakhorli, Julia Carvalho, Jane Cleland-Huang, and Patrick Mäder (DePaul University, USA; Harvard University, USA; TU Ilmenau, Germany) Architectural tactics such as heartbeat, resource pooling, and scheduling, offer proven solutions for systematically increasing the reliability, security, performance, and other critical characteristics of a software system. Current literature on architectural tactics advocates a requirements-driven approach for deciding when and where tactics should be used in order to address specific quality concerns. In this paper we explore a domain-driven approach by building predictor models which capture relationships between topical domain concepts and the use of specific architectural tactics. Based on an extensive analysis of over 1000 open source systems, we identify significant correlations between domain topics and architectural tactics, and use this information to construct a predictor for generating tactic-related recommendations. Our approach is validated through a series of experiments which demonstrate the ability to generate package level recommendations. It is also illustrated through a worked example of package-level recommendations in the OfBiz Neogia system.
@InProceedings{TwinPeaks13p1,
author = {Mehdi Mirakhorli and Julia Carvalho and Jane Cleland-Huang and Patrick Mäder},
title = {A Domain-Centric Approach for Recommending Architectural Tactics to Satisfy Quality Concerns},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {1--8},
doi = {},
year = {2013},
}
|
|
| Mirakhorli, Mehdi |
TwinPeaks '13: "A Domain-Centric Approach ..."
A Domain-Centric Approach for Recommending Architectural Tactics to Satisfy Quality Concerns
Mehdi Mirakhorli, Julia Carvalho, Jane Cleland-Huang, and Patrick Mäder (DePaul University, USA; Harvard University, USA; TU Ilmenau, Germany) Architectural tactics such as heartbeat, resource pooling, and scheduling, offer proven solutions for systematically increasing the reliability, security, performance, and other critical characteristics of a software system. Current literature on architectural tactics advocates a requirements-driven approach for deciding when and where tactics should be used in order to address specific quality concerns. In this paper we explore a domain-driven approach by building predictor models which capture relationships between topical domain concepts and the use of specific architectural tactics. Based on an extensive analysis of over 1000 open source systems, we identify significant correlations between domain topics and architectural tactics, and use this information to construct a predictor for generating tactic-related recommendations. Our approach is validated through a series of experiments which demonstrate the ability to generate package level recommendations. It is also illustrated through a worked example of package-level recommendations in the OfBiz Neogia system.
@InProceedings{TwinPeaks13p1,
author = {Mehdi Mirakhorli and Julia Carvalho and Jane Cleland-Huang and Patrick Mäder},
title = {A Domain-Centric Approach for Recommending Architectural Tactics to Satisfy Quality Concerns},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {1--8},
doi = {},
year = {2013},
}
|
|
| Nord, Robert L. |
TwinPeaks '13: "Understanding the Role of ..."
Understanding the Role of Constraints on Architecturally Significant Requirements
Neil A. Ernst, Ipek Ozkaya, Robert L. Nord, Julien Delange, Stephany Bellomo, and Ian Gorton (SEI, USA) A key constraint on software development is reliance on tools, which we define as COTS products, software services, languages, frameworks and platforms. These tools may have significant architectural impacts that are not obvious when the requirements are elicited, tools selected, and architecture sketched out. In this paper, we report on a case study we conducted to identify architecturally significant requirements (ASRs) that were impacted by tool selection. We identified ASRs in an existing health IT project, CONNECT, and also identified the constraints on the project that were tool-related. We produce a mapping showing how the architectural risks identified in the initial architectural analysis were impacted by the tool choices made. We produce metrics showing how much time has been consumed when implementing ASRs that involve working around/with these constraints and the risks associated with them.
@InProceedings{TwinPeaks13p9,
author = {Neil A. Ernst and Ipek Ozkaya and Robert L. Nord and Julien Delange and Stephany Bellomo and Ian Gorton},
title = {Understanding the Role of Constraints on Architecturally Significant Requirements},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {9--14},
doi = {},
year = {2013},
}
|
|
| Ozkaya, Ipek |
TwinPeaks '13: "Understanding the Role of ..."
Understanding the Role of Constraints on Architecturally Significant Requirements
Neil A. Ernst, Ipek Ozkaya, Robert L. Nord, Julien Delange, Stephany Bellomo, and Ian Gorton (SEI, USA) A key constraint on software development is reliance on tools, which we define as COTS products, software services, languages, frameworks and platforms. These tools may have significant architectural impacts that are not obvious when the requirements are elicited, tools selected, and architecture sketched out. In this paper, we report on a case study we conducted to identify architecturally significant requirements (ASRs) that were impacted by tool selection. We identified ASRs in an existing health IT project, CONNECT, and also identified the constraints on the project that were tool-related. We produce a mapping showing how the architectural risks identified in the initial architectural analysis were impacted by the tool choices made. We produce metrics showing how much time has been consumed when implementing ASRs that involve working around/with these constraints and the risks associated with them.
@InProceedings{TwinPeaks13p9,
author = {Neil A. Ernst and Ipek Ozkaya and Robert L. Nord and Julien Delange and Stephany Bellomo and Ian Gorton},
title = {Understanding the Role of Constraints on Architecturally Significant Requirements},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {9--14},
doi = {},
year = {2013},
}
|
|
| Paech, Barbara |
TwinPeaks '13: "Supporting the Collaborative ..."
Supporting the Collaborative Development of Requirements and Architecture Documentation
Tom-Michael Hesse and Barbara Paech (University of Heidelberg, Germany) In most software projects, particular requirements significantly drive the design of the software architecture by forcing architectural decisions to be made. As requirements and architecture are refined iteratively, their extensions and improvements need to be aligned continuously. Much research has been conducted to identify such requirements and their impact on architecture. However, it remains a problem how to collaboratively document such requirements and architectural knowledge under development. In particular, knowledge of architectural decisions such as assumptions or alternatives for the system erodes over time and can even vaporize completely. A major reason is the inability to easily manage informality and complexity of knowledge when performing both requirements engineering and architecture design. Therefore, we propose a documentation model for decisions supporting the intertwined documentation of related requirements and architecture knowledge. It provides documentation elements, which are common to both disciplines. In order to support refinement in documentation, knowledge can be iteratively accumulated at different levels of granularity. So the model fits to the twin peaks model of requirements and architecture. In consequence, the comprehension and collaboration between requirements engineers and system architects is improved by negotiating and refining the same documentation together in an ongoing process. We apply our approach to an example in order to demonstrate that it is applicable and useful for managing architectural decision knowledge in relation to the grounding requirements.
@InProceedings{TwinPeaks13p22,
author = {Tom-Michael Hesse and Barbara Paech},
title = {Supporting the Collaborative Development of Requirements and Architecture Documentation},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {22--26},
doi = {},
year = {2013},
}
|
|
| Silva, Fábio |
TwinPeaks '13: "STREAM-AP: A Process to Systematize ..."
STREAM-AP: A Process to Systematize Architectural Patterns Choice Based on NFR
Fábio Silva, Marcia Lucena, and Leonardo Lucena (UFRN, Brasil; IFRN, Brasil) The importance of non-functional requirements for computer systems is increasing. Satisfying these requirements require special attention to the software architecture, once an unsuitable archi-tecture introduces greater complexity in addition to the intrinsic complexity of the system. Some studies have shown that, despite requirements engineering and software architecture activities act on different aspects of development, they must be performed iteratively and intertwined to produce satisfactory software systems. The STREAM process presents a systematic approach to reduce the gap between requirements and architecture development, emphasizing the functional requirements, being the non-functional ones used in an ad hoc way. However, non-functional requirements typically influence the system as a whole. This paper presents a process to improve STREAM in making the choice of architectural patterns from non-functional requirements, in order to guide the refinement of an architectural solution.
@InProceedings{TwinPeaks13p27,
author = {Fábio Silva and Marcia Lucena and Leonardo Lucena},
title = {STREAM-AP: A Process to Systematize Architectural Patterns Choice Based on NFR},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {27--34},
doi = {},
year = {2013},
}
|
|
| Sutcliffe, Alistair |
TwinPeaks '13: "Bridging Users' Values ..."
Bridging Users' Values and Requirements to Architecture
Alistair Sutcliffe (University of Lancaster, UK) The paper describes a process for bridging from users' values and goal oriented requirements to architecture via architecture patterns. User values, such as privacy, sociability, creativity, etc are introduced and their implications for system architecture are explained. Many architectural implications are common to several user values so architecture patterns are proposed to collate these as high level requirements for components which can then be related to NFRs as well as user values. The process of analysing user values through to design of system architecture is illustrated with a case study in health informatics.
@InProceedings{TwinPeaks13p15,
author = {Alistair Sutcliffe},
title = {Bridging Users' Values and Requirements to Architecture},
booktitle = {Proc.\ TwinPeaks},
publisher = {IEEE},
pages = {15--21},
doi = {},
year = {2013},
}
|
16 authors
proc time: 0.02