Manuscript Instructions/Template
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
System Safety Engineering: Back to the Future
System Safety Engineering: Back To The Future Nancy G. Leveson Aeronautics and Astronautics Massachusetts Institute of Technology c Copyright by the author June 2002. All rights reserved. Copying without fee is permitted provided that the copies are not made or distributed for direct commercial advantage and provided that credit to the source is given. Abstracting with credit is permitted. i We pretend that technology, our technology, is something of a life force, a will, and a thrust of its own, on which we can blame all, with which we can explain all, and in the end by means of which we can excuse ourselves. — T. Cuyler Young ManinNature DEDICATION: To all the great engineers who taught me system safety engineering, particularly Grady Lee who believed in me, and to C.O. Miller who started us all down this path. Also to Jens Rasmussen, whose pioneering work in Europe on applying systems thinking to engineering for safety, in parallel with the system safety movement in the United States, started a revolution. ACKNOWLEDGEMENT: The research that resulted in this book was partially supported by research grants from the NSF ITR program, the NASA Ames Design For Safety (Engineering for Complex Systems) program, the NASA Human-Centered Computing, and the NASA Langley System Archi- tecture Program (Dave Eckhart). program. Preface I began my adventure in system safety after completing graduate studies in computer science and joining the faculty of a computer science department. In the first week at my new job, I received a call from Marion Moon, a system safety engineer at what was then Ground Systems Division of Hughes Aircraft Company. -
Infrastructure (Resilience-Oriented) Modelling Language: I®ML
Infrastructure (Resilience-oriented) Modelling Language: I®ML A proposal for modelling infrastructures and their interconnections Andrés Silva, Roberto Filippini EUR 24727 EN - 2011 The mission of the JRC-IPSC is to provide research results and to support EU policy-makers in their effort towards global security and towards protection of European citizens from accidents, deliberate attacks, fraud and illegal actions against EU policies. European Commission Joint Research Centre Institute for the Protection and Security of the Citizen Contact information Address: TP 210, EC JRC Ispra, Ispra (Va) Italy E-mail: [email protected] Tel.: +39 0332 789936 Fax: http://ipsc.jrc.ec.europa.eu/ http://www.jrc.ec.europa.eu/ Legal Notice Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use which might be made of this publication. Europe Direct is a service to help you find answers to your questions about the European Union Freephone number (*): 00 800 6 7 8 9 10 11 (*) Certain mobile telephone operators do not allow access to 00 800 numbers or these calls may be billed. A great deal of additional information on the European Union is available on the Internet. It can be accessed through the Europa server http://europa.eu/ JRC 63302 EUR 24727 EN ISBN 978-92-79-19324-8 ISSN 1018-5593 doi:10.2788/54708 Luxembourg: Publications Office of the European Union © European Union, 2011 Reproduction is authorised provided the source is acknowledged Printed in Italy Infrastructure (Resilience-oriented) Modelling Language: I®ML A proposal for modelling infrastructures and their connections Andrés Silva1 Roberto Filippini Universidad Politécnica de Madrid JRC of the European Commission Abstract The modelling of critical infrastructures (CIs) is an important issue that needs to be properly addressed, for several reasons. -
IS2018 Book of Abstract
th Annual INCOSE 28 international symposium Washington, DC, USA July 7 - 12, 2018 Delivering Systems in the Age of Globalization Status as of May 15 th , 2018 Book of Abstract Table of contents keynotes ............................................................................................................................................................................... p. 7 keynotes#Keynote#2: The Big Shift: Innovation and Systems Engineering ................................................................ p. 7 Papers .................................................................................................................................................................................. p. 8 Papers#107: A Framework for Concept and its Testing on Patents ............................................................................ p. 8 Papers#75: A Framework for Testability Analysis from System Architecture Perspective .......................................... p. 9 Papers#128: A Framework for Understanding Systems Principles and Methods .......................................................p. 10 Papers#31: A fresh look at Systems Engineering - what is it, how should it work? .....................................................p. 11 Papers#35: A Hybrid Liver-Candidate Transportation System to Improve Accessibility and Extend Organ Life in L ..p. 12 Papers#55: A Novel “Resilience Viewpoint” to aid in Engineering Resilience in Systems of Systems (SoS) .............p. 13 Papers#97: A successful use of systems approaches in -
Model for Safety Case Modeling and Documentation
SAFE – an ITEA2 project D3.1.3 Contract number: ITEA2 – 10039 Safe Automotive soFtware architEcture (SAFE) ITEA Roadmap application domains: Major: Services, Systems & Software Creation Minor: Society ITEA Roadmap technology categories: Major: Systems Engineering & Software Engineering Minor 1: Engineering Process Support WP3 Deliverable D3.1.3: Proposal for extension of Meta- model for safety case modeling and documentation Due date of deliverable: 31/03/2013 Actual submission date: 28/03/2013 Start date of the project: 01/07/2011 Duration: 36 months Project coordinator name: Stefan Voget Organization name of lead contractor for this deliverable: fortiss Editor: Maged Khalil (fortiss GmbH) Contributors: Maged Khalil (fortiss GmbH), Eduard Metzker (Vector Informatik GmbH) Reviewers: Eduard Metzker (Vector Informatik GmbH) 2013 The SAFE Consortium 1 (50) SAFE – an ITEA2 project D3.1.3 Revision chart and history log Version Date Reason 0.1 2012-09-19 Initialization of document 0.2 2012-10-18 Input to Introduction Section 4 0.3 2012-11-07 Input to Overview on ISO Section 5 0.4 2012-11-16 Input to EAST-ADL Overview Section 7 0.5 2012-11-16 Input to Overview on ISO Section 5 0.6 2012-11-23 Input to Methodology Section 6 0.7 2012-11-29 Further Input to Methodology Section 6 0.8 2012-12-20 Editing and Input in various sections 0.9 2013-02-13 Input to SAFE Meta-model Contribution Section 8 0.10 2013-02-15 Introduction of Patterns Section 6.3 0.11 2013-03-08 Editing and Input in various sections 0.12 2013-03-24 First version ready for review 0.13 2013-03-26 Incorporation of first review comments 0.14 2013-03-27 Updated version reviewed. -
Systems Theoretic Process Analysis (STPA): a Bibliometric and Patents Analysis
ORIGINAL ARTICLE Systems Theoretic Process Analysis (STPA): a bibliometric and patents analysis Modelo teórico - Sistêmico de Análise de Processos (STPA): uma análise bibliométrica e de patentes Sarah Francisca De Souza Borges1 , Marco Antônio Fontoura De Albuquerque1 , Moacyr Machado Cardoso Junior1 , Mischel Carmen Neyra Belderrain1 , Luís Eduardo Loures Da Costa1 1Área de Gestão Tecnológica do Programa de Ciências e Tecnologias Espaciais – CTE/G, Instituto Tecnológico De Aeronáutica - ITA, São José dos Campos, SP, Brasil. E-mail: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] How to cite: Borges, S. F. S., Albuquerque, M. A. F., Cardoso Junior, M. M., Belderrain, M. C. N. & Costa, L. E. L. (2021). Systems Theoretic Process Analysis (STPA): a bibliometric and patents analysis. Gestão & Produção, 28(2), e5073. https://doi.org/10.1590/1806-9649-2020v28e5073 Abstract: The Systemic Theoretical Process Analysis (STPA) model is used for hazard analysis and accident prevention, based on systemic thinking and the identification of causal scenarios, created by Professor Nancy Leveson of the Institute of Technology of Massachusetts (MIT). The purpose of this article is to perform a bibliometric and patent analysis of the STPA model. Since bibliometry is an important tool in the analysis of scientific production, this method is used as a descriptive statistic, for the purposes of this study, the concepts of Goffman's Epidemic Theory were highlighted, under a mainly qualitative analysis, for a study of decline and ascent scientific method. For the bibliometric analysis, the main page of Professor Nancy Leveson was used in MIT's Web site, besides the Web of Science, Mendeley, ResearchGate, Village of Engineering and Scientific Electronic Library Online (SciELO). -
Manuscript Instructions/Template
Safety Analysis in Early Concept Development and Requirements Generation1 Nancy G. Leveson Massachusetts Institute of Technology 77 Massachusetts Ave, Cambridge MA 02139 617-258-0505 http://[email protected] [email protected] Copyright © 2018 by Nancy G. Leveson. Published and used by INCOSE with permission. Abstract. This paper shows how a new hazard analysis technique, STPA (System Theoretic Process Analysis), can be used to generate high-level safety requirements early in the concept development phase that can then assist in the design of the system architecture. These general, system-level requirements can be refined using STPA as decisions are made. The process goes hand-in-hand with design and the rest of the lifecycle as STPA can be used to provide information to assist in decision- making throughout the development and even operations phases. STPA also fits into a model-based engineering process as it works on a model of the system (which is also refined as design decisions are made) although that model is different than the architectural models usually proposed for model- based system engineering today. The process promotes traceability throughout the development process so decisions and designs can be changed with minimum requirements for redoing previous analyses. Finally, while this paper describes the approach with respect to safety, it can be applied to any emergent system property. Early Concept Exploration and Development Early concept development, shown at the top left of the V-model (Figure 1), is the first step in the usual system engineering process. While the label may differ in variants of the model, this stage includes such activities as stakeholder and user analysis (needs analysis), customer requirements generation, regulatory requirements review, feasibility studies, concept and tradespace exploration, and establishment of criteria for evaluation of the evolving and final design. -
Download from an Unknown Website Cannot Be Said to Be ‘Safe’ Just Because It Happens Not to Harbor a Virus
A direct path to dependable software The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters. Citation Jackson, Daniel. “A direct path to dependable software.” Commun. ACM 52.4 (2009): 78-88. As Published http://dx.doi.org/10.1145/1498765.1498787 Publisher Association for Computing Machinery Version Author's final manuscript Citable link http://hdl.handle.net/1721.1/51683 Terms of Use Attribution-Noncommercial-Share Alike 3.0 Unported Detailed Terms http://creativecommons.org/licenses/by-nc-sa/3.0/ A Direct Path To Dependable Software Daniel Jackson Computer Science and Artificial Intelligence Laboratory Massachusetts Institute of Technology What would it take to make software more dependable? Until now, most approaches have been indirect: some practices – processes, tools or techniques – are used that are believed to yield dependable software, and the argument for dependability rests on the extent to which the developers have adhered to them. This article argues instead that developers should produce direct evidence that the software satisfies its dependability claims. The potential advantages of this approach are greater credibility (since the ar- gument is not contingent on the effectiveness of the practices) and reduced cost (since development resources can be focused where they have the most impact). 1 Why We Need Better Evidence Is a system that never fails dependable? Not necessarily. A dependable system is one you can depend on – that is, in which you can place your reliance or trust. A rational person or organization only does this with evidence that the system’s benefits outweigh its risks. -
Balancing Agility and Discipline a Guide for the Perplexed
Balancing Agility and Discipline A Guide for the Perplexed Written by Barry Boehm & Richard Turner August 2003 Presented by Ben Underwood for EECS810 Fall 2015 Balancing Agility and Discipline, A Guide for the Perplexed: Boehm & Turner 1 Presentation Outline What to Expect • Meet the Authors • Discipline, Agility, and Perplexity • Contrasts and Home Grounds • A Day in the Life • Expanding the Home Grounds: Two Case Studies • Using Risk to Balance Agility and Discipline • Conclusions • Q & A Balancing Agility and Discipline, A Guide for the Perplexed: Boehm & Turner 2 Meet the Authors Barry Boehm • Born 1935 • Educated in Mathematics at Harvard and UCLA • Worked in Programming and Information Sciences in private industry and government • General Dynamics, Rand Corporation, TRW, and DARPA • Currently at the University of Southern California • Professor of Software Engineering • Founding Director of USC’s Center for Systems and Software Engineering Balancing Agility and Discipline, A Guide for the Perplexed: Boehm & Turner 3 Meet the Authors Richard Turner • Born 1954 • Educated in Mathematics, Computer Science, and Engineering Management • Worked in Computer Science, Technology, and Research in private industry and government • FAA, Systems Engineering Research Center, Software Engineering Institute, George Washington University, and more • One of the core authors of CMMI • Currently at Stevens Institute of Technology • Professor in the School of Systems and Enterprises Balancing Agility and Discipline, A Guide for the Perplexed: Boehm & -
Software Defect Reduction Top 10 List
SOFTWARE MANANGEMENT TWO Current software projects spend about Software 40 to 50 percent of their effort on avoid- able rework. Such rework consists of effort spent fixing software difficulties that could Defect Reduction have been discovered earlier and fixed less expensively or avoided altogether. By implication, then, some effort must con- sist of “unavoidable rework,” an obser- Top 10 List vation that has gained increasing credibility with the growing realization Barry Boehm, University of Southern California that better user-interactive systems result from emergent processes. In such Victor R. Basili, University of Maryland processes, the requirements emerge from prototyping and other multistakeholder- shared learning activities, a departure from traditional reductionist processes that stipulate requirements in advance, ecently, a National Science insight has been a major driver in focus- then reduce them to practice via design Foundation grant enabled us to ing industrial software practice on thor- and coding. Emergent processes indicate establish the Center for Empiri- ough requirements analysis and design, that changes to a system’s definition that R cally Based Software Engineer- on early verification and validation, and make it more cost-effective should not be ing. CeBASE seeks to transform on up-front prototyping and simulation discouraged by classifying them as avoid- software engineering as much as pos- to avoid costly downstream fixes.” able defects. sible from a fad-based practice to an engineering-based practice through deri- vation, organization, and dissemination Software’s complexity and of empirical data on software develop- accelerated development ment and evolution phenomenology. The phrase “as much as possible” reflects the schedules make avoiding defects fact that software development must remain a people-intensive and continu- difficult. -
Machine Learning Testing: Survey, Landscapes and Horizons
1 Machine Learning Testing: Survey, Landscapes and Horizons Jie M. Zhang*, Mark Harman, Lei Ma, Yang Liu Abstract—This paper provides a comprehensive survey of techniques for testing machine learning systems; Machine Learning Testing (ML testing) research. It covers 144 papers on testing properties (e.g., correctness, robustness, and fairness), testing components (e.g., the data, learning program, and framework), testing workflow (e.g., test generation and test evaluation), and application scenarios (e.g., autonomous driving, machine translation). The paper also analyses trends concerning datasets, research trends, and research focus, concluding with research challenges and promising research directions in ML testing. Index Terms—machine learning, software testing, deep neural network, F 1 INTRODUCTION The prevalent applications of machine learning arouse inherently follows a data-driven programming paradigm, natural concerns about trustworthiness. Safety-critical ap- where the decision logic is obtained via a training procedure plications such as self-driving systems [1], [2] and medical from training data under the machine learning algorithm’s treatments [3], increase the importance of behaviour relating architecture [8]. The model’s behaviour may evolve over to correctness, robustness, privacy, efficiency and fairness. time, in response to the frequent provision of new data [8]. Software testing refers to any activity that aims to detect While this is also true of traditional software systems, the the differences between existing and required behaviour [4]. core underlying behaviour of a traditional system does not With the recent rapid rise in interest and activity, testing typically change in response to new data, in the way that a has been demonstrated to be an effective way to expose machine learning system can. -
Software Engineering Introduction
Software Engineering Introduction - Himasri Lekkala - CSCE Graduate student Software Engineering Application of engineering methodologies to design, develop and maintain a software within budget, on schedule and with high quality. Why Software Engineering? 1 2 3 4 5 Helps in utilizing Delivers the Makes possible Increases Customer the budget product on to handle large reliability of a satisfaction effectively schedule projects software Little Bug, Big Bang • Took 10 years and $7 billion to produce Ariane 5, a giant rocket. • Exploded in less than a minute after its launch due to a small bug in the software. Software Development Life Cycle (SDLC) Software Requirement Specification 1. Requirement (SRS) analysis Software has to be updated as 6. 2. Maintenance Design Design Document Specification needed. (DDS) SDLC At first, software is released 5. 3. in limited segment for User Deployment Development Coding Acceptance Test (UAT) 4. Testing Tests for bugs & ensures if all the requirements in SRS are met UML Diagrams (Unified Modeling Language) Class diagram Object diagram SDLC Models • Waterfall Model • Incremental Model • Spiral Model • Agile Model • Chaos Model • Scrum Model • V-Model • Sawtooth Model Waterfall Model Requirement Software Requirement Specification (SRS) Analysis Design Design Document Specification (DDS) Implementation Build code in small programs called units & perform unit testing Testing Integration of units and software testing Deployment & Maintenance Release into market and check for patches 11 Waterfall Model - Application 1 2 3 4 Requirements are Ample resources Technology is Suitable for short very well with required understood and is term projects. documented, clear expertise are not dynamic. and fixed. available to support the product. -
Devops Comes to Database Developers and Dbas
DevOps Comes to Database Developers and DBAs — It’s About Time Written by Daniel Norwood, Director of Product Marketing, Dell Software, and Robert Reeves, CTO, Datical Introduction Now your organization can apply automation to your database development lifecycle, breaking down silos Application teams have tools for managing their between development and operations teams and bringing development lifecycle — from source code control and you into the DevOps fold. With the right tools, database automated testing to continuous integration and automated developers and DBAs can finally keep up with the increasing deployment. But as a database developer or DBA, you’ve pace of application releases while protecting precious lacked the proper tooling to help you keep pace with the rest business data. of your organization. This white paper will explore the importance of bringing agile You face increasing pressure to deliver database changes and DevOps to database development and the obstacles faster, while you’re also responsible for ensuring that organizations face along the way. It describes what to look databases are always available and applications run at peak for when selecting tools to bring the database into the world performance. The conventional wisdom dictates that you of DevOps. Finally, it demonstrates how the right tools can have to choose between speed and quality, that you can’t go bring automation to database development and the value of faster and reduce risk at the same time. DevOps to the entire organization. Wrong. Background: Agile and DevOps … and DevOps solves the release bottleneck … Agile development is at the core of DevOps and the faster pace of As development teams became more application releases.