REG NASA-GB-A201-1989 SOFTWARE ASSURANCE GUIDEBOOK Includes Errata 7 30 2002.pdf

《REG NASA-GB-A201-1989 SOFTWARE ASSURANCE GUIDEBOOK Includes Errata 7 30 2002.pdf》由会员分享，可在线阅读，更多相关《REG NASA-GB-A201-1989 SOFTWARE ASSURANCE GUIDEBOOK Includes Errata 7 30 2002.pdf（26页珍藏版）》请在麦多课文档分享上搜索。

1、10f26 SOFTWARE ASSURANCE GUIDEBOOK, NASA-GB-A201 I. OVERVIEW A. Concepts and Definitions Software assurance is the planned and systematic set of activities that ensures that software processes and products conform to requirements, standards, and procedures. “Processes“ include all of the activities

2、involved in designing, developing, enhancing, and maintaining software; “products“ include the software, associated data, its documentation, and all supporting and reporting paperwork. The three mutually supportive activities involved in the software life cycle are management, engineering, and assur

3、ance. Software management is the set of activities involved in planning, controlling, and directing the software project. Software engineering is the set of activities that analyzes requirements, develops designs, writes code, and structures databases. Software assurance makes sure the management an

4、d engineering efforts put forth result in a product that meets all of its requirements. Software assurance is not an organization, but a set of related activities. It is unlikely that any NASA Center or NASA contractor has a single organizational entity that performs all of the functions defined in

5、this guidebook. The guidebook should be read as guidance to activities that are vital to the success of a software project. Some considerations for organizational structuring to enhance the probability of success are given in the section on establishing a software assurance activity. B. Goals of Sof

6、tware Assurance Software development, like any complex development activity, is a process full of risks. The risks are both technical and programmatic; that is, risks that the software will not perform as intended or will be too difficult to operate, modify, or maintain are technical risks, while ri

7、sks that the project will overrun cost or schedule are programmatic risks. The goal of software assurance is to reduce these risks. For example, coding standards are set to specify a minimum quality of code. If no standards are set, there exists some risk that the code will not come up to a minimum

8、usable standard, and that the code will require rework. If standards are set but there is no explicit process for assuring that all code meets the standards, then there is some risk that some coders will produce code that does not meet the standards. The assurance process involved is quality assuran

9、ce, and to have no quality aSsurance activity is to increase the risk that unacceptable code will be produced. Similarly, the lack of a nonconformance reporting and corrective action system increases the risk that problems in the software will be forgotten and not corrected, or that important proble

10、ms will not get priority attention. Other risk-related can be to upport all of the activities in this The point s that software assurance activities to reduce r sks, C. Purpose of this Guidebook http:/sate.gsknasa.gov!assure!agb.txl 7i30f2002 9: 19 AM Provided by IHSNot for ResaleNo reproduction or

11、networking permitted without license from IHS-,-,-20f26 The purpose of this Software Assurance Guidebook is to provide assistance, in the form of guidance, to NASA managers responsible for software acquisition and development and for establishing software assurance requirements. The style of the gui

12、debook is intended to be tutorial rather than directive. It is hoped that the reader will find the following sections an easily understood introduction to software assurance and a useful guide to formulating and addressing software project needs related to assurance. The remainder of this guidebook

13、will touch on each major activity within software assurance: software quality assurance, software quality engineering, verification and validation, nonconformance reporting and corrective action, safety, and security. Section II, Establishing a Project Software Assurance Activity, is designed to ass

14、ist managers in starting a new assurance activity or improving an existing assurance program. II. ESTABLISHING A PROJECT SOFTWARE ASSURANCE ACTIVITY A. Concepts and Definitions Every software development, enhancement, or maintenance project includes some assurance activities. The types, amount, and

15、formality of such activities are decisions of the project manager, based on an assessment of the project, its risks, and its development and operational environments. Even a simple, one person development job has assurance activities embedded in it, even if the programmer denies that tlqu;tlity assu

16、rance“ plays any part in what is to be done. Each programmer has some idea of how code should be written, and this idea functions as a coding standard for that programmer. Likewise, each of us has some idea of how documentation should be written, and this is a personal documentation standard. Each p

17、rogrammer reviews his/her products to make sure they meet their internal standards, and this is an assurance review or audit. Each programmer tests and inspects his/her own work, and these are verification and validation processes. The list could go on, but the idea should be clear. A project softwa

18、re assurance program involves the processes that each programmer goes through, but requires the planning and formal establishment of project, rather than personal, standards and processes. B. Tailoring Software Assurance to the Project Specific project characteristics and risks influence assurance n

19、eedst and assurance planning should be tailored to reflect this fact. Characteristics that should be considered include safety and mission criticality of the software, schedule and budget, size and complexity of the product to be produced, and size and organizational complexity of the development st

20、aff. The relat of critical to assurance 1 B as one -Nould expect: the more critical the software, the more and formal the software assurance effort must be. relat of schedule and is not int.ui tive, however; the the and schedule, the more http:/satc. gsk nasa.gov I assureiag b. txl 7/30/20029: 19 AM

21、 Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-30f26 critical it is to have a well planned and effective assurance effort. This does not mean that projects with more resources can afford to be lax, it just means that tight resources increase risks

22、that should be offset by a strong assurance program. The projected size of the software to be produced influences the level of assurance required. A large project requires explicit and detailed standards for all of the products in order to get at least a minimum standard of quality from the varied i

23、deas and experience of many different programmers. In addition, a large project requires significant efforts in testing and other verification activities, which have to be planned and the plans followed. In short, just due to the size of the activity, a significant and formal assurance program must

24、be established or risks of poor quality products must be accepted. On the other hand, a small project may require little formal assurance I and on a very small one, the assurance efforts may be left to the programmer involved if adequate, informal planning is done. Another factor that influences ass

25、urance planning is the projects organizational structure. A small, centralized development staff can easily participate in reviews and inspections, keep each other informed on the status of nonconformances, and help each other in meeting coding and documentation standards. A large or dispersed staff

26、 will have many different ideas of the best ways of doing things and many more difficulties in communicating them. In the latter case, a more formal assurance program and a larger assurance effort will be needed. A last but very important characteristic is the difference between the requirements of

27、a software providing organization and a software acquiring organization. A software provider actually develops the products by developing designs and writing code, etc., and therefore needs a full assurance program. An acquirer does not develop software and thus can limit its assurance activities to

28、 those that ensure that the provider is adhering to agreed to methods and standards and producing the agreed-to products. C. Creating the Software Assurance plan An effective assurance program requires planning and follow through; it cannot simply evolve along with the project. Adequate assurance pl

29、anning ensures that the assurance activities are focused on the quality requirements and risks associated with the specific project. The purpose of creating a software assurance plan is to document/specify the conduct of the activities that will comprise software assurance for a specific project. Ar

30、med with information about the project and the available software assurance resources, the project manager is ready to develop the plan. A useful guide for documenting assurance plans is provided in the assurance sections of the SMAP Management Plan Documentation Standard. In addition, the should be

31、 considered: plan software assurance in ion with management during the http:/satc,gsfc.nasa.gov!assure/agb.txt 7130/20029: 19 AM Provided by IHSNot for ResaleNo reproduction or networking permitted without license from IHS-,-,-40f26 Phase assurance activities properly. For example, design standards

32、must be produced well before design is to be done. Complete tool development or procurement before the tools are needed. Especially important is the development of test tools and test data sources. D. Project Structure Considerations In planning and establishing a software assurance program, one con

33、sideration is the software project organization and the location in that organization of the assurance activities. Experience has indicated, both in hardware and software, that some assurance functions are best done by organizational entities that are separate from the ones doing engineering activit

34、ies. Software Quality Assurance (SQA) is one activity that should be organizationally separated from the producing organizations. Administratively, the SQA organization should report no lower than the project manager; indeed, many large successful software producing organizations have the BQA organi

35、zation report administratively to top corporate management and interface with the project manager. The reason for this separation of function is that the BQA organization is managements arm that assures that standards are met and that procedures are followed. If SQA is not independent of the develop

36、ment activity, clear and impartial assessment will be difficult. In addition, many organizations have had success using an independent test team, or at least an independent test development team. The team is responsible for developing test plans, procedures, and test cases for formal acceptance test

37、s. Independence is required because these tests should be requirements driven and not influenced by the design structure and coding details. E. Completion Criteria Because of the nature of software, it is difficult to ascertain the status of a development or maintenance activity. It is important, th

38、erefore, to define criteria for the completion of specific development stages. For example, during the implementation phase, one has to do the lowest level detailed design of small program elements, code the elements, and unit test them. When a significant number of program elements are involved, it

39、 is difficult for anyone to ascertain the status of the units without specific completion criteria. For example, if there is a criterion that detailed design is complete only after the rework that finishes a design inspection, then the design can be said to be either complete or incomplete depending

40、 on the status of the rework. The setting of completion criteria is a management activity, but the audit of records is an SQA activity. The accuracy of the reported status can then be determined. This is important to both providers and acquirers of software, and this “status auditing! is an importan

41、t SQA function. “WELdLion of the Software Assurance Plan Once the project needs have been determined and the software assurance lS f the must be http:/ satc_ gsfc. nasa. gOY ! assure! agb. txl 7130/20029; 19 AM Provided by IHSNot for ResaleNo reproduction or networking permitted without license from

42、 IHS-,-,-50f26 implemented. Qualified, trained staff must be obtained, and special training must be made available where needed. If standards and procedures are not available for reuse on this project, they must be written. Staff must be trained in the standards and procedures, since merely writing

43、them down does not guarantee compliance. All of the above are management activities, but the assurance staff is a resource to help complete them. Staff devoted purely to assurance activities is usually small compared to the project staff. On the other hand, it is important to have people with specif

44、ic assurance responsibilities, even if they must be shared organizationally with other duties. Too often the truism that nquality is everybodys business II becomes “quality is nobodys businessll if specific responsibilities are not assigned. G. Sources of Help In addition to this guidebook, there ar

45、e other sources of help in planning and implementing a software assurance program. First, there is a NASA software planning requirement, stated in NMI 2410.10. In addition, there are Center requirements and guidance documents. All NASA Centers have assurance organizations that provide varying degree

46、s of support, assistance, and actual performance of software assurance activities. H. Summary Software assurance is an essential part of the development and maintenance of software. Software assurance forms part of the triad of activities, along with software management and software engineering that

47、, taken together, can provide a successful software development, enhancement, or maintenance activity. This guideboOk is intended to increase the general understanding in NASA of what comprises software assurance and how it is to be planned and implemented. III. SOFTWARE QUALITY ASSURANCE A. Concept

48、s and Definitions Software Quality Assurance (SQA) is defined as a planned and systematic approach to the evaluation of the quality of and adherence to software product standards, processes, and procedures. SQA includes the process of assuring that standards and procedures are established and are fo

49、llowed throughout the software acquisition life cycle. Compliance with agreed-upon standards and procedures is evaluated through process monitoring, product evaluation, and audits, Software development and control processes should include quality assurance approval points, where an SQA evaluation of the product may be done in relation to the applicable standards. B. Standards and Procedures standards and for software is critical, since these the framework from w