Object-Oriented Programming

Software Design Characteristics

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron

Software Design Characteristics

  • compatibility (interoperability)
  • fault-tolerance
  • reliability
  • usability
  • performance (efficiency)
  • scalability
  • robustness
  • extensibility
  • modularity
  • maintainability
  • reusability
  • security
  • portability

Compatibility (Interoperability)

The software can operate with other products designed for interoperability. For example, a piece of software may be backward-compatible with an older version of itself.

  • Scenario:
    1. v1 of a software release with v1-era data files
    2. Upgrade to v2
  • Questions
    • Are v1-era data files readable?
    • Direct use, or conversion?
    • Can v2-era data files be used with v1?


Developers can add new capabilities to the software without significant changes to the underlying architecture.

  • Are new input formats quickly added?
  • Changing the existing source code - white-box extensibility
  • Changing nothing about the existing source code - black-box extensibility


The software comprises well defined, independent components. This independence leads to better maintainability. The components could then be implemented and tested in isolation before being integrated to form a desired software system. Isolation before integration allows the division of work in a software development project.

  • Units of modularity depend on the level of design
  • For our purposes, think of classes. Can we test each class individually?
  • What is in each class?


The software is resistant to and able to recover from component failure.

  • Can we continue operations even with diminished resources?


A measure of how easily developers can make bug fixes or functional modifications. High maintainability can be the product of modularity and extensibility.

  • Can we easily maintain the current functionality?

Reliability (Software durability)

The software can perform a required function under stated conditions for a specified time.

  • Every time we run it, we expect a result in the time expected
  • Counterexample: Every time we run the program, we get a different result


Some or all aspects of the software are usable in other projects with little to no modification.

  • Often focused on, but not always the most crucial characteristic.
  • Much over design is from too much focus on reusability.


The software can operate under stress or tolerate unpredictable or invalid input. For example, a design can be resilient to low memory conditions.

  • Programs depend on resources: memory, disk space, file handles, etc.
  • Can it continue to operate with reduced resources?


The software can withstand and resist hostile acts and influences.

  • Most common are through the inputs
  • Does the design allow for the inputs to be verified?


The software user interface must be usable for its target user/audience. Default values for the parameters are a good choice for the majority of the users.

  • This is not just the end-user interface, but even our APIs


The software performs its tasks within a time-frame that is acceptable for the user and does not require too much memory.

  • Considers both time and space (memory used)
  • “Acceptable” time is based on requirements


The software should be usable across many different conditions and environments.

  • If the software is too tightly bound to a particular operating environment, it might not work in others.


The software adapts well to increasing data or the number of users.

  • scale up Increased resources to handle an increase in demand
  • scale out Increase number of instances to handle an increase in demand