Standards

• What is a standard?

• What are the benefits of using a standard?

• What are the costs?

• Do the costs exceed the benefits?

Definition of standard

A technical specification or other document available to the public, drawn up with the cooperation and consensus or general approval of all interests affected by it, based on the consolidated results of science, technology and experience, aimed at the promotion of optimum community benefits

» British Standards Institute, 1981

Standards are checklists

• (like a pilot’s checklist)

• Remind you of things you may forget

• Force you to acknowledge the consequences of not doing one of the tasks on the standard

• Don’t build the list from scratch: use one built by hundreds or thousands of professionals

Standards outside SE

• measures (gallons, liters, mm)

• sizing (electrical plugs)

Comparison of Standards

safe pushchairs safe software

Internal Product

External Product

ProcessResource

Comparison of Standards

• Other engineering:– guidelines for

product evaluation– guidelines for

acceptable outcomes

• Software engineering– guidelines for

process– guidelines for

techniques– few guidelines for

product evaluation

Software Engineering Standards

• Technical specifications available to public

• Consensus, but not necessarily of all affected parties (usually by committee)

• Not necessarily based on science, technology, or experience – Language standards w/o case studies– Techniques (clean room, OO design) w/o science

Example: 1228-1994 IEEE Standard for Software Safety

Plans• Abstract: The minimum acceptable requirements

for the content of a software safety plan are established. This standard applies to the software safety plan used for the development, procurement, maintenance, and retirement of safety-critical software. This standard requires that the plan be prepared within the context of the system safety program. Only the safety aspects of the software are included. This standard does not contain special provisions required for software used in distributed systems or in parallel processors

Example: 1008-1987 (R1993) IEEE Standard for Software Unit Testing

1. Scope and References2. Definitions3. Unit Testing Activities3.1 Plan the General Approach, Resources, and Schedule.3.2 Determine Features To Be Tested3.3 Refine the General Plan3.4 Design the Set of Tests3.5 Implement the Refined Plan and Design3.6 Execute the Test Procedures3.7 Check for Termination3.8 Evaluate the Test Effort and Unit

Partial list of standards610.12-1990 IEEE Standard Glossary of Software Engineering

Terminology 1062, 1998 Edition IEEE Recommended Practice for Software

Acquisition 1228-1994 IEEE Standard for Software Safety Plans1233, 1998 Edition IEEE Guide for Developing System

Requirements Specifications 730-1998 IEEE Standard for Software Quality Assurance Plans828-1998 IEEE Standard for Software Configuration

Management Plans

Partial list of standards1008-1987 (R1993) IEEE Standard for Software Unit Testing 1012-1998 IEEE Standard for Software Verification and

Validation 1028-1997 IEEE Standard for Software Reviews1045-1992 IEEE Standard for Software Productivity Metrics 1058-1998 IEEE Standard for Software Project Management

Plans1074-1997 IEEE Standard for Developing Software Life

Cycle Processes1219-1998 IEEE Standard for Software Maintenance

Partial list of standards1540-2001 IEEE Standard for Software Life Cycle

Processes--Risk Management1061-1998 IEEE Standard for a Software Quality Metrics

Methodology 829-1998 IEEE Standard for Software Test Documentation830-1998 IEEE Recommended Practice for Software

Requirements Specifications1016-1998 IEEE Recommended Practice for Software

Design Descriptions 1044-1993 IEEE Standard Classification for Software

Anomalies

Classification of standards

• Reference only:

• Subjective

• Partially Objective

• Objective

Classification of standards

• Reference only: – declares something will happen, but there is no

way to determine compliance– “Unit testing shall be carried out.”

• Subjective

• Partially Objective

• Objective

Classification of standards

• Reference only:

• Subjective– Only a subjective measure of conformance is

possible– “Unit testing shall be carried out effectively.”

• Partially Objective

• Objective

Classification of standards

• Reference only:

• Subjective

• Partially Objective– A measure of conformance, but still has

subjectivity– “Unit testing shall be carried

• Objective

Classification of standards

• Reference only:

• Subjective

• Partially Objective

• Objective– Conformance can be determined– “Unit testing shall be carried

Four categories of SE Standards• Process

– The Design Team shall validate the Software Specification by ...

• Internal Product– e.g. code: “each module should have a single

entry and exit

• External Product– e.g. reliability

• Resources

Motivation for standards

• Provide encapsulation of best practice

• Avoid repetition of past mistakes

• Provide framework for quality assurance (assure that standard has been followed)

• Assist in continuity between workers

Standards organizations

• IEEE

• ANSI

• US DoD

• NATO

• Bureau of Standards

How to use standards

• Understand the motivation behind the development of the standard

• Involve developers• Adapt standard to meet needs of organization• Review standards regularly and update to reflect

changing technology• Provide software tools when possible. Clerical

standards are a source of complaint

• “In many modern standards, the only truly mandatory activity is tailoring the standard to your particular needs.”

» Lewis Gray

Walkthrough of DO178B

• Software Development Standard for avionics

• Handbook for problem areas of software development

• Catalog of certification requirements

FAA Certification

• The FAA certifies systems, not software

• Software tools are either trusted or untrusted

• The product of a trusted tool is trusted.

Software Criticality LevelsCriticality

Level

Failure

Consequence

Example

A Catastrophic Auto pilot

B Hazardous navigation system

C Major navigation assist system

D minor

E no effect in-flight entertainment

DO178B Process

• Planning

• Requirements

• Design

• Coding

• Integral Processes

DO178 Process: Planning

• Languages: syntax, naming conventions, coding conventions, bounds on term complexity, indentation standards ...

• Tools: which tools, which subsets, ...

• Hardware: may be very stringent

• Methods

DO178B Planning

• Describe tasks needed to meet task objectives, such as code reviews, walkthroughs, change control, audits,

• Describe when processes occur, when processes exit, and who is responsible

DO178B Design

• How will requirements be satisfied?• Need

– architecture– algorithms/data structures– I/O Description– Data and control flow descriptions– Resource strategies– Scheduling and communication

DO178B Coding

• Implement low-level requirements

• Integration: load software onto target

• Cannot patch software: need to recertify entire system (expensive)

DO178B Integral ProcessRequirements-basedtest generation

Low-leveltests

AdditionalVerification

Integrationtests

Hardware integrationtests

Requirements coverageanalysis

Requirements coverageanalysis

DO178B Testing

• MCDC: Every atomic predicate is tested

• last 5% of test cases are difficult to generate

• Rockwell: 30% of development budget is in structural testing

DO178B Tools

• Must certify for each system: previous qualification efforts don’t transfer

• Qualify the tool or qualify the output?

• Qualifying a verification tool is easier than qualifying a synthesis tool

Evaluating Software Engineering Standards (Pfleeger, 1994)

• What is a good standard?

• What do the standards apply to?

• What was the case study?

• What did the authors find in the case study?

• Teams of 2

Assignment: Project teams

• Find 2 IEEE standards and give 1 page summary of the standard (include references)

• Find 2 “programming standards”– Summarize the standards– Compare and contrast the two standards

• Develop a coding standard for your team• Due 3/24