Copyright Prof. Dr. Shuichiro Yamamoto 2013 1 Prof. Dr. Shuichiro Yamamoto Nagoya University.

Slides:



Advertisements
Similar presentations
Mapping Assurance to the Software Engineering Process Alfred H. Kromholz, Ph.D. The MITRE Corporation mitre.org Copyright © 2004.
Advertisements

ARCH-05 Application Prophecy UML 101 Peter Varhol Principal Product Manager.
Chapter 4 Quality Assurance in Context
ITIL: Service Transition
Software Testing and Quality Assurance
Developing safety critical systems
Software Requirements
Analysis Concepts and Principles
Writing Good Software Engineering Research Papers A Paper by Mary Shaw In Proceedings of the 25th International Conference on Software Engineering (ICSE),
SE 555 – Software Requirements & Specifications Introduction
Software Architecture Quality. Outline Importance of assessing software architecture Better predict the quality of the system to be built How to improve.
Chapter 10: Architectural Design
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 5 Slide 1 Requirements engineering l The process of establishing the services that the.
IV&V Facility Model-based Design Verification IVV Annual Workshop September, 2009 Tom Hempler.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 11 System Test Design
Software Architecture premaster course 1.  Israa Mosatafa Islam  Neveen Adel Mohamed  Omnia Ibrahim Ahmed  Dr Hany Ammar 2.
What Exactly are the Techniques of Software Verification and Validation A Storehouse of Vast Knowledge on Software Testing.
The Project AH Computing. Functional Requirements  What the product must do!  Examples attractive welcome screen all options available as clickable.
The BIM Project Execution Planning Procedure
Effective Methods for Software and Systems Integration
QUALITY MANAGEMENT SYSTEM ACCORDING TO ISO
Romaric GUILLERM Hamid DEMMOU LAAS-CNRS Nabil SADOU SUPELEC/IETR.
Chapter 10 Architectural Design
Introduction to Software Quality Assurance (SQA)
Chapter 6 Software Implementation Process Group
ISO 9001:2000 QUALITY MANAGEMENT SYSTEM REQUIREMENTS
An Introduction to Software Architecture
Business Analysis and Essential Competencies
CSC 480 Software Engineering Lecture 14 Oct 16, 2002.
T. Dawson, TASC 9/11/13 Use of a Technical Reference in NASA IV&V.
Instructor: Peter Clarke
Software Requirements Engineering CSE 305 Lecture-2.
A GENERIC PROCESS FOR REQUIREMENTS ENGINEERING Chapter 2 1 These slides are prepared by Enas Naffar to be used in Software requirements course - Philadelphia.
Certification and Accreditation CS Phase-1: Definition Atif Sultanuddin Raja Chawat Raja Chawat.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 10 Use Case Design.
10/16/2015Bahill1 Organizational Innovation and Deployment Causal Analysis and Resolution 5 Optimizing 4 Quantitatively Managed 3 Defined 2 Managed Continuous.
Software Design Deriving a solution which satisfies software requirements.
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.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
1 Quality Attributes of Requirements Documents Lecture # 25.
Over View of CENELC Standards for Signalling Applications
Business Analysis. Business Analysis Concepts Enterprise Analysis ► Identify business opportunities ► Understand the business strategy ► Identify Business.
Copyright ©2004 Virtusa Corporation | CONFIDENTIAL Requirement Engineering Virtusa Training Group 2004 Trainer: Ojitha Kumanayaka Duration : 1 hour.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
Requirements Analysis
Software Engineering, COMP201 Slide 1 Software Requirements BY M D ACHARYA Dept of Computer Science.
Software Engineering Lecture 10: System Engineering.
ISO 9001:2015 Subject: Quality Management System Clause 8 - Operation
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
Wrap up. Structures and views Quality attribute scenarios Achieving quality attributes via tactics Architectural pattern and styles.
 System Requirement Specification and System Planning.
ITIL: Service Transition
Articulating Your Practice C3 - Session #3
Chapter 5 – Requirements Engineering
Object-Oriented Software Engineering Using UML, Patterns, and Java,
SYSTEM ANALYSIS AND DESIGN
Requirements Analysis and Specification
Articulating Your Practice C3 - Session #3
By Dr. Abdulrahman H. Altalhi
CHAPTER 2 CREATING AN ARCHITECTURAL DESIGN.
Chapter 5 Designing the Architecture Shari L. Pfleeger Joanne M. Atlee
An Introduction to Software Architecture
Test Case Test case Describes an input Description and an expected output Description. Test case ID Section 1: Before execution Section 2: After execution.
Software Design Methodologies and Testing
Applying Use Cases (Chapters 25,26)
A Semantic Peer-to-Peer Overlay for Web Services Discovery
Software Reviews.
Information system analysis and design
Presentation transcript:

Copyright Prof. Dr. Shuichiro Yamamoto Prof. Dr. Shuichiro Yamamoto Nagoya University

Agenda Pitfalls of assurance case deployment Patterns of argument decomposition Early evaluations of pattern applications Future plan 2 Copyright Prof. Dr. Shuichiro Yamamoto 2013

Necessity of Decomposition Pattern Copyright Prof. Dr. Shuichiro Yamamoto 2013

Pitfalls Fundamental Challenges Confusion of Argument Structure & Control Structure Controlling the Represented Range Diversity of Decomposition Approaches Copyright Prof. Dr. Shuichiro Yamamoto

Claim decomposition What should the claim be and how should it be expressed? What should be written as strategies? How much should the argument be decomposed using the strategies? What should be written as context? What should be written as evidence? How far should the hierarchical structure be extended? How should the relationships between context and evidence be analyzed? Copyright Prof. Dr. Shuichiro Yamamoto

Assurance case ambiguity 6 Goal ? Strategy ? Evidence ? Context ? Width ? Depth? Relationship? Sentence ? Copyright Prof. Dr. Shuichiro Yamamoto 2013

Confusion of Argument Structure & Control Structure Mixing up of strategies and goals. Content that should be written as a claim being expressed in the form of an action or function statement rather than as a proposition. Misunderstanding of strategies as judgment branches. Decomposing into function execution sequences instead of arguments. Copyright Prof. Dr. Shuichiro Yamamoto

Controlling the Represented Range Copyright Prof. Dr. Shuichiro Yamamoto This does not extend to cover measures taken regarding maintenance of the train itself or the dangers associated with maintenance work.

9 Architecture Functional Attributes Infinite set Complete Monotonic concretion Copyright Prof. Dr. Shuichiro Yamamoto 2013

Formal Claim Decompositions 10 typesexplanation Architecture splitting a component into several sub-components functional splitting a component into several sub-functions Attributes splitting a property into several attributes Infinite set inductive partitioning from a base case (e.g., over time) complete capturing the full set of values for risks, requirements, etc. monotonic the new system only improves on the old system concretion making informal statements less vague Robin Bloomfield and Peter Bishop, Safety and Assurance Cases: Past, Present and Possible Future – an Adelard Perspective Copyright Prof. Dr. Shuichiro Yamamoto 2013

Architecture decomposition 11 System is dependable System architecture design Argument over System architecture Sub system A is dependable Sub system B is dependable Interactions between A and B are dependable Copyright Prof. Dr. Shuichiro Yamamoto 2013

Functional decomposition 12 Search system is dependable Argument over functions Keyword input function is dependable Data management function is dependable Keyword search function is dependable Result of search function is dependable Copyright Prof. Dr. Shuichiro Yamamoto 2013

Attribute decomposition 13 Search system is dependable Argument over quality attributes System is available System is reliable System is safe System is consistent System protects confidenti ality System is maintaina ble Copyright Prof. Dr. Shuichiro Yamamoto 2013

Infinite set decomposition 14 [K=1] The claim holds [K=N]If the claim holds for N, then it also holds for K=N+1 Claim holds for every N Argument over induction Claim holds for NIf Claim holds for N, then it also holds for N+1 Copyright Prof. Dr. Shuichiro Yamamoto 2013

Complete decomposition 15 System is dependable Argument over risk System risk includes input, process and output risks System is dependable for input risk System is dependable for process risk Copyright Prof. Dr. Shuichiro Yamamoto 2013

Monotonic decomposition 16 As-is System problem is resolved in the To- be system As-is System Argument over As-is System problem As-is System problem is identified Solution is proposed to resolve As-is System problem To-be system can be realized by implementing Solution for resolve As-is System problem Copyright Prof. Dr. Shuichiro Yamamoto 2013

Decomposition by concretion 17 Argument over concretion Definition of object Ambiguity of object is resolved Ambiguity of object is identified Concretion of object is provided Ambiguity of object is reduced by the concretion Copyright Prof. Dr. Shuichiro Yamamoto 2013

18

Design of experiment Examinee is an engineer who has more than 20 years experience in the embedded system development. 4 hour course of assurance case education was provided to the examinee. Copyright Prof. Dr. Shuichiro Yamamoto

The content of the course text Introduction to assurance case 10 pages Assurance case development method26 pages Assurance case exercises 15 pages Argument decomposition patterns 15 pages Copyright Prof. Dr. Shuichiro Yamamoto

Case study: LAN device monitoring Copyright Prof. Dr. Shuichiro Yamamoto Manager Network valid LAN device P3 P1P1 P2 Interactionsdescription P1 ① Initial packets to LAN devices ② Get names and information P2 ① Initial packets to abnormal LAN devices ② Interception P3 ① Set up sensors ② Validate sensor status ③ Update sensor software ④ Update interception table Monitor sensors 1000 LAN devices for each sensors 2000 sensors LA N Sensors invalid LAN device

Example of architecture decomposition Copyright Prof. Dr. Shuichiro Yamamoto

Number of nodes Copyright Prof. Dr. Shuichiro Yamamoto * ) ( number ) shows the number of hazards described in Context Architecture elementsContextClaimStrategyEvidence Sensor Power unit1(16) Main board1(17) HW case1(6)20713 HW interaction1(16) Software1(25) HW- SW Interaction1(11) Manager HW1(4)13410 SW1(18) HW- SW Interaction1(8)24816 Interaction between sensors and manager 1(23) Total 10(144 )

Man hours for work categories Copyright Prof. Dr. Shuichiro Yamamoto Specification Analysis 5 Pattern selection 30 Architecture decomposition 10 Risk analysis 62 D-Case description 110 Total 217

Relationship between claim and evidence Copyright Prof. Dr. Shuichiro Yamamoto claim evidence

Relationship between claim and strategy Copyright Prof. Dr. Shuichiro Yamamoto Claim Strategy

Relationship between evidence and context(risk) Copyright Prof. Dr. Shuichiro Yamamoto Risk Evidence Electric power device

Copyright Prof. Dr. Shuichiro Yamamoto

Effectiveness of argument patterns As the examinee said, the architecture decomposition pattern was useful to analyze risk, although the decision to choose it from argument decomposition patterns needed time to understand appropriateness between the target system and argument patterns. Many pitfalls discussed in section 2 were not observed in the course of the experiment. This also showed the effectiveness of the argument pattern. Without the knowledge of argument patterns, the examinee could not develop a large assurance case consists of 1098 nodes in 15 days. Copyright Prof. Dr. Shuichiro Yamamoto

Limitations of patterns Bloomfield's patterns do not, however, take decomposition by process or condition into considerations. For example, in argumentation by conditional judgment, a claim can be decomposed using a strategy such as that shown in Figure 2. Here, based on evidence, a condition is defined and dependability is verified both for the case where that condition is satisfied and the case where it is not. In other words, Goal G_4 claims that the condition is defined; Goal G_2 claims that an appropriate action is taken when the condition is satisfied; and Goal G_3 claims that an appropriate action is taken when it is not. Copyright Prof. Dr. Shuichiro Yamamoto

Correlation with System Development & Operation Materials The correlation between an assurance case’s context and evidence and those documents used in system development and operation has not clearly been defined, leading to a situation where multiple documents and multiple assurance cases have simply been handled at a combined level. Specific relationships at the element level were thus unclear, and as a result, valuable information from system development and operation documents could not be fully utilized. Copyright Prof. Dr. Shuichiro Yamamoto

Systems, Documentation & Assurance Cases Copyright Prof. Dr. Shuichiro Yamamoto

Creating Assurance Cases for Process Validation (1)Establish a claim based on the goal. (2) Argue each procedure necessary to achieve the goal according to the strategy. (3) Establish input information using contexts. (4) Establish the verification result for the process output as evidence. Copyright Prof. Dr. Shuichiro Yamamoto

Summary This paper introduced some of the pitfalls commonly encountered when developing assurance cases, as well as assurance case pattern methods for dealing with them. Evaluation of the pattern approach was also evaluated for assuring a LAN device management system. The experimental evaluation showed the effectiveness of the architecture pattern of argument decomposition. The examinee developed assurance case contains more than 1000 nodes systematically in less than 2 weeks, after learned assurance case introduction course and patterns in 4 hours. Methods for extending assurances case patterns based on process definition were also discussed. Copyright Prof. Dr. Shuichiro Yamamoto

Copyright Prof. Dr. Shuichiro Yamamoto