SAS_08_AADL_Exec_Gluch MAC-T IVV-08-149 Model-Based Software Assurance with the SAE Architecture Analysis & Design Language (AADL) California Institute.

Slides:



Advertisements
Similar presentations
SEP1 - 1 Introduction to Software Engineering Processes SWENET SEP1 Module Developed with support from the National Science Foundation.
Advertisements

Software Process Models
Chapter 2 The Software Process
© 2004 by Carnegie Mellon University The Society of Automotive Engineers (SAE) Architecture Analysis & Design Language (AADL) Standard An International.
Copyright 2003 CMMI: Executive Briefing Presented by Kieran Doyle
Using UML, Patterns, and Java Object-Oriented Software Engineering Royce’s Methodology Chapter 16, Royce’ Methodology.
Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University 1 Pittsburgh, PA Architecture Analysis & Design Language (SAE.
Fundamentals of Information Systems, Second Edition
System Engineering Instructor: Dr. Jerry Gao. System Engineering Jerry Gao, Ph.D. Jan System Engineering Hierarchy - System Modeling - Information.
Introduction to Software Testing
IV&V Facility Model-based Design Verification IVV Annual Workshop September, 2009 Tom Hempler.
SAS_06_STOL_Tool_Cooper Automated Systems Test and Operations Language (STOL) Analysis Tool Jason G. Cooper July 20, 2006.
National Aeronautics and Space Administration SAS08_Classify_Defects_Nikora1 Software Reliability Techniques Applied to Constellation Allen P. Nikora,
Capability Maturity Model
Effective Methods for Software and Systems Integration
Chapter : Software Process
Process: A Generic View
MAC-T IVV SAS_08_AADL_Tech_Gluch Model-Based Software Assurance with the SAE Architecture Analysis & Design Language (AADL) California Institute.
Integrated Capability Maturity Model (CMMI)
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
Software Engineering II Lecture 1 Fakhar Lodhi. Software Engineering - IEEE 1.The application of a systematic, disciplined, quantifiable approach to the.
Chapter 2 The process Process, Methods, and Tools
CLEANROOM SOFTWARE ENGINEERING.
N By: Md Rezaul Huda Reza n
Engineering, Operations & Technology | Information TechnologyAPEX | 1 Copyright © 2009 Boeing. All rights reserved. Architecture Concept UG D- DOC UG D-
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
1 Chapter 2 The Process. 2 Process  What is it?  Who does it?  Why is it important?  What are the steps?  What is the work product?  How to ensure.
1PBI_SAS_08_Exec_ShullSeptember 2008MAC-T IVV Dr. Forrest Shull, FCMD Kurt Woodham, L-3 Communications OSMA SAS 08 Infusion of Perspective-Based.
1M.Sc.(I.T.), VNSGU, Surat. Structured Analysis Focuses on what system or application is required to do. It does not state how the system should be implement.
The Challenge of IT-Business Alignment
T. Dawson, TASC 9/11/13 Use of a Technical Reference in NASA IV&V.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
Soft Tech Development Inc. 1 Software Project Tracking A CMM Level 2 Key Process Area Soft Tech Development Inc.
Chapter 2 Process: A Generic View
Ævol : A Tool for Planning Architecture Evolution David Garlan & Bradley Schmerl Carnegie Mellon University.
Research Heaven, West Virginia A Compositional Approach for Validation of Formal Models Bojan Cukic, Dejan Desovski West Virginia University NASA OSMA.
10/16/2015Bahill1 Organizational Innovation and Deployment Causal Analysis and Resolution 5 Optimizing 4 Quantitatively Managed 3 Defined 2 Managed Continuous.
Software Engineering Principles Principles form the basis of methods, techniques, methodologies and tools Principles form the basis of methods, techniques,
CHECKPOINTS OF THE PROCESS Three sequences of project checkpoints are used to synchronize stakeholder expectations throughout the lifecycle: 1)Major milestones,
Lecture Topics covered CMMI- - Continuous model -Staged model PROCESS PATTERNS- -Generic Process pattern elements.
Using Architecture and Analysis Design Language (AADL) to Independently Validate and Verify (IV&V) System Performance Requirements and Design Performance.
Software Engineering - I
Software Engineering Prof. Ing. Ivo Vondrak, CSc. Dept. of Computer Science Technical University of Ostrava
Fifth Lecture Hour 9:30 – 10:20 am, September 9, 2001 Framework for a Software Management Process – Life Cycle Phases (Part II, Chapter 5 of Royce’ book)
Process Improvement. It is not necessary to change. Survival is not mandatory. »W. Edwards Deming Both change and stability are fundamental to process.
Development of Methodologies for Independent Verification and Validation of Neural Networks NAG OSMA-F001-UNCLASS Methods and Procedures.
CEN5011, Fall CEN5011 Software Engineering Dr. Yi Deng ECS359, (305)
Fundamentals of Information Systems, Second Edition 1 Systems Development.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
MODEL-BASED SOFTWARE ARCHITECTURES.  Models of software are used in an increasing number of projects to handle the complexity of application domains.
International Workshop Jan 21– 24, 2012 Jacksonville, Fl USA Model-based Systems Engineering (MBSE) Initiative Slides by Henson Graves Presented by Matthew.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
1 Chapter 2 A Generic View of Process Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
1 Overview of Maintenance CPRE 416-Software Evolution and Maintenance-Lecture 3.
Overview of RUP Lunch and Learn. Overview of RUP © 2008 Cardinal Solutions Group 2 Welcome  Introductions  What is your experience with RUP  What is.
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
Software Engineering Introduction.
Software Engineering INTRODUCTION TO SOFTWARE DEVELOPMENT.
Software Engineering (CSI 321) Software Process: A Generic View 1.
SwCDR (Peer) Review 1 UCB MAVEN Particles and Fields Flight Software Critical Design Review Peter R. Harvey.
RATIONAL UNIFIED PROCESS PROCESS FRAMEWORK OVERVIEW.
IV&V Facility 7/28/20041 IV&V in NASA Pre-Solicitation Conference/ Industry Day NASA IV&V FACILITY July 28, 2004.
Technical Presentation
Lecture 3 Prescriptive Process Models
CS4311 Spring 2011 Process Improvement Dr
Software Engineering (CSI 321)
IEEE Std 1074: Standard for Software Lifecycle
CMMI – Staged Representation
Introduction to Software Testing
HHS Child Welfare National IT Managers' Meeting
Presentation transcript:

SAS_08_AADL_Exec_Gluch MAC-T IVV Model-Based Software Assurance with the SAE Architecture Analysis & Design Language (AADL) California Institute of Technology Carnegie Mellon University Pittsburgh, PA September 2008 Executive Presentation Dave Gluch – SEI/ERAU Peter Feiler – SEI Kurt Woodham – L-3 Communications Kenny Meyer & Katie Weiss – JPL Ken Evensen - ERAU

2 MAC-T IVV SAS_08_AADL_Exec_Gluch Problem/Approach Problem - Current software development and assurance practices often do not adequately address broad system-level concerns until integration. Detailed evaluation of correct software operation in the system context is often relegated to front-end book-keeping (timing sheets) and ad-hoc analyses followed by extensive testing at integration. Approach - A sound systems engineering approach involves early evaluation of system architecture characteristics relevant to the operation of the software, such as Sensor/command data latency CPU throughput Synchronous/asynchronous task management Data-bus packet definitions and update rates Extend the use of the SAE Architectural Analysis and Design Language (AADL) and corresponding toolset capabilities as effective tools for rigorous model-based analysis of software architectures early in the development lifecycle and to transition these into NASA project V&V and IV&V software assurance practices. Strengthens assurance capabilities Defines a process framework that is adaptable to life-cycle phases (abstraction levels) Integrates established analysis techniques and tools

3 MAC-T IVV SAS_08_AADL_Exec_Gluch Relevance to NASA Early identification of significant system issues is key to reducing risk to development cost and schedule Typical analytical tools are not adaptable and require high degree of data specificity to provide meaningful insight Fidelity that is often unavailable until design phase activities Multiple specialized and independent tools required AADL inherently flexible – allows analysis at various levels of abstraction Early feasibility studies conducted with resource bounds or existing models of typical architecture components (buses, processors, etc...) Precision of analysis refined as design matures – reducing level of abstraction within targeted model elements and facilitating root cause analysis of identified anomalies Integration of multiple analysis approaches Benefit demonstrated in FY06 ISS case study Required round-trip command response latency violation. Uncovered in Stage Testing, but would have been easily identified in analysis of relatively abstract model

4 MAC-T IVV SAS_08_AADL_Exec_Gluch Project Overview Three-Phase extension of successful FY06 Facility Initiative: “Application of SAE Architecture Analysis & Design Language (AADL) to IV&V of NASA Flight Projects” Phase 1 Demonstrate AADL-driven Model-Based Engineering (MBE) in software assurance for NASA development — JPL Mission Data System (MDS) case study Generate a beta version of an AADL practice framework Phase 2 (current activities) Refine AADL practice framework using case study results as applicable Elaborate/extend case study — Continued development of MDS case study; evaluating additional options Develop and initiate execution of JPL transfer plan Phase 3 Continue JPL case studies aligned with transition of mature framework Develop and initiate execution of IV&V transfer plan Execute IV&V pilot study aligned with IV&V transfer plan

5 MAC-T IVV SAS_08_AADL_Exec_Gluch Case Study: MDS Reference Model Textual & Graphical Representations Excerpt from the Textual Specification: system implementation complete.MDS_system subcomponents Hardware_Being_Controlled: system controlled_systems.sensors_actuators; State_Knowledge: system state.knowledge; Mission_Planning_Execution: system planning.mission_and_execution; State_Estimation: system estimators.of_state; State_Control: system contollers.of_state; Hardware_Adapter: system adapters.hardware; Excerpt from the Textual Specification: system implementation complete.MDS_system subcomponents Hardware_Being_Controlled: system controlled_systems.sensors_actuators; State_Knowledge: system state.knowledge; Mission_Planning_Execution: system planning.mission_and_execution; State_Estimation: system estimators.of_state; State_Control: system contollers.of_state; Hardware_Adapter: system adapters.hardware; MDS Principles Closed loop Goal-Directed Explicit models Separation of Concerns Integral Fault Protection MDS Principles Closed loop Goal-Directed Explicit models Separation of Concerns Integral Fault Protection MDS Control System

6 MAC-T IVV SAS_08_AADL_Exec_Gluch Technical Accomplishments & Outcomes Milestones Completed initial case study investigations into the MDS control system (8/2007) Completed a report on the MDS year 1 case study efforts (12/2007) Developed a beta practice framework document for project V&V and IV&V (12/2007) Specific Case Study and Practice Framework Accomplishments Demonstrated that the AADL can effectively model MDS top level constructs and can address key MDS architectural themes (e.g. state-based closed loop control) Shown that MBE and AADL can provide a foundation for the analysis of critical MDS performance elements and system assurance concerns (e.g. latency, scheduling) Applied practices to MDS example adaptations Defined analysis views that address critical concerns Current activities Investigating goal planning and re-planning issues within MDS case study Conducting analyses of the MDS integral fault protection capabilities Developing exemplar applications of the Practice Framework

7 MAC-T IVV SAS_08_AADL_Exec_Gluch Tech Transfer Accomplishments JPL On-site 11/8/2007 — AADL overview presentation (approximately 25 participants) — Working session with MDS project to discuss case study and future analysis JPL On-site 6/18/2008 — Process/technology transfer approach discussions — Working session with MDS project to provide status on 11/8/2007 direction — Meet with Europa project as potential case study target SEI On-site 7/24/2008 — Discuss transfer plan approach and potential inhibitors of successful transition — Condensed overview of AADL language, tools, and analysis capabilities (excerpts from on-site SEI training material) Conference paper – currently under revision for near-term submission Tech Transfer Maturing practice framework focusing on detailing analysis practices – applied directly to case studies as demonstration of framework instantiation and execution Out-year goals focused on migration of practice framework into embedded development and assurance activities Configuring additional case studies to target typical analytical activities beneficial to both development verification/validation and independent assurance

8 MAC-T IVV SAS_08_AADL_Exec_Gluch Next Steps Phase 2 - Initiate IV&V Transition and Extend Development Verification Update analysis framework document Complete extended case studies and Case Study Report Develop a JPL transition plan Phase 3 – Mature Transition Conduct a pilot study in-line with a development project Support implementation of the JPL transition plan Develop an IV&V transition plan and support initial implementation