06-23-11 | 1 › Matthias Galster › Paris Avgeriou Handling Variability in Software Architecture – Problems and Implications.

Slides:



Advertisements
Similar presentations
P-20 Data Collaborative Grant University/College Work Group February 24, 2010.
Advertisements

Institutional coordination of climate change policy: Lessons from the South African experience B.A.S.I.C Project Beijing Michael Goldblatt 18 th February.
VARIABILITY IN SOFTWARE PRODUCT LINE ARCHITECTURES VARI-ARCH 2010 ECSA 4th European Conference on Software Architecture Copenhagen, August 23, 2010.
1.Quality-“a characteristic or attribute of something.” As an attribute of an item, quality refers to measurable characteristics— things we are able to.
Explicit vs Implicit. Explicit: Explicit: A function defined in terms of one variable. y= 3x + 2 is defined in terms of x only. Implicit: Implicit: A.
Domain Engineering Silvio Romero de Lemos Meira
May 14, May 14, 2015May 14, 2015May 14, 2015 Azusa, CA Sheldon X. Liang Ph. D. Software Engineering in CS at APU Azusa Pacific University, Azusa,
Requirements Engineering n Elicit requirements from customer  Information and control needs, product function and behavior, overall product performance,
Academic Vocabulary. List 1- Define the following words 1. Abbreviate 2. Brainstorm 3. Confirm 4. Describe 5. Exaggerate 6. Fact 7. Hypothesize 8. Identify.
| 1 › Department of Mathematics and Computing Science, Software Engineering and Architecture Group / Matthias Galster Describing Variability in.
Overview Lesson 10,11 - Software Quality Assurance
Requirement Engineering – A Roadmap
UNDERSTANDING BILINGUAL TRANSLATION OF SPECIALIZED TEXTS.
Karolina Muszyńska Based on
SWE Introduction to Software Engineering
The Software Product Life Cycle. Views of the Software Product Life Cycle  Management  Software engineering  Engineering design  Architectural design.
Software Architecture. Agenda " Why architect? " What is architecture? " What does an architect do? " What principles guide the process of architecting?
Autonomic Software Product Lines (ASPL) Nadeem Abbas, Jesper Andersson, Welf Löwe Linnaeus University, Sweden Monday, August 23, st International.
Domain-Specific Software Engineering Alex Adamec.
Address - #22, 1 st Floor, Station View Road, Kodambakkam, Chennai JTech Soft Solutions Website:
Proceso kintamybių modeliavimas Modelling process variabilities Donatas Čiukšys.
® IBM Software Group © 2006 IBM Corporation Writing Good Use Cases Module 4: Detailing a Use Case.
Introduction to Software Quality Assurance (SQA)
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
The Rational Unified Process
Requirements Analysis
Using Empirical Article Analyses to Assess Students Learning of Psychology Research Methods Sarah Richardson, Michael Schiel, Kaetlyn Graham, & Allen Keniston.
Software Processes Sumber dari : cc.ee.ntu.edu.tw/~farn/courses/SE/ch4.ppt.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Key steps in conducting survey research Decide if a survey is the best design to use Short time, economical, dispersed population, anonymity Report what.
Implementing Global Climate Change Research: Assessing the Challenge of Defining and Evaluating Decision Support Rebecca J. Romsdahl, PhD – Earth System.
Software Processes lecture 8. Topics covered Software process models Process iteration Process activities The Rational Unified Process Computer-aided.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes.
Part 1-Intro; Part 2- Req; Part 3- Design  Chapter 20 Why evaluate the usability of user interface designs?  Chapter 21 Deciding on what you need to.
Software Engineering Lecture # 17
Software Project Management Lecture # 10. Outline Quality Management (chapter 26)  What is quality?  Meaning of Quality in Various Context  Some quality.
Basic Concepts Software Architecture. What is Software Architecture? Definition: – A software architecture is the set of principal design decisions about.
CZECH STATISTICAL OFFICE 1 The Quality Metadata System In the Czech Statistical Office Work Session on Statistical Metadata (METIS)
10 Software Architecture CSCU 411 Software Engineering.
APRIL 16, 2013 A review of Chapters CHAPTER FOURTEEN The Role of Assessment VOCABULARY.
Integrated Risk Management Charles Yoe, PhD Institute for Water Resources 2009.
Component Based SW Development and Domain Engineering 1 Component Based Software Development and Domain Engineering.
Complaints Resolution Framework March What is a Complaints Resolution Framework? The International Standard on complaint handling ISO 1002 directs.
Department of Computer Science Borislava I. Simidchieva, Leon J. Osterweil Laboratory for Advanced Software Engineering Research University of Massachusetts,
Understanding Use: Predicting Action on a message Laura A. Dabbish Jianwei Wang CSCI6800 Spring 2005.
| 1 › Matthias Galster, University of Groningen, NL › Armin Eberlein, American University of Sharjah, UAE Facilitating Software Architecting by.
Software Product Line Material based on slides and chapter by Linda M. Northrop, SEI.
Part4 Methodology of Database Design Chapter 07- Overview of Conceptual Database Design Lu Wei College of Software and Microelectronics Northwestern Polytechnical.
Software Architectural Assumptions in Software Architecting Chen Yang a,b, Peng Liang a, Paris Avgeriou b a State Key Lab of Software Engineering, Wuhan.
ISO/IEC JTC1/SC7 WG42 Upcoming NWIP for IS Architecture Evaluation Invitation to IEEE for Early Informal Comments at WICSA 2011 Workshop on Standards.
1  [company] Inc. [year] Girl Scouts of the USA Secure Site Project Kickoff [date]
IT SOFTWARE PROJECT MANAGEMENT
These materials are prepared only for the students enrolled in the course Distributed Software Development (DSD) at the Department of Computer.
03/01/20161 A MODEL FOR VARIABILITY DESIGN RATIONALE IN SPL Ismênia Galvão, Pim van den Broek & Mehmet Akşit VARI-ARCH 2010, Copenhagen,
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
Title of your Study Your Name Date of your defense.
Basic Concepts and Definitions
X = Y. Direct variation X 1 X = Y 1 Y 2.
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
Identifying and Promoting Family Outcomes at the Local Level Illinois Part C.
DEVELOPING AND TESTING THE STANDARD OF PRACTICE AND EVALUATION OF CRITICAL-CARE-NURSING TOOL (SPECT) FOR GRADUATES OF CRITICAL CARE NURSE EDUCATION PROGRAMS.
Universal GO 4 IT Training. Welcome and Introductions.
Slide 3.1 © The McGraw-Hill Companies, 2002 SOFTWARE LIFE-CYCLE MODELS.
Software Quality Assurance
Chapter 4 – Requirements Engineering
CAPE Internal Assessment
دانشگاه شهیدرجایی تهران
تعهدات مشتری در کنوانسیون بیع بین المللی
Redesigning the Archival Services’ Website with User Perspectives
Presentation transcript:

| 1 › Matthias Galster › Paris Avgeriou Handling Variability in Software Architecture – Problems and Implications

| 2 Research question ›Variability Primarily addressed in SPLE, but key fact of many systems Characteristic of the architecture of SW systems What problems are experienced while performing variability-related tasks when architecting a SW-intensive system?

| 3 Method ›Exploratory study as part of a SA course at RuG | 3 Step 1: Pre-questionnaire Step 1: Pre-questionnaire Step 3: Post-questionnaire Step 3: Post-questionnaire Step 2: Performing variability-related tasks, Results recorded on worksheet Step 2: Performing variability-related tasks, Results recorded on worksheet Analyze results from tasks: Implicit problems Analyze results from tasks: Implicit problems Analyze feedback from participants: Explicit problems Analyze feedback from participants: Explicit problems Followed by Used to

| 4 Study design – tasks | 4  Create variability model  Suggest binding times Architect taken from  Determine common + varying features  Identify dependencies + types of dependencies  Derive variation points + variants

| 5 Problems #Problem Less experienced Explicitly stated 1Identification of common non-functional characteristics 2Identification of varying functional features X 3Identification of valid variation points XX 4Translation of variation points into variability model 5Translation of variants into variability model 6Identification / characterization of dependencies between variation points X 7Identification / characterization of dependencies between variants X 8 Identification / characterization of dependencies between variation points and variants X 9Modeling of common parts 10 Modeling depencendies between variation points, variation points and variants, and variants 11Identification of binding times for variation points and variants

| 6 Implications – methods and tools ›Problems highlight areas for new where methods / tools ›Management of dependencies high priority ›Transition to architecture models high priority

| 7 Implications – training of architects ›Problems hint to areas in which architects need training ›Variability modeling all architects ›Identifying and characterizing dependencies all architects ›Identification of varying features and variation points less experienced architects

| 8 Implications – architecture description ›Problems point to concerns of stakeholders ›Architecture descriptions should frame Concerns derived from problems

| 9 Thank you for your attention