Dependability

From

Jump to: navigation, search

Contents

Justify trust in a program.

  • Prevent faults from being introduced during development.
  • Design a program to tolerate faults.
  • Find and remove faults from a program.
  • Characterize failure modes and predict their occurrence.

Judge a computer system by ethical standards.

  • Expect ethical, social impact, decolonizing, and anti-oppression goals in a system specification.
  • Conceptualize unethical use as an attack, i.e. an oppression fault.
  • Consider development-time ethical faults including programmer treatment and classism in the workplace (maintenance staff vs. programmers).
  • Justify correctness through the frame of Aristotle’s ethos, pathos, logos.
  • Identify Tussle relevant to a program and isolate it using modularity.
  • Distinguish attackers by ethical categories as in the Byzantine/Altruistic/Rational model.
  • Incorporate contributions by members of marginalized communities.

Craft specifications that define program correctness.

  • Create specifications that thoughtfully reflect consideration of the purpose of a program.
  • Discuss the intended utility of a program to humans.
  • Predict ethical considerations of a program in use.
  • Distinguish between correct and dependable code and systems.

Reason about a program and its possible executions.

  • Use formal reasoning to create code that is correct by construction, or to verify aspects of existing code.
  • Justify the way a program is decomposed, by analyzing an existing set of modules to describe its benefits and drawbacks, by arguing for why a decomposition was designed the way it was, and by improving a decomposition when warranted.
    • separation of concerns
    • Parnas
    • Tussle
  • Distinguish safety and liveness properties (e.g. partial correctness, termination) and prove that a program satisfies a property.
  • Apply formal methods of structured programming such as analyzing pre- and post-conditions and using predicate transformers.

Write a program that is secure against malicious attack

  • Distinguish a system from its environment and identify their common plane, the system boundary.
  • Compare the actual behavior of a system and its intended function.
  • View the total state of a system as including internal state and external state.
  • View a system as a structure of components, perhaps recursively structured, until it rests on components whose internal structure is unknown or uninteresting and are considered atomic.

Debug a program.

  • Use static analysis tools, such as compilers and linters.
  • Recognize common static errors, including syntax errors, and recall common solutions.
  • Use dynamic analysis tools, such as interactive debuggers and profilers.
  • Simulate a program’s steps mentally or in writing to peform snapshot analysis and predict behavior.
  • Run a program under a debugger to observe computations and isolate unexpected behavior.
  • Add assertions and logging to a program to observe computations and isolate unexpected behavior.

Test a program.

  • Interact with a program in order to confirm expected behaviors and attempt to trigger faults.
  • Write an automated test to confirm an expected behavior or correct handling of exceptional conditions.
  • Combine automated tests into a test suite.
  • Perform unit testing by writing automated tests that isolate each program module.
  • Perform test-driven development by writing tests for requirements before modifying a program to satisfy those requirements.

Write a program that handles errors during execution gracefully.

  • Recognize common runtime errors.
  • Distinguish logic errors, such as a programmer’s mistake, from exceptional conditions, such as a file not existing.
  • Detect and handle exceptional conditions within a program by return type, exceptions, etc.

Maintain a program.

  • Modify a program’s source to add or subtract features.
  • Modify a program to work in another environment.
Personal tools
MediaWiki Appliance - Powered by TurnKey Linux