Cis 573 computer aided verification
This presentation is the property of its rightful owner.
Sponsored Links
1 / 143

CIS 573 Computer Aided Verification PowerPoint PPT Presentation


  • 92 Views
  • Uploaded on
  • Presentation posted in: General

CIS 573 Computer Aided Verification. Carl A. Gunter Fall 1998 Part 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. References.

Download Presentation

CIS 573 Computer Aided Verification

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Cis 573 computer aided verification

CIS 573Computer Aided Verification

Carl A. Gunter

Fall 1998

Part 2


How is software built

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.


References

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.


Classes of software

Classes of Software

  • Custom

  • `Shrink Wrapped’

  • Most critical software follows custom design standards; these will be our principle concern.


Standards for the software industry

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.


Standard defined

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


Types of standards

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


Institutional standards

Internal standards: procedures internal to a company or government body.

Procurement standards: standards of an institution concerning its contractual relations with others.

Institutional Standards


International standards organizations

ISO---International Organization for Standardization

IEC---International Electrotechnical Commission

ITU---International Telecommunication Union

International Standards Organizations


Information technology committees

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


Examples of interface standards

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


Examples of quality control standards

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


Other standards

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


People in standards preparation

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


Iso organization

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


Ansi organization

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


The documentary hypothesis

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


Cis 573 computer aided verification

Case Study

The European Space Agency

Software Engineering Standard


Pss 05 0

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


Use of esa

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


Structure of esa

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


Product standards

Product Standards

  • User Requirements

  • Software Requirements

  • Architectural Design

  • Detailed Design and Production

  • Transfer

  • Operations and Maintenance


Procedure standards

People

Software Project Management

Quality Assurance

Software

Configuration Management

Verification and Validation

Procedure Standards


Classes of standard practices

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


Indicating priorities

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


Those acronyms

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!


Examples

``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


Esa contents

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


Esa life cycle

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


Life cycle phases 1 of 3

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


Life cycle phases 2 of 3

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


Life cycle phases 3 of 3

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


The waterfall model

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


The waterfall approach

The Waterfall Approach


Plan to throw one away

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


Alternatives to the waterfall approach

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


Incremental delivery approach

Incremental Delivery Approach


Evolutionary design approach

Evolutionary Design Approach

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


Prototyping

Prototypes usually implement high risk functional, performance or user interface requirements and

usually ignore quality, reliability, maintainability and safety requirements.

Prototyping


Spiral model

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


Esa contents1

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


Activities

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.


Questions about the esa standard

Questions about the ESA Standard

Who are the `users' of the software?

Is it assumed that hardware requirements are already known?


Classification of user requirements

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.


Attributes of user requirements

Attributes of User Requirements

Identifier

Need

Priority

Stability

Source

Clarity

Verifiability


Esa contents2

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


Activities1

Activities

  • Construction of Logical Model.

  • Specification of software requirements.

  • Technical review.


Software requirements phase

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.


Classification part 1

Classification, part 1

Functional

Performance

Interface

Operational

Resource

Verification

Acceptance testing


Classification part 2

Classification, part 2

Documentation

Security

Portability

Quality

Reliability

Maintainability

Safety


Challenge of specifying software

Challenge of Specifying Software

The difficulty of specifying what software is intended to do is a dirty little secret of the software industry.

This problem pervades experience with both technical and commercial aspects of software.

One would like to see something like an architect's blueprints for software, but such a successful formalism has not yet emerged.

Notations and pictures can be more harmful than helpful.


Pictures can be misleading

Pictures can be Misleading


Recognized specification languages

The CS literature describes a wide variety of languages for specifing software requirements. Here are a few that are ISO standards or DIS's:

Telecommunications languages: SDL, Lotos, Estelle.

`Model-based' languages: VDM, Z.

Lotos and Estelle are derived from process algebras. We will look at one such algebra.

Recognized Specification Languages


Cis 573 computer aided verification

Process Algebras are algebraic formalisms for describing concurrency, communication, non-determinism, and resources.

Communicating Sequential Processes (CSP) is one of the best-known process algebras. It was introduced by Tony Hoare.

Another well-known process algebra, due to Robin Milner, is Calculus of Communicating Systems (CCS).

There are now many process algebras under study. We will look at a specific problem using CSP.

Case Study

CSP


Dining philosophers

The problem was introduced by Edsgar Dijkstra; it epitomizes a collection of issues important to concurrent computation.

We will use the problem to illustrate formal specification (using CSP) and rigorous proof of safety from deadlock.

Let us assume that there are 5 philosophers and 5 forks. We describe the problem informally at first.

Dining Philosophers


Dining philosophers described informally

Actions the philosophers can take: sit down, get left fork, get right fork, put down left fork, put down right fork, stand up.

They lead a simple life: thinking and eating.

They do not communicate directly with one another.

They interact only through their contention over forks!

Dining Philosophers, Described Informally


Dining philosophers in deadlock

What if all of the philosophers pick up the forks on their left at the same time?

No right forks will be available so all 5 philosophers will wait.

The result is deadlock, a situation in which progress cannot be made because of interlocking resource contention.

Dining Philosophers in Deadlock


Rigor

How can we treat this problem rigorously so we will be able to characterize it precisely and recognize when it has been solved?

Code it in C. Too many extraneous details.

Describe it mathematically. But, what kind of mathematics?

We require a suitable applied mathematics of computing.

Rigor


Esa contents3

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


Activities2

Construction of the Physical Model.

Specification of the Architectural Design.

Selection of Programming Languages.

Technical review and walkthrough.

Activities


Major ad approaches

Functional Decomposition

Jackson Development System

Object-Oriented Design

Major AD Approaches


Product standards1

User Requirements

Software Requirements

Architectural Design

Detailed Design and Production

Transfer

Operations and Maintenance

Product Standards


Esa contents4

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


Activities3

Detailed Design

Production

Coding

Integration

Testing

Technical review, inspection, walkthrough.

Activities


Testing

Unit tests verify the design and implementation of all components from the lowest level defined in the DD up to the lowest level defined in the AD.

Integration tests verify that major components interface correctly.

System tests verify compliance with system objectives as stated in the SRD.

Acceptance tests verify compliance with system objectives as stated in the URD.

Testing


Production of test documentation

Production of Test Documentation


System tests

System tests should include such activities as:

passing data into the system, correctly processing and outputing it;

practice for acceptance tests;

stress tests;

preliminary estimation of reliability and maintainability;

verification of the Software User Manual.

System Tests


Esa contents5

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


Activities4

Installation.

Acceptance testing.

Provisional acceptance.

Activities


Product standards2

User Requirements

Software Requirements

Architectural Design

Detailed Design and Production

Transfer

Operations and Maintenance

Product Standards


Esa contents6

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


Activities5

Final acceptance

Maintenance

Activities


Esa on warranties

ESA on Warranties

The early part of the OM phase should include a warranty period in which the developer should retain responsibility for correcting errors. The end of the warranty period is marked by final acceptance.

ESA at page 48.


Esa contents7

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


Esa contents8

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


Activities6

Activities

  • Organizing

  • Setting objectives and priorities

  • Managing risk

  • Choosing tools and methods (`technical management')

  • Planning, scheduling, and budgeting

  • Reporting


Project management documents

Project Management Documents

  • SPMP The Software Project Management Plan is the controlling document for the management of the project.

  • PHD The Project History Document explains deviations between estimates and actuals.


Esa potential risks

ESA Potential Risks

  • Quality and stability of user requirements

  • Level of definition and stability of external interfaces

  • Adequacy and availability of resources

  • Availability and quality of tools

  • Staff training and experience

  • Definition of responsibilities

  • Short time scales

  • Technical novelty of the project


Topics to be covered

Topics to be Covered

  • Software metrics will be discussed in two parts: cost and quality.

  • Material will be drawn from SEI maturity model literature.

  • Organization, staffing, and tracking will be discussed only indirectly.

  • Our topic in this section is cost estimation.


Organizational standards

Organizational Standards

  • The ESA standard is a project standard. It describes the approach to be taken for an individual project without direct reference to other projects.

  • Organizational standards include criteria relating projects. They may be applied to whole companies or to specific teams.

  • The ISO 9000 series and the SEI process maturity levels are examples.

  • The goal is to provide sellers a way to convince buyers of quality. (Or, to shift to a negligence standard of liability.)


Iso 9000

Case Study

ISO 9000

Computer

Software


Process maturity levels

Case Study

Process Maturity Levels

  • The SEI framework is based on the idea that organizations have achieved a level of maturity that can be determined by an assessment.

  • The assessed level of maturity aids the organization in determining its priorities for improvement.

  • Maturity is founded on the concept of statistical control.


Process maturity levels1

Process Maturity Levels


The first two maturity levels

The First Two Maturity Levels

  • Initial Until the process is under statistical control, orderly progress in process improvement is not possible. While there are many degrees of statistical control, the first step is to achieve rudimentary predictability of schedules and costs.

  • Repeatable The organization has achieved a stable process with a repeatable level of statistical control by initiating rigorous project management of commitments, costs, schedules, and changes.


Cost estimation

Cost Estimation

  • Effective cost estimation is essential for project success in a commercial context.

  • Cost estimation is difficult for software, but this doesn't make it less necessary. It is assigned as a managment responsibility in the ESA standard.

  • Cost estimation is generally attempted after the software specification phase.

  • SPM06: An estimate of the total project cost shall be included in the SPMP/AD.


The mythical man month

The Mythical Man-Month

  • More programming projects have gone awry for lack of calendar time than for all other causes combined.

  • Our estimating techniques, built around cost-accounting, confuse effort and progress. The man-month is a fallacious and dangerous myth, for it implies that men and months are interchangeable.

  • Partitioning a task among multiple people occasions extra communication effort---training and intercommunication.

  • Source: Brooks


Size estimation

Size Estimation

  • Start with as detailed a product structure as is technically possible.

  • Precisely define the standard of measurement.

  • Estimate the size of each product element.

  • Sum these elements to produce a total estimate.

  • Apply appropriate contingencies.


Work breakdown structures

Work Breakdown Structures

  • A WBS is a semi-formal way to break down a goal hierarchically into simpler work elements.

  • The breakdown generally has two parts: product structure and process structure.

  • Size estimates are made for each of the product elements.


Wbs for compiler

WBS for Compiler


Size measures

Size Measures

  • There are two popular measures

    • LOC: Lines of Code based on source text.

    • Function Points: Weighted measure of functional requirements.


Counting lines of code

Counting Lines of Code

  • For given code, what should we count?

  • Executable lines

  • Executable lines plus data definitions

  • Executable lines, data definitions, and comments

  • Physical lines on an input screen

  • Logical delimiters (eg. semicolons)


Counting lines of code continued

Counting Lines of Code, Continued

  • What body of code should be counted?

  • Only new lines

  • New and changed lines

  • New, changed, and reused lines

  • All delivered lines plus temporary scaffolding

  • All delivered lines, temporary scaffolding, and support code


Problems with loc

Problems with LOC

  • There is no semantic content to code size. In many cases the metricis misleading and may do harm.

  • Searching through a library to find reusable code takes time, but gratuitous use of library code may bloat target code size.

  • Good coding involves finding abstractions that reduce code size. Benefits may lie in maintenance and quality.

  • Tools may aid solving a problem quickly while increasing or decreasing code size.


Function points

Function Points

  • The function point method is based on experimental results from business applications.

  • It is based on the counting items and assigning weights:

  • Adjustment of 25% on the total is at the discretion of the estimator.


Wideband delphi estimation technique

Wideband Delphi Estimation Technique

  • Given a measure, a procedure is needed for obtaining an estimate.

  • A group of experts is given the specifications.

  • They meet to discuss the product.

  • They anonymously complete estimation forms.

  • The results are tabulated and returned.

  • Estimates of others are kept anonymous.

  • They meet again to discuss their results.

  • Cycle continues until estimates converge adequately.


Delphi estimation form sample

Delphi Estimation Form Sample


Contingency factors

Contingency Factors


Size estimation1

Size Estimation


Productivity estimation

Productivity Estimation

  • Programmer productivity shows wide variation.

  • Multi-project data may offer a reasonable basis for estimation.

  • There is wide variation in productivity based on the nature of the product.

  • Productivity of staff are influenced by many factors; cause and effect may be difficult to separate.


Relative productivity

Relative Productivity


Relative productivity cont

Relative Productivity, Cont.


Environment productivity figure

Environment Productivity Figure


Sample calculation figure

Sample Calculation Figure


Scheduling differences

Scheduling Differences

  • Definitions of project phases

  • Software methods used

  • Product types being developed

  • Programmer skill levels

  • Degrees of urgency


Trw scheduling data figure

TRW Scheduling Data Figure


Martin marietta scheduling data figure

Martin Marietta Scheduling Data Figure


Esa contents9

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


Software quality assurance sqa

Software Quality Assurance (SQA)

  • From ANSI/IEEE Std 730-1989: SQA is “a planned and systematic pattern of all actions necessary to provide adequate confidence that the item or product conforms to established technical requirements”.

  • ESA quality assurance activity is the process of verifying that the ESA standard is being applied.


Activities7

Activities

  • Management

  • Documentation

  • Standards, practices, conventions, and metrics

  • Reviews and audits

  • Testing activities

  • Problem reporting and corrective action


Activities continued

Activities, Continued

  • Tools, techniques and methods

  • Code and media control

  • Supplier control

  • Training

  • Risk management


Esa contents10

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


Definition and standards

Definition and Standards

  • “Configuration management is the art of identifying, organizing, and controlling modifications to the software being built by a programming team.” (Babich)

  • Configuration management is different from maintenance.

  • MIL-STD-943 is the DoD CM standard.

  • The ESA CM standard is similar to the ANSI/IEEE Std 828-1990.


Esa requirement scm01

ESA Requirement SCM01

All software items, for example documentation, source code, object or relocatable code, executable code, files, tools, test software and data, shall be subjected to configuration management procedures.


Activities8

Activities

  • Identification: name and identify items.

  • Item storage: control libraries.

  • Change control: evaluate proposed changes and coordinate implementation of approved changes.

  • Status accounting: track and report configuration items status.

  • Release: transfer appropriate items to user.


Scm23 25

SCM23-25

  • To ensure security and control of the software, at a minimum, the following software libraries shall be implemented for storing all the deliverable components (e.g. documentation, source and executable code, test files, command procedures):

    • SCM23 Development (or Dynamic) library;

    • SCM24 Master (or Controlled) library;

    • SCM25 Static (or Archive) library.


Libraries

Libraries


Scm30

SCM30

  • Software Problem Report (SPR).

  • Software Review Board (SRB) assigns the SPR for analysis.

  • Suggested changes are reported in a Software Change Request (SCR).

  • The SRB reviews the SCR and assigns responsibility for implementation if appropriate.

  • Software Modification Report (SMR).


Ast tool set activities

Case Study

AST Tool Set Activities

  • Build: generate executables, libraries, documentation, and so on from source files.

  • Test: test, debug, and improve the source.

  • Install: place generated files in public directories.

  • Package: collect source or gnerated files for use on other systems.

  • Bootstrap: build and install on other systems, possibly in the absence of AST tools.

  • Version Management: manage multiple versions of software.


Esa contents11

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


Activities9

Activities

  • Reviews.

  • Tracing.

  • Testing.

  • Formal proof.


Reviews

Reviews

  • Review standards in ESA are very similar to those in IEEE/ANSI Std 1028-1928. This latter standard describes:

    • Technical reviews

    • Software inspection

    • Walkthroughs

    • Management reviews

    • Audits


Verification by reading

Verification by Reading

Product

Project

Technical

Review

Testing

Software

Inspection

Management

Review

Simulation

Formal

Verification

Walkthrough

Audit

From the IEEE Standard for Software Reviews and Audits


Esa perspective

ESA Perspective

  • Technical reviews are recommended at the UR, SR, AD, and DD phases.

  • Walkthroughs are recommended for the SR, AD, and DD phases.

  • Inspections are recommended for the SR, AD, and DD phases.

  • Audits are required as part of the SQA procedure.


Technical review

Technical Review

  • Objective is to evaluate a software element and provide management with evidence that:

  • The element conforms to its specification.

  • The development (or maintenance) is being done according to plans, standards, and guidelines for the project.

  • Changes to the element are properly implemented and affect only those system areas identified by the change specification.


Software inspection

Software Inspection

  • Objective is to detect and identify software element defects. This is a peer examination that:

  • Verifies that the software element(s) satisfies its specifications

  • Verifies that the software element(s) conforms to applicable standards

  • Identifies deviation from standards and specifications

  • Collects software engineering data

  • Does not examine stylistic issues


Software inspection continued

Software Inspection, Continued

  • A software inspection is conducted by a group of 3 to 6 peers of the author(s) of the software.

  • Roles: moderator, reader, recorder, inspector(s), author. The moderator cannot be the author.

  • Reader leads the inspection team through the software.


Walkthroughs

Walkthroughs

  • The objective of a walkthrough is to evaluate a software element.

  • The scope of the evaluation is more general than that of a technical review.

  • Better implementation approaches are considered.

  • The walkthrough also includes exchanges of techniques and style variations, and education of the participants.


Walkthroughs continued

Walkthroughs, Continued

  • The author makes an overview presentation of the software.

  • This is discussed with his audience.

  • The author then `walks through' the software in detail.


Traceability

Traceability

  • SVV01 Forwards traceability requires that each input to a phase shall be traceable to an output of that phase.

  • SVV02 Backwards traceability requires that each output of a phase shall be traceable to an input to that phase.


Testing1

Testing

  • ``The amount of time spent in testing software is frequently underestimated.'' (ESA on page 75)

  • Testing classes

    • Unit: DD test of DD

    • Integration: DD test of AD

    • System: DD test of SR

    • Acceptance: TR test of UR

    • Regression:Change at all phases


Testing activities

Testing Activities

  • Planning the general approach and allocating resources.

  • Detailing the general approach for various kinds of tests in a test design.

  • Defining the inputs, predicted results and execution conditions in a test case specification.

  • Stating the sequence of actions to be carried out by test personnel in a test procedure.

  • Logging the execution of a test procedure in a test report.


Formal proof

Formal Proof

  • The challenge of proving software correct has led to unrealistic expectations, controversy, and productive bursts of research activity for more than two decades.

  • For this discussion, let us distinguish between:

    • Rigorous proof to the the standards of a mathematician, and

    • Formal proof using logic.


Rigor and formality

Rigor and Formality

  • Two controversial claims:

    • Formality provides automated support for the creation of rigorous arguments and enforcement for standards of rigor.

    • Rigorous specifications are not difficult to formalize.


Formal specification and proof

Formal Specification and Proof

  • Specification (formally or rigorously) of correctness criteria, and

  • Proof (formally or rigorously) that the criteria are met.


Limits of formal specification

Limits of Formal Specification

  • A precise specification is not guaranteed to be correct from the UR perspective.

  • However, precision can aid validation.


  • Login