CIS 573 Computer Aided Verification

1. CIS 573Computer Aided Verification Carl A. Gunter Fall 1998 Part 2

2. How is Software Built? • Learn by building. • Knowledge captured in standards. • Many to choose from! • We will examine PSS-05-0, the software engineering standard of the European Space Agency.

3. References • C. Mazza, J. Fairclough, B. Melton, D. de Pablo, A. Scheffer, and R. Stevens. Software Engineering Standards. Prentice Hall, 1994. • Available online from course web page. • C. Mazza, J. Fairclough, B. Melton, D. de Pablo, A. Scheffer, and R. Stevens. Software Engineering Guide. Prentice Hall, 1996.

4. Classes of Software • Custom • `Shrink Wrapped’ • Most critical software follows custom design standards; these will be our principle concern.

5. Standards for the Software Industry • Computer software standards are less advanced than computer hardware standards at the present time. • Successful development of the software industry depends on (and is currently driven by) progress in software standardization.

6. Standard Defined A standard is a document, established by concensus and approved by a recognized body, that provides for common and repeated use, rules, guidelines, or characteristics for activities or their results aimed at an achievement of the optimum degree of order in a given context. Note---Standards should be based on the consolidated results of science, technology, and experience aimed at the promotion of optimum community benefits. ISO/IEC Guide 2

7. De jure: standards created by a body empowered by concensus to formulate standards. De facto: products that have gained market acceptance and are recognized as the product against which others will be compared. Regulatory: standards that have been accepted by the government and have a legal force behind them and governmental ability to force acceptance and use. Source: Encyclopedia of Computer Science. Types of Standards

8. Internal standards: procedures internal to a company or government body. Procurement standards: standards of an institution concerning its contractual relations with others. Institutional Standards

9. ISO---International Organization for Standardization IEC---International Electrotechnical Commission ITU---International Telecommunication Union International Standards Organizations

10. Each of these international organizations has a committee concerned with information technology. Joint Technical Committee on Information Technology (JTC1). Joint committee of ISO and IEC. ITU Telecommunications (ITU-T, formerly CCITT) Information Technology Committees

11. ISO/IEC8652:1995, Information technology --- Programming languages --- Ada. ISO/IEC9794-8, Information technology --- Open Systems Interconnection --- The Directory: Authentication framework. Better known as ITU-T Rec. X.509 Examples of Interface Standards

12. ISO 9001:1994, Quality Systems --- Model for Quality Assurance in Design, Development, Production, Installation and Servicing. ISO 9000-3:1991, Quality Management and Quality Assurance Standards --- Part 3: Guidelines for the the Application of ISO 9001 to the Development, Supply and Maintenance of Software. Examples of Quality Control Standards

13. ANSI/IEEE Std 754-1985, Binary Floating-Point Arithmetic. IETF RFC 793, Internet Protocol. J. Postel, 1981. IEFT RFC2068, Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. January 1997. ANEP: Active Network Encapsulation Protocol, S. Alexander, C. A. Gunter, A. D. Keromytis, G. Minden, D. Wetherall, B. Braden, A. W. Jackson. Other Standards

14. Secretariat: non-volunteer portion of the standards group responsible for administering the organization. Working Groups: volunteers (typically industry and government representatives) engaged in standards development. Example: the American National Standards Institute (ANSI) is the secretariat for JTC1. People in Standards Preparation

15. Example: ISO standards working group for formal specification languages. Technical Committee JTC1 Sub-Committee SC22: Programming Languages, Their Environments and System Software Interfaces. Working Group WG19: Formal Specification Languages. ISO Organization

16. Example: ANSI standards technical committee for specification languages. Accredited Standards Committee (ASC) NCITS (formerly X3): Information Technology. Technical Committee Class J: Languages. Technical Committee J21: Formal Description Techniques. ANSI Organization

17. The Documentary Hypothesis Amid a wash of paper, a small number of documents become the critical pivots around which every project's management revolves. These are the manager's chief personal tools. Brooks

18. Case Study The European Space Agency Software Engineering Standard

19. The European Space Agency is a consortium formed by European governments for the development of a commercial space program. PSS-05-0 is their standard for software engineering. It was developed out of experience from the US Apollo missions. Our course reading is a generalized version of the standard from which space-specific material has been removed. Hereafter `ESA' refers to PSS-05-0 and this generalized standard. PSS-05-0

20. It is intended for software projects involving 5 to 50 man-years of effort. It defines no specific contractual boundaries. It is now used by a variety of companies and government organizations. It is a project standard, not an organizational standard. Use of ESA

21. Product Standards: software to be defined, implemented, operated, and maintained. Procedure Standards: procedures which are used to manage a software project.Appendices: summaries, tables, forms and checklists of mandatory practices. Structure of ESA

22. Product Standards • User Requirements • Software Requirements • Architectural Design • Detailed Design and Production • Transfer • Operations and Maintenance

23. People Software Project Management Quality Assurance Software Configuration Management Verification and Validation Procedure Standards

24. Mandatory: These must be followed, without exception, in all software projects. Recommended: These are strongly recommended; if not followed, a justification must be given. Guideline: No justification is required if not followed. Classes of Standard Practices

25. These priorities are indicated by the verbs `shall', `should', and `may'. Examples from ESA: ``The products of a software development project shall be delivered in a timely manner and be fit for their purpose.'’ ``Procedures for handling new requirements should be established at the beginning of the project.'’ ``Software requirements may require the construction of prototypes to clarify or verify them.'’ Mandatory practices are numbered in an appendix. For instance, fitness for intended purpose is SLC01. Indicating Priorities

26. The ESA standard is unreadable without knowing the meaning of several dozen acronyms. Fortunately they are listed on a page near the end. Those Acronyms!

27. ``Up to the end of the TR phase, the formal review meeting is a UR/R, SR/R, AD/R or DD/R, depending on the document. In the OM phase the formal review is conducted by the SRB. Templates for RID, DCR and DSS forms are provided in Appendix E.'’ ``During the DD phase, the TR phase section of the SQAP shall be produced (SQAP/TR). The SQAP/DD shall cover in detail all the quality assurance activities to be carried out in the DD phase.'’ Examples

28. Product Standards User Requirements Software Requirements Architectural Design Detailed Design and Production Transfer Operations and Maintenance Process Standards Software Project Management Quality Assurance Configuration Management Verification and Validation ESA Contents

29. A life cycle model structures project activities into phases and defines the activities in the phases. A life cycle approach is a combination of the basic phases of the life cycle model. SLC03: All software projects shall have a life cycle approach which includes the basic phases shown in Figure 1.1. ESA Life Cycle

30. UR (User Requirements) The problem definition phase: determine the needs of the users by interviewing or surveying them. Ask them questions or obtain reactions to a prototype. SR (Software Requirements) The analysis phase: describe what the software has to do, and not how to do it. Life Cycle Phases, 1 of 3

31. AD (Architectural Design) Define the structure of the software: determine components, their inputs and outputs, and the control flow between them. Select a programming language. DD (Detailed Design and Production) Use the selected programming language to divide the components into modules and/or classes; produce implementations of components; do verification and testing. Life Cycle Phases, 2 of 3

32. TR (Transfer) Build deliverables and carry out provisional acceptance (validation) tests with end-user. OM (Operations and Maintenance) Place software into practical use. Correct bugs during warranty period. Life Cycle Phases, 3 of 3

34. The waterfall model (`waterfall approach' in ESA terminology) was the earliest software `process model'. The choice of phases differs in various standards and organizations. The model has been widely criticized as too monolithic because communication backwards between phases is often needed. It seems best-suited to solving well-understood problems. The Waterfall Model

35. The Waterfall Approach

36. Plan to Throw One Away For most projects, the first system built is barely usable: too slow, too big, too hard to use, or all three. Plan to throw one away; you will, anyhow. Brooks

37. Incremental Approach: There is a staged delivery of components or functions. Evolutionary Approach: Multiple releases are provided. This approach is well-suited to prototyping. Alternatives to the Waterfall Approach

38. Incremental Delivery Approach

39. Evolutionary Design Approach The “DEV” box is equivalent to the UR, SR, AD, DD, and TR phases.

40. Prototypes usually implement high risk functional, performance or user interface requirements and usually ignore quality, reliability, maintainability and safety requirements. Prototyping

41. Another model that emphasizes risk identification as a central aspect of its approach is based on a `non-linear' view of the software lifecycle. The `spiral model' is due to Barry Boehm (1988). It has a widely-recognized picture. Spiral Model

43. Product Standards User Requirements Software Requirements Architectural Design Detailed Design and Production Transfer Operations and Maintenance Process Standards Software Project Management Quality Assurance Configuration Management Verification and Validation ESA Contents

44. Activities • Capture of User Requirements: Involve criticism and experience with existing software. Use interviews and surveys. • Determination of Operational Environment: Account for the real world in which the software is to operate. • Specification of User Requirements: Write down the user requirements. • Technical review of User Requirements Specification.

45. Questions about the ESA Standard Who are the `users' of the software? Is it assumed that hardware requirements are already known?

46. Classification of User Requirements Capabilities needed by users to solve a problem or achieve an objective. Constraints placed by users on how the problem is to be solved or the objective achieved.

47. Attributes of User Requirements Identifier Need Priority Stability Source Clarity Verifiability

48. Product Standards User Requirements Software Requirements Architectural Design Detailed Design and Production Transfer Operations and Maintenance Process Standards Software Project Management Quality Assurance Configuration Management Verification and Validation ESA Contents

49. Activities • Construction of Logical Model. • Specification of software requirements. • Technical review.

50. Software Requirements Phase SR02 The developer shall construct an implementation independent model of what is needed by the user. SR03 A recognized method for software requirements analysis shall be adopted an applied consistently in the SR phase. SR08 Each software requirement shall be verifiable.