Source: https://www.scribd.com/doc/155635246/Esa-Bssc962
Timestamp: 2018-03-23 04:12:11
Document Index: 443118326

Matched Legal Cases: ['art 1', 'art 2', 'art 2', 'art 2', 'art) 4', 'art. 3', 'art.3']

Esa Bssc962 | Reliability Engineering | Library (Computing)
Esa Bssc962
Description: This is a short version of configuration management of documents during software development lifecycle followed at European Space Agency. I found it very handy to make templates of documents.
This is a short version of configuration management of documents during software development lifecycle followed at European Space Agency. I found it very handy to make templates of documents.
BSSC(96)2 Issue 1 May 1996
Prepared by: ESA Board for Software Standardisation and Control (BSSC)
european space agency / agence spatiale européenne
8-10, rue Mario-Nikis, 75738 PARIS CEDEX, France
BSSC(96)2 Issue 1 DOCUMENT STATUS SHEET
DOCUMENT STATUS SHEET
DOCUMENT STATUS SHEET 1. DOCUMENT TITLE: BSSC(96)2 2. ISSUE 1 3. REVISION 0 4. DATE 1996 5. REASON FOR CHANGE
Approved, May 8th, 1996 Board for Software Standardisation and Control M. Jones and U. Mortensen, BSSC co-chairmen
Copyright © 1996 by European Space Agency
BSSC(96)2 Issue 1 TABLE OF CONTENTS
CHAPTER 1 INTRODUCTION...................................................................................1 1.1 PURPOSE .................................................................................................................. 1 1.2 OVERVIEW................................................................................................................. 1 CHAPTER 2 SMALL SOFTWARE PROJECTS.........................................................3 2.1 INTRODUCTION........................................................................................................ 3 2.2 COMBINE THE SR AND AD PHASES ...................................................................... 4 2.3 SIMPLIFY DOCUMENTATION .................................................................................. 4 2.4 SIMPLIFY PLANS....................................................................................................... 4 2.5 REDUCE THE RELIABILITY REQUIREMENTS ......................................................... 5 2.6 USE THE SYSTEM TEST SPECIFICATION FOR ACCEPTANCE TESTING ........... 6 CHAPTER 3 PRACTICES FOR SMALL SOFTWARE PROJECTS...........................7 3.1 INTRODUCTION........................................................................................................ 7 3.2 SOFTWARE LIFE CYCLE .......................................................................................... 8 3.3 UR PHASE ................................................................................................................. 8 3.4 SR/AD PHASE ........................................................................................................... 9 3.5 DD PHASE ............................................................................................................... 12 3.6 TR PHASE................................................................................................................ 14 3.7 OM PHASE .............................................................................................................. 15 3.8 SOFTWARE PROJECT MANAGEMENT................................................................. 15 3.9 SOFTWARE CONFIGURATION MANAGEMENT ................................................... 16 3.10 SOFTWARE VERIFICATION AND VALIDATION................................................... 19 3.11 SOFTWARE QUALITY ASSURANCE .................................................................... 21 APPENDIX A GLOSSARY ..................................................................................... A-1 APPENDIX B REFERENCES................................................................................. B-1 APPENDIX C DOCUMENT TEMPLATES.............................................................. C-1
BSSC(96)2 Issue 1 PREFACE
The ESA Software Engineering Standards, ESA PSS-05-0, define the software practises that must be applied in all the Agency’ s projects. While their application in large projects is quite straightforward, experience has shown that a simplified approach is appropriate for small software projects. This document provides guidelines about how to apply the ESA Software Engineering Standards to small software projects. The guide has accordingly been given the nickname of ‘ PSS-05 lite’ . The following past and present BSSC members have contributed to the production of this guide: Michael Jones (co-chairman), Uffe Mortensen (co-chairman), Gianfranco Alvisi, Bryan Melton, Daniel de Pablo, Adriaan Scheffer and Jacques Marcoux. The BSSC wishes to thank Jon Fairclough for drafting and editing the guide. The authors wish to thank all the people who contributed ideas about applying ESA PSS-05-0 to small projects. Requests for clarifications, change proposals or any other comment concerning this guide should be addressed to: BSSC/ESOC Secretariat Attention of Mr M Jones ESOC Robert Bosch Strasse 5 D-64293 Darmstadt Germany BSSC/ESTEC Secretariat Attention of Mr U Mortensen ESTEC Postbus 299 NL-2200 AG Noordwijk The Netherlands
There are several criteria for deciding whether a software project is small.2 OVERVIEW Chapter 2 defines what is meant by a small software project and discusses some simple strategies for applying ESA PSS-05-0 to them.BSSC(96)2 Issue 1 INTRODUCTION 1 CHAPTER 1 INTRODUCTION 1. software failure would result in the loss of life. This document has been produced to provide organisations and software project managers with guidelines for the application of the standards to small software projects. or loss of property.1 PURPOSE ESA PSS-05-0 describes the software engineering standards to be applied for all deliverable software implemented for the European Space Agency (ESA) [Ref 1]. Appendix C contains simplified document templates. and therefore whether this guide can be applied. 1. this guide should not be applied when the software is ‘ critical’ (e. or major inconvenience to users) or when ESA PSS-01-21 ‘ Software Product Assurance Requirements for ESA Space Systems’ applies.g. ‘ Guide to the Software Engineering Standards’ [Ref 2 to 12]. Appendix B contains a list of references. Appendix A contains a glossary of acronyms and abbreviations. . Whatever the result of the evaluation. These are discussed in Chapter 2. Chapter 3 explains how the mandatory practices of ESA PSS-05-0 should be applied in a small software project. Additional guidelines on the application of the standards are provided in the series of documents described in ESA PSS-05-01.
2 BSSC(96)2 Issue 1 INTRODUCTION This page is intentionally left blank .
BSSC(96)2 Issue 1 SMALL SOFTWARE PROJECTS 3 CHAPTER 2 SMALL SOFTWARE PROJECTS 2.1). Section 4. One or more of the following strategies are often suitable for small projects producing non-critical software: • combine the software requirements and architectural design phases • simplify documentation • simplify plans • reduce the reliability requirements • use the system test specification for acceptance testing. The following sections review these strategies. The factors that are related to the ‘ size’ of a software development project are: • project development cost • number of people required to develop the software • amount of software to be produced. . excluding comments.1 INTRODUCTION ESA PSS-05-0 lists several factors to consider when applying it to a software project (see Introduction. A software project can be considered to be small if one or more of the following criteria apply: • less than two man years of development effort is needed • a single development team of five people or less is required • the amount of source code is less than 10000 lines.
An efficient way to organise the project is therefore to: • combine the SR and AD phases into a single SR/AD phase • combine the SR/R and AD/R into single formal review at the end of the SR/AD phase. 2. Each of the reviews normally involve the user. For a small software project. Developers should document the detailed design by putting most detailed design information into the source code and extending the SSD to contain any detailed design information that cannot be located in the source code (e. and can last two weeks to a month. Developers should use the simplified document templates provided in Appendix C. separate reviews of the SRD and ADD lengthen the project significantly. The plans may be generated when writing the proposal.g. The production of a Project History Document is considered to be good practice but its delivery is optional. These phases end with formal reviews of the Software Requirements Document and Architectural Design Document. and are designed to cover the documentation requirements of all projects.4 BSSC(96)2 Issue 1 SMALL SOFTWARE PROJECTS 2. Software Configuration Management Plan and Software Verification and Validation Plans are combined. This means that the phase sections of the Software Project Management Plan. The purpose of the software quality assurance function in a project is to check that the project is adhering to standards and plans. Developers should combine the SRD and ADD into a single Software Specification Document (SSD) when the SR and AD phases are combined.3 SIMPLIFY DOCUMENTATION The document templates provided in ESA PSS-05-0 are based upon ANSI/IEEE standards. information about the software structure).2 COMBINE THE SR AND AD PHASES ESA PSS-05-0 requires that software requirements definition and architectural design be performed in separate phases. 2.4 SIMPLIFY PLANS In small software projects it is highly desirable to plan all phases at the start of the project. In a small .
the Software Verification and Validation Plan and the Software Quality Assurance Plan into a single document (called a‘ Quality Plan’ in ISO 9000 terminology). The cost of this exhaustive testing may exceed the cost of repairing the defects during operations. 80% coverage) • review every statement not covered in testing. In small software projects.BSSC(96)2 Issue 1 SMALL SOFTWARE PROJECTS 5 software project this is normally done informally by the project manager. This is sometimes known as the ‘ statement coverage requirement’ .g. the Software Configuration Management Plan. Reliability is built into software by: • designing the software to be reliable • reviewing documents and code • testing the code. test cases have to be invented to force execution of all the statements. However achieving high coverage in testing can be quite expensive in effort. ESA PSS-05-0 requires that the test approach be outlined in the test plan and refined in the test design. and that the number of defects becomes very low when the statement coverage exceeds 90%. Developers may find it convenient to combine the technical process section of the Software Project Management Plan. There is good evidence that significant numbers of defects remain in the software when the statement coverage falls below 70% [Ref 14]. Developers should: • set a statement testing target (e.5 REDUCE THE RELIABILITY REQUIREMENTS The reliability requirements on software should be set by trading-off the cost of correcting defects during development against the cost of: • correcting the defects during operations • penalties resulting from failure during operation • loss of reputation suffered by producing a faulty product. 2. . it is sufficient to outline the test approach only. This means that the Test Design sections of the SVVP can be omitted. The practice of producing a Software Quality Assurance Plan may be waived. ESA PSS-05-0 requires that every statement be executed at least once.
.6 USE THE SYSTEM TEST SPECIFICATION FOR ACCEPTANCE TESTING When the developer is responsible for producing the acceptance test specification. the acceptance tests often repeat selected system test cases and procedures. They should be used whenever possible. One approach to documenting acceptance tests is simply to indicate in the system test specification which test cases and procedures should be used in acceptance testing. 2.6 BSSC(96)2 Issue 1 SMALL SOFTWARE PROJECTS Software tools are available for measuring test coverage.
1 INTRODUCTION Figure 3.BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS 7 CHAPTER 3 PRACTICES FOR SMALL SOFTWARE PROJECTS 3. Guidance (in italics) is attached where appropriate to explain how .1 illustrates a small software project life cycle approach with the following features: • the software requirements and architectural design phases have been combined • the simplified document templates described in Appendix C are used • detailed design information has been included in the source code • plans have been combined • reliability requirements have been reduced • no test design documentation is produced • selected system tests are used for acceptance testing • all SQA practices are not applicable • the Project History Document is not a required deliverable. Tracing /AT plan UR URD SVVP/ST Plan/IT Plan SR/AD SSD SVVP/ST spec DD code Software System SUM TR STD OM Figure 3.1: Small software project life cycle The following sections describe the small software project mandatory practices. SPMP SCMP informal inputs SVVP/Reviews. The practices are tabulated with their ESA PSS-05-0 identifier.
1 (of PSS05): UR phase . each user requirement shall include a measure of priority so that the developer can decide the production schedule. UR05 UR06 UR07 UR08 .Definition of the architectural design DD phase . Software development activities shall be systematically planned and carried out.Definition of the software requirements AD phase .Detailed design and production of the code TR phase . 3.2 SOFTWARE LIFE CYCLE SLC01 SLC02 SLC03 The products of a software development project shall be delivered in a timely manner and be fit for their purpose.Transfer of the software to operations OM phase . 3.3 UR PHASE UR01 UR02 UR03 UR04 The definition of the user requirements shall be the responsibility of the user.Definition of the user requirements SR phase . This guidance is based upon the strategies described in Chapter 2. Essential user requirements shall be marked as such. The source of each user requirement shall be stated.Operations and maintenance In small projects. Each user requirement shall include an identifier. For incremental delivery.8 BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS the practice is applied in a small project. Figure 1. or breaches of security. All software projects shall have a life cycle approach which includes the basic phases shown in Part 1. The user shall describe the consequences of losses of availability. the SR and AD phases are combined into an SR/AD phase. The outputs of the UR phase shall be formally reviewed during the User Requirements Review. Each user requirement shall be verifiable. so that developers can fully appreciate the criticality of each function.
The outputs of the SR phase shall be formally reviewed during the Software Requirements Review. All known user requirements shall be included in the URD. This practice applies to the SR/AD phase. The URD shall provide a general description of what the user expects the software to do. 3. SR07 SR08 SR09 . A recognised method for software requirements analysis shall be adopted and applied consistently in the SR phase. For incremental delivery. The developer shall construct an implementation-independent model of what is needed by the user. The URD shall define all the constraints that the user wishes to impose upon any solution. The URD shall describe the external interfaces to the software system or reference them in ICDs that exist or are to be written. Each software requirement shall be verifiable. The URD shall always be produced before a software project is started. References that trace software requirements back to the URD shall accompany each software requirement. The URD shall describe the operations the user wants to perform with the software system. each software requirement shall include a measure of priority so that the developer can decide the production schedule. An output of the UR phase shall be the User Requirements Document (URD). Essential software requirements shall be marked as such. SR04 SR05 SR06 Each software requirement shall include an identifier.BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS 9 UR09 UR10 UR11 UR12 UR13 UR14 UR15 UR16 Non-applicable user requirements shall be clearly flagged in the URD.4 SR/AD PHASE SR01 SR02 SR03 SR phase activities shall be carried out according to the plans defined in the UR phase.
SR14 SR15 The SRD shall be consistent. SR10 An output of the SR phase shall be the Software Requirements Document (SRD). unless it is a constraint placed by the user. unless it has to be present as a constraint. This practice applies to the SSD. This practice applies to the SSD. This practice applies to the SR/AD phase. . shall say what the software is to do. the AD plans should be made in the UR phase. The SRD shall not include implementation details or terminology. This practice applies to the SR/AD phase. The SSD should be compiled according to the table contents in Appendix C of this guide. The SRD shall cover all the requirements stated in the URD.10 BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS The outputs of software requirements definition activities are reviewed in the SR/AD phase review. This practice applies to the SSD. SR18 The SRD shall be compiled according to the table of contents provided in Appendix C. AD02 A recognised method for software design shall be adopted and applied consistently in the AD phase. This practice applies to the SSD. SR16 SR17 Descriptions of functions . SR11 SR12 SR13 The SRD shall be complete. This practice applies to the SSD. This practice applies to the SSD. The SRD shall avoid specifying the hardware or equipment.. In small projects.. The SRD information is placed in the Software Specification Document (SSD). A table showing how user requirements correspond to software requirements shall be placed in the SRD. and must avoid saying how it is to be done. AD01 AD phase activities shall be carried out according to the plans defined in the SR phase. This practice is not applicable.
12. AD15 The computer resources (e. range of possible values of each element. AD06. the structure). CPU speed. system software) needed in the development environment and the operational environment shall be estimated in the AD phase and defined in the ADD. storage. Only the selected design approach shall be reflected in the ADD. which describes the design of the software using implementation terminology. The control flow between the components shall be defined in the ADD. functions to be performed. . AD16 The outputs of the AD phase shall be formally reviewed during the Architectural Design Review. This practice applies to the SSD. data output. This practice applies to the SSD. 8 apply to the SSD. type. 7.e. The method used to decompose the software into its component parts shall permit a top-down approach. memory. Data structures that interface components shall be defined in the ADD. The outputs of software architectural design activities are reviewed in the SR/AD phase review. 13 apply to the SSD. This practice applies to the SSD. Data structure definitions shall include the: AD10 AD11 AD12 AD13 AD14 • • • • description of each element (e. AD10. initial values of each element. AD04 AD05 For each component the following information shall be detailed in the ADD: AD06 AD07 AD08 AD09 • • • data input.g. 11. This practice applies to the SSD. name.BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS 11 AD03 The developer shall construct a ‘ physical model’ .g. dimension). relationships between the elements (i.
This practice applies to the SSD. This practice applies to the SSD. AD22 AD23 The ADD shall be consistent.12 BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS AD17 The ADD shall define the major components of the software and the interfaces between them. concurrent production and documentation. as appropriate during the project. This practice applies to the SSD. AD21 A table cross-referencing software requirements to parts of the architectural design shall be placed in the ADD.5 DD PHASE DD01 DD phase activities shall be carried out according to the plans defined in the AD phase. The SSD should be compiled according to the table contents in Appendix C of this guide. This practice applies to the SSD. structured programming. AD18 AD19 AD20 The ADD shall define or reference all external interfaces. The ADD shall be an output from the AD phase. covering all the software requirements described in the SRD. This practice applies to the SSD. The ADD shall be sufficiently detailed to allow the project leader to draw up a detailed implementation plan and to control the overall project during the remaining development phases. This practice applies to the SSD. DD phase plans are contained in the plans made in the UR phase and updated. The detailed design and production of software shall be based on the following three principles: DD02 DD03 DD04 • • • top-down decomposition. This practice applies to the SSD. 3. The ADD shall be complete. This practice applies to the SSD. . AD24 The ADD shall be compiled according to the table of contents provided in Appendix C.
DD11 DD12 DD13 DD14 Part 2 of the DDD shall have the same structure and identification scheme as the code itself. Detailed design information is placed in the SSD and source code. This practice applies to the SSD.review every statement not covered in testing. After production.set a statement testing target (e. All deliverable code shall be identified in a configuration item list.g. Before a module can be accepted. DD07 Integration testing shall check that all the data exchanged across an interface agrees with the data structure specifications in the ADD. DD09 System testing shall verify compliance with system objectives. This practice applies to the SSD. 80% coverage) . . This practice applies to the SSD. DD08 Integration testing shall confirm that the control flows defined in the ADD have been implemented. as stated in the SRD. Software tools are available for measuring test coverage. They should be used whenever possible. The DDD shall be an output of the DD phase.BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS 13 DD05 DD06 The integration process shall be controlled by the software configuration management procedures defined in the SCMP. a critical design review shall be convened to certify its readiness for implementation. the DD Review (DD/R) shall consider the results of the verification activities and decide whether to transfer the software. DD10 When the design of a major component is finished. Software projects should: . Not applicable. with a 1:1 correspondence between sections of the documentation and the software components. every statement in a module shall be executed successfully at least once. Not applicable. Acceptance should be performed by the project manager after unit testing and by the customer at the end of the phase.
whether the software can be provisionally accepted or not.6 TR PHASE TR01 TR02 Representatives of users and operations personnel shall participate in acceptance tests. The Software Review Board (SRB) shall review the software’ s performance in the acceptance tests and recommend. Acceptance tests necessary for provisional acceptance shall be indicated in the SVVP. TR03 TR04 The capability of building the system from the components that are directly modifiable by the maintenance team shall be established. An output of the TR phase shall be the STD.14 BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS DD15 The DDD shall be complete. The statement of provisional acceptance shall be produced by the initiator. on behalf of the users. The STD shall be handed over from the developer to the maintenance organisation at provisional acceptance. to the initiator. and all documentation about software changes performed during the TR phase. The provisionally accepted software system shall consist of the outputs of all previous phases and modifications found necessary in the TR phase. accounting for all the software requirements in the SRD. The traceability matrix in the SSD must be updated instead. DD16 A table cross-referencing software requirements to the detailed design components shall be placed in the DDD. and sent to the developer. This practice means that all requirements in the SSD must be implemented in the code. TR phase plans are established in the UR phase and updated as appropriate. TR phase activities shall be carried out according to the plans defined in the DD phase. DD17 A Software User Manual (SUM) shall be an output of the DD phase. The STD shall contain the summary of the acceptance test reports. TR05 TR06 TR07 TR08 TR09 TR10 . 3.
Even when no contractor is involved. The SPMP does not have phase sections: there is a single plan for all the SR/AD.BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS 15 3. By the end of the UR review. This practice applies to the SPMP.8 SOFTWARE PROJECT MANAGEMENT SPM01 SPM02 All software project management activities shall be documented in the Software Project Management Plan (SPMP). This practice applies to the SPMP. OM02 OM03 OM04 OM05 OM06 OM07 OM08 OM09 OM10 3. Procedures for software modification shall be defined. the SR phase section of the SPMP shall be produced (SPMP/SR). All the acceptance tests shall have been successfully completed before the software is finally accepted. Consistency between code and documentation shall be maintained. OM phase activities that involve the developer shall be carried out according to the plans defined in the SPMP/TR. on behalf of the users.. Resources shall be assigned to a product’ s maintenance until it is retired. The statement of final acceptance shall be produced by the initiator.. SPM03 SPM04 The SPMP/SR shall outline a plan for the whole project. DD and TR phases. Not applicable.7 OM PHASE OM01 Until final acceptance. shall authorise all modifications to the software. . and sent to the developer. The PHD shall be delivered to the initiator after final acceptance. there shall be a final acceptance milestone to arrange the formal hand-over from software development to maintenance. A precise estimate of the effort involved in the SR phase shall be included in the SPMP/SR. The SRB . However developers are encouraged to produce a PHD for internal use. A maintenance organisation shall be designated for every software product in operational use.
tools. integration and testing activities. SPM12 No software production work packages in the SPMP/DD shall last longer than 1 man-month. SPM07 A precise estimate of the effort involved in the AD phase shall be included in the SPMP/AD. 3. the DD phase section of the SPMP shall be produced (SPMP/DD). A bar chart (i.9 SOFTWARE CONFIGURATION MANAGEMENT SCM01 All software items. files. SPM08 During the AD phase. This practice applies to the SPMP. This practice applies to the SPMP. Gantt Chart) should be used to show the relationship. Not applicable. shall be subjected to configuration management procedures. test software and data. for example documentation. . source code. SPM06 An estimate of the total project cost shall be included in the SPMP/AD. SPM11 The SPMP/DD shall contain a planning network showing relationships of coding. SPM10 The SPMP/DD shall contain a WBS that is directly related to the decomposition of the software into components. SPM09 An estimate of the total project cost shall be included in the SPMP/DD. This practice applies to the SPMP.e. executable code. the AD phase section of the SPMP shall be produced (SPMP/AD). This practice applies to the SPMP. Not applicable. This practice applies to the SPMP. the TR phase section of the SPMP shall be produced (SPMP/TR).16 BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS SPM05 During the SR phase. SPM13 During the DD phase. This practice applies to the SPMP. However the SPMP should be updated when the SSD has been produced. object or relocatable code.
storing and changing software items through development. Every configuration item shall have an identifier that distinguishes it from other items with different: SCM03 SCM04 SCM05 SCM06 SCM07 SCM08 SCM09 SCM10 SCM11 • • requirements. a software module shall have a standard header that includes: SCM12 SCM13 SCM14 SCM15 SCM16 SCM17 SCM18 • • • • configuration item identifier (name.BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS 17 SCM02 The configuration management procedures shall establish methods for identifying. version).g. with at least the following data: . In the TR phase. without requiring the modification of the identifiers of any existing CIs. The identifier shall include an indication of the type of processing the CI is intended for (e. In the OM phase. a list of changed configuration items shall be included in each Software Release Note (SRN). As part of the configuration identification method. change history (version/date/author/description). The identifier shall include a number or a name related to the purpose of the CI. especially functionality and interfaces. An SRN shall accompany each release made in the OM phase. type. The identifier of a CI shall include a version number. creation date. All documentation and storage media shall be clearly labelled in a standard format. filetype information). Each component defined in the design process shall be designated as a CI and include an identifier. implementation. A common set of configuration management procedures shall be used. The configuration identification method shall be capable of accommodating new CIs. integration and transfer. original author. a list of configuration items in the first release shall be included in the STD. The identifier of documents shall include an issue number and a revision number.
The status of all configuration items shall be recorded. the date and status of each RID and DCR. test files. for reference. SCR and SMR.3.2. To perform software status accounting.2. source and executable code. date. the SRN shall record the faults that have been repaired and the new requirements that have been incorporated. at a minimum. Old releases shall be retained. Master (or Controlled) library. Up-to-date security copies of master and static libraries shall always be available. For each release.2). Modified software shall be retested before release. The change procedure described (in Part 2.18 BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS SCM19 SCM20 SCM21 SCM22 • • • • project name. the following software libraries shall be implemented for storing all the deliverable components (e. command procedures): SCM23 SCM24 SCM25 SCM26 SCM27 SCM28 SCM29 • • • Development (or Dynamic) library.3. Software problems and change proposals shall be handled by the procedure described (in Part 2. documentation.2. the date and status of each SPR.1) shall be observed when changes are needed to a delivered document. Section 3. type.2. . As a minimum. version). content description. Procedures for the regular backup of development libraries shall be established.g. To ensure security and control of the software. each software project shall record: SCM30 SCM31 SCM32 SCM33 SCM34 SCM35 SCM36 SCM37 SCM38 SCM39 • • • • the date and version/issue of each baseline. documentation and code shall be consistent. Section 3. a summary description of each Configuration Item. Static (or Archive) library. configuration item identifier (name. Static libraries shall not be modified.
the DD phase section of the SCMP shall be produced (SCMP/DD).10 SOFTWARE VERIFICATION AND VALIDATION SVV01 Forwards traceability requires that each input to a phase shall be traceable to an output of that phase. 3. the AD phase section of the SCMP shall be produced (SCMP/AD). and any CASE tool outputs or prototype code. SCM48 During the DD phase. to be produced in the DD phase.BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS 19 SCM40 All software configuration management activities shall be documented in the Software Configuration Management Plan (SCMP). the TR phase section of the SCMP shall be produced (SCMP/TR). . and any CASE tool outputs or prototype code. SCM45 The SCMP/AD shall cover the configuration management procedures for documentation. Not applicable. Not applicable. SCM47 The SCMP/DD shall cover the configuration management procedures for documentation. SCM49 The SCMP/TR shall cover the procedures for the configuration management of the deliverables in the operational environment. This practice applies to the SCMP SCM44 During the SR phase. to be produced in the SR phase. Configuration management procedures shall be in place before the production of software (code and documentation) starts. the SR phase section of the SCMP shall be produced (SCMP/SR). Not applicable. Not applicable. This practice applies to the SCMP. This practice applies to the SCMP. and CASE tool outputs or prototype code. to be produced in the AD phase. SCM41 SCM42 SCM43 The SCMP/SR shall cover the configuration management procedures for documentation. deliverable code. This practice applies to the SCMP SCM46 During the AD phase. By the end of the UR review.
SVV14 SVV15 The developer shall construct a system test plan in the SR phase and document it in the SVVP. This practice applies to SVVP. The SVVP shall ensure that the verification activities: • • • • are appropriate for the degree of criticality of the software.. the DD phase section of the SVVP shall be produced (SVVP/DD). . are sufficient to assure the quality of the product. SVV10 The SVVP/SR shall define how to trace user requirements to software requirements. the SR phase section of the SVVP shall be produced (SVVP/SR). Functional and physical audits shall be performed before the release of the software. reliability. the AD phase section of the SVVP shall be produced (SVVP/AD).. All software verification and validation activities shall be documented in the Software Verification and Validation Plan (SVVP). Not applicable. SVV05 SVV06 SVV07 SVV08 SVV09 By the end of the UR review. This practice applies to SVVP.20 BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS SVV02 SVV03 SVV04 Backwards traceability requires that each output of a phase shall be traceable to an input to that phase. maintainability and safety requirements . so that each software component can be justified. verify that the product will meet the quality. SVV13 The SVVP/AD shall define how to trace software requirements to components. During the SR phase. This practice applies to SVVP.. SVV11 SVV12 The developer shall construct an acceptance test plan in the UR phase and document it in the SVVP. During the AD phase. so that each software requirement can be justified. Not applicable. meet the verification and acceptance testing requirements (stated in the SRD).
SVV18 SVV19 The developer shall construct a unit test plan in the DD phase and document it in the SVVP. system and acceptance test designs shall be described in the SVVP. This practice applies to the SVVP. Not applicable. Not applicable. The unit. Not applicable. Not applicable. system and acceptance test cases shall be described in the SVVP. SVV17 The developer shall construct an integration test plan in the AD phase and document it in the SVVP. The unit.11 SOFTWARE QUALITY ASSURANCE SQA01 An SQAP shall be produced by each contractor developing software. integration. The unit. in detail. SQA04 The SQAP/SR shall describe.BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS 21 SVV16 The SVVP/AD shall describe how the DDD and code are to be evaluated by defining the review and traceability procedures. . SQA05 The SQAP/SR shall outline the quality assurance plan for the rest of the project. 3. SQA02 All software quality assurance activities shall be documented in the Software Quality Assurance Plan (SQAP). Not applicable. Not applicable. integration. SQA03 By the end of the UR review. This is done in the SR/AD phase. the quality assurance activities to be carried out in the SR phase. system and acceptance test procedures shall be described in the SVVP. the SR phase section of the SQAP shall be produced (SQAP/SR). integration. system and acceptance test reports shall be described in the SVVP. SVV20 SVV21 SVV22 The unit integration.
SQA08 During the AD phase. SQA07 The SQAP/AD shall cover in detail all the quality assurance activities to be carried out in the AD phase. Not applicable. SQA09 The SQAP/DD shall cover in detail all the quality assurance activities to be carried out in the DD phase. the DD phase section of the SQAP shall be produced (SQAP/DD). . Not applicable. Not applicable. SQA10 During the DD phase. the AD phase section of the SQAP shall be produced (SQAP/AD). the TR phase section of the SQAP shall be produced (SQAP/TR). Not applicable. SQA11 The SQAP/TR shall cover in detail all the quality assurance activities to be carried out from the start the TR phase until final acceptance in the OM phase.22 BSSC(96)2 Issue 1 PRACTICES FOR SMALL SOFTWARE PROJECTS SQA06 During the SR phase. Not applicable. Not applicable.
Standards and Specifications1 Software Configuration Management Plan Software Project Management Plan Software Quality Assurance Plan Software Requirements System Test Software Transfer Document Software Requirements Document Software Specification Document Software User Manual Software Verification and Validation Plan User Requirements Document Unit Test Work Breakdown Structure 1 Not ‘ Programming Saturdays and Sundays’ .BSSC(96)2 Issue 1 GLOSSARY A-1 APPENDIX A GLOSSARY A.1 LIST OF ACRONYMS AND ABBREVIATIONS AD ADD ANSI AT DD DDD ESA IEEE IT PHD PSS SCMP SPMP SQAP SR ST STD SRD SSD SUM SVVP URD UT WBS Architectural Design Architectural Design Document American National Standards Institute Acceptance Test Detailed Design and production Detailed Design Document European Space Agency Institute of Electrical and Electronics Engineers Integration Test Project History Document Procedures.
A-2 BSSC(96)2 Issue 1 GLOSSARY This page is intentionally left blank. .
ESA PSS-05-06 Issue 1 October 1994. Computer. Guide to the Software Detailed Design and Production Phase. September 1994. ESA PSS-0507 Issue 1 December 1994. Guide to the Software Requirements Definition Phase. Guide to Software Quality Assurance. ESA PSS-05-08 Issue 1 June 1994. Guide to the User Requirements Definition Phase. 6. ESA PSS-05-11 Issue 1 July 1993. 9. 13. ESA PSS-05-0 Issue 2 February 1991. Guide to the ESA Software Engineering Standards. Guide to Software Verification and Validation. Guide to Software Project Management. Guide to the Software Transfer Phase . ESA PSS05-05 Issue 1 May 1992. ESA PSS-05-03 Issue 1 October 1991. 2. IEEE. ESA PSS-05-02 Issue 1 October 1991. 10. ESA PSS-05-01 Issue 1 October 1991. Guide to Software Configuration Management. S. 11. Boehm. 8. 7. Achieving Software Quality with Testing Coverage Measures. ESA PSS-05-10 Issue 1 February 1994.London and M.BSSC(96)2 Issue 1 REFERENCES B-1 APPENDIX B REFERENCES 1. Guide to the Software Architectural Design Phase. . ESA PSS-05-04 Issue 1 January 1992. 5. 3. 12. ESA Software Engineering Standards. Software Engineering Economics. 4. Guide to the Software Operations and Maintenance Phase.Lyu. J. B. ESA PSS-05-09 Issue 1 November 1992. Prentice-Hall (1981) 14.Horgan.
B-2 BSSC(96)2 Issue 1 REFERENCES This page is intentionally left blank. .
the section should be omitted and the sections renumbered.Abstract b . .Table of contents c .Document Status Sheet d . Section titles which are to be provided by document authors are enclosed in square brackets.Document Change Records made since last issue If there is no information pertinent to a section.BSSC(96)2 Issue 1 DOCUMENT TEMPLATES C-1 APPENDIX C DOCUMENT TEMPLATES All documents should contain the following service information: a . Guidelines on the contents of document sections are given in italics.
2.4 Overview of the document 2 General Description 2.2 General constraints Describe the main constraints that apply and why they exist.3 User characteristics Describe who will use the software and when. acronyms and abbreviations 1. 2.1 Purpose of the document 1. Describe the main capabilities required and why they are needed. 2.4 Operational environment Describe what external systems do and their interfaces with the product.3 References 1.1 General capabilities Describe the process to be supported by the software. with attributes. 3.1 Capability requirements 3.C-2 BSSC(96)2 Issue 1 DOCUMENT TEMPLATES C.2 Definitions. 3 Specific Requirements List the specific requirements.2 Constraint requirements .1 URD TABLE OF CONTENTS 1 Introduction 1. Include a context diagram or system block diagram.
with attributes. with diagrams. Show the components and the control and data flow between them.5 Resource requirements 3.2 Decomposition description Describe the physical model.2 Definitions. 3. .4 Operational requirements 3.1 Design method Describe or reference the design method used. 3 Specific Requirements List the specific requirements. acronyms and abbreviations 1.1 Functional requirements 3.9 Security requirements 3.12 Reliability requirements 3.13 Maintainability requirements 3.7 Acceptance testing requirements 3.BSSC(96)2 Issue 1 DOCUMENT TEMPLATES C-3 C.6 Verification requirements 3.2 SSD TABLE OF CONTENTS 1 Introduction 1.11 Quality requirements 3.8 Documentation requirements 3. Subsections may be regrouped around high-level functions.10 Portability requirements 3.2 Performance requirements 3.4 Overview of the document 2 Model description Describe the logical model using a recognised analysis method.3 References 1.3 Interface requirements 3.14 Safety requirements 4 System design 4.1 Purpose of the document 1. 4.
3 Interfaces Define the control and data flow to and from the component. 5.5 Processing Describe the control and data flow within the component. 5. such as files used for interfacing major components.1 Type Say what the component is (e. 8 Software Requirements vs Components Traceability matrix Provide tables cross-referencing software requirements to components and vice versa. 5.n.n.g.2 Function Say what the component does. 5.C-4 BSSC(96)2 Issue 1 DOCUMENT TEMPLATES 5 Component description Describe each component. operate and maintain the software. Otherwise give an outline description.6 Data Define in detail the data internal to components.4 Dependencies Describe the preconditions for using this component. program etc) 5. . module.7 Resources List the resources required. 5. such as displays and printers.n. Structure this section according to the physical model. 7 User Requirements vs Software Requirements Traceability matrix Provide tables cross-referencing user requirements to software requirements and vice versa.n. Outline the processing of bottom-level components.n.n [Component identifier] 5. 5.n. file. 6 Feasibility and Resource Estimates Summarise the computer resources required to build.n.
Describe the purpose of the software. 2 [Overview section] Describe the process to be supported by the software. 1. Processing Summarise the processing using pseudo-code or a PDL C.4 How to use this document Say how the document is intended to be read.5 Related documents Describe the place of the SUM in the project documentation. 1. 1. .1 Intended readership Describe who should read the SUM. 1.3 SOURCE CODE DOCUMENTATION REQUIREMENTS Each module should contain a header that defines: Module Name Author Creation Date Change History Version/Date/Author/Description Function Say what the component does. 1.6 Conventions Describe any stylistic and command syntax conventions used.BSSC(96)2 Issue 1 DOCUMENT TEMPLATES C-5 C. and what the user and/or operator needs to supply to the software. 1.4 SUM TABLE OF CONTENTS 1 Introduction 1.3 Purpose Describe the purpose of the document. and what the software does to support the process.7 Problem reporting instructions Summarise the SPR system for reporting problems. Interfaces Define the inputs and outputs Dependencies Describe the preconditions for using this component.2 Applicability statement State which software release the SUM applies to.
(f) Cross references to other operations Refer to any complementary. for each basic operation. (b) Cautions and warnings Do’ s and don’ ts. . (e) Possible error messages and causes List the possible errors and likely causes. 4 [Instruction section] From the trainee’ s viewpoint. provide: (a) Functional description What the operation does. for each task. Appendix A Appendix B Appendix C Error messages and recovery procedures List all the error messages. Glossary List all terms with specialised meanings. provide: (a) Functional description What the task will achieve. (c) Formal description Required parameters Optional parameters Default options Parameter order and syntax (d) Examples Give worked examples of the operation. (c) Procedures Include: Set-up and initialisation Input operations What results to expect (d) Probable errors and possible causes What to do when things go wrong. predecessor or successor operations. Index (for manuals of 40 pages or more) List all important terms and their locations.C-6 BSSC(96)2 Issue 1 DOCUMENT TEMPLATES 3 [Installation section] Describe the procedures needed to the software on the target machine. 5 [Reference section] From the expert’ s viewpoint. (b) Cautions and warnings Do’ s and don’ ts.
5 Acceptance Test Report Summary For each acceptance test. 4 Configuration Item List List all the deliverable configuration items. .1 Purpose of the document 1.5 STD TABLE OF CONTENTS 1 Introduction 1.BSSC(96)2 Issue 1 DOCUMENT TEMPLATES C-7 C.3 References 1.4 Overview of the document 2 Build Report Describe what happened when the software was built from source code 3 Installation Report Describe what happened when the software was installed on the target machine. 8 Software Modification Reports List the SMRs completed during the TR phase. acronyms and abbreviations 1. 7 Software Change Requests List the SCRs raised during the TR phase and their status at STD issue.2 Definitions. give the: user requirement identifier and summary test report identifier in the SVVP/AT/Test Reports test result summary 6 Software Problem Reports List the SPRs raised during the TR phase and their status at STD issue.
C-8 BSSC(96)2 Issue 1 DOCUMENT TEMPLATES C.2 Definitions. 4. . style and tools for documentation. describe the inputs.1 Purpose of the document 1. tasks.1 Organisational roles and responsibilities Describe project roles.1 Work packages For each work package. responsibilities and reporting lines. Define and reference the coding standards. 2.1 Project inputs List what documents will be input to the project. Define and reference the design and production tools. when and where.2 Organisational boundaries and interfaces Describe the interfaces with customers and suppliers.5 Project support functions Summarise the procedures for SCM and SVV and identify the related procedures and plans 4 Work Packages. effort requirements. outputs. 3 Technical Process 3. 3. 3.4 Methods and tools Describe or reference the development methods used. acronyms and abbreviations 1.3 Budget Describe the total cost of the project. Describe the format.3 References 1.4 Overview of the document 2 Project organisation 2.2 Project outputs List what will be delivered.6 SPMP TABLE OF CONTENTS 1 Introduction 1. Schedule. resources allocated and verification process. 3. when and by who 3. and Budget 4.2 Schedule Describe when each work package will be start and end (Gantt Chart) 4.3 Process model Define the life cycle approach to the project.
2 Configuration Item Storage Describe the procedures for storing CIs in software libraries.BSSC(96)2 Issue 1 DOCUMENT TEMPLATES C-9 C.1 Purpose of the document 1. Describe the procedures for storing media containing CIs.3 References 1.4 Configuration Status Accounting Describe the procedures for keeping an audit trail of changes. 2. acronyms and abbreviations 1.2 Definitions.7 SCMP TABLE OF CONTENTS 1 Introduction 1. 2.4 Overview of the document 2 SCM Activities 2. Describe how it will be established.5 Build procedures Describe the procedures for building the software from source. 2.3 Configuration Item Change Control Describe the change control procedures.1 Configuration Identification Describe the CI identification conventions.6 Release procedures Describe the procedures for the release of code and documentation. Describe the level of authority required to change it. 2. . 2. For each baseline: Describe when it will be created. Describe what it will contain.
System and Acceptance Testing Sections 1 Introduction 1.3 References 1.1 Purpose of the document 1.4 Testing tasks Describe the tasks needed to prepare for and carry out the tests. Integration.5 Environmental needs Describe the properties required of the test environment. 2.6 Test case pass/fail criteria Define the criteria for pass or failing a test case .4 Overview of the document 2 Reviews Describe the inspection.2 Features to be tested Identify the features to be tested. 3 Tracing Describe how to trace phase inputs to outputs. Unit. 2.8 SVVP TABLE OF CONTENTS Reviews and tracing section 1 Introduction 1.3 References 1. List the items that must be delivered when testing ends. 2.1 Test items List the items to be tested. acronyms and abbreviations 1.1 Purpose of the document 1.4 Overview of the document 2 Test Plan 2. walkthrough and technical review procedures.3 Test deliverables List the items that must be delivered before testing starts. 2.2 Definitions. 2.2 Definitions. acronyms and abbreviations 1.C-10 BSSC(96)2 Issue 1 DOCUMENT TEMPLATES C.
. measure.n. 3.3 Input specifications Describe the input for the test case. 5.BSSC(96)2 Issue 1 DOCUMENT TEMPLATES C-11 3 Test Case Specifications (for each test case.1 Test case identifier Give a unique identifier for the test case. proceed.2 Description List the items being tested.n. 5 Test Report template 5.) 3. 4 Test Procedures (for each test procedure. 3. 5. stop. 4. Describe the problems.n. List the test cases this procedure executes. 4.5 Environmental needs Describe the test environment. setup. who did it.n.n.n. shut down.1 Test procedure identifier Give a unique identifier for the test procedure..3 Procedure steps Describe how to log.2 Purpose Describe the purpose of the procedure.n. wrap-up the test. Say when the test was done.n. . restart. 3. and who witnessed it..2 Test items List the items to be tested.1 Test report identifier Give a unique identifier for the test report.n.. 3.) 4. and how to handle contingencies.n. start.3 Activity and event entries Identify the test procedure.n.4 Output specifications Describe the output required from the test case. Say whether the software passed or failed each test case run by the procedure.
C-12 BSSC(96)2 Issue 1 DOCUMENT TEMPLATES .
Documents Similar To Esa Practices for Small Sw Prjt Bssc962
SE Lecture4 Ch5-6 Req
RE - SRS Template
Change-Control-Request-Template-Instructions.doc
Srs_template - Uidb
Standardization of Information Systems Development Processes and Banking Industry Adaptations
CIA 3 RBA
05 Domain Requirememts Usecase Analysis
IEEE_SRS
MELJUN CORTES JEDI Slides-7.9 Software Configuration Management
OO Concept Chapt1
10135 Integrity v6
MediocreRCA_V6
Upload 28.doc
Topic 03 Scope WBS
Session-1 - Intro to BA-1
Defect Elim
Audit Observation-BEFORE AFTER
More From jgonzalezsanz8914
A Bayesian Model for Controlling Software Inspections Sw_inspection
Fraunhofer IESE Interview Systems Engineering in the IoT Era
Hardware Project Management 8p Drechsler_breiter_icsoft2007
Raytheon_Control of Product Manufacturing Processes for Suppliers and Outside Production
Creativity Toolkit for New Product Development
ASQ SQP Software-reuse-Antipatterns-revisited 2017 SET 12P
EOI Fundamentos del Lean Manufacturing 12P.pdf
Abbreviated C++ Code Inspection Checklist Baldwin-inspect
Monte Carlo Simulation For Statistical Physics Coddington P .pdf
Creativity Toolkit For New Product Development.pdf
FDA Design Control Guidance 1997 53p
Applying_Iso_Iec_9126-1_Quality_Model_To_Q Req_Eng On_Critical_Software.pdf
Tesis 1997 Design and Implementation of Cellular Manufacturing 83p
Gestión Clínica Para Oftalmólogo1
Breve Compilacion Normas
Agile Cmmi 2006
A Comparative Study of Cost Estimation Models for Web Hypermedia Applications (Mendes)
•Configuration Management Standard
6SIGMA10fehlmann Slides
CMMI n2 n3 Comparison Iso 9001 2000
An Exceptionally Simple Theory of Everything - A Garrett Lisi [2007 - 31pp] Good !
Español_BCN_SEV_VLL_Secret_gmv1XXXX-aa_vN_OfertaCompleta.docx
STAR Critical Design Review Check List v3.0
An Ontology-Based System for the Marketing Information 2006 ... - Clic-cimec 9P
05_Competitividad_Ind_Sw.pdf
Baldrige Health Care Free Sample 2013 2014
Value Stream Mapping V1 JGS