DOCSLIB.ORG

Handbook of Software Quality Assurance, 4Th

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Handbook of Software Quality Assurance, 4Th Handbook of Software Quality Assurance Fourth Edition For a listing of recent related Artech House titles, turn to the back of this book. Handbook of Software Quality Assurance Fourth Edition G. Gordon Schulmeyer Editor a r techhouse. com Library of Congress Cataloging-in-Publication Data A catalog record for this book is available from the U.S. Library of Congress. British Library Cataloguing in Publication Data A catalogue record for this book is available from the British Library. ISBN-13: 978-1-59693-186-2 Cover design by Igor Valdman © 2008 ARTECH HOUSE, INC. 685 Canton Street Norwood, MA 02062 All rights reserved. Printed and bound in the United States of America. No part of this book may be reproduced or utilized in any form or by any means, electronic or mechanical, includ- ing photocopying, recording, or by any information storage and retrieval system, without permission in writing from the publisher. All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Artech House cannot attest to the accuracy of this informa- tion. Use of a term in this book should not be regarded as affecting the validity of any trade- mark or service mark. 10 9 8 7 6 5 4 3 2 1 For my grandchildren, Jimmy, Gabrielle, Chandler, Mallory, Neve, and Julian In memory of James H. Heil, prior contributor to former editions of this handbook The following copyrights, trademarks, and service marks appear in the book and are the property of their owners: Capability Maturity Model®, Capability Maturity Modeling®, CMM®, CMMI® are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University. CMM® Integration, TSP, PSP, IDEAL, SCAMPI, SCAMPI Lead Assessor, and SCAMPI Lead Appraiser are service marks of Carnegie Mellon University. CobiT is registered in the U.S. Patent and Trademark Office by Information Systems Audit and Control Association. Excel, MS, Word for Windows are trademarks of Microsoft Corporation. Gold Practice is a Trademark of the Data and Analysis Center for Software. IBM is a registered trademark of IBM Corporation. IEEE Std 730TM-2002 is a trademark of the IEEE Computer Society. IEEE Standard for Software Reviews, IEEE Std 1028-1997 reprinted with permission from IEEE Std. 1028-1997, IEEE Standard for Software Reviews, Copyright © 1997, by IEEE. Standard for Software Safety Plans, IEEE Std. 1228-1994 reprinted with permission from IEEE Std. 1228-1994 for Software Safety Plans, Copyright © 1994, by IEEE. The IEEE disclaims any responsibility or liability resulting from the placement and use in the described manner. ISACA is registered in the U.S. Patent and Trademark Office by Information Systems Audit and Control Association. ITIL is a Registered Trade Mark, and a Registered Community Trade Mark of the Office of Government Commerce, and is registered in the U.S. Patent and Trademark Office. IT Infrastructure Library is a Registered Trade Mark of the Office of Government Commerce. Microsoft, MS-WORD, and Windows are registered trademarks of Microsoft Corporation. Trusted Pipe is registered with the U.S. Patent and Trademark Office by Don O’Neill. The excerpts from: 1. “Comments on Software Quality” by W. S. Humphrey; 2. “The Team Software ProcessSM (TSPSM)” by W. Humphrey; 3. “Mapping TSPSM to CMMI®” by J. McHale and D. S. Wall; 4. “SCAMPISM Upgrade Team, Standard CMMI® Appraisal Method for Process Improvement (SCAMPISM) A, Version 1.2: Method Definition Document,” Handbook CMU/SEI-2006-HB-002; 5. “Applications of the Indicator Template for Measurement and Analysis,” Technical Note CMU/SEI- 2004-TN-024; 6. “CMMI® for Development (CMMI-DEV), Version 1.2,” Technical Report CMU/SEI-2006-TR- 008, Copyright 2006 Carnegie Mellon University; 7. “The Measurement and Analysis Process Area in CMMI®,” Copyright 2001 Carnegie Mellon University; 8. “Relationships Between CMMI® and Six Sigma,” Technical Note CMU/SEI-2005-TN-005, Copyright 2005 Carnegie Mellon University; 9. “Engineering Safety-related Requirements for Software-Intensive Systems,” Carnegie Mellon University; 10. “Safety-Critical Software: Status Report and Annotated Bibliography,” Technical Report CMU/SEI- 93-TR-5, Copyright 1993 Carnegie Mellon University; 11. “Software Inspections Tutorial” by D. O’Neill and A. L. Ingram as contained in the Software Engineer- ing Institute Technical Review 1988; from Carnegie Mellon University and Software Engineering Institute are 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 war- ranty of any kind with respect to freedom from patent, trademark, or copyright infringement. The SEI and CMU do not directly or indirectly endorse the Handbook of Software Quality Assurance, Fourth Edition. Contents Preface xvii CHAPTER 1 Organizing for Quality Management 1 1.1 The Quality Management Framework 1 1.1.1 Object (Entity) 2 1.1.2 Product 3 1.1.3 Process 3 1.1.4 Requirement 3 1.1.5 User 4 1.1.6 Evaluation 5 1.1.7 Measure and Measurement 5 1.1.8 Quality 6 1.2 Quality Program Concepts 8 1.2.1 Elements of a Quality Program 8 1.2.2 Considerations 15 1.3 Organizational Aspects of the Quality Program 17 1.4 Quality Program Organizational Relationships 17 1.4.1 Establish Requirements and Control Changes 18 1.4.2 Establish and Implement Methods 20 1.4.3 Evaluate Process and Product Quality 21 1.5 Mapping Quality Program Functions to Project Organizational Entities 22 1.5.1 Planning 23 1.5.2 Establish Requirements and Control Changes 24 1.5.3 Establish and Implement Methods 25 1.5.4 Evaluate Process and Product Quality 27 1.6 Example Organizational Implementations of a Quality Program 27 1.6.1 Project Engineering Process Group 28 1.6.2 Quality Program Structures in Large Projects 28 1.6.3 Quality Program Structures for Small Projects in Large Organizations 31 1.6.4 Quality Program Structures in Small Organizations with Small Projects 31 1.7 Summary 33 References 33 vii viii Contents CHAPTER 2 Software Quality Lessons Learned from the Quality Experts 35 2.1 Introduction 35 2.2 Kaoru Ishikawa 37 2.3 Joseph M. Juran 39 2.4 Yoji Akao 43 2.5 W. Edwards Deming 44 2.6 Genichi Taguchi 49 2.7 Shigeo Shingo 51 2.8 Philip Crosby 52 2.9 Watts S. Humphrey 56 2.10 Conclusion 60 References 60 CHAPTER 3 Commercial and Governmental Standards for Use in Software Quality Assurance 63 3.1 SQA in ISO Standards 63 3.1.1 ISO 9000:2005 and ISO 9001:2000 64 3.1.2 ISO/IEC 90003 64 3.1.3 ISO/IEC 2500n—ISO/IEC 2504n (SQuaRE) 65 3.1.4 ISO/IEC 14598 and ISO/IEC 15504 66 3.1.5 ISO/IEC 9126 67 3.1.6 The Special Role of ISO/IEC 12207 68 3.2 SQA in IEEE Standards 69 3.2.1 IEEE Std 730-2002 69 3.2.2 IEEE Std 829-1998 70 3.2.3 IEEE Std 1028-1997 70 3.2.4 The Special Role of IEEE/EIA 12207 71 3.3 SQA in COBIT® 72 3.4 SQA in ITIL® 74 3.4.1 ISO/IEC 20000 76 3.5 SQA and Other Standards 77 3.5.1 ANSI/EIA-748-A-1998 77 3.5.2 RTCA/DO-178B 79 3.6 Whatever Happened to U.S. Department of Defense Standards? 80 3.6.1 Influential Past Standards 80 3.6.2 SQA in Active DoD Standards 82 3.7 Reminders About Conformance and Certification 83 3.7.1 Conformance 83 3.7.2 Conformance to an Inactive Standard 83 3.7.3 Certification 83 3.8 Future Trends 84 3.8.1 Demand for Personal Credentials Will Increase 84 3.8.2 Systems Engineering and Software Engineering Standards Will Converge 85 References 85 Contents ix CHAPTER 4 Personnel Requirements to Make Software Quality Assurance Work 89 4.1 Introduction 89 4.2 Facing the Challenge 90 4.3 Organization Structure 92 4.4 Identifying Software Quality Assurance Personnel Needs 94 4.5 Characteristics of a Good SQA Engineer 97 4.6 Training the Hardware QA Engineer 99 4.7 Training the Software Engineer 99 4.8 Rotating Software Engineers 101 4.9 New College Graduates 102 4.10 SQA Employment Requisitions 103 4.11 What to Expect from Your SQA Engineering Staff 104 4.12 Developing Career Paths 106 4.13 Recommendations 106 References 107 Selected Bibliography 107 Appendix 4A Typical Software Quality–Related Job Descriptions 107 Software Quality Assurance Manager 107 Engineer Software Quality Assurance 108 Software Reliability Engineer 108 Software Configuration Management Specialist 108 Software Safety Engineer 109 Software Librarian Aide 109 Senior Software Librarian 109 Software Quality Assurance Engineering Assistant 110 Software Quality Engineering Assistant 110 Software Quality Assurance Aide 110 CHAPTER 5 Training for Quality Management 111 5.1 Introduction 111 5.2 Context for a Quality Evaluation Training Program 111 5.2.1 Quality Evaluation to Quality Assurance 111 5.2.2 Audience for Quality Evaluation Training 112 5.2.3 Organizational Training Program 112 5.2.4 Needed Skills and Knowledge 113 5.3 Two Examples 116 5.3.1 Evaluation of Adherence to Process (PPQA) 116 5.3.2 Evaluation of Product Quality 118 5.4 Summary 119 Reference 119 CHAPTER 6 The Pareto Principle Applied to Software Quality Assurance 121 6.1 Introduction 121 6.2 WWMCCS—Classic Example 1 123 x Contents 6.2.1 Manpower 123 6.2.2 Cost of Contracts 123 6.2.3 By Release 125 6.2.4 By Function 125 6.3 Federal Reserve Bank—Classic Example 2 127 6.4 Defect Identification 132 6.4.1 Rubey’s Defect Data 133 6.4.2 TRW Defect Data 135 6.4.3 Xerox Defect Data 138 6.5 Inspection 140 6.6 Pareto Charts Comparison 143 6.7 Conclusions 145 References 146 CHAPTER 7 Inspection as an Up-Front
Load more

Recommended publications
  • Optimization of Software Quality Using Management and Technical Review Techniques
    International Journal of Computer Trends and Technology (IJCTT) – volume 17 Number 6 Nov 2014 Optimization of Software Quality using Management and Technical Review Techniques Inibehe Emmanuel Akpannah Post Graduate Student (MSc. Information Technology), SRM University, Chennai, India Abstract compromising the security of the entire system. Optimizing the quality of software is a function of Improving the quality of our software process leads the degree of reviews made during the early life of to minimal rework, cost effectiveness and also a software development process. Reviews detect meeting up with schedules, which all lead to errors and potential errors early in the software improvement in capability measurement. Software development process. The errors detected during review is a chain process, it is dynamic and review the early life cycle of software are least expensive needs to be performed at every phase of the to correct. Efficient involvement in software development process until there is a transition to the inspections and technical reviews, help developers testing phase. improve their own skills, thereby mitigating the Software design and code review is a phase in the occurrence of errors in the later stage of software software development process in which development process. The ideas gathered on this programmers (authors of codes), quality assurance paper point that a properly implemented program of (QA) team, and peer reviewers get together to technical and management reviews drastically review design and code [9]. One way of optimizing reduces the time as well as the cost required for the quality of software is finding and correcting testing, debugging, and reworking, and dramatically errors at the early stage of a software development improves the quality of the resulting product.
    [Show full text]
  • Software Reviews
    Software Reviews Software Engineering II WS 2020/21 Enterprise Platform and Integration Concepts Image by Chris Isherwood from flickr: https://www.flickr.com/photos/isherwoodchris/6807654905/ (CC BY-SA 2.0) Review Meetings a software product is [examined by] project personnel, “ managers, users, customers, user representatives, or other interested parties for comment or approval —IEEE1028 ” Principles ■ Generate comments on software ■ Several sets of eyes check ■ Emphasis on people over tools Code Reviews — Software Engineering II 2 Software Reviews Motivation ■ Improve code ■ Discuss alternative solutions ■ Transfer knowledge ■ Find defects Code Reviews — Software Engineering II Image by Glen Lipka: http://commadot.com/wtf-per-minute/ 3 Involved Roles Manager ■ Assessment is an important task for manager ■ Possible lack of deep technical understanding ■ Assessment of product vs. assessment of person ■ Outsider in review process ■ Support with resources (time, staff, rooms, …) Developer ■ Should not justify but only explain their results ■ No boss should take part at review Code Reviews — Software Engineering II 4 Review Team Team lead ■ Responsible for quality of review & moderation ■ Technical, personal and administrative competence Reviewer ■ Study the material before first meeting ■ Don’t try to achieve personal targets! ■ Give positive and negative comments on review artifacts Recorder ■ Any reviewer, can rotate even in review meeting ■ Protocol as basis for final review document Code Reviews — Software Engineering II 5 Tasks of
    [Show full text]
  • Software Inspection, Maintenance, Visual Model, Inspection Tools
    Software Engineering 2014, 4(1): 19-24 DOI: 10.5923/j.se.20140401.03 Automated Visual Software Inspection System: Re-Making the Fagan Methodology Oladipo Onaolapo Francisca*, Ugoh Geraldine Ebere Computer Science Department, Nnamdi Azikiwe University, Awka, Nigeria Abstract Software inspection is aimed at detecting error early during the software development process and improving the skills of developers. There are several inspection models for both large and small scale software projects but this paper recognised that they are mostly designed in and for developing countries; in addition it was observed that software inspection in small student groups in Nigeria institutions are based on the traditional, meeting-oriented approach. This therefore necessitated a need to formalize an inspection model suitable for small software projects executed by students in a typical university computer science laboratory. Based on extensive research and analysis, a visual software inspection model is proposed in this paper. This model matured into an inspection tool developed using the techniques of Structured Systems Analysis and Design Methodology (SSADM) and scripting tools. An experimental evaluation of the tool using five study criteria showed that the inspection model was a well-defined disciplined process for the analysis and monitoring of a software development process for a systematic detection of any deviation from the pre-defined specifications of the software system. Keywords Software inspection, Maintenance, Visual model, Inspection tools adopted even when pair programming approaches are 1. Introduction adopted. A great deal of time is spent on correcting errors during the testing phase and most maintenance being done A software inspection methodology is considered efficient are corrective not adaptive.
    [Show full text]
  • A Community of Practice Around Peer Review for Long-Term Research Software Sustainability
    A Community of Practice Around Peer Review for Long-Term Research Software Sustainability Karthik Ram Noam Ross University of California, Berkeley, EcoHealth Alliance, The rOpenSci Project The rOpenSci Project Carl Boettiger Maelle€ Salmon University of California, Berkeley, The rOpenSci Project The rOpenSci Project Stefanie Butland Scott Chamberlain The rOpenSci Project University of California, Berkeley, The rOpenSci Project Abstract—Scientific open source projects are responsible for enabling many of the major advances in modern science including recent breakthroughs such as the Laser Interferometer Gravitational-Wave Observatory project recognized in the 2017 Nobel Prize for physics. However, much of this software ecosystem is developed ad hoc with no regard for sustainable software development practices. This problem is further compounded by the fact that researchers who develop software have little in the way of resources or academic recognition for their efforts. The rOpenSci Project, founded in 2011 with the explicit mission of developing software to support reproducible science, has in recent years undertaken an effort to improve the long tail of scientific software. In this paper, we describe our software peer-review system, which brings together the best of traditional academic review with new ideas from industry code review. & MODERN SCIENCE RELIES very heavily on open source software to acquire, manipulate, and ana- Digital Object Identifier 10.1109/MCSE.2018.2882753 lyze large volumes of data. One would be hard Date of publication 30 November 2018; date of current pressed to find areas of science today that do not rely on software to generate new discoveries. version 8 March 2019. March/April 2019 Published by the IEEE Computer Society 1521-9615 ß 2018 IEEE 59 Accelerating Scientific Discovery With Reusable Software Such software, often referred to as research soft- analyze their data.
    [Show full text]
  • Presentation of an Approach for Adapting Software Production Process Based ISO/IEC 12207 to ITIL Service
    ACSIJ Advances in Computer Science: an International Journal, Vol. 2, Issue 2, No. 3 , May 2013 www.ACSIJ.org Presentation of an approach for adapting software production process based ISO/IEC 12207 to ITIL Service Samira Haghighatfar1, Nasser Modiri 2 and Amir Houshang Tajfar3 1 Department of Computer Engineering, Payam Noor University Tehran, Iran [email protected] 2 Department of Computer Engineering, Zanjan Branch, Islamic Azad University Zanjan, Iran [email protected] 3 Department of Information Technology, Payame Noor University Tehran, Iran [email protected] manage and Provide the same language and syntax, IT Abstract Infrastructure Library (ITIL) are recommended. The standard ISO/IEC 12207 is software life cycle standard that This paper is organized as follows: Sect. 1, Sect.2 reviews not only provides a framework for executable effective method ISO/IEC 12207 standard and it’s processes. Section 3 for production and development software, but also can ensure reviews ITIL process. Section 4 presents a mapping that organizational goals are realized properly. In this paper, ITIL between ITIL processes and ISO/IEC 12207. Finally, we standard shall be used for better process control and management and providing a common language and syntax between will conclude the discussion. stakeholders. In addition, the process of mapping between these two standards shall be considered. Keywords: ISO/IEC 12207, Information Technology 2. ISO/IEC 12207 standard Infrastructure Library (ITIL). International Organization for Standardization (ISO) associated with IEC, with foundation the Joint Technical 1. Introduction Committee (JTC1), began to develop international standards for production and documentation of software Currently, the competition is a key factor for ensuring the products.
    [Show full text]
  • A Framework for Software Development Technical Reviews
    46 A Framework for Software Development Technical Reviews Lesley Pek Wee Kim a, Chris Sauer b, and Ross Jeffery C a School of Computer Science and Engineering bFujitsu Centre, Australian Graduate School of Management cSchool ofInfonnation Systems The University of New South Wales, Sydney 2052, Australia. Abstract Reviews are seen as an important aid to achieving high quality software. But, there is considerable variance in the literature. Three seminal review types - Fagan's inspection, Freedman and Weinburg's technical review, and Yourdon's structured walkthrough are briefly described. A framework is presented to identify core features and variants. The core components represent an implicit nonnative theory of reviews; the variants indicate possible variations to the theory. There are indications emerging that this theory may be flawed. This framework provides a foundation from which to empirically test the core components of the theory and its variants. Keyword Codes: 0.2, 0.2.0, 0.2.9 Keywords: software engineering, quality, inspection, structured walkthrough, technical review. 1. INTRODUCTION Software engineering is said to be 'a strategy for producing quality software' [5]. It is widely agreed that the traditional approach of defect testing just before product delivery is far too late [I], especially if we consider the popular 61: characterisation of quality which translates to approximately 3 to 4 defects per million lines of code [8]. The software review technique is seen as a method of removing errors throughout the software life cycle. The literature offers competing prescriptions. These prescriptions appear to be similar in a number of basic features, but detailed examination reveals many differences.
    [Show full text]
  • Peer Analsys in Software Development
    International Journal of Management and Applied Science, ISSN: 2394-7926 Volume-3, Issue-1, Special Issue-1, Jan.-2017 http://iraj.in PEER ANALSYS IN SOFTWARE DEVELOPMENT MIRIYALA MARKANDEYULU Asst.professor Computer Sceince and Engineering Department, Gvr&s College of Engineering & Technology Budampadu, Guntur. E-mail:[email protected] Abstract— Decision making, Analysis, defects detection and correct mistakes is important in software development process. Defects in the code decrease the quality of the software. Peer review is simple but has a huge impact on software quality. Also, peer review destroy defects early, easily, low-cost and efficiently. Code defects must be examined for better quality, high-performance, lowcost, re-use, modification and easy development of software. In this paper, the questions of what peer review is, why it is necessary for software development process and importance of peer review are told briefly by investigating in the literature. Keywords— Services, Quality of feedback, Peer review Software, Reviewing, Open source software. I. INTRODUCTION get together to review code. Finding and correcting bugs at this stage is generally inexpensive. In Software analysis is a process or a type of meeting addition, this process inclined to reduce the more types during which a software product (document, expensive process of handling, locating, and fixing system, application etc.) is examined by a team bugs during later stages of development or after members, managers, users, customers. A code review programs are delivered to users. reveals directly the location of a bug, while testing Pair programming is one of the Extreme requires a debugging step to locate the origin of a Programming (XP) and a kind of peer review in bug.
    [Show full text]
  • Cognitive-Support Code Review Tools
    Cognitive-Support Code Review Tools Improved Efficiency of Change-Based Code Review by Guiding and Assisting Reviewers Von der Fakult¨atf¨ur Elektrotechnik und Informatik der Gottfried Wilhelm Leibniz Universit¨atHannover zur Erlangung des akademischen Grades Doktor-Ingenieur (abgek¨urzt:Dr.-Ing.) genehmigte Dissertation von Herrn M. Eng. Tobias Baum geboren am 28.04.1985 in Hannover, Deutschland 2019 Betreuer: Prof. Dr. Kurt Schneider 1. Referent: Prof. Dr. Alberto Bacchelli 2. Referent: Prof. Dr. S¨oren Auer Vorsitzende der Pr¨ufungskommission: Prof. Dr. Eirini Ntoutsi Tag der Promotion: 25. Oktober 2019 c 2019 Tobias Baum. Some figures contain icons made by Freepik from www.flaticon.com Parts of this thesis share material with published articles (see pg. 273f) and are c the respective publishers. To my family . Abstract Code reviews, i.e., systematic manual checks of program source code by other developers, have been an integral part of the quality assurance canon in software engineering since their for- malization by Michael Fagan in the 1970s. Computer-aided tools supporting the review process have been known for decades and are now widely used in software development practice. De- spite this long history and widespread use, current tools hardly go beyond simple automation of routine tasks. The core objective of this thesis is to systematically develop options for improved tool support for code reviews and to evaluate them in the interplay of research and practice. The starting point of the considerations is a comprehensive analysis of the state of research and practice. Interview and survey data collected in this thesis show that review processes in practice are now largely change-based, i.e., based on checking the changes resulting from the iterative-incremental evolution of software.
    [Show full text]
  • Institutionen För Datavetenskap Department of Computer and Information Science
    Institutionen för datavetenskap Department of Computer and Information Science Master thesis Quality Assurance Techniques in OpenUP by Raham Sardar and Usman Fazal LIU-IDA/LITH-EX-A--11/005--SE 2011-02-04 Linköpings universitet Linköpings universitet SE-581 83 Linköping, Sweden 581 83 Linköping Master Thesis Quality Assurance Techniques in OpenUP by Raham Sardar and Usman Fazal LIU-IDA/LITH-EX-A--11/005--SE 2011-02-04 Supervisor & Examiner: Kristian Sandahl, IDA Abstract Abstract Agile methods change the software processes. Agile processes such as Scrum, Extreme Programming (XP), Open Unified Process (OpenUP) etc. have techniques that improve software quality. No doubt that the purpose of these techniques is to inject quality assurance into the project under development. This thesis presents quality assurance techniques in Open Unified Process (OpenUP) along with comparative study to extreme programming (XP) for agile software development. OpenUP is an agile and unified process that contains the minimal set of practices that help teams to be more effective in developing software. It assists to achieve quality by an iterative and incremental approach with artifacts, checklists, guidelines, disciplines and roles. On the other side XP emphasizes on values such as communication, feedback, respect, and courage. In addition, XP prescribes a collection of techniques, which aim to improve software quality. Both these processes have the same purpose, to develop software that meets the stakeholder’s needs and expectations, however they uses different approaches to achieve their goals. This thesis compares both processes in four different points of view, by comparing their quality techniques, focus in time, and cost of usage and social perspective.
    [Show full text]
  • Software-Testing Strategies
    WEEK 8 SOFTWARE-TESTING STRATEGIES Achmad Benny Mutiara [email protected] 8.1 STATIC-TESTING STRATEGIES ▪ Static testing is the systematic examination of a program structure for the purpose of showing that certain properties are true regardless of the execution path the program may take. – Consequently, some static analyses can be used to demonstrate the absence of some faults from a program. ▪ Static testing represents actual behavior with a model based upon the program’s semantic features and structure. – Human comparison often consists of people exercising little discipline in comparing their code against notions of intent that are only loosely and imprecisely defined. But human comparisons may also be quite structured, rigorous, and effective as is the case of inspections and walkthroughs, which are carefully defined and administered processes orchestrating groups of people to compare code and designs to careful specifications of intent. 1 ▪ Static testing strategies include: – Formal technical reviews – Walkthroughs – Code inspections – Compliance with design and coding standards 2 8.1.1 Formal Technical Reviews ▪ A review can be defined as: – A meeting at which the software element is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. ▪ What is a software review? A software review can be defined as a filter for the software-engineering process. ▪ The purpose of any review is – to discover errors in the analysis, design, and coding, testing and implementation phases of the software development cycle. – to see whether procedures are applied uniformly and in a manageable manner. 3 Objectives for Reviews ▪ Review objectives are used: – To ensure that the software elements conform to their specifications.
    [Show full text]
  • ESRS Guidelines for Software Safety Reviews
    IAEA Services Series No. 6 ESRS guidelines for software safety reviews Reference document for the organization and conduct of Engineering Safety Review Services (ESRS) on software important to safety in nuclear power plants INTERNATIONAL ATOMIC ENERGY AGENCY July 2000 The originating Section of this publication in the IAEA was: Engineering Safety Section International Atomic Energy Agency Wagramer Strasse 5 P.O. Box 100 A-1400 Vienna, Austria ESRS GUIDELINES FOR SOFTWARE SAFETY REVIEWS: REFERENCE DOCUMENT FOR THE ORGANIZATION AND CONDUCT OF ENGINEERING SAFETY REVIEW SERVICES (ESRS) ON SOFTWARE IMPORTANT TO SAFETY IN NUCLEAR POWER PLANTS IAEA, VIENNA, 2000 IAEA-SVS-06 © IAEA, 2000 Printed by the IAEA in Austria July 2000 FOREWORD The IAEA provides safety review services to assist Member States in the application of safety standards and, in particular, to evaluate and facilitate improvements in nuclear power plant safety performance. Complementary to the Operational Safety Review Team (OSART) and the International Regulatory Review Team (IRRT) services are the Engineering Safety Review Services (ESRS), which include reviews of siting, external events and structural safety, design safety, fire safety, ageing management and software safety. Software is of increasing importance to safety in nuclear power plants as the use of computer based equipment and systems, controlled by software, is increasing in new and older plants. Computer based devices are used in both safety related applications (such as process control and monitoring) and safety critical applications (such as reactor protection). Their dependability can only be ensured if a systematic, fully documented and reviewable engineering process is used. The ESRS on software safety are designed to assist a nuclear power plant or a regulatory body of a Member State in the review of documentation relating to the development, application and safety assessment of software embedded in computer based systems important to safety in nuclear power plants.
    [Show full text]
  • Chapter 1. Who Cares: Why Does Software Matter for Dod?
    Chapter 1. Who Cares: Why Does Software Matter for DoD? The future battlespace is constructed of not only ships, tanks, missiles, and satellites, but also algorithms, networks, and sensor grids. Like no other time in history, future wars will be fought on civilian and military infrastructures of satellite systems, electric power grids, communications networks, and transportation systems, and within human networks. Both of these battlefields— electronic and human—are susceptible to manipulation by adversary algorithms. — Cortney Weinbaum and Lt Gen John N.T. “Jack” Shanahan, “Intelligence in a Data-Driven Age,” (Joint Force Quarterly 90, 2018), 5 This chapter provides a high-level vision of why software is critical for national security and the types of software we will have to build in the future. We also provide a description of different types of software, where they are used, and why a one-size-fits-all approach will not work. 1.1 Where Are We Coming From, Where Are We Going? While software development has always been a challenge for the Department of Defense (DoD), today these challenges greatly affect our ability to deploy and maintain mission-critical systems to meet current and future threats. In the past, software simply served as an enabler of hardware systems and weapons platforms. Today, software defines our mission-critical capabilities and our ability to sense, share, integrate, coordinate, and act. Software is everywhere and is in almost everything that the Department operates and uses. Software drives our weapon systems; command, control, and communications systems; intelligence systems; logistics; and infrastructure, and it drives much of the backroom enterprise processes that make the Department function.
    [Show full text]