Proceedings of 16th International Conference on Software Engineering

R. Kazman; L. Bass; G. Abowd; M. Webb

University of Waterloo

R. Kazman; G. Abowd; L. Bass; P. Clements

University of Waterloo, Canada

Develop scenarios. As we described earlier, the first and second steps are highly interdependent. While we were evolving an architectural description, we were continually developing scenarios that represented the various stakeholder roles in the system (page 5)

IEEE/IFIP Conference on Software Architecture (WICSA 2004)

University of Twente

IFIP International Conference on Engineering for Human-Computer Interaction

Eelke Folmer, Jilles van Gurp & Jan Bosch

University of Groningen

4.1 Create Usage Profile
The steps that need to be taken for usage profile creation are the following: Software Architecture Analysis of Usability 45
1. Identify the users: rather than listing individual users, users that are representative for the use of the system should be categorized in types or groups (for example system administrators, end-users etc).
2. Identify the tasks: Instead of converting the complete functionality of the system into tasks, representative tasks are selected that highlight the important features of the system. For example, a task may be “find out where course computer vision is given”.
3. Identify the contexts of use: In this step, representative contexts of use are identified. (For example. Helpdesk context or disability context.) Deciding what users, tasks and contexts of use to include requires making tradeoffs between all sorts of factors. An important consideration is that the more scenarios are evaluated the more accurate the outcome of the assessment is, but the more expensive and time consuming it is to determine attribute values for these scenarios.
4. Determine attribute values: For each valid combination of user, task and context of use, usability attributes are quantified to express the required usability of the system, based on the usability requirements specification. Defining specific indicators for attributes may assist the analyst in interpreting usability requirements as will be illustrated in the case study in section 5. To reflect the difference in priority, numeric values between one and four have been assigned to the attributes for each scenario. Other techniques such as pair wise comparison may also be used to determine a prioritization between attributes.
5. Scenario selection & weighing: Evaluating all identified scenarios may be a costly and time-consuming process. Therefore, the goal of performing an assessment is not to evaluate all scenarios but only a representative subset. Different profiles may be defined depending on the goal of the analysis. For example, if the goal is to compare two different architectures, scenarios may be selected that highlight the differences between those architectures. If the goal is to analyze the level of support for usability, scenarios may be selected that are important to the users. To express differences between usage scenarios in the usage profile, properties may be assigned to scenarios, for example: priority or probability of use within a certain time. The result of the assessment may be influenced by weighing scenarios, if some scenarios are more important than others, weighing these scenarios reflect these differences. A usage profile that is created using these steps is summarized in a table (See Table 2). Figure 2 shows the usage profile creation process.

Journal of Systems and Software

Bedir Tekinerdogan, Hasan Sozer, Mehmet Aksit

University of Twent

European Conference on Software Architecture

Iffat Fatima(B) and Patricia Lago

Vrije Universiteit Amsterdam

2013 35th International Conference on Software Engineering (ICSE)

Agile Software Architecture

Georg Buchgeher *, Rainer Weinreich

Software Competence Center Hagenberg (SCCH), Hagenberg, Austria

Continuous testing is a combination of techniques and tools like test-driven development (TDD) and regression testing [56]. TDD [59] is essentially a method for continuously developing test-cases as part of software design. It is thus also seen as a design approach, because it ensures that the system is testable by applying good design principles [60]. Regression testing, on the other hand, is the process of retesting software after modifications to ensure that the new version of the software has retained the capabilities of the old version and that no new defects have been introduced [61]. Both TDD and regression testing are well integrated into the development process. Tools for creating and executing test cases are integrated with development tools and environments and provide test automation, which is important due to the principle of constant change in agile processes. Continuous code analysis as provided by static code analysis tools like PMD,b Checkstyle,c and FindBugs™d are either directly integrated in an Integrated Development Environment (IDE) or in the build infrastructure and can thus be applied automatically and on a regular basis. CI [57,62] also provides automation using a dedicated build infrastructure (build server). It promotes the principle of early build and delivery. Builds are typically performed on a daily basis. Building a system usually incorporates the execution of test cases and of static code analysis. Continuous refactoring [52], on the other hand, focuses on problem resolution rather than analysis, though analysis activities need to precede refactoring activities. In the ideal case, refactoring is also performed continuously [58], because it is easier to make several smaller changes throughout the development process than to make larger changes later in development. However, large refactorings cannot always be avoided [43]. Refactoring support is often part of modern IDEs. Finally, pair programming [52] is an example for continuous ad hoc analysis during development. Code is developed collaboratively by two developers sitting in front of one machine. Analysis during development is ad hoc and thus not easily repeatable.

Journal of Systems and Software

Phase 1: Analyze the implicaons of change smuli on soware architecture
Phase 2: Analyze and prepare soware architecture to accommodate change
smuli and potenal future changes
Phase 3: Finalize the evaluaon
(Figure 3)

2013 Sixth Latin-American Symposium on Dependable Computing

João M. Franco; Raul Barbosa; Mário Zenha-Rela

University of Coimbra, Portugal

Software Quality Journal

LIMING ZHU, AYBUKE AURUM, IAN GORTON, ROSS JEFFERY

University of New South Wales

Tenth International Workshop on Software Specification and Design. IWSSD-10 2000

University of California, bine

Formal Methods for Software Architectures

Jeff Kramer, Jeff Magee & Sebastian Uchitel

Department of Computing, Imperial College London

2011 Eighth International Conference on Information Technology: New Generations

University of Illinois at Chicago

In another study we looked at the multi-year evolution of a software system in a captive software community connected by a common business licensing agreement. The original approach specified the evolution of the software architecture at a high level of detail accounting for uncertainty through scenario analysis. However, selecting the most probable scenario was consistently failing to
provide meaningful guidance, because the variability of business needs and the changes to the contextual environment make architectural prediction very hard. A much more successful outcome resulted when the emergent nature of software was understood and accepted. As a result, the software architecture evolution was modified to focus on providing sufficient flexibility across decision points and to guide architecture evolution by calibrating the influencers. An example of calibration was the decision to increase the modifiability of the system by increasing the separation of concerns between a messaging functionality and the image transport application-specific functionality. This decision was intended to accommodate the expectation that different types of payload may need to be transported in the future, in addition to images. Once the architectural calibration was done to account for the change in the software purpose, further specification was delegated to the design and development activities. The emergent approach to specifying software architecture has proved in multiple studies to be much more scalable and practical than the traditional approach to predict and over specify.

Empirical Software Engineering

Jihyun Lee, Sungwon Kang & Chang-Ki Kim

Information and Communications University, Seoul

International Conference on Fundamental Approaches to Software Engineering

Robert Allen, Rdmi Douence, and David Garlan

Carnegie Mellon University

3rd IEEE International Workshop on Visualizing Software for Understanding and Analysis

K. Gallagher; A. Hatch; M. Munro

University of Durham

Proceedings of the 34th Annual Hawaii International Conference on System Sciences

University of Auckland

Formal Methods for Software Architectures

Carnegie Mellon University

FSE 2014: Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering

Lu Xiao, Yuanfang Cai, Rick Kazman

Drexel University

17th IEEE International Conference and Workshops on Engineering of Computer Based Systems

Heriot-Watt University

Su Liu, Reng Zeng, Zhuo Sun, Xudong He

Florida International University

Memorias del X Workshop Latinoamericano Ingeniería de Software Experimental

Silverio Martínez-Fernández, Claudia Ayala, Xavier Franch, David Ameller

Universitat Politècnica de Catalunya

Proceedings of First BeNeLux conference on software architecture

Nico Lassing, Daan Rijsenbrij and Hans van Vliet

Vrije Universiteit

2010 Fifth International Conference on Software Engineering Advances

Georg Buchgeher; Rainer Weinreich

Software Competence Center Hagenberg

Capturing of Scenarios: Scenarios are special kinds of requirements, which are part of the LISA model. They can be linked to other elements of the architecture model. This way we support traceability between the scenario and the parts of the architecture where the scenario is addressed.
Prioritization of Scenarios: Scenarios can be ranked according to their importance and difficulty. Each scenario has a quality attribute category. Using these information scenarios can be visualized as utility tree (see Figure 6).
A utility tree is a central part of ATAM for refining a system’s quality attributes. Further scenarios can be sorted according to their importance and difficulty. This supports the selection of the most important and difficult scenarios.
(page 6)

European Conference on Software Architecture

Warsaw University of Technology

2023 IEEE 20th International Conference on Software Architecture (ICSA)

Priyadarshini; Simon Greiner; Maike Massierer; Oum-El-Kheir Aktouf

Robert Bosch GmbH, Cross Domain Computing Solutions, Abstatt, Germany

We evaluate our implementation of the method by applying it to a real-world component for autonomous driving. We show that the method is able to identify unintended interactions while providing only few false positive findings.

1. Architectural elements analysis
2. Behavioral analysis
3. Interaction analysis

Proceedings. Fifth IEEE International Symposium on High Assurance Systems Engineering (HASE 2000)

University of Kent at Canterbury

Software architecture risk analysis (SARA): A methodology to assess security risks in software architectures, and an application

Archit. Defin. Eval

Defence Research and Development Canada

PROCEEDINGS OF THE 3D PROGRESS WORKSHOP ON EMBEDDED SYSTEMS

Johan Muskens, Michel Chaudron and Rob Westgeest

Technische Universiteit Eindhoven

Joint proceedings of the second international software architecture workshop (ISAW-2) and international workshop on multiple perspectives in software development

Sonia Bot, Chung-Horng Lung, Mark Farrell

Nortel Technology

Using the Architecture Tradeoff Analysis Method (ATAM) to evaluate the software architecture for a product line of avionics systems: A case study

Software Engineering Institute, Carnegie Mellon University

Mario Barbacci, Paul Clements, Anthony Lattanze, Linda Northrop, William Wood

Carnegie Mellon University

International Conference on Software Engineering and Computer Systems

M. A. Isa & Dayang N. A. Jawawi

Universiti Teknologi Malaysia

CPASA [6] method is proposed as an enhancement of the PASA method for enhancing performance assessment of software architecture. Originally, the PASA method aims to assess the performance aspects of system architecture with consideration of the specifications and requirements of the system when it is already completed. In response to this, CPASA was designed to enable continuous change as early as the requirements engineering level. System requirements evolve throughout the development lifecycle in order to obtain the best final design decisions. Therefore, any performance problems could be detected and fixed along the way to avoid problems in the final design decision. The CPASA method revises the original PASA method in two main aspects.
The first aspect is the development scopes. Unlike the PASA method, which focuses on the design steps, the CPASA method covers the requirement step until the design step in terms of performance assessment. The second aspect is the minimization of step in the performance assessment process. The CPASA method concentrates on minimizing the performance assessment steps with the
help of the agile development process. This process intends to benefit the stakeholders when the requirements are frequently changed during the performance assessment process. The result from solving performance issues in system architecture with the CPASA method can provide a complete system design with the continuous change in the initial design decision during development process.

Proceedings of Nordic Workshop on Programming and Software Development Environment Research

University of Karlskrona/Ronneby

IWPSE '02: Proceedings of the International Workshop on Principles of Software Evolutio

Nanzan University

(1) Evolution Cost Metrics
For sofhvare architectures, evolution is made by a set of change operations on the components and connectors. As illustrated in Figure 2, we assume software architecture as a tree comprising of a set of components and connectors connecting them. Each component and connector is identified with a unique identifier, label.
To measure the evolution of software architectures, we introduce thc metrics based on the rewriting opcrdtions on the trees. As commonly used, we employ following three types of operations on the components and connectors.

(2) Metrics of Architecture Preservation over the Evolution
Now, we introduce a metric of architectare preservation factor, APF in short. Assume all the elements in a tree are prenrdered. And, assume there is a mapping from an element Ei in the tree "IN to an element Ej in the tree TM. Denote such a mapping as a pair (i, j). So, we denote the collection of all such mappings (i, j) as XNM. For any (it, Jr) and 02, J2) in Xm, t, we assume XtCM meets the following three conditions [9, 10].
1) it = i2 if and only ifjt =J2
2) it < i2 if and only ifji <j2
3) it is ancestor ofi 2 if and only ifji is an anccktor ofj2
The above three conditions preserve local structure within a mapping Xto, t- However, as illustrated in Figure 3, our concern is change of software architecture. So, the condition 3) is modified to 3a) as follows 3a) For it, i2, there is a sub-tree Sit and Si2 and an element e(i) of maximum ordering number starting from i, e(ii) < i2 if and only if c(Sii) < Si x
If a mapping, XNM, meets the conditions of 1), 2) and 3a), it is generally called structure preservation mapping. By setting the origin of the sub-tree to the mot of the tree, we call the sub-tree, meeting the conditions of 1), 2) and 3a), as APM (Architecture Preservation Mapping).

Proceedings of the First Working IFIP Conference on Software Architecture

George Mason University

Software architecture for unified management of event notification and stream I/O and its use for recording and analysis of user events

Proceedings of the 35th Annual Hawaii International Conference on System Sciences

Jan Stelovsky and Christoph Aschwanden

University of Hawaii at Manoa

Proceedings of the Int. Conf. on Computer and Communication Engineering,

D. Nassar, W. AbdelMoez, M. Shereshevsky, H. H. Ammar, Ali Mili, Bo Yu, S. Bogazzi

West Virginia University

International Conference on Software Reuse

University Politehnica of Bucharest

Electronic Communications of the EASST

SAP AG Darmstadt

Fourth Annual ACIS International Conference on Computer and Information Science (ICIS'05)

Younbok Lee; Ho-Jin Choi

Step 2 & 3: Refine and prioritize scenarios
This step is to refine scenarios to get more detailed and concrete response goals. ATAM has only one notion of response measure whereas CBAM has five:
(1)worst case, (2)best case, (3)current case, (4)desired case, and (5)expected case. A response measure in an ATAM evaluation is comparable to a desired-case response measure in a CBAM evaluation [3].
Here, only four values of the quality attribute response level will be elicited and recorded because a current-case value is not available for the new development while it can be elicited from the system with maintenance or upgrade purpose. The desiredcase quality attribute level indicates the targeted state that we want to achieve [1, 12]. In Table 2 below, '50% ripple' can be understood as one of two people is likely to incorporate the defect during changing source code.
In this step, the weight of the scenario was rated with the consideration of its economic implication for the business goals. The weight of entire set of scenarios was constrained to 100. In this context, the rationale for putting the weight value to each scenario can be summarized as the following:
- The risk of 'being behind schedule' is so critical for the success of the project.
- Scenario 2 came from the customer's requirement, 'deliver the system in Korean and English version'.
Scenario 3 is also important in that none of team members will maintain the system.
- The usability issue in scenario 3 in is rather important in typical web-based system. Our customer stressed the easiness of WBS manipulation.
- Availability aspect in scenario 4 is less important since the number of concurrent users is not so high and user group is rather restricted.

Proceedings. 2005 IEEE Networking, Sensing and Control, 2005.

Jiwen Wang; Chenghao Guo; Fengyu Liu

Nanjing University of S&T

The second one is autonomy: it should provide the
ability to address the anomalies (discovered through
observability in the performance of a resulting system or its
execution environments). Autonomy is achieved according to
the following steps: planning, deploying, and making the
imperative changes;

International Workshop on Embedded Software

Procedia Computer Science

O. Deryugina, E. Nikulchev, I. Ryadchikov, S. Sechenev, E. Shmalko

Russian Technological University

International Journal of Software Engineering and Its Applications

University of Hull

Enhancing the software architecture analysis and design process with inferred macro-architectural requirements

2012 First IEEE International Workshop on the Twin Peaks of Requirements and Architecture (TwinPeaks)

Plamen Petrov; Ugo Buy; Robert L. Nord

University of Illinois at Chicago

Example 2–As part of our research and industrial experience we studied and then experimented with a realwork project from a US-based company. This example follows three versions of a system as it evolved over time.
Version #1 was developed following traditional, industryaccepted requirements engineering and architectural analysis and design methodology. Version 2 was based on an initial iteration of the multi-level context-aware software architecture analysis and design method that explicitly treated the definition of a macro-architecture as an early step in the architecture process. Version 3 was based on a later iteration that further refined the process to include the concept of backward-inferred architecture requirements.

Formal security analysis for software architecture design: An expressive framework to emerging architectural styles

Science of Computer Programming

Nacha Chondamrongkul, Jing Sun, Ian Warren

Mae Fah Luang University

These steps can be used to define security metrics and scenarios to analyse. We define the security metric and attack scenario based on security configuration in the architecture design. The security configuration represents characteristics that are involved in the security metric such as how important is the component and specific security control applied to the infrastructure that the software system is deployed on. With the formal definition of security characteristics in the ontology library, security characteristics can be detected in the ontology model representing the architecture design, according to the process shown in Fig. 6. The ontology classes and rules are processed by the ontology reasoner to classify the types of ontology individuals representing components and connectors according to the definitions of class. This class inference identifies the security characteristic representing metrics and scenarios

30th Annual International Computer Software and Applications Conference (COMPSAC'06)

National University of Defense Technology

JOURNAL OF SOFTWARE

Harbin Normal University

Jason McC. Smith and David Stotts

University of North Carolina

A case study in performance, modifiability and extensibility analysis of a telecommunication system software architecture

Proceedings. 10th IEEE International Symposium on Modeling, Analysis and Simulation of Computer and Telecommunications Systems

M. Castaldi; P. Inverardi; S. Afsharian

Universit`a dell’Aquila

Nacha Chondamrongkul, Jing Sun, Ian Warren

The University of Auckland

C. Security Attack Scenarios Analysis
With the ontology classes defined as previously described, the ontology reasoner can pinpoint which connector is vulnerable to data tampering and data disclosure. We use this information to generate attack scenarios by inserting attacker components into the design model. These attacker components represent software components that adversaries use. Then, Linear Temporal Logic (LTL) assertions are generated and inserted into the behavioural model in ADL. This allows the model checker to trace how the components interact with each other in response to the attacker’s request. Algorithm 1 shows how the attacker component and LTL assertions are generated. This algorithm loops through VulnConnSet that contains inferred individuals that are of type DataTamperingConnector or DataDisclosureConnector. The attacker component is added to the model, and its attack port is attached to the outbound role of the vulnerable connector. The outbound role is where the request is initiated to make system responses. All inbound roles that handle the requests are iterated in the second loop.
This iteration finds the port attached to an inbound role and its component to generate a LTL assertion.

INTERNATIONAL CONFERENCE ON COMMUNICATION, COMPUTER AND POWER

WM Abdelmoez, AH Jalali, K Shaik, T Menzies, HH Ammar

Arab Acamdey for Science and Technology

29th Annual International Computer Software and Applications Conference (COMPSAC'05)

S.S. Gokhale; S. Yacoub

Yuhong Cai, John Grundy, John Hosking and Xiaoling Dai

University of Auckland

ICSE '06: Proceedings of the 28th international conference on Software engineering

Muhammed Ali Babar, Barbara Kitchenham, Ian Gorton

National ICT Australia Ltd

2009 Third IEEE International Conference on Secure Software Integration and Reliability Improvement

Seattle University

ISAW '98: Proceedings of the third international workshop on Software architecture

Judith A. Stafford, Alexander L. Wolf

University of Colorado

Proceedings of the 21st International Conference on Computer Theory and Applications

Fadi HajSaid, Yousef Hassouneh, Hany Ammar

West Virginia University

For each component
· If the component is a database element
o Check data sensitivity
§ Assign severity based on data sensitivity (Critical =high sensitive, Major= medium sensitive,
Minor= low sensitive)
· Else // component is not a database element
o if the component has a direct connection with a database component
§ Assign database component severity to the non-database component
o Else// no direct connection with database
§ Assign severity based on reachability (Minor= high reachable, Low = low reachable)
· Check Access rights of the component
§ If (Access rights == admin)
· Increase severity level by one level
· Normalize the component’s severity

International Conference on Software Engineering Research and Practice

Hassan Reza, and Washington Helps

University of North Dakota

In a SOA environment, one of the design decisions for security must include identity that must be decoupled from the services. In a SOA, both users and services have identities. These identities need to be properly distinguished so that appropriate security controls can be applied [10]. Furthermore, the identities may need to be propagated throughout the SOA environment. Propagation is the scenario in which a user or service may need to access multiple layers of services. Therefore, identity services are required in the infrastructure to deal with identity mediation issues in a way that services can be easily interconnected without any concern about how to map and propagate user identity from one service to the next.

Another scenario which shows how security negatively impacts performance involves the requirement for message level security. For instance, the integrity of messages must be maintained to ensure that unauthorized changes are not made to them. That is, the data must be delivered as it was intended. In order to enforce this requirement, some schemes involve encoding redundant information such as checksums and encrypting the entire message. Again, this results in similar overhead as described in the previous example and thus leads to the performance degradation such as increased latency

International Conference on the Quality of Software Architectures

Heinz Z¨ullighoven, Carola Lilienthal, and Marcel Bennicke

University of Hamburg

Second International Conference on the Quantitative Evaluation of Systems (QEST'05)

Rajeshwari G and Santonu Sarkar

Software Engineering and Technology Labs, Infosys Technologies Ltd

29th Annual International Computer Software and Applications Conference (COMPSAC'05)

Tingting Han; Taolue Chen; Jian Lu

Nanjing University

Journal of Korea Society of Industrial Information Systems

Kang, Byeong-Do ; Lee, Roger Y.

Carnegie Mellon University

2014 International Conference on Data and Software Engineering (ICODSE)

InstitutTeknologi Bandung

Decision Science Letters

Mahnaz Amirpour, Ali Harounabadi, Seyyed Javad Mirabedini

Islamic Azad University

International Journal of System and Software Engineering

Shahkar Riyaz Tramboo, S. M. K. Quadri

University of Kashmir

Journal of Theoretical and Applied Information Technology

T.K.S. RATHISH BABU, DR.N.SANKARRAM

S.K.R. Engineering College

5.2. Software Architecture Evolution
Software evolvability is the software system’s capability for change to future events [35].This results in better economic value of the software. For long-term systems, evolvability is required explicitly during the whole software lifecycle to have a good productive lifetime of software systems.
The software lifecycle studies can be based on five sub-categories:
5.2.1. Quality Considerations during Design:
The approaches for the assessment of the software lifecycle can be based on conditions like quality attribute focused on the requirement, influencing factors and scenario.
5.2.2. Evaluation of Architectural Quality:
The approaches for the evaluation of the architectural quality can be experience-based, metric-based and scenario-based.
5.2.3. Economic Valuation:
These approaches enlarge the information on the architectural conclusions’ business consequences, and aid development teams in selecting among architectural options.
5.2.4. Architecture Knowledge Management:
These approaches enhance the architectural integrity by improving architecture documentation by the extraction of architectural knowledge from different information sources.
5.2.5. Models for Software Evolution:
These techniques function as modeling software artifacts providing traceability and visualization of the impact of software architecture artifacts’ evolution.

Advances in Intelligent Systems and Computing

Goa Institute of Management

Table 1 Maintainability scenarios
Scenario name Scenario description
Addition Addition of a new component to the architecture
Deletion Deletion of an existing component from the architecture
Edition Edition of an existing component. Two cases
– Change in ports
– No change in ports

Risk assessment and mitigation approach for architecture evaluation in component based software development

2016 3rd International Conference on Computing for Sustainable Global Development (INDIACom)

Maushumi Lahon; Uzzal Sharma

Maushumi Lahon; Uzzal Sharma

Supporting Reliability Modeling and Analysis for Component-Based Software Architecture: An XML-Based Approach

2013 13th International Conference on Quality Software

Shanghai Jiao Tong University

International Journal of Computer Applications Technology and Research

M Sadeghian, I Kordkooy, H Motameni

Komail Institute of Higher Education

Extending and adapting the architecture tradeoff analysis method for the evaluation of software reference architectures

Technische Universiteit Eindhoven

Samuil Angelov, Jos J. M. Trienekens, Paul Grefen

Fontys University of Applied Sciences

11th Asia-Pacific Software Engineering Conference

Muhammad Ali Babar, Ian Gorton

National ICT Australia Ltd. and University of New South Wales, Australia

International Workshop on Architectural Reasoning for Embedded Systems

Juan C. Dueñas, William L. de Oliveira, Juan A. de la Puente

Technical University of Madrid

Empirical Software Engineering

Mikael Lindvall, Roseanne Tesoriero Tvedt & Patricia Costa

Fraunhofer Center for Experimental Software Engineering, Maryland

2004 Australian Software Engineering Conference. Proceedings.

Muhammad Ali Babar, Liming Zhu, Ross Jeffery

National ICT Australia Ltd. and University of New South Wales, Australia

Journal of Software Maintenance and Evolution: Research and Practice

Nokia Research Center

Software Architecture Evaluation in Practice: Retrospective on More Than 50 Architecture Evaluations in Industry

2014 IEEE/IFIP Conference on Software Architecture

Fraunhofer IESE

Proceedings. Fourth Working IEEE/IFIP Conference on Software Architecture (WICSA 2004)

Liming Zhu, Muhammad Ali Babar, Ross Jeffery

National ICT Australia Ltd. and University of New South Wales, Australia

A periodic data structure change request from stakeholders arrives when data use case changes. The system has to be modifiable according to the data structure change request within certain scope under certain time and maintenance cost.

Elements General Scenarios
Source Stakeholders
Stimulus A periodic data structure
change request
Environment Normal condition
Artifact System
Response Modify
Response Measure Certain time and maintenance cost

Elements General Scenarios
Source Independent source
Stimulus A large number of data requests
Environment Normal condition
Artifact System
Response Transfer the data
Response Measure Within certain amount of time

Elements Refined General Scenarios
Source User interface
Stimulus A large number of requests on
data entity attribute
Environment Normal condition
Artifact System
Response Transfer the data
Response Measure Within certain amount of time

Ninth Asia-Pacific Software Engineering Conference, 2002.

Heeseok Choi; Keunhyuk Yeom

2010 3rd International Conference on Computer Science and Information Technology

Abdulaziz Alkussayer; William H. Allen

Florida Institute of Technology

The OWASP CLASP project has identified twenty-two specific threats (called vulnerabilities) [23]. These threats convey a simpler form of threat profiling for this case study. Hence, based on these identified threats and on the interaction steps in the use case, we have developed the corresponding security requirements for the target architecture to generate security scenarios as described in Section III-B. Next, we will walk through the framework to evaluate the security risks of the initial (non-secure) design of the architecture. Then, we propose improvements to the initial architecture by integrating security patterns during the architectural transformation stage. After that, the enhanced (secure) design is evaluated. Finally, the risk levels are compared and final results are discussed.
The first step of the framework is to determine the goal of the evaluation. In this case study, the goal is to evaluate the risk of the initial (non-secure) architecture design. The second step is to create the security scenarios. Hence, a total of twenty-two security scenarios have been created for this example. Following the scenario template explained earlier, each scenario is linked to a specific security requirement, potential threat, and security pattern(s) that may be used to remediate that threat.
The third step in the framework is to create the security scenario profile. In this case, the FST distilled from the security scenario profile contains 22 different scenarios. The scenarios within the FST are then categorized into security objectives

Procedia computer science

Goa Institute of Management

2006 IEEE International Multitopic Conference

Muhammad Usman, Naveed Ikram

Mohammad Ali Jinnah University

Beihang University

EASE '17: Proceedings of the 21st International Conference on Evaluation and Assessment in Software Engineering

Silvia Abrahão and Emilio Insfran

Universitat Politècnica de València

27th Annual NASA Goddard/IEEE Software Engineering Workshop, 2002. Proceedings.

R.T. Tvedt; M. Lindvall; P. Costa

Fraunhofer Center Maryland for Experimental Software Engineering and Washington College

Proceedings Eighth IEEE Symposium on Software Metrics

M. Lindvall; R. Tesoriero; P. Costa

Fraunhofer Center Maryland for Experimental Software Engineering and Washington College

Software & Systems Modeling

Ali Sedaghatbaf, Mohammad Abdollahi Azgomi

Trustworthy Computing Laboratory, School of Computer Engineering, Iran University of Science and Technology,

Eighth ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD 2007)

Chang-Ki Kim; Dan-Hyung Lee; In-Young Ko; Jongmoon Baik

Electronics Telecommunications Research Institute(ETRI)

On the Move to Meaningful Internet Systems: OTM 2009 Workshops

Capgemini sd&m, Carl-Wery-Straße 42, 81739 Munich, Germany

A framework for groupware-supported software architecture evaluation process in global software development

Journal of Software: Evolution and Process

IT University of Copenhagen

International Conference on the Quality of Software Architectures

Frank Salger, Marcel Bennicke, Gregor Engels & Claus Lewerentz

sd&m AG, Carl-Wery-Straße 42, 81739 München, Germany

2010 3rd International Conference on Computer Science and Information Technology

Abdulaziz Alkussayer; William H. Allen

Abdulaziz Alkussayer; William H. Allen

12th European Conference On Information Technology Evaluation (ECITE 2005)

André Vasconcelos, Pedro Sousa, José Tribolet

Technical University of Lisbon

ACM Transactions on Software Engineering and Methodology

Dalia Sobhy, Leandro Minku, Rami Bahsoon, Rick Kazman

Arab Academy of Science and Technology and Maritime Transport

Design-Time Evaluation
D1:Business goals & scenarios are obtained from stakeholders
D2:Particular decisions are selected for diversification and new DAO are formed
D3: The implication of benefit and cost of all decisions are elicitedD4:The DAO are evaluated using binomial real options theory
D5: The set of dao along with their evaluation are provided

Proactive Run-time Evaluation
R1:Monitoring data (actual quality & cost) of each dao
R2:Monitoring data (actual quality) of each dao and exponential smoothing benefit of each dao
R3:Forecast exponential benefit smoothing of each dao is provided
R4:A significant change (worse) triggered based on forecast exponential smoothing benefit
R5: New dao is recommended based on forecast benefit & actual costs overtime (i.e.cost-benefit trade-offs)

(figure 1)

Eighth ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing (SNPD 2007)

Jinhua Li; Zhenbo Guo; Yun Zhao; Zhenhua Zhang; Ruijuan Pang

College of Information Engineering, Qingdao University

SHARK '08: Proceedings of the 3rd international workshop on Sharing and reusing architectural knowledge

Aida Erfanian, Fereidoun Shams Aliee

Shahid Beheshti University

Journal of Systems and Software

Rick Kazman, Len Bass, Mark Klein

University of Hawaii and Carnegie Mellon University