Transcript Responsibilities - Index

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
External Product
Process
Resource
Internal Product
safe pushchairs
safe software
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 References
2. Definitions
3. Unit Testing Activities
3.1 Plan the General Approach, Resources, and Schedule.
3.2 Determine Features To Be Tested
3.3 Refine the General Plan
3.4 Design the Set of Tests
3.5 Implement the Refined Plan and Design
3.6 Execute the Test Procedures
3.7 Check for Termination
3.8 Evaluate the Test Effort and Unit
Partial list of standards
610.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 Plans
1233, 1998 Edition IEEE Guide for Developing
System Requirements Specifications
730-1998 IEEE Standard for Software Quality
Assurance Plans
828-1998 IEEE Standard for Software Configuration
Management Plans
Partial list of standards
1008-1987 (R1993) IEEE Standard for Software
Unit Testing
1012-1998 IEEE Standard for Software Verification
and Validation
1028-1997 IEEE Standard for Software Reviews
1045-1992 IEEE Standard for Software Productivity
Metrics
1058-1998 IEEE Standard for Software Project
Management Plans
1074-1997 IEEE Standard for Developing Software
Life Cycle Processes
1219-1998 IEEE Standard for Software Maintenance
Partial list of standards
1540-2001 IEEE Standard for Software Life Cycle
Processes--Risk Management
1061-1998 IEEE Standard for a Software Quality
Metrics Methodology
829-1998 IEEE Standard for Software Test
Documentation
830-1998 IEEE Recommended Practice for Software
Requirements Specifications
1016-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 Levels
Criticality
Level
A
Failure
Example
Consequence
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 Process
Requirements-based
test generation
Low-level
tests
Integration
tests
Requirements coverage
analysis
Additional
Verification
Requirements coverage
analysis
Hardware integration
tests
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