Cis 573 computer aided verification
Download
1 / 143

CIS 573 Computer Aided Verification - PowerPoint PPT Presentation


  • 136 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' CIS 573 Computer Aided Verification' - ramya


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, Assurance in Design, Development, Production, Installation and Servicing.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 Assurance in Design, Development, Production, Installation and Servicing.: 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 specification languages.

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 specification languages.

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 man-years of effort.: 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 man-years of effort.

  • User Requirements

  • Software Requirements

  • Architectural Design

  • Detailed Design and Production

  • Transfer

  • Operations and Maintenance


Procedure standards

People man-years of effort.

Software Project Management

Quality Assurance

Software

Configuration Management

Verification and Validation

Procedure Standards


Classes of standard practices

Mandatory man-years of effort.: 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 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.'’

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 and defines the activities in the phases. (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 and defines the activities in the phases. (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 and defines the activities in the phases. (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 terminology) was the earliest software `process model'.


Plan to throw one away
Plan to Throw One Away terminology) was the earliest software `process model'.

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: terminology) was the earliest software `process model'. 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 terminology) was the earliest software `process model'.


Evolutionary design approach
Evolutionary Design Approach terminology) was the earliest software `process model'.

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 central aspect of its approach is based on a `non-linear' view of the software lifecycle.

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 central aspect of its approach is based on a `non-linear' view of the software lifecycle.

  • 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 central aspect of its approach is based on a `non-linear' view of the software lifecycle.

Who are the `users' of the software?

Is it assumed that hardware requirements are already known?


Classification of user requirements
Classification of User Requirements central aspect of its approach is based on a `non-linear' view of the software lifecycle.

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 central aspect of its approach is based on a `non-linear' view of the software lifecycle.

Identifier

Need

Priority

Stability

Source

Clarity

Verifiability


Esa contents2

Product Standards central aspect of its approach is based on a `non-linear' view of the software lifecycle.

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 central aspect of its approach is based on a `non-linear' view of the software lifecycle.

  • Construction of Logical Model.

  • Specification of software requirements.

  • Technical review.


Software requirements phase
Software Requirements Phase central aspect of its approach is based on a `non-linear' view of the software lifecycle.

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 central aspect of its approach is based on a `non-linear' view of the software lifecycle.

Functional

Performance

Interface

Operational

Resource

Verification

Acceptance testing


Classification part 2
Classification, part 2 central aspect of its approach is based on a `non-linear' view of the software lifecycle.

Documentation

Security

Portability

Quality

Reliability

Maintainability

Safety


Challenge of specifying software
Challenge of Specifying Software central aspect of its approach is based on a `non-linear' view of the software lifecycle.

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 central aspect of its approach is based on a `non-linear' view of the software lifecycle.


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


Process Algebras specifing software requirements. Here are a few that are ISO standards or DIS's: 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 left at the same time?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 left at the same time?

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. left at the same time?

Specification of the Architectural Design.

Selection of Programming Languages.

Technical review and walkthrough.

Activities


Major ad approaches

Functional Decomposition left at the same time?

Jackson Development System

Object-Oriented Design

Major AD Approaches


Product standards1

User Requirements left at the same time?

Software Requirements

Architectural Design

Detailed Design and Production

Transfer

Operations and Maintenance

Product Standards


Esa contents4

Product Standards left at the same time?

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 left at the same time?

Production

Coding

Integration

Testing

Technical review, inspection, walkthrough.

Activities


Testing

Unit tests left at the same time? 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 left at the same time?


System tests

System tests should include such activities as: left at the same time?

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 left at the same time?

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. left at the same time?

Acceptance testing.

Provisional acceptance.

Activities


Product standards2

User Requirements left at the same time?

Software Requirements

Architectural Design

Detailed Design and Production

Transfer

Operations and Maintenance

Product Standards


Esa contents6

Product Standards left at the same time?

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 left at the same time?

Maintenance

Activities


Esa on warranties
ESA on Warranties left at the same time?

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 left at the same time?

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 left at the same time?

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 left at the same time?

  • Organizing

  • Setting objectives and priorities

  • Managing risk

  • Choosing tools and methods (`technical management')

  • Planning, scheduling, and budgeting

  • Reporting


Project management documents
Project Management Documents left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

ISO 9000

Computer

Software


Process maturity levels

Case Study left at the same time?

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 left at the same time?


The first two maturity levels
The First Two Maturity Levels left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?


Size measures
Size Measures left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?


Contingency factors
Contingency Factors left at the same time?


Size estimation1
Size Estimation left at the same time?


Productivity estimation
Productivity Estimation left at the same time?

  • 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 left at the same time?


Relative productivity cont
Relative Productivity, Cont. left at the same time?


Environment productivity figure
Environment Productivity Figure left at the same time?


Sample calculation figure
Sample Calculation Figure left at the same time?


Scheduling differences
Scheduling Differences left at the same time?

  • 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 left at the same time?



Esa contents9

Product Standards left at the same time?

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) left at the same time?

  • 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 left at the same time?

  • Management

  • Documentation

  • Standards, practices, conventions, and metrics

  • Reviews and audits

  • Testing activities

  • Problem reporting and corrective action


Activities continued
Activities, Continued left at the same time?

  • Tools, techniques and methods

  • Code and media control

  • Supplier control

  • Training

  • Risk management


Esa contents10

Product Standards left at the same time?

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 left at the same time?

  • “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 left at the same time?

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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?


Scm30
SCM30 left at the same time?

  • 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 left at the same time?

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 left at the same time?

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 left at the same time?

  • Reviews.

  • Tracing.

  • Testing.

  • Formal proof.


Reviews
Reviews left at the same time?

  • 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 left at the same time?

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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • ``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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

  • 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 left at the same time?

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

  • However, precision can aid validation.


ad