Design Decision Rationale: Experiences and Steps Ahead Towards Systematic Use Davide FalessiMartin BeckerGiovanni Cantone SHARK '06, June 11, 2006, Torino,

Slides:



Advertisements
Similar presentations
Object-Oriented Application Frameworks Much of the cost and effort stems from the continuous re- discovery and re-invention of core concepts and components.
Advertisements

CONCEPTUAL WEB-BASED FRAMEWORK IN AN INTERACTIVE VIRTUAL ENVIRONMENT FOR DISTANCE LEARNING Amal Oraifige, Graham Oakes, Anthony Felton, David Heesom, Kevin.
Environment case Episode 3 - CAATS II Final Dissemination Event Brussels, 13 & 14 Oct 2009 Hellen Foster, Jarlath Molloy NATS, Imperial College London.
The design process IACT 403 IACT 931 CSCI 324 Human Computer Interface Lecturer:Gene Awyzio Room:3.117 Phone:
<<Date>><<SDLC Phase>>
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,
A Gift of Fire, 2edChapter 10: Professional Ethics and Responsibilities1 PowerPoint ® Slides to Accompany A Gift of Fire : Social, Legal, and Ethical Issues.
Object-Oriented Analysis and Design
The Process of Interaction Design. Overview What is Interaction Design? —Four basic activities —Three key characteristics Some practical issues —Who are.
SE 555 Software Requirements & Specification Requirements Management.
COST G9 - Work group 2 Cadastral science meeting Aalborg, Dk Modeling methodology for real estate transactions Radoš Šumrada Faculty.
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh 1 Dealing.
MSc Software Engineering Dissertation Finding a Research Problem and Additional Guidance Stewart Green.
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Requirement Engineering – A Roadmap
Amirkabir University of Technology, Computer Engineering Faculty, Intelligent Systems Laboratory,Requirements Engineering Course, Dr. Abdollahzadeh 1 Goal.
Architecture and Requirements
Software engineering on semantic web and cloud computing platform Xiaolong Cui Computer Science.
Software Product Line Architectures (SPLA) Nipun Shah
Software Architecture premaster course 1.  Israa Mosatafa Islam  Neveen Adel Mohamed  Omnia Ibrahim Ahmed  Dr Hany Ammar 2.
Developing Enterprise Architecture
Trooper Security, Inc. Security Solutions Center.
ISO Tor Stålhane IDI / NTNU. What is ISO ISO 9001 was developed for the production industry but has a rather general structure ISO describes.
WinCBAM: From Requirements Negotiation to Software Architecture Decisions Hoh In Rick Kazman David Olson Texas A&M SEI/CMU Texas A&M From Software Requirements.
Towards an activity-oriented and context-aware collaborative working environments Presented by: Ince T Wangsa Supervised by:
Developing a Socio-Economic Dataframe AIM: Construct, test and refine a framework for the collection and management of socio- economic fisheries data Make.
Developing.NET Web Service- based Architectures with Aspect-Oriented Component Engineering Santokh Singh 1, Professor John Grundy 1,2 and Professor John.
Requirements Elicitation. Who are the stakeholders in determining system requirements, and how does their viewpoint influence the process? How are non-technical.
MOHANA PRIYA TEST SCENARIO  Test scenario represent a powerful tool for test design and are a single event or a sequence of events that happen.
HCI in Software Process Material from Authors of Human Computer Interaction Alan Dix, et al.
1 Chapter 5 Software Engineering Practice. 2 What is “Practice”? Practice is a broad array of concepts, principles, methods, and tools that you must consider.
What is a Business Analyst? A Business Analyst is someone who works as a liaison among stakeholders in order to elicit, analyze, communicate and validate.
Lecture 7: Requirements Engineering
University of Palestine software engineering department Testing of Software Systems Testing throughout the software life cycle instructor: Tasneem.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Illustrations and Answers for TDT4252 exam, June
Assessing the influence on processes when evolving the software architecture By Larsson S, Wall A, Wallin P Parul Patel.
Designing software architectures to achieve quality attribute requirements F. Bachmann, L. Bass, M. Klein and C. Shelton IEE Proceedings Software Tzu-Chin.
Rational Unified Process Fundamentals Module 5: Implementing RUP.
Task-oriented approach to information handling support within web-based education Lora M. Aroyo 15 November 2001.
For Goal-Driven Business Process Modeling Saeed A.Behnam,  Daniel Amyot, Gunter Mussbacher SITE, University of.
Using SaaS and Cloud computing For “On Demand” E Learning Services Application to Navigation and Fishing Simulator Author Maha KHEMAJA, Nouha AMMARI, Fayssal.
Requirement Handling
A Lean Approach for Evolving Heterogeneous Wireless Sensor Networks An Assisted Living Case Study Thomas Patzke Software.
System Context and Domain Analysis Abbas Rasoolzadegan.
Personalized Interaction With Semantic Information Portals Eric Schwarzkopf DFKI
1-1 Software Development Objectives: Discuss the goals of software development Identify various aspects of software quality Examine two development life.
Software Architecture Evaluation Methodologies Presented By: Anthony Register.
An approach for Framework Construction and Instantiation Using Pattern Languages Rosana Teresinha Vaccare Braga Paulo Cesar Masiero ICMC-USP: Institute.
27/3/2008 1/16 A FRAMEWORK FOR REQUIREMENTS ENGINEERING PROCESS DEVELOPMENT (FRERE) Dr. Li Jiang School of Computer Science The.
CASE (Computer-Aided Software Engineering) Tools Software that is used to support software process activities. Provides software process support by:- –
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Software Engineering Introduction.
Prof. Hany H. Ammar, CSEE, WVU, and
Ontology-Based Interoperability Service for HL7 Interfaces Implementation Carolina González, Bernd Blobel and Diego López eHealth Competence Center, Regensurg.
Professional Ethics and Responsibilities
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Software Packaging for Reuse James Marshall (INNOVIM), Code 614.5, NASA GSFC The Software Packaging for Reuse document (version 1.0), developed and recently.
Rule-based Context-aware Adaptation Using a Goal-Oriented Ontology Hongyuan Wang (Jilin University, China) Rutvij Mehta (The University of Texas at Dallas,USA)
Banaras Hindu University. A Course on Software Reuse by Design Patterns and Frameworks.
Course Overview Stephen M. Thebaut, Ph.D. University of Florida Software Engineering.
1 Requirements Analysis Lecture # Recap of Requirements Elicitation - 1 Requirements elicitation deals with discovering requirements for a software.
Managing Enterprise Architecture
 System Requirement Specification and System Planning.
Page 1 An Overview of The COTS-Aware Requirements Engineering and Software Architecting Project (CARE/SA) The University of Texas at Dallas Department.
OICA „Certification of automated Vehicles“
The Extensible Tool-chain for Evaluation of Architectural Models
Conduction of a simulation considering cascading effects
COMPONENT – BASED SOFTWARE ENGINEERING MODULE 2 – SECOND SEMESTER MKHIZE, BSC HONS COMPUTER SCIENCES, DIP IT, ICDL.
                                                                                        Global sensitivity analysis and uncertainty quantification for.
Presentation transcript:

Design Decision Rationale: Experiences and Steps Ahead Towards Systematic Use Davide FalessiMartin BeckerGiovanni Cantone SHARK '06, June 11, 2006, Torino, Italy

2 Problem CBSE and PLA testify both the importance of reuse and the achieved standardization. Design Decision Rationale (DDR): + is promising, - is not yet largely utilized, - no standard methods exist. DDR NEEDS FURTHER IMPROVEMENTS Introduction DGA Motivators&Inhibitors Solution Conclusion

3 Outline New DDR documentation framework the Decision, Goal, and Alternatives (DGA). Motivators and inhibitors of using DDR. A solution: be systematic! Reuse only pays off when enacted in a systematic, pre-planned, and carefully focused way. DDR usage scenarios, enlightening who, what, when, and which items, allow a scenario-focused efficient DDR documentation (DDRD) and the persuasion of DDR maintainers and payees. Introduction DGA Motivators&Inhibitors Solution Conclusion

4 DGA Context Ambient Intelligence (AmI) is a vision of intelligent environments that react in a sensitive and adaptive way to the presence of humans and objects in order to provide various services to people. BelAmi (Bilateral German-Hungarian Research Collaboration on Ambient Intelligence Systems) project in the assisting living domain. Introduction DGA Motivators&Inhibitors Solution Conclusion

5 DGA Context There are AmI characteristics that demand for DDR usage, including: New combinations of required qualities, e.g., flexibility and efficiency, interoperability, and safety. Several stakeholders with specific knowledge and views. Architects and designers have to negotiate their objectives that interfere with the issues of others. Requirements do change substantially. Introduction DGA Motivators&Inhibitors Solution Conclusion

6 DGA Rationale Our decision was to capture DDR by documenting decisions that stakeholders were making in the AmI context by using the CBAM method. In fact, the SEI presented Cost Benefit Analysis Method (CBAM) as a rational decision-making process for software architectural decisions, which is able to give stakeholders help in the elicitation of costs and benefits. We designed the Decision, Goals and Alternative (DGA) technique that, as its name partially suggests (“decision”, “alternative”), is related to CBAM. Introduction DGA Motivators&Inhibitors Solution Conclusion

7 DGA Decision Drivers Design Decision Non-Functional RequirementFunctional Requirement Decision RelationshipBusiness Goal Is it complete? Introduction DGA Motivators&Inhibitors Solution Conclusion

8 DGA stages: 1.Understand what to document. Define project goals. 2.Enact the documentation. For each design decision, describe the level of importance that every pre-defined goal (see point 1 above) has for this decision; for each decision-related alternative, describe the level of fulfillment of every pre-defined goals. Our Experience Decision Goal and Alternatives DDR Framework Introduction DGA Motivators&Inhibitors Solution Conclusion

9 DGA Example of Usage: Stage 1 Introduction DGA Motivators&Inhibitors Solution Conclusion

10 2.a Goal importance 2.b Goal fulfillment Introduction DGA Motivators&Inhibitors Solution Conclusion DGA Example of Usage: Stage 2

11 DDR Motivators & Inhibitors DDR Communication Design quality Reusability Domain knowldg. Additional effort Unclear benefit Inconsistencies Personal int. Introduction DGA Motivators&Inhibitors Solution Conclusion

12 How to mitigate the impact of inhibitors and emphasize on the impact of motivators? We propose a new approach aimed to enact a systematic DDR use based on the concept of DDR Use Case (DDRUC). DDRUC enlightening who profits from what information in which amount, allow a scenario- focused efficient DDRD and the persuasion of DDR maintainers and payees. Introduction DGA Motivators&Inhibitors Solution Conclusion

13 The set of DDRUC is supposed to be partial and illustrative, however its description is complete. Do you agree? Our Solution DDR Use Case Description Introduction DGA Motivators&Inhibitors Solution Conclusion

14 Process for a Systematic DDR Use.

15 Our Solution Example of Scenario Focused DDRD Using a DDRD framework recently proposed in literature and the abovementioned DDRUC, we rationally deduced which information is required by which DDRUC. Introduction DGA Motivators&Inhibitors Solution Conclusion

16 Example of scenario focused DDRD the Chosen framework The framework, aimed to capture Architectural Rationale, recently proposed by Tyree and Akerman Introduction DGA Motivators&Inhibitors Solution Conclusion

17 60% of T&A DDR information is not used ! (percentage of empty box) By analyzing the contents of the traceability matrix, we can derive that the amount of effort needed for using DDR heavily depends on the specificities of the DDRUC. Example of scenario focused DDRD Results Introduction DGA Motivators&Inhibitors Solution Conclusion

18 Future Work Investigate the relationships between “Usefulness” and the “Which”, “When”, and “How” of design decision documentation, respectively. Develop a decision-making support tool. Figure out incompatibility issues and which design rationale information is already available, so that we do not need to document them again, when using a certain software architecture design method. Investigate the relationship between design rationale information and the “type”, “granularity” and “hierarchies” of a decision. Introduction DGA Motivators&Inhibitors Solution Conclusion

19 Conclusion We described: Decision, Goal, and Alternatives (DGA) DDR framework. Motivators and inhibitors of using DDR. An approach for systematic DDR employment based on the concept of DDR Use Case (DDRUC). Introduction DGA Motivators&Inhibitors Solution Conclusion

20 Main contact Davide Falessi, Ph.D. Student University of Rome “Tor Vergata”, Dept. of Computer Science, System and Industrial Engineering; Via del Politecnico 1, Roma Phone: Url: