Balancing Practices: Inspections, Testing, and Others JAXA scenario (formal method) Masa Katahira Japanese Space Agency.

Slides:



Advertisements
Similar presentations
Verification and Validation
Advertisements

Lecture # 2 : Process Models
Software system modeling
Software Testing and Quality Assurance
Copyright © 2006 Software Quality Research Laboratory DANSE Software Quality Assurance Tom Swain Software Quality Research Laboratory University of Tennessee.
ECE Synthesis & Verification1 ECE 667 Spring 2011 Synthesis and Verification of Digital Systems Verification Introduction.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
Chapter 17 Code Review, Test Data, and Code Comparison.
Overview of Software Requirements
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
1 Software Testing and Quality Assurance Lecture 1 Software Verification & Validation.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation.
Software Testing Prasad G.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 11 System Test Design
Verification and Validation
1CMSC 345, Version 4/04 Verification and Validation Reference: Software Engineering, Ian Sommerville, 6th edition, Chapter 19.
Chapter 24 - Quality Management Lecture 1 1Chapter 24 Quality management.
Test Design Techniques
CASE Tools And Their Effect On Software Quality Peter Geddis – pxg07u.
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 27 Slide 1 Quality Management 1.
Software Testing Verification and validation planning Software inspections Software Inspection vs. Testing Automated static analysis Cleanroom software.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
System/Software Testing
S/W Project Management
Verification and Validation Yonsei University 2 nd Semester, 2014 Sanghyun Park.
Software Quality Assurance Lecture #8 By: Faraz Ahmed.
University of Palestine software engineering department Testing of Software Systems Fundamentals of testing instructor: Tasneem Darwish.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Verification and Validation.
CMSC 345 Fall 2000 Unit Testing. The testing process.
Software Testing.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 6 Slide 1 Requirements Engineering Processes l Processes used to discover, analyse and.
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
This chapter is extracted from Sommerville’s slides. Text book chapter
B. Fernández, D. Darvas, E. Blanco Formal methods appliedto PLC code verification Automation seminar CERN – IFAC (CEA) 02/06/2014.
Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 1: Software and Software Engineering.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 22 Slide 1 Software Verification, Validation and Testing.
1 Introduction to Software Engineering Lecture 1.
Today’s Agenda  HW #1  Finish Introduction  Input Space Partitioning Software Testing and Maintenance 1.
This chapter is extracted from Sommerville’s slides. Textbook chapter
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 10 Slide 1 Chapter 13 Finalizing Design Specifications.
Software Development Problem Analysis and Specification Design Implementation (Coding) Testing, Execution and Debugging Maintenance.
Software Engineering1  Verification: The software should conform to its specification  Validation: The software should do what the user really requires.
Winter 2011SEG Chapter 11 Chapter 1 (Part 1) Review from previous courses Subject 1: The Software Development Process.
Software Quality Assurance and Testing Fazal Rehman Shamil.
Requirements Analysis
Chapter 13 Finalizing Design Specifications
HNDIT23082 Lecture 09:Software Testing. Validations and Verification Validation and verification ( V & V ) is the name given to the checking and analysis.
Introduction to Hardware Verification ECE 598 SV Prof. Shobha Vasudevan.
Winter 2007SEG2101 Chapter 121 Chapter 12 Verification and Validation.
1 Software Testing and Quality Assurance Lecture 17 - Test Analysis & Design Models (Chapter 4, A Practical Guide to Testing Object-Oriented Software)
Testing Overview Software Reliability Techniques Testing Concepts CEN 4010 Class 24 – 11/17.
Software Test Plan Why do you need a test plan? –Provides a road map –Provides a feasibility check of: Resources/Cost Schedule Goal What is a test plan?
Verification vs. Validation Verification: "Are we building the product right?" The software should conform to its specification.The software should conform.
Cs498dm Software Testing Darko Marinov January 24, 2012.
IWFST 2005 Formal Specification and Verification of a Communication Protocol Ho Jung Bang Sung Deok Cha.
©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 19Slide 1 Verification and Validation l Assuring that a software system meets a user's.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini XVII. Verification and Validation.
CSC 480 Software Engineering
Verification and Validation
Input Space Partition Testing CS 4501 / 6501 Software Testing
Verification and Validation
Verification and Validation
Introduction to Software Testing
Lecture 09:Software Testing
Verification and Validation Unit Testing
Static Testing Static testing refers to testing that takes place without Execution - examining and reviewing it. Dynamic Testing Dynamic testing is what.
Software system modeling
Software Reviews.
Testing, Inspection, Walkthrough
Presentation transcript:

Balancing Practices: Inspections, Testing, and Others JAXA scenario (formal method) Masa Katahira Japanese Space Agency

Strategy to select methods Methods Compliment –Inspection/Review –Testing –Formal Method Theorem Proving Auto Model Checking Inspections/Reviews –Hard to cover all aspects Testing –Not complete, too late in some case Formal Method –TP: Complex for practical use –MC: State explosion possible We realize that –the correct use of particular methods, –the combination of several methods are very important. But how? –Quality Goals –Budget Limitation –System Characteristics –Data availability, Development Phase

Selection and Scalability of Methodologies (sample) Completeness/Consistency Selection (Depth) Light Full set Phases Modeling/Model Checking Inspection/Review (Check List) Simulation Interface Validation Design Coverage & Timing Verification Coverage Auto Test Case Generation & Robustness Evaluation Test Case & Test Test Result Review Compliance/Traceability Risk Analysis (Robustness) Process & Quality Static analysis (Problem Reports) In line Process Monitor (SMIP) Manual Check (Tools Support) Auto Equivalency Check Hazard Analysis/SFMEA REA Assessment Attributes (Sample)

Still we don’t know how to decide methods’ selection!

Fig.1 Each methods’ effectiveness among all significant issues Fig.2 Each methods’ effectiveness among all Editorial Errors Fig.3 Each methods’ effectiveness among all Significant issues and Editorial errors Consideration For projects A,B,C, there is not enough time to perform model checking. Review with check list instead. For Project D, a checklist is useful for the data correctness and consistency of data handling system. For Project E, the effective of model checking is confirmed due to having enough time. Review also shows important role in erroneous description in the specification For design phase such as C,E, model checking and a checklist help finding errors which can not be found by review. For projects A,B,C, there is not enough time, and the review with check list shows efficiency. For Project D, Review as well as review with checklist shows the efficiency for data handling system. For such as Project E case, when enough time is assigned, the model checking shows good results.

Lessons Learned Summary in JAXA case study MethodAdvantageDisadvantage Formal Model/ Model Checking ● It is useful to find the problem concerning the complicated state/mode transition and processing timing issues which is hard to be found by manual. ● Erroneous description in the spec. at modeling which is more effective than normal review. ● A certain mount of time are necessary to modeling and model checking. ● Need to know modeling and model checking knowledge. ● Low cost effectiveness for software which does not have complicated logic such as data handing, or transformation Review with Checklist (Inspection) ● High cost effectiveness even if there is very short time to access it. ● Erroneous descriptions are covered by check items in the list. ● It does not depend on the skill of evaluators than model methods. ● There are limited based on the items in the checklist. ● It is hard to check the detailed behaviors in the complex system and to cover the possible combination.

Boundary of Formal Method Application Available man-month Safety Critical System Characteristics Complexity Important Border

JAXA formal method activity

Needs and remaining issues of formal method [Problem Statement] Need to assure the high reliability of spacecraft Facing to the difficulty to prove the goodness only by test and inspection because of system complexity and safety requirements such “must not work” Large number of defects are introduced mostly at the Requirement Phase or the Early Design Phase. Unintended or Unexpected system/software behavior is difficult to be found at the inspection/review by manual. [Challenge] Knowledge base inspection/review is still very important, but model checking gives a chance to detect important findings which are easy to miss by the reviewer. Modeling task itself gives a chance to think enough deeply what the specification really says as if the reviewers build the software by themselves. [Remaining Issues] Quality of Model and model checking task –Large amount of time is spent to correct the erroneous model Abstraction and partitioning techniques –To avoid state explosion, and missing the scenarios Better Productivity –Hard to find real problems from thousands of auto checking results Personnel skill

Modeling and model checking in JAXA Requirement Model (SpecTRM *1, Uppaal) Design Model (SpecTRM, Uppaal) Req. Spec. ICD Hazard Report Design Spec. ICD Hazard Report Modeling Natural Language Input Tools Uppaal Flow Diagram Tool Flow Diagram Tool Model Checking (Static Analysis) Completeness Consistency Reachability Completeness Consistency Reachability Equivalency SMV, SPIN Executable Code Simulation (Dynamic Analysis) Robustness Behavior Analysis Findings Test CaseProposal Operation Model Procedure Ope. Scenario Consistency Task Model Tool *1:SpecTRM: Specification Tools and Requirements Methodology Direct Modeling

Productivity improvement Modeling Task Cost

Real issues from the results of the modeling and model checking Identified issues in the specification

Modeling –Can organize information and execute the modeling in the brain –Identify lots of basic problems in the specification (ambiguous descriptions, inconsistency of the contents, unclear data definition) as to make the accurate model of the specification in the formal language Automated Consistency analysis –Effective to identify the inconsistency in the requirement specification –Identify the inconsistency among the procedures in case that multiple tasks executions are allowed simultaneously in the design level. Automated Completeness analysis –Check whether the nodes after the transition at the branch in the flowchart meet the number of the transition conditions and its contents, and whether all error handling and exceptional procedure are covered in the design level. Formal Validation of the functional behavior using SPIN –Effective to validate whether the procedures are executed without stagnation and those behavior meet the requirements for the procedure flow in the detailed design –Effective to verify whether hazard control function/failure recovery functions are working without unintended stop in the real time Lessons Learned from industry use of modeling and model checking

Questions? (Formal Method) A)What is the role of formal method (Theorem Proving, Model checking etc.) in many quality practices? B)When is a Formal Method necessary or efficient? C)What is a Formal Method useful for? Specific Aspects? D)What are most important research issues to deploy the method into real projects? Industry Needs? E)What empirical data gathered at the industry will be useful to future research? F)What is an expected benefit from use of formal method?

Backup Slide

Findings from each methods (Spacecraft’s Projects) Significant: Signification Issues to be modified such as incorrect or missing functions/logic/data Editorial: Editorial Errors in the specification No Issue: Non real problem (misunderstanding/modeling mistake) Type of system Findings type and number from each methods ReviewFormal Modeling and Model Checking Review with Checklist SignificantEditorialNo IssueSum System A (Controller) /Req System B (Controller) /Req System C (Controller)/Design System D (DataHandling), Design System E (Controller)/Design SignificantEditorialNo IssueSumSignificantEditorialNo IssueSum

SpecTRM (Model) Based Robustness Test Environment (SpecRobusT) Outline: By using specification models, the important test cases are generated for full software simulation during development contractor ’ s test phase automatically and comparing results. Especially, all inputs are verified in the model to generate the test cases. Auto tests are performed at 10,000 – 100,000 cases / sec. Results of Project application: # of Test Case : 550,870,000,000 Benefits: –Verification at very early phase –Introduction to automated test environment –Introduce “ Test Before Development ” paradigm into development process Implementation Procedure