Reliability is often measured with time to failure (TTF) or number of failures in a given time period
Reliability is about continuing offering services despite faults happening
A system may require high availability but low reliability, and vice versa
Example: aeroplane auto-land system
Both reliability and availability should be tied to particular services
Different services may have different requirements for reliability and availability
Reliability / availability scenarios
Example reliability / availability scenarios
An incorrect external message is received by a process. The process informs the operator of the receipt of the message, discards the message and the system continues to operate with no downtime.
While writing summary statistics to database, the system receives an exception indicating that database is full. The system should immediately stop processing the statistics set, log fatal message and shut down.
The processor hardware that the process runs on fails. The process should be switched to a new processor without any loss of data and within 15 minutes.
Activities for availability
Capture availability requirements and schedule
Types of services
Levels of services
Required schedule for services
Estimate platform availability
Hardware: may utilise published MTTF rates
OS, network, middleware: more difficult to estimate than for hardware
E.g. watchdog, heartbeats/pings, monitors, exceptions etc.
Message / input checks
Redundancy, both software and hardware
Hardware clustering and load balancing
Backup of data, state rollback, use of transactions
Switch levels of service
Establish a strategy for design-level solutions
Error and exception handling
Safety = absence of catastrophic consequences to the user(s) and the environment
These consequences may involve injuries or deaths
Example: embedded software in cars
Safety is addressed by identifying possible conditions of the system (hazards) that may lead to undesirable consequences (mishaps)
Example hazard: ABS ceases working properly
Example mishap: a car falls off the road
Mishaps are prevented by preventing hazards
Capturing and achieving safety requirements is often similar to reliability
Within your group, identify services and levels of services in the system.
Identify some faults that could be critical for dependability point of view. Try to write at least one appropriate scenario.
Security = the capability of the software to protect information so that unauthorised persons or systems cannot read or modify them and authorised persons or systems are not denied access to them (ISO/IEC 9126, 2001)
Security is divided into the following attributes
Confidentiality = protection of unauthorised disclosure
Integrity = protection of unauthorised modification
Availability = protection from denial of service to authorised users
Accountability = capability of tracing actions unambiguously to the actor
Compared to performance and reliability, security has no clean quantitative measures
Assets, threats, countermeasures
Security is about protecting assets (information, services)
Security is about threats that could be targeted to assets
Threats exploit vulnerabilities in the system or in the organisation
Threats materialise in the form of attacks
Example security scenarios
A third party component attempts to modify information it is not authorised to modify. The attempt is prevented by restricting third party components’ freedom of execution.
A student attempts to exploit an application that has been left unattended. This is prevented by locking the application after a certain elapsed time and requiring authentication to a locked application.
A thief has gained physical access to the mobile device. Unwanted incidents are reduced by encrypting sensitive information stored on the device.
A cracker tries to log in into an authenticated service by brute-force guessing. The attempt is prevented by using non-transferable authentication tokens (e.g. biometric authentication).
Capturing requirements with misuse cases
Activities for achieving security
Identify sensitive assets
Define security policy
Who can access what (access control)
Identify threats to the system
Design security implementation
For each threat, design a way to migitate them
Design a detection and recovery approach for security policy breeches
For selected technologies, assess and integrate them
Prevent / resist attacks
Authenticate principals (how, with what)
Authorise access (access control)
Limit exposure, e.g. hide services
Limit access, e.g. single access point
Compartmentalisation, e.g. sandboxing
Obfuscation, e.g. cryptography
Fairness, e.g. bandwidth throttling
Limit unwanted consequences
Recover from attacks
Restoration, e.g. redundancy
Within your group, identify some sensitive assets and threats to the system.
Try to construct a scenario that addresses some threat.
Maintainability = the ease with which a software system can be maintained
May address activities before the first release and after it
Maintainability is probably the most architecturally sensitive quality attribute
Maintainability is determined by how functionality is divided
If changes can be localised into one or few components, they are often easier to implement
Maintainability is often specified by specifying the change requests that may be targeted to the system
For each change request, the response of the system is the required change
How many components are changed / added / deleted?
What is the cost of implementing the change request?
How long does it take to implement the change request?
Also the probability of change requests should be anticipated
More probable or frequent changes should be easier to implement
Maintainability is typically achieved by adding indirection or abstraction
Activities for achieving maintainability
Characterise the evolution needs
Type of change required
Magnitude of change required
Likelihood of change
Timescale of required changes
Assess the current ease of evolution
Evaluate also whether support for evolution is needed
Flexibility doesn’t come without a cost
Preparing for changes that never occur is a major waste of resources
Compare to XP, which doesn’t anticipate any particular change
Abstraction and generalisation
Decompose system elements with clear responsibilities
Avizienis, Algirdas; Laprie, Jean-Claude; Randell, Brian and Landwehr, Carl. Basic Concepts and Taxonomy of Dependable and Secure Computing. IEEE Transactions on Dependable and Secure Computing, 1(1), 2004.
Bass, Len; Clements, Paul and Kazman, Rick. Software Architecture in Practice. 2nd edition. Addison-Wesley, 2003.
Folmer, Eelke and Bosch, Jan. Architecting for Usability: A Survey. Journal of Systems and Software 70, 2004.
ISO/IEC 15408-1. Information technology – Security techniques – Evaluation criteria for IT security – Part 1: Introduction and general model. ISO/IEC Standard 15408-1, 1999.
ISO/IEC 9126-1. Software engineering – Product quality – Part 1: Quality model. ISO/IEC Standard 9126-1:2001, 2001.
Matinlassi, Mari and Niemelä, Eila. The Impact of Maintainability on Component-based Software Systems. Proc. of EUROMICRO Conference (EUROMICRO’03). 2003.
Rozanski, Nick and Woods, Eoin. Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Addison-Wesley, 2005.
Smith, Connie and Lloyd, William. Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software. Addison-Wesley, 2002.