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

CIS 573 Computer Aided Verification PowerPoint PPT Presentation


  • 112 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 573Computer 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

  • 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

  • Custom

  • `Shrink Wrapped’

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


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

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


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


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

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

Institutional Standards


ISO---International Organization for Standardization

IEC---International Electrotechnical Commission

ITU---International Telecommunication Union

International Standards Organizations


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


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


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


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


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


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


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

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


Case Study

The European Space Agency

Software Engineering Standard


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


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


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

  • User Requirements

  • Software Requirements

  • Architectural Design

  • Detailed Design and Production

  • Transfer

  • Operations and Maintenance


People

Software Project Management

Quality Assurance

Software

Configuration Management

Verification and Validation

Procedure Standards


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


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


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!


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


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


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


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


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


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


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


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


Evolutionary Design Approach

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


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

usually ignore quality, reliability, maintainability and safety requirements.

Prototyping


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


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

  • 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

Who are the `users' of the software?

Is it assumed that hardware requirements are already known?


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

Identifier

Need

Priority

Stability

Source

Clarity

Verifiability


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

  • Construction of Logical Model.

  • Specification of software requirements.

  • Technical review.


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

Functional

Performance

Interface

Operational

Resource

Verification

Acceptance testing


Classification, part 2

Documentation

Security

Portability

Quality

Reliability

Maintainability

Safety


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


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


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


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


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


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


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


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


Construction of the Physical Model.

Specification of the Architectural Design.

Selection of Programming Languages.

Technical review and walkthrough.

Activities


Functional Decomposition

Jackson Development System

Object-Oriented Design

Major AD Approaches


User Requirements

Software Requirements

Architectural Design

Detailed Design and Production

Transfer

Operations and Maintenance

Product Standards


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


Detailed Design

Production

Coding

Integration

Testing

Technical review, inspection, walkthrough.

Activities


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


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


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


Installation.

Acceptance testing.

Provisional acceptance.

Activities


User Requirements

Software Requirements

Architectural Design

Detailed Design and Production

Transfer

Operations and Maintenance

Product Standards


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


Final acceptance

Maintenance

Activities


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.


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


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

  • Organizing

  • Setting objectives and priorities

  • Managing risk

  • Choosing tools and methods (`technical management')

  • Planning, scheduling, and budgeting

  • Reporting


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

  • 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

  • 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

  • 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.)


Case Study

ISO 9000

Computer

Software


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

  • 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

  • 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

  • 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

  • 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


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

  • 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

  • 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

  • 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

  • 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

  • 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


Contingency Factors


Size 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, Cont.


Environment Productivity Figure


Sample Calculation Figure


Scheduling Differences

  • Definitions of project phases

  • Software methods used

  • Product types being developed

  • Programmer skill levels

  • Degrees of urgency


TRW Scheduling Data Figure


Martin Marietta Scheduling Data Figure


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)

  • 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.


Activities

  • Management

  • Documentation

  • Standards, practices, conventions, and metrics

  • Reviews and audits

  • Testing activities

  • Problem reporting and corrective action


Activities, Continued

  • Tools, techniques and methods

  • Code and media control

  • Supplier control

  • Training

  • Risk management


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

  • “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

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.


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

  • 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


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).


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.


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

  • Reviews.

  • Tracing.

  • Testing.

  • Formal proof.


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

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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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.


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

  • 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

  • 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

  • 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

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

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


Limits of Formal Specification

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

  • However, precision can aid validation.


  • Login