Author Software Engineering Institute

Slides:



Advertisements
Similar presentations
Carnegie Mellon University Software Engineering Institute CERT® Knowledgebase Copyright © 1997 Carnegie Mellon University VU#14202 UNIX rlogin with stack.
Advertisements

© 2013 Carnegie Mellon University UFO: From Underapproximations to Overapproximations and Back! Arie Gurfinkel (SEI/CMU) with Aws Albarghouthi and Marsha.
UNCLASSIFIED © 2011 Carnegie Mellon University Building Malware Infection Trees Jose Andre Morales 1, Michael Main 2, Weilang Luo 3, Shouhuai Xu 2,3, Ravi.
SEP1 - 1 Introduction to Software Engineering Processes SWENET SEP1 Module Developed with support from the National Science Foundation.
LIFE CYCLE MODELS FORMAL TRANSFORMATION
© 2011 Carnegie Mellon University System of Systems V&V John B. Goodenough October 19, 2011.
Two-tiered, Multi-team Assessment of CSIRTs
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
© 2010 Carnegie Mellon University B OXES : A Symbolic Abstract Domain of Boxes Arie Gurfinkel and Sagar Chaki Software Engineering Institute Carnegie Mellon.
© 2013 Carnegie Mellon University Academy for Software Engineering Education and Training, 2013 Session Architect: Tony Cowling Session Chair: Nancy Mead.
© 2013 Carnegie Mellon University Measuring Assurance Case Confidence using Baconian Probabilities Charles B. Weinstock John B. Goodenough Ari Z. Klein.
© 2010 Carnegie Mellon University ® CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. V&V Principles Verification.
© Carnegie Mellon University The CERT Insider Threat Center.
© 2010 Carnegie Mellon University Acquisition Implications of SOA Adoption Software Engineering Institute Carnegie Mellon University Pittsburgh, PA
Job No/ 1 © British Crown Copyright 2008/MOD Developing a High Integrity Code Generator Using iUML/iCCG Sam Moody AWE plc, Aldermaston, Berkshire, United.
© 2015 Carnegie Mellon University Property Directed Polyhedral Abstraction Nikolaj Bjørner and Arie Gurfinkel VMCAI 2015.
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor Formal Methods in Software Engineering1.
Project Change Management
S5-1 © 2001 Carnegie Mellon University OCTAVE SM Process 5 Identify Key Components Software Engineering Institute Carnegie Mellon University Pittsburgh,
L4-1-S1 UML Overview © M.E. Fayad SJSU -- CmpE Software Architectures Dr. M.E. Fayad, Professor Computer Engineering Department, Room #283I.
CPN'021 Coloured Petri Nets in UML-Based SW Development – Designing Middleware for Pervasive Healthcare Jens Bæk Jørgensen Centre for Pervasive Computing.
1 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by.
© 2011 Carnegie Mellon University Should-Cost: A Use for Parametric Estimates Additional uses for estimation tools Presenters:Bob Ferguson (SEMA) Date:November.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
© 2011 Carnegie Mellon University QUELCE: Quantifying Uncertainty in Early Lifecycle Cost Estimation Presenters:Dave Zubrow PhD Bob Ferguson (SEMA) Date:November.
Modeling State-Dependent Objects Using Colored Petri Nets
© 2015 Carnegie Mellon University Software Engineering Institute Carnegie Mellon University Pittsburgh, PA A Cognitive Study of Incident Handling.
DoDAF DoD Architectural Framework across multiple levels (Zachman And MoDAF are similar) UPDM Unified Modeling Language (UML) Profile for DoDAF and ModAF.
Ipek Ozkaya, COCOMO Forum © 2012 Carnegie Mellon University Affordability and the Value of Architecting Ipek Ozkaya Research, Technology.
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
© 2010 Carnegie Mellon University Team Software Process.
This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.
Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Prescriptive Process Models copyright © 1996, 2001, 2005 R.S. Pressman & Associates, Inc.
Chapter 8 Architecture Analysis. 8 – Architecture Analysis 8.1 Analysis Techniques 8.2 Quantitative Analysis  Performance Views  Performance.
Conditions and Terms of Use
By: Md Rezaul Huda Reza 5Ps for SE Process Project Product People Problem.
Testing Workflow In the Unified Process and Agile/Scrum processes.
Ch.2 Part C: Message Sequence Charts, UML EECE **** Embedded System Design.
Documenting Software Architectures 1.Uses and Audiences for Architecture Documentation Architecture documentation serves as a means of education Architecture.
Performance evaluation of component-based software systems Seminar of Component Engineering course Rofideh hadighi 7 Jan 2010.
Software Engineering Emphasis for Engineering Computing Courses William Hankley Computing & Information Sciences Kansas State University.
1 Software Engineering: A Practitioner’s Approach, 7/e Chapter 2 Process: A Generic View Software Engineering: A Practitioner’s Approach, 7/e Chapter 2.
CrossCheckSimulation Results Conclusions References Model Instrumentation Modeling with CUTS Property Specification SPRUCE Challenge Problem Checking Model.
© 2015 Carnegie Mellon University Parametric Symbolic Reachability Software Engineering Institute Carnegie Mellon University Pittsburgh, PA Arie.
Checking Model Specifications with CrossCheck™ Jonathan Springer James Ezick U.S. Air Force AFRL-SBIR FA C-0049 Unclassified, DISTRIBUTION STATEMENT.
UML (Unified Modeling Language)
© 2015 Carnegie Mellon University COCOMO 2015 November 17, 2015 Distribution Statement A: Approved for Public Release; Distribution is Unlimited Causal.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
21/1/ Analysis - Model of real-world situation - What ? System Design - Overall architecture (sub-systems) Object Design - Refinement of Design.
Software Engineering I. Introduction to Software Engineering Software models Formal Specification using ASML (Abstract State Machines Language) Software.
Introduction to UML Hazleen Aris Software Eng. Dept., College of IT, UNITEN. …Unified Modeling Language.
CS223: Software Engineering Lecture 31: Acceptance Testing.
RTAS 2014 Bounding Memory Interference Delay in COTS-based Multi-Core Systems Hyoseung Kim Dionisio de Niz Bj ӧ rn Andersson Mark Klein Onur Mutlu Raj.
1 CERT BFF: From Start To PoC June 09, 2016 © 2016 Carnegie Mellon University This material has been approved for public release and unlimited distribution.
Data Science: What It Is and How It Can Help Your Company
Secure Software Workforce Development Panel Session
David Svoboda & Aaron Ballman
Models for Resources and Management
Author Software Engineering Institute
Michael Spiegel, Esq Timothy Shimeall, Ph.D.
Unified Modeling Language
Metrics-Focused Analysis of Network Flow Data
Software Design Methodology
QUELCE: Quantifying Uncertainty in Early Lifecycle Cost Estimation
Dynamic Cyber Training with Moodle
The Software Dilemma Ceci Albert.
Requirement Validation
Developing Useful Metrics
Presentation transcript:

Author Software Engineering Institute 4/26/2017 Model Testing: Testing Executable Requirements, Architecture, and Design Models Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213 Donald G. Firesmith Principal Engineer Engineer

Author Software Engineering Institute Copyright 2015 Carnegie Mellon University This material is based upon work funded and supported by the Department of Defense under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the United States Department of Defense. NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. This material has been approved for public release and unlimited distribution except as restricted below. This material may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at permission@sei.cmu.edu. DM-0002518 Author Software Engineering Institute 4/26/2017

Verification and Validation Methods Traditionally, V&V ≈ Analysis + Demonstration + “Inspection” + Test. There are actually more methods for verification and validation. Testing is similar to other dynamic V&V methods.

Author Program 4/26/2017 Model Testing Model testing tests executable requirements, architecture, and/or design models the same way traditional testing tests software (and systems). A requirements, architecture, or design model of a system is executable if: It describes the system in sufficient detail (e.g., components, functions, relations, processes, and status changes) that it can be executed as a simulation of that system. A means exists (e.g., modeling tool, simulation engine, execution engine, or human brain) to run the model. Model testing is NOT the same thing as Model-Based Testing (MBT)! Model testing uses testing to uncover defects in the models. MBT uses models to automate testing to uncover defects in the software / systems.

Model-Based Shift Left Testing Author Program 4/26/2017 Model-Based Shift Left Testing

Shift Left Testing Model-Based Shift Left Testing ← Author Program 4/26/2017 Shift Left Testing Major trend in software testing. Move testing earlier in development cycle (left on timeline) Four types of shift left testing: Traditional Shift Left Testing Move emphasis from system-level GUI testing via record/playback to API, component integration, and unit testing Incremental Shift Left Testing Few deliveries/releases with testing of multiple large increments Agile/DevOps Shift Left Testing Many deliveries/releases with testing of multiple small increments Model-Based Shift Left Testing ← Test executable requirements, architecture, and/or design models (move testing left to models)

Model Testing

Author Program 4/26/2017 Model Testing

Model Testing

Testable Models – Requirements Models Author Program 4/26/2017 Testable Models – Requirements Models Example executable models include: ConOps storyboards (simulations) Use case path sequence diagrams Decision trees, finites state machines, and Petri nets Executable requirements languages Requirements prototypes

Testable Models – Architecture/Design Models Author Program 4/26/2017 Testable Models – Architecture/Design Models Examples executable models include: Architecture Analysis and Design Language (AADL) models Unified Modeling Language (UML) models and System Modeling Language (SysML) models: Communication diagrams, interaction diagrams, sequence diagrams, state machine diagrams, activity diagrams, and timing diagrams, Object Constraint Language (OCL) or Action Semantic Language (ASL) Unified Profile for DODAF and MODAF (UPDM 2.0) Hardware Description Languages Architecture prototypes Design models for automatic code generation