《BS-7165-1991.pdf》由会员分享,可在线阅读,更多相关《BS-7165-1991.pdf(32页珍藏版)》请在三一文库上搜索。
1、BRITISH STANDARD BS 7165:1991 Recommendations for Achievement of quality in software Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 10:23:30 GMT+00:00 2006, Uncontrolled Copy, (c) BSI BS 7165:1991 This British Standard, having been prepared under the direction
2、of the Information Systems Technology Standards policy Committee, was published under the authority of the Board of BSI and comes into effect on 28 February 1991 BSI 01-1999 The following BSI references relate to the work on this standard: Committee reference IST/15 Draft for comment 86/64000 DC ISB
3、N 0 580 18843 4 Committees responsible for this British Standard The preparation of this British Standard was entrusted by the information Systems Technology Standards Policy Committee (IST/-) to Technical Committee IST/15, upon which the following bodies were represented: British Computer Society B
4、usiness Equipment and Information Technology Association Computing Services Association Department of Trade and Industry Electronic Engineering Association HM Treasury (Central Computer and Telecommunications Agency) Institute of Scientific and Technical Communicators Institution of Electrical Engin
5、eers Ministry of Defence National Computing Centre Ltd. User Standards Forum for Information Technology (Institute of Data Processing Management) Amendments issued since publication Amd. No.DateComments Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 10:23:30 GM
6、T+00:00 2006, Uncontrolled Copy, (c) BSI BS 7165:1991 BSI 01-1999i Contents Page Committees responsibleInside front cover Forewordiii 1 Scope 1 2 Definitions 1 3 Pre-development activities 2 3.1 The customers specification of requirements 2 3.2 The suppliers response 2 3.3 The procurement specificat
7、ion2 3.4 Software life cycle management planning 2 3.5 Planning for software quality 3 4 Suppliers codes of practice 3 4.1 General 3 4.2Project management 3 4.3 Design techniques and methods 3 4.4 Programming techniques and methods 3 4.5 Software development facilities 3 4.6 Documentation 4 4.7Confi
8、guration management 4 4.8 Design review 4 4.9 Tests and trials 5 4.10 Transfer to customer 5 4.11 Post-design services/maintenance 5 4.12 Sub-contracting of software 5 5 Software quality procedures 6 5.1 General 6 5.2 Project management 6 5.3 Design techniques and methods6 5.4 Programming techniques
9、 and methods 6 5.5 Software development facilities 6 5.6 Documentation 7 5.7 Configuration management7 5.8 Design review 8 5.9 Tests and trials 8 5.10 Transfer to customer 9 5.11 Post-design services/maintenance9 5.12 Sub-contracting of software 9 Appendix A Pre-contractual activities 10 Appendix B
10、Planning for software quality 11 Appendix C Design and programming techniques and methods 12 Appendix D Documentation 13 Appendix E Configuration management 15 Appendix F Design reviews 19 Appendix G Tests 21 Appendix H Trials procedure 22 Appendix J Transfer to customer 22 Appendix K Subcontracting
11、 of software 23 Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 10:23:30 GMT+00:00 2006, Uncontrolled Copy, (c) BSI BS 7165:1991 ii BSI 01-1999 Page Figure 1 Typical fault reporting procedure 16 Figure 2 Typical software modification procedure 17 Figure 3 Typica
12、l document modification procedure 18 Publications referred toInside back cover Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 10:23:30 GMT+00:00 2006, Uncontrolled Copy, (c) BSI BS 7165:1991 BSI 01-1999iii Foreword This British Standard was prepared under the d
13、irection of the Information Systems Technology Standards Policy Committee. Through cooperation with the Ministry of Defence this British Standard is based on, and is technically equivalent to DEF STAN 00-16 Issue 1, February 1984: Guide to Achievement of Quality in Software1). The DEF Standard has b
14、een prepared primarily for operational defence application and most of the differences introduced have the purpose of expanding the scope so that this British Standard is applicable to the quality of software in a wide range of manufacturing and service industries. This British Standard addresses th
15、e procurement cycle and covers subjects which are important to software quality. It is assumed that the more general aspects of quality management required by BS 5750 are established practice. For the achievement of quality in software it is necessary to satisfy three principal aims: a) a clear defi
16、nition of what is to be achieved and when (specifications and plans); b) a description of the activities and functions that need to be performed (codes of practice); c) the control and monitoring of the way in which activities/functions are performed (quality control). Collectively these aims can be
17、 summed up in the term “quality”, as defined in BS 4778. This standard provides guidance as to how these aims may be achieved to help those responsible for software based projects to meet their commitments effectively, efficiently and economically. The degree and formality of implementation, and the
18、 extent of the quality activities, will vary according to the needs of the project. The methods used to implement the principles identified in this standard will also vary according to the size and complexity of the task, and the structure and management organization of the particular organization.
19、Care has been taken in this standard to identify quality activities without pre-judging the question of who should carry them out. Reference to organizational structures such as “quality departments” have been avoided so that there is flexibility regarding the organizational methods used to satisfy
20、the principles expressed in this document. The quality functions can be integrated with the project tasks provided adequate functional independence is maintained. As with any engineering activity it is important that suitable codes of practice are specified so that uniform approaches and methods can
21、 be applied by designers and associated staff, thus enabling both an assessment of achievement and of quality to be made. Many of the fundamental activities that have a direct bearing on the quality of the final software will be defined by the codes of practice. One of the significant quality functi
22、ons is to ensure that activities and standards set out in the codes of practice are being followed and that the requirements of the contract, in terms of quality, are defined and satisfied. The extent and nature of these activities should be defined in appropriate quality procedures. When this stand
23、ard was approved for publication, work was proceeding in a number of organizations to prepare related informative documents. For example, additional information is published in: a) STARTS Purchasers Handbook2). 1) Available from the head of section, STAN-8, Room 5150A, Kentigern House, 65 Brown Stre
24、et, Glasgow G2 8EX. 2) Available from NCC Publications, National Computing Centre, 61 Oxford Road, Manchester M1 7ED. Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 10:23:30 GMT+00:00 2006, Uncontrolled Copy, (c) BSI BS 7165:1991 iv BSI 01-1999 b) Draft Interim
25、 Defence Standard 00-55 (May 1989) Requirements for the Procurement of Safety Critical Software in Defence Equipment3). In addition, the International Organization for Standardization (ISO) is preparing a standard covering the application of BS 5750-1 to software. A British Standard does not purport
26、 to include all the necessary provisions of a contract. Users of British Standards are responsible for their correct application. Compliance with a British Standard does not of itself confer immunity from legal obligations. Summary of pages This document comprises a front cover, an inside front cove
27、r, pages i to iv, pages 1 to 24, an inside back cover and a back cover. This standard has been updated (see copyright date) and may have had amendments incorporated. This will be indicated in the amendment table on the inside front cover. 3) Available from the head of section, STAN-8, Room 5150A, Ke
28、ntigern House, 65 Brown Street, Glasgow G2 8EX. Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 10:23:30 GMT+00:00 2006, Uncontrolled Copy, (c) BSI BS 7165:1991 BSI 01-19991 1 Scope This British Standard gives recommendations: a) for a software quality control s
29、ystem intended to meet the requirements of BS 5750; and b) on the practical realization of these requirements to ensure that software is of the required quality. The principles expressed in this standard are applicable to all types of procurement involving software, ranging from feasibility study th
30、rough full development to in-service use and maintenance support. The recommendations in this standard are applicable to all types of software (including firmware). Many recommendations of this standard are also applicable to the maintenance of software by the user during its in-service life. This s
31、tandard addresses pre-contract activities because they have a direct effect upon the quality of software. This standard does not cover the ramifications of safety critical software, where extra or more intensive quality practices need to be established to meet the approval of the relevant safety ass
32、essment authority. NOTE 1The words “supplier” and “customer” can be used to mean either separate organizations or separate groups within organizations. NOTE 2Throughout this standard it is recommended that various data are kept. A recommended method of doing this is given in BS 5760-1, with a view t
33、o building up a data library. A further Part of BS 5760 is in course of preparation that will give guidance on how to use these data to improve the next and subsequent products. NOTE 3Appendices A to K give detailed advice supporting the actions outlined in clauses 5 to 7. NOTE 4The titles of the pu
34、blications referred to in this standard are listed on the inside back cover. 2 Definitions For the purposes of this British Standard the following definitions apply. 2.1 walk through a review process in which a designer or programmer leads one or more other members of the development team through a
35、segment of design or code that he or she has written, while the other members ask questions and make comments about technique, style, possible errors, violation of development standards and other problems NOTEThis definition is identical with that in IEEE Standard 729 Glossary of software engineerin
36、g terminology4). 2.2 software software covers all instructions and data which are input to a computer to cause it to function in any mode; it includes operating systems, supervisory systems, compilers and test routines, as well as application programs. Software includes the documents used to define
37、and describe the program (including flow charts, network diagrams and program listings) and also covers specifications, test plans, test data, test results and user instructions 2.3 firmware software code or logic implanted in non-volatile hardware device (i.e. firmware = device + software/logic) 2.
38、4 maintenance any activity intended to eliminate faults or keep hardware or programs in satisfactory working condition, including tests, measurements, adjustments and repairs 2.5 quality the totality of features and characteristics of a product or service that bear on its ability to satisfy stated o
39、r implied needs NOTEThis definition is identical with that in BS 4778-1. 2.6 quality control the operational techniques and activities which are used to fulfil requirements for quality NOTEThis definition is identical with that in BS 4778-1. 2.7 quality assurance all those planned and systematic act
40、ions necessary to provide adequate confidence that a product or service will satisfy given requirements for quality NOTEThis definition is identical with that in BS 4778-1. 2.8 customer the agency placing the requirement with the supplier 2.9 user the individual or group ultimately making use of the
41、 output associated with the subject software 4) Available from BSI Sales Department, Linford Wood, Milton Keynes MK14 6LE. Licensed Copy: London South Bank University, London South Bank University, Fri Dec 08 10:23:30 GMT+00:00 2006, Uncontrolled Copy, (c) BSI BS 7165:1991 2 BSI 01-1999 2.10 supplie
42、r the agency tasked with generating software for the customer 2.11 procurement the act of procuring material, i.e. software, for the customer 2.12 procurement specification the specification provided by the customer reflecting the customers requirements for the software 2.13 post development subsequ
43、ent development undertaken on completion of the initial development 2.14 fault an accidental condition that causes the software to fail to perform its required function NOTEThe terms project management; project manager; and quality management in the context of this document refer to the suppliers or
44、ganization. 3 Pre-development activities 3.1 The customers specification of requirements It is essential to establish and document system requirements in a form that is understood by both the customer and prospective suppliers (see BS 5515). The first step is to produce a specific statement of requi
45、rements to which potential suppliers can respond. This statement should specify for example, the function of the system, the performance required and all environmental and design constraints including those applicable to software (see appendix A). BS 6719 gives more detailed guidance. 3.2 The suppli
46、ers response The supplier should be required to respond with proposals that describe, point by point and in the order given in the specification of requirements, how they would meet these requirements. The suppliers proposals should also describe how they would plan and manage the project and assure
47、 the quality of the system (see appendix A). A procurement specification can then be produced. 3.3 The procurement specification Procurement specifications may be produced by the customer or by a supplier but should, in any case, be subject to mutual agreement and should define what is to be supplie
48、d and how it is to be accepted. It is important that aims or objectives should be clearly differentiated from firm requirements. Some trade-off aspects may be left to be determined during the course of the development, in which case the requirement should be defined in overall terms of system perfor
49、mance. There are a number of disciplines and methodologies used in the production of procurement specifications, all of which are aimed at securing standardization and precision in the definition of the requirement. Changes to procurement specifications should be the subject of formal control procedures. These should be linked with similar controls of defining specifications and acceptance testing specifications that will be raised in the course of implementation of the task. Only in this way can the implications of changes be properly examined and established. NO
链接地址:https://www.31doc.com/p-3735825.html